3年、Androidアプリ開発を取り巻く環境も大きく変わってきました。本エントリでは、以前のエントリからこれまでにAndroid版クックパッドアプリにあった技術選択の推移や、現在の状況を記していきます。クックパッドアプリの開発環境は以下のようになっています。Kotlinの採用でしょう。それぞれに関して1つずつ振り返っていきたいと思います。26以下のアプリは今後リリースもしくはアップデートできなくなるという発表をしたことで、無理矢理にでも上げざるを得ない状況が各アプリにあったと思います。23だったアプリが、今年の9月にようやく26を満たすことが出来るようになりました。targetSdkVersionをこれだけ長い時間かけて上げていったのには理由がありました。Bundleに含められるデータサイズ制限です。24以上の端末でアプリを使用すると、画面遷移を行った瞬間にクラッシュするという事態が発生していました。ここを直すために色々と手を尽くして、最終的に以下の対応をすることで大きな問題を起こすことなくアップデートすることが出来ました。26で入ったバックグラウンド制限です。Messagingの実装が古く、BroadcastReceiver内でServiceを起動しており、見事にバックグラウンド制限に引っかかっていました。Messagingへの移行を行いました。ここでもまた、アプリ上で使っているFirebaseプロジェクトが現在GCMで使っているプロジェクトと一致していない、という問題もあったのですが、GCMは2019年4月以降プッシュ通知を送れない状況であることと、そのプロジェクトはGCM以外の用途では使っていなかったこと、またプッシュ通知を送信する基盤実装への修正も容易であったことを踏まえて、廃止されるまでは両方のプロジェクトにプッシュ通知を送信する、という対応で事なきを得ました。ローカルプッシュ通知の実装も、AlarmManagerからBroadcastReceiverを経由してServiceを起動する流れになっており、こちらもバックグラウンド制限に引っかかっていました。26に上げることが出来ました。28に関しては、上で挙げたような大きな障害はなく、すんなりと上がって今は最新の環境で開発が行えている状況です。minSdkVersionminSdkVersionに関しては、以前ブログでも紹介があった通り、現在は21となっています。詳細は以下の記事を参照ください。21にした話これによって、開発環境のアップデートに対する作業がぐっとやりやすくなりました。この1年でここまでのアップデートを行えたのはこの取り組みがあったおかげだと思っています。I/Oで公式にサポートすると発表した直後から導入したいというのは話していたのですが、クックパッドアプリに関しては導入するのにだいぶ時間がかかってしまいました。その頃のクックパッドアプリの最大の問題として「どこになにを書けばいいかが分からない」というものがあり、長い間続いているプロジェクトでアーキテクチャなどもうまく導入できておらず、無法地帯なコードベースがあったため、この状態のままKotlinを導入しても問題が増えるだけだと感じていました。そのため、どこからKotlinを導入するか、どういう風に進めるかを基盤チームで議論した結果、VIPERアーキテクチャを導入し各画面の実装をアーキテクチャに対応させながらKotlinを導入していくことが決まりました。100%のプロジェクトも中には存在します。導入の際にはStyleGuideを定めたり、社内でKotlin勉強会を開いたりして知見を共有し合ったりしていました。方針が決まってからしばらく別の施策によって手が止まっていたのですが、クックパッドアプリでも今年の3月頃から導入を開始していて、今ではプロジェクトの約20%のコードがKotlinに置き換わっています。Swiftに比べてまだまだ手を付けられていない状況ですが、手を付けられるところから少しずつKotlinコードへの変換とアーキテクチャの適用を行っています。APIとの通信にはVolleyを使用していました。APIとの通信層に使用するコアライブラリをOkHttp3に置き換えました。APIはGarageで作られているため、Garageのリクエスト方式に沿ったものがあったほうが良いだろうという判断をして、社内ライブラリとしてgarage-client-androidを作成して使っています。以降の展望としては、API側の変化を伴うものになっていくのではないかなと予想しています。あるかどうかが分かりにくく、開発効率も下がるしバグが発生しやすいというものがあります。モバイルアプリでは、一画面で複数のリソースが必要になることが多く、RESTFullなAPIだと複数のAPI通信を行う必要がある場合が発生し、扱いが難しいところがあります。これを解決するために、社内の一部新規サービスではGraphQLを使用したAPI通信を始めていたり、gRPCやSwaggerなどの型制約を解決できるような仕組みを使えないか検討し始めていたりします。Injection以前の記事時点ではRoboGuiceを使用していました。RoboGuiceは2016年8月の時点でサポートが終了し、別のDIライブラリへの移行を余儀なくされる形となっていました。前回の記事でも言及していたとおり、社内ではDIライブラリを使うべきかどうかという議論がずっと繰り返されており、Kotlinを導入した際に同時に導入したVIPERアーキテクチャではDIライブラリを使用しない形で進めていこうという話もしていました。現段階で使っている箇所に関しては簡単に剥がすことも出来ないため、2018年4月からは実装も薄くてRoboGuiceからの移行が比較的簡単だったToothpickというDIライブラリを導入しています。導入しようとしていた4月時点ではまだproguardへの対応が行われている最中だったため、少し時期尚早だったかなと思っていたのですが、いまのところ大きな問題もなく運用出来ています。ちなみに、クックパッドで最近リリースされたcookpadTVアプリに関しては、DIライブラリにはDagger2を使用しています。このあたりの技術選定は基本的に各サービスごとのエンジニアに任せるようにしています。Loader画像読み込みには、以前はPicassoを使用していましたが、こちらも長らく開発が滞っていたため、昨年Glideに移行しました。導入段階ではFacebook製のfrescoも検討していましたが、こちらは画像読み込みの際のインターフェースがPicassoと大きく離れていたり、画像のサイズを予め知っておく必要があったりと、移行作業に難ありだったため見送りました。PicassoからGlideへの移行に関しては、インターフェースも非常に似通っているためほとんど技術的な問題は起きませんでしたが、リリース後「画像が読み込めない」というお問い合わせが多数寄せられ、とても頭を悩ませたことは記憶に新しいです。(結果的に、通信レイヤーで使用していたOkHttp3のバグだったことが判明し、OkHttp3のアップデートを行うことで解決しました)Debuggingデバッグツールには、StethoとHyperion-Androidを導入しています。Sthethoは、通信層のコアライブラリをOkHttp3に置き換えたことにより、プロキシを介さずにアプリの通信履歴を見ることが出来て、非常に重宝しています。Hyperionは、SharedPreferencesに保存されているデータの中身を見たり、View構造を探索したりと、非常に多機能で優秀な上に、拡張してデバッグ用のメニューを追加することも出来ます。今までは、クックパッドアプリのサイドメニュー下にデバッグ版のみ表示されるツールメニューを用意していたのですが、Hyperion導入後はHyperionのメニューとしてデバッグメニューをまとめることが出来るようになり、デバッグ用の機能を管理するのがとても楽になりました。CI上でのAndroidエミュレータの扱いに関してもここ数年で大きく動きがありました。Testの実行に使用していました。起動時間や実行時間がネックとなり、それらの改善を行うためにこれまで様々な取り組みをしてきました。各取り組みに関してはそれぞれブログがまとまっているので、そちらを御覧ください。Playの機能を使うことが出来ません。これに対して、クックパッドアプリでは新たにいくつかの方法を検討中です。AWSなどのデバイスファームの使用などが挙げられます。CI環境に関してもその時々で要求されるものは移り変わっていくので、色々な選択肢を試しながら技術選択を行っています。Enterprise上でのPullRequest駆動での開発が盛んですが、その中でもコードレビューを行う際にLintやfindbugsなどの静的解析ツールによる指摘を自動化しています。dangerというオープンソースのツールに乗り換えました。dokumiの設定はdokumi本体に含める必要があり、各プロジェクトの設定がツールに含まれる形になってしまい、ツールとプロジェクトの関係が密になりすぎるという問題がありました。その点、dangerは各プロジェクトごとにRubyで設定ファイルを記述することで動作するし、プラグインを作成するのも容易だったため、複数のプロジェクトに簡単に導入できるという点が乗り換えたポイントでした。個人的に、dokumiと違ってdangerのコメントは上書きされていくので、PullRequest上に指摘コメントが積み重なっていき読みづらくなることが減るところが気に入っています。danger導入時に関する話は以下のブログ記事で詳細に書かれているため、よろしければ読んでみてください。Android開発のコードレビューbotを乗り換えた話リリースエンジニアリング以前から、リリースに伴う作業を手作業ではなく機械によって自動化するために、fastlane/supplyを使ってリリース関連の作業を自動化しています。弊社のCI環境はJenkinsなので、Jenkinsのgoogle-play-android-publisher-pluginを使用する選択や、Gradleプラグインのgradle-play-publisherなどを使用する選択も取れたのですが、その中でもfastlaneを使用している理由は以下の点が大きいかなと思っています。fastlaneはiOSアプリでも積極的に使用されていて、内製のプラグインも開発されているなど、iOSとの仕組み共通化のためにも使えるGradleプラグインとして採用するとビルドに影響が出てしまうので、ビルドとリリースフローは分離したいRuby製のツールなので、社内の開発リソースと一致しやすい(※個人的な意見です)Groovy書きたくない(※あくまでも個人的な意見です)最近では、fastlane/supplyを利用してアプリの自動リリースを行い、リリースフローの機械化・自動化も進めています。こちらに関しては、iOSでの取り組みが先行しているため、以下のブログ記事を参照ください。Consoleのリリーストラックを有効活用してリリースフローの最適化を行った話」というセッションが採択されたため、そこで詳細に話す予定です。ご興味のある方は足を運んでいただけると幸いです。おわりにいかがでしたでしょうか。思いつく限りの最近のクックパッドアプリの開発事情について書き記してみました。近年のクックパッドアプリは、目新しいものを導入したというよりは今まで使っていたものがどんどんと使えなくなっていったためアップデートしていったという話が主になっていることがわかります。いえ、新しい技術を試していないわけではなく、使えるものは積極的に取り入れていくし、色々な技術を試すための環境は充分に用意されています。今回はクックパッドアプリの開発事情について書きましたが、最近は新規サービスもどんどんと生まれてきており、複数のアプリに対する仕組みの共通化なども積極的に行っています。2018年版Tweet関連記事2019-10-21クックパッドアプリ(Android)の開発効率化のためにやったこと/やっていることモバイル基盤部のこやまカニ大好き(id:nein37)です。Nativeで作った新アプリについて(5日間連載)こんにちは投稿開発部の丸山@h13i32maruです。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。