DroidKaigi 2019 に行ってきた - まりぴよこのブログ

droidkaigi.jp

Android開発歴2年目にして、去年はヒヨって行けなかったDroidKaigi参加してきました。

忘れないうちに聞いてきたセッションの感想など ✏️

見てきたセッション 👀

マルチモジュールなプロジェクトでテストはどう変わる？

droidkaigi.jp

マルチモジュール、普通に見かけるようになってきたので。。（joinしたプロジェクトがそもそもマルチモジュール構成です！っての普通にあるもんなぁ・・）

差分ビルドや動作確認がモジュールで完結したりなど、マルチモジュールにはメリットがある。（最近のアプリはデカイので・・）

ただし色々ハマりポイントも。モジュール間の依存に気をつけないと、循環参照になってしまったり。

依存関係の構築はなるべくモジュールに閉じた形にしたい。

テスト方針としては

モジュール内テスト
モジュールをまたいだテスト

基本的にはテスト対象とやり取りするものをモックする

テストメトリクスは、モジュールごとに出るので、マルチモジュールプロジェクトの場合は結果をマージする。（gradleのタスクとか書いてマージ）

紹介されてた PIT というツール、良さそう。

pitest.org

Mutation test というのも初めて聞いた。「テストコードが正しいかを計測」してくれるらしい。境界値をわざと超えるようにコードを書き換えて、正しくFailするか調べる、みたいな感じ。

テストの世界奥深し 👀

マルチモジュールプロジェクトでのDagger2を用いたDependency Injection

droidkaigi.jp

やはりマルチモジュール。 Dagger2に今ひとつ苦手感のある私てきには外せぬ・・

DI Dagger2

どこに、なにをinjectするかを全て網羅する
- Module なにを 型とインスタンスの紐づけ
- Component どこに

マルチモジュールのDIで注意すること

ApplicationにInjectorを1つしか持てない
マルチモジュールで複数のInjectorを作ろうとすると、あと勝ちになって片方クラッシュする
解決するには、その1つしか持てないFragmentIngeatorに複数のInjectorを持つ（独自実装）
- 実際に欲しいInjectorを見けるまで探す（実装方針ざっくり）
Dynamic Feature module
- そもそも知らなかったのでよくわからなかったけど、依存関係が逆転する、らしい
- 呼び出すタイミングを変えてあげれば大丈夫

LiveData と Coroutines で実装する DDD の戦術的設計

droidkaigi.jp

午後イチの部。スーパー有名人あんざいさんの回なので、超満員。聞けてよかった。

DDDは多少知ってる・・くらいのにわか知識量だったので、サクサクと進むプレゼンに「あ〜今ちょっと巻き戻したい・・ ><」とかなりながら、必死に食らいつく状態でした・・（ビデオがあるさ・・）

あとで・・きっと・・ブログに書いてくれるはず〜・・・と期待しつつ、見てみたらやっぱあった！

y-anz-m.blogspot.com

DroidKaigi conference appを題材にしてて、わかりやすくてよかった。拙いながらもconference app contributeしてたから、親近感 :sparkles:

保存形式とモデルの表現が同じとは限らない

公募セッションではない、特殊なセッション（？）をどう扱っていくか、を考えていく過程など、ほーーなるほど〜〜という感じでとてもよかったです。

保存形式データの構造（サーバーレスポンス）をそのまま表現してよいのか？という、よく遭遇する課題感へのアプローチ方法が聞ける、素晴らしいチャンスやった。

Androidならでわな実装面の話ViewModel, Coroutinesなんかも出てきて、マジお腹いっぱい・・

いやほんと、これはマジビデオで再履修すべき濃い〜内容でした。

Master of Android Theme

droidkaigi.jp

Push通知の方に行くか、若干迷ったんだけど、やはり生こにふぁーさんを見に行かねば！と思ってこっちに。まさかのフル英語セッションでびっくりした（てよく見たら英語てアプリでも書いてあった）

themeとstyleなんやねん！いつ使い分けるん！とか困ってた一昨年の自分に見せてあげたい内容でした。にゃーたちが可愛かった。ナイトモードとか、結構サクッと入れられるんや〜と学ぶ。英語だったので、ヒアリング頑張って、ちょっと疲れた・・やっぱこにふぁーさん、挑戦の人て感じなんだな。💪

The good and bad of modern app architecture

droidkaigi.jp

Fast Retailingの人。英語ネイティブによる英語セッションだったので、残された英語を聞く力（だいぶ疲労で残されている力が少ない）を振り絞って頑張って聞いた。

ユニクロの系統アプリ（GUとか）いくつも扱える、巨大フレームワークっぽい感じ・・イチ開発者として入るのは結構大変そう・・（キャッチアップに5ヶ月かかるとか言ってて、そりゃキツイわってなった）

多分大勢で別々の工程を並行できるようにとか、ベースのフレームワークの設計とかこれは・・大変そう・・・という感じ。

別ブランドのアプリを統合的に扱うってむしろ辛そうとか思ったんだけど、世界に通じる大企業だと色々違うんだろう（なんか雑な感想）この辺で頭がだいぶ疲労で死にかかってた・・

Understanding Kotlin Coroutines: コルーチンで進化するアプリケーション開発

droidkaigi.jp

ひつじさんの素敵すぎるプレゼン。✨ 来てよかった・・・目から鱗がポロポロ落ちる感・・・😭✨✨

Coroutinesなんかわからんのよねを、聞いている人に寄り添う優しさで素晴らしい解説。

マジで・・素晴らしすぎ・・・

難しいことを優しく解説してくれる、の典型のような。

意図的に普通よりちょっとゆっくりに話してると思うんだけど、それがとても聞きやすい。聞いてる人が一生懸命ついてこようとしてること、をちゃんと理解してる感じ。聴衆の様子も把握してて、なんかもう。人に対するホスピタリティが素晴らしいのだなーとほんと感激した。

素晴らしい。（←何回め）

人前で話す機会はほぼない私ですが、何か機会があるときはひつじさんのプレゼンを思い出したい。

終わる頃には、「明日からコルーチン使う！！！！」って叫びたくなる感じでした。（実際コルーチン使うときにもっかい最初からフルでビデオを見直したいです・・）

コルーチン
- 中断可能（中断そして再開を提供）
  - suspend な関数で止まれる
- 軽量スレッドみたいなもんと言われる
- 自由度が高い
  - 継続 continuation 前の状態を引き継ぐ
- 非同期処理でもキャンセルできる
  - コルーチンスコープは箱庭
  - コルーチンは job を launch する（launch コルーチンを作るビルダー）
スレッド
- 中断できない
- 必ず終了しなければならない

並行と並列

コルーチンを使うとき（いつ使うと良いのか）

アプリの規模
開発効率化
拡張性
ライブラリ
キャッチアップコスト
メインスレッド止めない
関心の分離
- 単一責任
アプリ構造
- モジュール間通信
- MVVM

クロスプラットフォーム開発3種の神器 React Native / TypeScript / GraphQL

droidkaigi.jp

このところjs勉強してるので、ReactNativeにも興味を示している。ので覗いてきた 👀

はてなの人たちの「カクヨム」というアプリの話。

既存のAndroid Nativeアプリに、ReactNativeで新規画面を追加していくやつ。部分的な導入ができるのは良い。

クロスプラットフォーム (Android and iOS)
react native ネイティブのハイブリッド
- 既存ネイティブアプリに追加できる
JSX

iOSの方もネイティブに対して追加していく感じ。

リポジトリ戦略
- AndroidとiOS両方 monorepoにして合体
リリース戦略
- Android, iOSで別々に

ReactNativeを使う利点

react component作成が軽い
リスト向き
storybookでcomponentを随時確認できるの良い
UI構築が爆速
- ホットリロードがさらに良い

微妙だった点

Androidのデバッグビルドが重い
パフォーマンスチューニングがつらい
カスタムビューはあまり向かない
- React nativeのコンポーネントだけだとよい
React nativeのview pagerよくなかった
- 普通にやると、全ページ描画してしまう
- 遷移系は全てネイティブアプリ側で実装
query途中で止められない
- うまくやらないとAPIアクセスし過ぎてしまう
android studioのバージョンをホイホイ上げられない
iOSだと動くんだけど〜・・というコンポーネントがちょいちょいある
非常に稀だがたまにクラッシュ

Day1ここまで。

中規模以上のアプリ開発におけるCIレシピとリリースフロー戦略

droidkaigi.jp

CIで自動化されている素敵プロジェクトに入ることはあるけど、自分で整備したことはなくていつも「縁の下の力持ち、環境を整備してくれる人」に感謝して生きてる勢なのです。

でもCIっていつもお世話になってるし、自分でもいつかできるようにならねば・・！というモチベーションで行ってきた。

中規模＝2人以上　という感じだった。 1人でもこういうの面倒だから、あった方が良い。うん。

ブランチ戦略とかはGitFlowはわりかし馴染みがあるので、ウンウン納得！て感じで聞いてた。

~BitWise~ bitrise （サービス名、空耳アワーでまちがって覚えてた💦 twitterで正しいサービス名教えて貰えてありがたし🙏🙏）

https://www.bitrise.io/

というCIサービス結構良さそう。アプリに特化しているらしい。証明書サポートなどもある。

自分一人でアプリやるなら有効な選択肢になりそ。

CI
- テスト実行
  - いつでも
- staging apk
  - feature branchマージ時
- release (production apk)
  - master に release branch マージ、tagを打ったとき
CIのワークフロー
- ワークフローの再利用
  - 小分けにする
  - ワークフロー名で他から呼ばれて実行するとわかるようにするなど（BitWiseの場合 _ 始まりのワークフローは他からコールされるもの扱いになる）
  - 変数を切り出す（ワークフロー内のプロジェクトごとに変わるものを切り出しておく）

アプリの段階的公開

一部のユーザーからリリース（期間を開けて少しずつ増やす）機能
iOSの場合、期間・タイミング・比率など、一定で自動的にリリースされる
Androidは開発者が細かく指定できる
- カスタマイズできるのはいいが、結構手間かかる
- Androidは手動（忘れちゃうことがある）
  - google play developer apiで自動化すると良い

Guide to app architectureを踏まえた既存アプリの設計改良

droidkaigi.jp

既存アプリの課題分析、課題を解決していくアプローチなど、とても良い知見。見に行ってよかった。

楽天のフリマアプリ。

既存レガシーコードの設計改良
Viewが持つロジックのテストがない設計レベルでの強制がない
画面回転など Activity再構成へのアプローチ
場当たり的な技術導入画面ごとに違う設計（←こういうのはなかったと言ってたのでレガシーコードと言ってもかなりしっかり保守していたんだろうと思う）
Guide to app architecture
- recommended app architecture メイン
- conference app 2018 とても参考になった
- app components activityなど
App Architectureを更にちょうど良い感じでカスタマイズ・ルールを明確に
- ViewModel 拡張
  - instance state バックグラウンドでの破棄にも対応
- ViewModel - View間のやりとり明確に
Viewに反映するもの
- 揮発性イベント
  - snackbarなど、1回限り出したいもの
  - SingleLiveData イベント発行は一回だけ
  - イベントを複製できないので、複数observerが登録されると1つだけしか通知されない
- 不揮発性イベント
  - 状態を表す
  - 途中でActivityが破棄されたとしても、状態を保持したいし、変更を通知してほしい
  - DataBinding

Best practice for text on Android and its internals.

droidkaigi.jp

Google中の人によるTextViewのパフォーマンスなど。さすが中の人、めちゃくちゃプレゼン上手・・！

TextView & RecyclerView
意外と重いTextView
- systrace.py パフォーマンス計測
- UI threadで 1フレーム 16ms 越えると赤（フレーム落ちちゃう）
TextView.onMeasure が遅い 98%!!
- onMeasure とは。コンポーネントの幅、高さを測るやつ
- Textは諸々フォントやサイズ、スタイルなどを内部的に画像に変換、それから幅・高さを測る（←なるほど重そう）
ハイフネーション（英単語などを - で区切るやつ）かなり重い
- 特別な事情がなければOFFした方がいい
キャッシュがある（なるべくキャッシュに納めたい）
UIスレッドで重い処理なるべくやめる
- バックグラウンド！
バックグラウンドに回せない処理の場合、キャッシュを先に実行しておく
- PrecomputedText
- api28以上
- compat 版を使って（SDKのやつにはバグが・・）
getTextFuture
- RecyclerView prefetch
- RecyclerViewで新しいのが来るとき
- UIスレッドが重くなる
  - 事前にやってもこれらが重なると間に合わずにフレーム落ちる
  - api27までは同時に1スレッドしか処理してくれない（28で改善）

その他テキスト周りの新しめapi

Downloadable font
typeface.builder ttc
日本語、中国語などが合体
- indexでどれにするか指定
- api26以降
VariableFont
- 新しいのでまだ対応フォント少ない
- 普及すればすごく良い！
- weight,styleなど指定できる（フォントが対応してれば）
LocaleList
- カンマ区切りでロケールリスト渡せる英語、日本語みたいなオーダーで
- api 24以降
Serif Fallback
- ラテン意外もSerifあればだしてくれる
- api28以降
Justification
- whitespace で合わせる（英語など）
- api28以降
LineSpacing
- ビルマ語などめっちゃ背が高いフォント
- api28以降

SDK version upで色々恩恵あるんだなーと感動 ✨ GoogleIOのプレゼンを良い参考文献として紹介してたので、ちょっぴりIO気分になってみた ☺️

Android Vitals徹底活用

droidkaigi.jp

Android Vitalsなにそれ？な状態から聞き始め。。

GooglePlay - ユーザーに快適なアプリを公開するためのサービス
快適さを追求
- ユーザーに価値ある体験を届ける
- 致命的に体験を損ねない（クラッシュとか）←Vitalsが役立つ！
- パフォーマンス（ヌルヌル動くとか）←Vitalsが役立つ！
Vitalsがウオッチできること
- クラッシュレート
  - crashiticsとほぼ同じ
  - でもcrashitics初期化前のクラッシュみれる
リリース前レポート
- とても良い
- 数台の仮想機（？）でテストしてくれる
- デフォルトではなにも指定しなくてもPlayStore側がアプリのUIを解析してなんかいい感じにUI自動テストしてくれる
- roboscript で開発者が追加でテストを指定することもできる
- ただし結構重い（数時間かかることも）
  - リリース計画に関わることもあるので、計画的に！
ANR
- 起動時重い場合
- ライブラリなどが厄介な場合も。導入前に検討しておいた方がいい
- パフォーマンス改善の手がかりが見つけられる
パフォーマンス指標
- 起動時間分布
- レンダリング時間分布（16ms越え処理落ち）
- 分布が見れるだけで原因はわからない
- AndroidStudioのメソッドトレースで原因を地道に探す
  - ただし、メソッドトレース中遅くなる
  - 絶対値の実行時間は参考にならないので注意
- バックグラウンドに回せる処理を探す（かなり有効）
  - スレッドセーフでない処理は無理