#tech

2018年2月8日、9日の日程で開催された DroidKaigi 2018 に参加してきました。

技術的な詳細については、
後日、セッションのスライドや動画が公開されるようなので、
そちらを見ていただいたほうが正確です。

この記事では、私が参加したセッションの感想を書こうと思います。

内容について、
私が誤認していて、間違った捉え方をしたまま書いている部分もあるかもしれません。
気になるセッションがありましたら、
元になるスライドや動画を参照いただけますように、よろしくお願いします。

Day 1: 10:00 ~ ウェルカムトーク

最初におしゃれな動画が流れて、会場を盛り上げる。
このおしゃれな動画を用意するのに、どれくらいお金がかかるんだろうと
いらぬ心配をしてしまう。

DroidKaigi には、参加者に向けた専用アプリも作られている。
これにもすごい贅沢なリソースが割かれているのだなと、
いらぬ心配をしてしまう。

DroidKaigi 2018 は参加者、約1,000人。セッション数は 85 になった。

日本における１プラットフォームの主要な技術者は
1000 人程度と言うことなのかなという気もした。
（もちろん総人口はもっといるけど）

そう考えると、企業間のエンジニア争奪戦が
いかに熾烈なものとなるか、容易に想像できる気がした。

ウェルカムトークで感じた大きなことは、
Android 界隈において、
Java => Kotlin へのシフトが、
私が思っていた以上に大きなムーブメントとして捉えられているのだなと痛感した。

実際に会場で、アンケートされていたのだけど、
いま仕事で Kotlin を使っている人というのは、だいたい３割くらいだった。

DroidKaigi に足を運ぶような、
情報感度の高い人たちのなかで３割だから、
Android 業界全体で言うと、まだまだなんじゃないかなという気はした。

だけど、
Android 界隈でのオピニオンリーダー、
影響力の高い人たちが、声高に Kotlin を推進してるため、
これは思ったよりも早く、
Android における Kotlin の地位は上がってくるような実感があった。

Day 1: 10:20~ Kotlin アンチパターン by Naoto Nakazato

このセッションは、ウェルカムトークの後にすぐ大ホールで行われたので、
DroidKaigi 参加者は必修。

Kotlin は、もはや当たり前だよね圧力がすごい。

Nakazato (@oxsoft) さんは、HOT PEPPER Beauty 所属で Android 開発 7 年のベテラン。
内容としては Kotlin は言語仕様もかなり多様なので、
使っていく上での落とし穴などについての情報共有。

アンチパターンとして１０個ほど紹介してくださった。
Kotlin やってないので、あまりわからない話題が多かったが、
実際に Kotlin を触ることになったら、スライドを見直してみたい。

感想としては、Kotlin は null 安全が魅力的。
非常にモダンな言語だが、
多くある便利な機能を無理やり使うのではなく、
現場レベルでちゃんと取捨選択していく、議論していくのが大切なのだなと感じた。

Day 1: 11:20~ How to improve your MVP architecture and tests. by @kirimin

kirimin さんは paymo の開発に携わっている。
paymo は主要部分（90%）が Kotlin となっており、
アーキテクチャには MVP を採用。

MVP は Android Clean Architecture を参考にして生まれた。
MVP の勘所は、Activity を View と定義するところにある、と感じた。

Activity は MVC でいうところの
View - Controller の両方を持ってしまっている、
特殊な存在だ。

その Activity を View という概念に閉じ込めるための
方法論が MVP や MVVM などの
最近の Android のアーキテクチャの概念なのかなという感じがした。

MVP において Presenter の存在意義は、
Android のテストを書きやすくするという面にもあるようだ。

自動テストには３階層ある

UIテスト（Android では Espresso など、Instrumentation Test）
統合テスト（Android では Presenter 層のテスト、View は mockito でモック化、UnitTest）
Unitテスト（Android では Model 層のテスト、 UnitTest）

これはピラミット構造のように、下から順番に手厚く書かれているのが
理想的であるという話。
ただ Android では、先程の特殊な Activity の存在のせいで、
理想型のようにテストを書いていくというのが難しくなっている。
（paymo では実際のところ中間の presenter のテストが手厚くなっているらしい）

実際の仕事では、仕様変更やスピードを重視するために、
最初は手厚く書いていたテストであっても、
どんどん無効になっていったり、修正が追いつかなくなってくるテストが多い。

これについては、
テストコード自体の構造化をもっと進めるなどして、
テストコードを書く負荷を下げていく。
メンテナンスしやすいテストコードを書く方法を模索していく。

もうひとつは、Presenter 層の処理を、より Model 層へ落としていくことで
全体的に負荷が下がっていくのではないかという話だった。

セッションのあとで @kirimin さんに話をしにいってみた。
以前は@kirimin さんはフリーランスとして、いろいろな Android アプリ開発現場を
巡ってこられたそうなんだけど、
ちゃんとテストが書かれた Android アプリというのは本当に少なかったそう。

UI を持つアプリのテストというのは、
難しい課題なのだなということを、改めて認識しました。

Day 1: 12:50~ Android Back to the Future by mhidaka

Android の10年の歴史を振り返る。

Android でアーキテクチャの設計の議論が進んできた背景には、
どうしても Activity が肥大化してしまうという皆の共通課題があった。
Android で設計の議論が本格的に進んできたのは、ここ２，３年の話らしい。

いろいろな設計思想（MVP, MVVM, Flux など）が、それぞれ一長一短だと思われているのはなぜか？
設計思想を、具体的な Android の実装に落とし込んでいくと、
人によって解釈の違い、ちょっとした差異が生まれてしまう。
だれしもが、ある思想を正確に具体的な実装に落とし込んでいくというのは、難しいことなのだ。（チーム開発だし）

mhidaka さんは、とにかく、とにかく、トークが上手でした。

Day 1: 15:40~ 素晴らしいNDKの世界 / Building High Performance Android Apps with NDK by hak@, Gerry Fan

Google から。

NDK と言うものを、このとき初めて聞きました。
オーディオプログラミング、グラフィックス、またハードウェアに近い機能（カメラなど）の
ハイパフォーマンスな実装を可能とする SDK のようでした。

とにかく OpenGL より Vulkan を使えというお話（誘導）が印象に残っています。

NDK の紹介で終始されていましたが、
個人的に知らず勉強になった言葉が２つありました。

CPU Governor
サーマルスロットリング

前者は、CPU というのは常に全力疾走しているわけではなくて、
人間の使っている状況に合わせて、
ときには能力をセーブして動くような機構になっているということ。

後者は、熱暴走を回避するためのハードウェアの自己制限機能のことですが、
熱によって、アプリの性能が落ちてしまうという文脈でも使われるそう。

Day 1: マルチモジュールのすヽめ by @kgmyshin

わたしはこれまで、Android でマルチモジュール出来るということを知りませんでした。
ちなみに Android Studio から「New Module」で簡単に追加できますよ（♪）

マルチモジュールを採用する動機としては、
アプリ開発をしていたら、どんなアプリを作っていてもだいたい必要だよねという機能、
（例えばログイン・ログアウト機能とか、強制アップデート機能とか、ログ収集とか）
それをアプリ本体のモジュールから分離したいというところから始まった。

モジュール分割をするした上で、
具体的にどのような構造で作るのか、モジュール間の連絡をどのようにするのかなど、
具体的な話がありました。

いまのところモジュール分割をしないネガティブな理由としては、
DataBinding が、まだ若干モジュール分割に弱いところがあるというのが挙げられていました。
ただし、これは次第に解決されつつあるとのこと。

ただ、個人的にはちょっとモヤモヤした感覚はあって、
これが当たり前になっていくかというと、そうでもないかもしれないなという感想でした。
自分の案件で検討する場合は、よく事前に調べて見る必要はあるかなと思いました。

以下、Day2 に入ります。

Day 2: 12:50~ React Native Androidはなぜ動くのか by nkzn

React Native の内部実装についてかなり詳しくお話されており、
わたくしには正直、ほとんどわかりませんでした。

Day 2: 14:00~ Dagger2を活用してAndroid SDKの依存関係をクリーンにする by @kr9ly

DI コンテナの Dagger2 については知っていたのですが、
Android でどの程度一般的なのか疑問でした。

DroidKaigi に来てみて感じたのは、
意外とみんな Dagger2 当たり前に使ってる気がする。という感覚。
そのため、Dagger2 の実際のところを知りたくて、このセッションに入り込みました。

セッションの中でアンケートが取られていましたが、
このセッションの参加者の約３割は、何らかの形で Dagger2 を使っているとのことでした。

DI を Android の世界に持ち込むのが難しく感じられる理由のひとつが、
AndroidSDK の何をするにも Context が必要になる問題。

Dagger2 を使う上での色々なテクニックが紹介されていましたが、
かなり複雑で、触ったことのない私にはちょっと聞いているだけでは理解できませんでした。
このセッションの内容は、
プロジェクトとして GitHub に公開してくださっているので、
実際に Dagger2 を検討する場合などに、いちどしっかり勉強してみようと思いました。

サンプルプロジェクト
https://github.com/kr9ly/dagger2-sampleapp

Day 2: Implementing Dropbox Offline Folders by Rodrigo

Dropbox の Android 実装についてのお話。
その名の通り、Dropbox というファイル共有アプリを
どういう設計に基づいて作っていったのかという話でした。

他のアプリでは見られない特徴かもなと感じたのが、
巨大なファイルが扱われる可能性があるため、
そういうファイルを Android 上で扱うために工夫が必要だったこと。

ファイルの同期には、通常の API などよりも多くの時間がかかるため、
ネットワーク切れなどが体感として感じやすく、
そこをどういう風に解決しなければいけなかったのかという話。

いろいろな Manager クラスが登場して、
動機やキャッシュなどを工夫して実装している感じがして、
なかなかちょっとした Android アプリ程度では、
ここまで考えることないだろうなという気がして、
これを作るときは楽しかっただろうなという感じがしました。

結構詳細なクラス図が紹介されていたので、
似たような機能を考える必要が出てきたら、これを見ると為になるだろうなと感じました。

Day 2: 15:40~ ConstraintLayout, now and future by thagikura, Nicolas Roard, John Hoford

Google から。

最近の Android Studio で、新しい Activity を作ると
必ず自動挿入される ConstraintLayout。
そのため名前だけは知っているという人は多くいそうですが、
DroidKaigi でアンケートされていた結果によると、
ConstraintLayout をちゃんと使っているプロジェクトは、
そんなに多くはないような印象でした。

ConstraintLayout は、旧来の RelativeLayout や LinearLayout を
本当に置き換えることを目指しているのだなというのを感じて、
ConstraintLayout ちゃんと取り入れることを考えなければいけないと感じました。

とにかくセッション中で紹介されたあらゆる機能は、
たしかに RelativeLayout や LinearLayout を古臭く感じさせるものばかりで、
ConstraintLayout を大前提として、アプリを作るというのは、これは普通になっていくべきだなと感じました。

相当詳しく機能紹介されていたので、
ConstraintLayout を採用するときは、このセッションの資料か動画をみるととてもいいと思いました。

個人的には、勉強になるいいセッションでした。

Day 2: 16:50~ Androidではじめるデザインスプリント by mochico

デザインスプリントという言葉を初めて知りました。

プロダクトデザイン、開発手法のフレームワークで、
５日間で、設計と開発までを行ってしまい、
それを何度も何度も繰り返して、良いプロダクトを生み出していこうという考え方のようです。

心に残った言葉は、

「できるだけ、早く、正しく失敗すること」

正しく失敗するって、むずかしいですけど、大切なことですよね。

Day 2: AI is ready for you. Are you ready for AI? by rejasupotaro

Cookpad UK からの使者。

Google はモバイルファーストから AI ファーストに移行するという有名な話がありましたが、
これは何を意味しているのでしょうか？

上の質問にこたえることが出来るか？
と思って、自分の中に答えがなかったので参加してみました。

正直に言いますと、もうかなり疲れがピークに達していて、
ほとんど話が耳に入らず、ただ TensorFlow は重要なんだなということだけ耳に残ってしまいました。無念。

Day 2: 開発者が知っておきたい通知の歴史 by kobakei

前述の通り、疲れがピークに達していて、あまり耳に入りませんでした..。
ごめんなさい、素直に引き上げてればよかったのですが..。

ただ、Android において通知を正しく実装する、
ちゃんと動くように実装するというのは簡単なことではなくて、
どういったポイントを抑えながら実装するべきなのかを、
かなり詳細に解説されているのだなと思いました。

いまから通知の実装をやるときは、
このセッションの資料と動画を、ちゃんと見直すと、なかなかいい感じに出来るのではないかと感じました。

また、ちょっとおもしろかった小話は、
Google のドキュメントであっても、日本語で書かれたら信用するのを止めましょうという話。
単純に翻訳が追いついてなくて、古い情報になっていることがあるため、
かならず英語で読んでくださいという話でした。

Google の出しているドキュメントなら、日本語でも大丈夫だろうと油断しておりましたが、油断禁物でした。

最後に

セッションの他にも、エンジニアの方と交流する時間を持てて、
それがとても幸せな時間でした。
本当に楽しかったです、ありがとうございました。

セッション以外で面白かったことがひとつ。

企業ブースで、実際のプロダクトのソースコードを公開している企業が何社かありました。
すごい勇気のある行動だなと思いつつ、
とても貴重な機会だったので、出来る限り見せていただきました。

これが一般的なことなのかわかりませんが、
技術交流という名目では、ソースコードをある程度限定的であっても
こういう場で見ることが出来るというのは、嬉しいなと感じました。

ソースコードを見ながら、その企業の方と、
あれこれと話をするというのは、結構、楽しい他体験でした。

以上です！