
Kazuki Chigita
Android Application Developer
Android Application Developer
Actions
An android application developer who is interested in application architecture, system design, and refactoring.
アプリアーキテクチャや設計、リファクタリングに興味がある Android エンジニア
Compose Runtimeの自作で学ぶRecompositionの仕組み
「Recomposition」とは、状態の変化に応じて、影響を受ける可能性のあるコンポーザブルを再実行し、UIに変更を反映させる仕組みです。これは従来のAndroid Viewシステムには見られない、Jetpack Composeにおける重要な概念の一つです。
Recompositionを適切に扱うには、その動作のタイミング、ルール、影響範囲(スコープ)など、関連する複数の概念を複合的に理解しなくてはなりません。この点が、特にCompose初学者にとって学習のハードルを上げる要因の一つとなっています。
このセッションでは、Recompositionの理解を深めるため、簡易的なCompose Runtimeをゼロから自作し、可能な限りコードを使って紹介します。これにより、Recompositionがどのように機能するのか、その本質を掴むことを目指します。
簡易的ですが、実際に動くランタイムを構築する経験は、公式ドキュメントを読むだけでは得難い、より深く具体的な理解へと繋がります。この実践を通して、Recompositionの仕組みが腑に落ち、パフォーマンス上の問題点を直感的に見抜くヒントが得られるかもしれません。
さらに、このセッションは、本物のCompose Runtimeがいかに広範な事柄を考慮し、多くの機能を提供しているかという驚きと再発見をもたらすでしょう。
Composeの核となるランタイムの自作を通して、Recompositionの概念を中心にJetpack Composeの設計思想を学び、その奥深い世界を探求しましょう!
セッション内容 (予定)
- Recompositionとは? 基本的な考え方
- コンポーザブル関数の登録と呼び出しの仕組み
- Recompositionの賢い制御 スキップの仕組み
- Recompositionのスキップ 型の不変性と安定性
- 副作用とRecomposition
- 状態の保持 rememberの仕組み
- 自作ランタイムでは触れない Compose Runtimeの高度な機能
build.gradle(.kts)再入門:基礎の学び直しと変化に強いビルド設定術
Androidアプリ開発を始めると、まず出会うのが `build.gradle` です。しかし、「各ブロックが何をしているのか」「この設定は本当に必要なのか」「なぜファイルが複数あるのか」など、次から次へと疑問が湧き、まるで暗号を解読するかのような感覚に陥る初学者の方も多いのではないでしょうか。
初学者以外にも、gradleはプロジェクトの進化と共に設定が複雑化しやすく、定期的な見直しが不可欠な要素です。gradleは常に進化し続けています。過去に一度設定した古い書き方や当時のワークアラウンドが残り続け、気が付かない間に標準的な設定からかけ離れた事になっていることは少なくありません。あるいは、プロジェクトの規模が大きくなればなるほどgradleファイルの整理が難しくなるという課題もよくある悩みの一つでしょう。
このセッションでは、そんなgradleのあれこれを、一度ゼロベースで学習し直します。また、セッションの後半では過去によく使用されていた書き方やtipsが現在どのように置き換えられたか、deprecatedになったかなどの現在と過去を比較するような内容に触れます。このセッションを通して、gradleの現在と過去の知識を整理し、未来の開発に活かせる確かな基盤を築くことを目指します。
Android "を" ビルドしてAndroid Systemを覗いてみよう
Android開発者の皆さんは日々Android アプリ (apk / aab) をビルドしていますが、Android"を”ビルドしたことがありますか?Andriodをベースとする組み込みデバイス等の開発に従事している方は、日常的にビルドしているかもしれません。
Androidはオープンソースでコードの大部分が公開されており、Androidそのものをビルドし、システムイメージを作ることが可能になっています。また、カスタムのカーネルをビルドし、それを前述のシステムイメージに埋め込むことも可能です。
システムイメージ・カーネルをビルドすること自体は普段のサービスアプリ開発において、役に立つ機会は少ないです。しかし、ただ何となくみていたAndroidシステムの挙動の裏側を鮮明に理解することができ、今後のアプリ開発に役に立つ機会がきっと来るでしょう。
本セッションでは、サービスアプリ開発者であるスピーカーの視点から主にアプリ開発者に向けて、Androidのシステムイメージのビルド方法、カーネルのビルド方法を Android Developers に記載されている行間を補完しながら step by stepで進めていきます。
その後、コードの一部を修正しながらAndroidシステムの動きに迫っていきます。
<予定しているアジェンダ>
- Android システムについての簡単な概要
- Android のビルド方法
- カーネルのビルド方法
- 実例1. Android システムを修正しながら確認する navigation bar の振る舞い
- 実例2 :Android システムを修正しながら確認する Dialog の振る舞い
DroidKaigiカンファレンスアプリの歴史からみるアプリアーキテクチャのこれまでとこれから
2016年から2021年にかけて、DroidKaigiではカンファレンスアプリが作成されてきました。各年、カンファレンスのセッション情報を閲覧できるAndroid(iOS)アプリとして、時の Android エンジニアがその時代の最先端の技術を駆使して設計・実装を進めたものです。そこにはたくさんの知見やベストプラクティスが散りばめられています。また、時代を先取りした技術選定にも例年注目が集まっています。
2016年のアプリはJavaで記述され、rx1系をメインとするデータフローの制御、Android Support Librariesを用いたUI構築を行っていました。最新の2021年のアプリでは、Kotlinで記述され、Kotlin coroutines を多く活用、マルチモジュール構成、Kotlin Multiplatformを活用した iOS アプリとのロジック共通化、JetpackComposeによるUI記述と、大きくトレンドは変化しています。
また、アプリアーキテクチャも回を重ねるごとにMVC、MVVM、Flux、MVI等と変化しています。
例年、カンファレンスセッション情報閲覧アプリとして作成されてきたため、提供される機能に大きな差はありません。そのため当時主流のアーキテクチャや設計ルール等はどのような時流で構築され、現在ではどのような技術に代替されたのかを知る事ができる良き題材と言えます。
アーキテクチャ変遷の歴史を知ることは、実務においても大きく役立ちます。特に息の長いアプリの開発を行っているときには、1. 古くから触られてきたクラスであり、手つかずである 2. deprecatedなメソッドを多用しているが適切な改修方法が不明瞭である といった歴史的背景という言葉で片付けられがちな課題に当たることも経験上多いです。
当時どのような背景のもと技術選定・アーキテクチャ選定が行われたのか、そしてその後の歴史を知ることで、違和感や課題に向き合い、現代風の適切なリファクタリングを行う道標を得ることができます。
本セッションでは、簡単に各年の実装を比較した後に、セッション情報取得・表示という機能に絞ってその実装方法の差分について紹介します。また、これからの Jetpack Compose や KMM 中心の未来のデファクトアプリ開発へ対応するためのヒントをカンファレンスアプリの実装から探っていきます。
予定アジェンダ
- DroidKaigiカンファレンスアプリ概要
- 各年の技術スタック・アーキテクチャの概要比較
- 技術の変遷について1 : rx -> coroutines / flow
- 技術の変遷について2 : xml layout -> Jetpack Compose
- 技術の変遷について3 : 状態保持
- 技術の変遷について4 : MVC -> MVVM -> MVI
- アプリアーキテクチャのこれから : 宣言的UIとマルチプラットフォームへの対応
- TBD
継続的に機能開発を進めながら行うマルチモジュール化
2017年頃からアプリケーションのマルチモジュール化による利点が多く得られるようになった.特に「差分ビルドのビルド時間短縮化」「InstantAppやDynamicFeatureModuleの導入可能」「モジュール依存関係グラフのDAG化」といった利点が語られる.これらの利点は肥大化したアプリケーション上で高速に開発を行う上での助けになったり,ユーザ体験を向上させる手助けとなったりする.
一方で,これまで大部分をアプリケーションモジュール(:app)で開発されてきたアプリケーションを,容易にマルチモジュール化することは難しい.特にMVVMやFluxといったルールを明確化したアーキテクチャに乗っていない場合は問題が顕著だ.また,並行してマルチモジュール化とは本質的に無関係な機能改善を進めていく必要がある場合,問題はさらにややこしくなる.
本セッションでは上に挙げた実体験を基にどのようにしてマルチモジュール化を進めていったのかを時系列順に,そのハマりどころと解決方法を中心に紹介する.
<アジェンダ(仮)>
- マルチモジュールとは何で,導入するとどう嬉しいのか?
- はじめの一歩は:appから:legacyへ
- ApplicationモジュールとLibraryモジュールの違いによって生じる問題
- Flavor,buildType,BuildConfigのマルチモジュールでの取り扱い
- 共通リソースのモジュール化とそのハマりどころ
- マルチモジュールとJetPack 〜どのようなライブラリの導入効果が高いのか〜
- 意味境界としてのモジュール分割 〜モジュール分割戦略〜
- 継続的な機能開発との共存法
- TBD

Kazuki Chigita
Android Application Developer
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top