起床
ViewPager っぽいけれど Fragment 用意するほどでもないときは RecyclerView と PagerSnapHelper の組み合わせでいいよね、と思っていたところにそれを実装した ViewPager2 が月面から降ってきた
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
休憩時間で少し触ってみて帰宅後エントリを書いた。
Gradle BOM importでライブラリバージョン管理 / DroidKaigi2019
バージョンを変数に纏めるならグループ ID も変数に纏めたくなる、わかる
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
まだまだ新しい（とくに Android 界隈では）やり方なので OkHttp 等の依存解決でしか使えないのかw #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
enforcedPlatform と force を頂上対決させたりすると読んでいる側としてもややこしくなるし、これらはやむを得ないときに使った方がいい、気がした #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
ライブラリのバージョンを変数に切り出すことはしていたけれど、同様に、重複して記述される GroupID も変数に切り出すことはやっていなかった。理はあると感じつつも、個人的には、ドキュメントに示されている依存解決の設定記述からコピペしやすいことも考慮に入れていた。が、GroupID を変数に置き換える程度はたいした労力を必要ともしないものではある。BOM の普及後もここは変わらないはずなので、地味なことかもしれないけれどちゃんと考えてあげたい。
Android Text The performance and features
systrace を使ったプロファイリング。Google Chrome のプロファイリングのような可視化がされるんだね。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
TextView だけが遅いのか？ Twitter っぽい一覧を作ってみてアイテムの描画速度を見てみると、Root.onMeasure 20,000 μsec のうち TextView.onMessure が 19,000μsec くらい占めている #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
なるほど。TextView に表示するテキストが1行に収まらないと判定したときは、じゃあ収まらなそうなこの単語を、どの文字で改行すれば収まるかな？ -> doLayout がその境界値を確かめるために何度もブン回りまくる、ということなのか。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
Hyphenation、必要なかったらオフ。PrecomputedText をつかえば最高。副作用もないよ！ #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
日本語 はhyphenation 対応していないのでオフにしても意味は無い、が、英単語にはもちろん聴く。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
「TextView は重い！」なんて考えたことも無かったので、あ、こんなに色々なことやってたんだと素直にびっくりした。TextView は、重いんですね。一見なめらかに動いているように見えるアプリでもちょちょっとカクつきが発生していることはある。何事にも言えることだけれど、ひとまず、計測して、何が原因か見極めてそれを直すのが、大事。
Android Vitals 徹底活用
Crashlytics が初期化される前のクラッシュ、Crashlytics が検知できないようなネイティブ層のエラーが取得できる、よい #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
Proguard で難読化したはいいけれど mapping.txt 上げ忘れたー！ はあるあるなので自動化されたリリース作業にはここらへん入れておきたい。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
僕は忘れたことあります。大変お恥ずかしい。
開発用実機って """高性能""" な端末を使っている事が多いのでロースペック、ミドルスペックな端末でのパフォーマンスが実は悪い、ということを見落とすこと、ある。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
ThreeTenBackport の https://t.co/4P3T0w2wDM() でメインスレッドをブロックするの勿体ない。のでバックグラウンド上でゾーン情報を初期化するように変更した。爆速になるわけではないが改善。 #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
「まず、ボトルネックを探す」、計測もせずに最適化の行動をするな、というやつ #droidkaigi #room3
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
今日から始める依存性の注入
「DI 使ってる人？」 → いっぱい
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
「DI に Dagger 使ってる人？」 → いっぱい
「『俺は Dagger を理解している』という人？」 → 皆無#droidkaigi #room1
依存オブジェクトの生存期間を表現するスコープ。例えば Repository はシングルトンでもいいのだけれど、Presenter は各画面の Activity と同じ生存期間でいてほしい。そういうときにスコープの考えを使う。 #droidkaigi #room1
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
マルチモジュールプロジェクト文化がじわじわ広まると「モジュール」のコンテキストややこしくなりそうだし、気をつけたい #droidkaigi #room1
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
Dagger2 で AAC ViewModel を注入するためのライブラリとしてはこういうものもあることを教えてもらった。 #droidkaigi #room1
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
evant/injectedvmprovider: Small lib to use easily use Android's ViewModels with a depedency injection framework like dagger https://t.co/U8Bbc16vzb
マルチモジュール Android アプリケーション
ははァん compile ではなく implemantation による依存解決であれば、変更が発生したときにコンパイルが必要になるのは直接依存しているモジュールだけで、間接参照している更に上のモジュールに影響は発生しないと、implemantation ええやん（今更知った） #droidkaigi #root2
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
なんとなくだけれど個人的には垂直方向モジュール分割（機能観点で分ける）のほうがしっくり来るかな。ここで考えられるのが、画面間の循環参照が発生すること。そこは common モジュールに用意したインタフェースを参照することにして、DI コンテナを使って注入する、という作戦。 #droidkaigi #room2
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
既存のモノモジュールをマルチモジュールにしていくにはボトムアップよりもトップダウンでやるのがよさそうかな #droidkaigi #room2
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) 2019年2月8日
マルチモジュール気になるという漠然とした感情がありつつ、はて、どうやって分けるのがいいのかなという知識がなかったのでとても参考になるお話だった。
ところでこのセッションもそうであるように、今年はマルチモジュールのセッションが予想よりも沢山あってすこしびっくりしました。プロダクトでの実例が実は結構あり、こうやって知見として公開されてきているとすると…自分の情報感度が鈍っている証拠なので、とても恥ずかしい気持ちです。
build.gradle.ktsに移行しよう
build.gradle.kts よさそうだけれど既存プロジェクトの移行はほんの少し色々やらなきゃいけない感じ #droidkaigi #room2
— バトルプログラマー柴田智也🔄🍣乙倉とよしのんと結婚した (@tomoya_shibata) February 8, 2019
個人的には *.gradle を弄っている最中、型情報や強力な IntelliSense、Syntax チェックが入るのは精神衛生的に良いのではと Gradle Kotlin DSL に好感を感じた。一方で、あくまでも build.gradle などを対象としたとき、毎日たくさん編集するかな？ そうではないのなら無理に Gradle Kotlin DSL である必要は薄いのかもしれない、という意見もあった。既存プロジェクトを想定とするのか、新規プロジェクトで考えてみるのかなど、様々な条件にも左右されそうな指標だと思う。そもそもとして、自分は Gradle Kotlin DSL を使って build.gradle を書いたことがなかったので発表資料も参考にして、どういうものかを手を動かして確認してみるつもり。
