はじめまして、グノシー開発部新卒エンジニアの山本です。主にグノシーのAndroid版や、最近リリースしたLucraのAndroid版を作ったり、サーバーサイドでGo/Pythonで開発をしたりしています。

少し時間が空いてしまいましたが、9月25~26日にニューヨークで開催されたdroidconNYC 2017に会社に費用を出してもらって参加してきました。今回はそのレポートを書いていこうと思います。

droidconについて

droidconとは世界各地で行われるAndroid専用のカンファレンスで、Android専用でいえば世界でも最大規模のカンファレンスです。ニューヨークの他にもロンドンやベルリン等(日本はまだ😢)で行われ、終了後には各サービスでスライド等が盛り上がるので知ってる人も多いかと思います。

今回のdroidcon NYC 2017では70以上のセッションが行われ、900人以上のandroidエンジニアが参加しました。 AndroidエンジニアにはおなじみのJakeも参加するなどAndroid業界の祭り感があります。

上の写真は会場の入り口です、おしゃれな雰囲気が出ていると思います。

会場

会場はタイムズスクエアの角のところを奥に入ったところというかなりニューヨークな場所でした。

朝ごはんが出たり

コーラやコーヒーなどが飲み放題だったり

可愛いグッズが配られたりしていました。 Wifiも速いしコンセントも豊富にあって言うことないですね 😂

これはただの夕食ですね 😂

セッション

トータルのセッション数としては70以上ありますが、同時に4セッションが行われるので実際に見れたのは20セッションほどでした。

すべてのセッションの動画は基本的にはすべてYouTubeのチャンネルにアップロードされるので(今月末とかだと思います)そちらで見るか、スライドだけで良い方はこちらにまとまっているのでそちらでチェックすることができます。

以下では僕が参加できたセッションの内、気になったトピック毎に抜粋して載せていこうと思います。

全体の印象

全体の印象としては一定以上の規模のアプリでは

RxJava
Dagger 2
Kotlin

はもうデフォルトで採用されるものとして定着しているように感じました。

数年前はDagger(kotlin)入れるとこんないいことがあるよ的なセッションがありましたが今回はなく、当然のようにスライドのコードがkotlinであったりとか、Daggerのパフォーマンス改善といったより発展したセッションが複数ありました。

グノシーでも上記のライブラリ(言語)はすべて使っていますが、今となっては無い生活は考えられないのでそういうことなんだと思います。

アーキテクチャ

カンファレンスといえばアーキテクチャの話といったイメージがあるぐらい一向に落ち着く気配を見せないアーキテクチャ議論ですが今回も数多くのセッションがありました。既存の比較的古いといってもいいMVC, MVP, (素直な)MVVMのアーキテクチャでは非同期処理や状態保持の方法が実装者に委ねられており可読性に問題があることが多いという課題感はどこも持っているようでした。

MVI

MVIに関するセッションが複数あり、上記の課題感の解決策としての盛り上がりを感じました。 MVIとはWebでいうRedux(Flux)のような一方向データフローをAndroidでも実現しようというアーキテクチャです。

非同期処理による状態遷移の難しさですが、具体的には

サーバー側からの完了通知やユーザー入力等、イベントが複数スレッドから呼ばれた場合の状態遷移の難しさ
- 状態遷移を単一スレッドに制限したり排他制御を自分で書くのが難しい
(素直な)MVPだと状態をViewとPresenterどちらも持ててしまうので、どちらで持つのか問題、またその整合性
- AndroidのViewが絡むのでだるい
- これはMVVMでも解決しようとしていますが

からくると思いますが、MVIはそれらの問題を

ユーザー入力やAPIの完了通知を一つのストリームに流し、状態遷移はただの関数であるreducerのみで行う
View側は状態を一切持たずに変更通知のみを受け取り、変更後の状態のみによって表示を変更する

といった制約をもたせることによって解決しています。この解法はRedux(Flux)の概念と非常に似ており、いろいろあったJavaScript業界で、ある程度完成された方法をAndroidにも持ってきた形なので多少の安心感があります。

また、ユーザー入力や完了通知のストリームをRxJavaで表現する事によって可読性の高いコードになっています。RxJavaでのココらへんの状態遷移の書き方はJake(また)さんの以下のスライドがわかりやすいです。

今回のdroidconの Model View Intent, Embracing Reactive UI's では、実際のMVIを用いたアプリのコードがgithub上に公開されているので参考にしてグノシーのコードも書き換えていければなと思いました。

TodoMvi: https://github.com/yousuf-haque/TodoMvi

Viewパフォーマンス

これもどのカンファレンスでも多いトピックですがViewのパフォーマンス周りのセッションもかなり多かったです。今年はFacebookから登壇される方が多く、Lithoに関する発表を開発者から直接聞けたのはいい経験でした。

Litho

LithoとはFacebookがオープンソースで開発しているUIフレームワーク(レイアウト+レンダリング)で、以下の特徴があります。

非同期レイアウト
- 通常のViewのサイズを測ったりレイアウトを決める処理はメインスレッド上で行われますが、複雑なレイアウトだとレイアウトに時間がかかりスクロールがカクついたりといったことが起きがちですが、Lithoはこれらの処理をバックグラウンドスレッドで行うためユーザー体験を損なわない
よりフラットなView階層
- ネストの深いViewはレイアウトが重くなりがちですが、LithoだとすべてのViewは一つのView内にレイアウトされるため軽い
テキスト描画の最適化
- TextViewはかなり重いViewですがLithoを使うとTextViewを使わずに描画するので軽い
リサイクルの最適化
- RecyclerViewだと行毎のリサイクルですが、LithoはリストではなくてもすべてのViewをより細かい単位でリサイクルします(1テキスト、1画像単位でリサイクルされる)

このリストだけ見るとAndroidエンジニア歓喜という感じですが、レイアウトをコードで書く必要があったりでそれなりに移行コストは高くなっています。ただ、LithoをFacebookのタイムラインのレイアウトに使うとレンダリング(measure,layout,draw)にかかる時間が1/10になったという話をしていたので乗り換える価値はありそうです。

ConstraintLayoutの登場でViewのネスト問題は改善されてきていますが、TextViewやImageViewなどのそもそもViewが重い問題は永遠に残り続けるのでCustomViewで気合で乗り切るのかLithoのような仕組みを取り込んでいくのかは検討していきたいですね。

FacebookはReactNativeだと思っていたんですが、どういう住み分けなのかも気になりますね。

名前はStethoとかけてるの…？🤔

オフライン対応

オフライン対応は意外とセッションが多かったです。こちらもFacebookの方からの発表がほとんどでしたが、Facebookのように電波の不安定な環境で使われることが多いアプリ以外でもユーザー体験向上のためにオフライン対応を進めているアプリが多いようでした。

ネットワークがないとエラーを出すアプリが多い中、オフラインはエラーじゃなくてステータスだからエラーで甘えるな的なことをおっしゃっていて、すいませんでしたという感じでした。

こちらはグノシーでも進めていきたいところなのでまた詳しくブログに書いていこうと思います。

まとめ

他にもRoomとSQL Delight(どちらもSQL用ライブラリ)の開発者によるどちらのライブラリがいいか直接対決があったり、Android thingsのハンズオンでTensorFlowを用いた物体認識など楽しいセッションが数多くあり常にワクワク感のある非常に良いカンファレンスでしたが長くなりそうなのでこの辺にします。

これまでカンファレンスにはあまり行ったことがなかったのですが、海外の優秀なAndroidエンジニアの方とふれあい、自分に足りないものや目指すものが見えたことは非常にいい経験でした。

初海外で単独ニューヨークというかなり緊張感のあるカンファレンスでしたが、無事得るものは得て帰ってこれたのはよかったです。次に行く機会があれば、もうすこし英語で会話がスムーズにできるようになりたいですね(ほんとにこれは苦労した)。