現在はリリースごとに5人程度がコミットし、2週間に1度リリースを行う開発体制となっています。プログラミング言語はJavaで、コメントも含めたアプリのソースコードの行数は約15万行です。本エントリでは、Android版クックパッドアプリで使っている技術、具体的にはライブラリやフレームワークについて紹介します。そのための技術選択のアプローチについても概説します。技術選択の基本的な方針まず技術選択の方針についてですが、これはサービスの性質に依存すると考えています。行ったりしており、最新の技術を使って開発できるようにしています。クックパッドのウェブサービス同様に、モバイルアプリの開発もこの先10年以上続くでしょう。したがって技術選択の基本的な指針においては、この先10年間継続してメンテナンスおよび更新していくことができるかどうかが重要です。Androidに関して言えば、まずGoogleの推奨する標準的な開発環境とサポートライブラリをベースにし、その上で適切な技術を選択していくということも必要です。技術選択の各論さて、前置きはこのくらいにして、実際にアプリで選択しているライブラリやフレームワークについて、選択の理由や所感などを紹介していきます。バックエンドにしたVolleyを使っています。APIとの通信に適していると考えられたからです。リクエストキューがあると、認証が完了するまで他のリクエストを停止するということが簡単にできます。Volleyの採用は間違いでした。2013で大々的に紹介されたにも関わらず、Gradleから利用しやすいアーティファクトの形でリリースはされず、リポジトリの公開のみにとどまっています。22でdeprecatedになりました。clientに依存しています。この状況を踏まえると、Volleyの未来は明るくなさそうです。Volleyはカスタマイズ性や安定性にも難があります。clientではVolleyを大きく拡張しているのですが、結果的にVolleyのインターフェイスにしたがっているだけでVolley自体のコードはあまり使っていません。これは、Volley自体のロジックではアプリの要求を満たせなかったり、エラーハンドリングに問題があったためです。clientもいずれOkHttpで置きかえるでしょう。4.4からはHttpURLConnectionのバックエンドがOkHttpになっていますが、これはこれでキャッシュまわりにクラッシュするバグがあるので、最新のOkHttpを直接使うほうがいいでしょう。Volleyについての反省点は、新しい技術に飛びついて痛い目を見たということです。Volleyの実装で参考にできる点は多々ありますが、今となっては使用はおすすめできません。InjectionDIはRoboGuiceを採用しています。比較検討され、RoboGuiuceが採用されました。RoboGuiceを採用した理由は次の通りです。ある2009年から継続して開発されている歴史が長く採用事例も多いので知見がたまっている一方でRoboGuiceは、重厚でバグを追いにくいこと、動作が遅いことなどの欠点もあります。移行が議論されていますが、依存関係の記述方法が異なるため移行コストが高く、あまり進捗はありません。DIは概念が複雑で使うのが難しいフレームワークなので、そもそもDIを使うべきか否かという議論も行っています。いまのところは、DIでコードを劇的にシンプルにできるという利点は大きいと判断し、DIを使おうというところに落ち着いています。導入して、こちらも併用しています。ViewHolderパターンの記述が煩雑であるということで導入しました。いう新しいライブラリが発表されました。ライブラリを置き換える強力なものだったため、さっそく導入して使い始めています。Binding導入にあたっての利点には次のようなものがあります。いくつかバグがあるので、一般的には次の安定版を待つのが無難でしょう。Boltsなどを検討したのですが、使い方が難しいわりに効果があまり見込めないということで採用はしませんでした。RxJava以前はコールバックベースのインターフェイスとAsyncTaskをCountDownLatchを駆使して制御していました。RxJavaを使っていなコードもかなりありますが、徐々に書き換えは進んでいます。RxJavaの導入については以下のエントリで詳しく紹介しています。クックパッド開発者ブログRxJavaの用途としては連続したHTTPリクエストのネストを重ねることなく記述できるプロミス的な使い方が典型的です。行っており、RxJavaを使わないコードと比べるとシンプルで読みやすくなりました。難しく*2、何度もバグを出しています。はずですが、RxAndroidの方向性について若干モメているようで、まだ枯れているとは言いがたい技術です。RxJava自体の欠点もあります。表現するのですが、これらは使い方が異なるため、使う際は注意が必要です。いう一つの型で表現するというRxJavaの特徴が、かえって使いにくくしているという結果になっているのです。このようにRxJavaの導入は利点も欠点もありますが、RxJavaの根底にあるReactiveX自体の歴史は長く十分に枯れており*3、RxJavaの開発も活発なので、総合的に見て導入のメリットはあると考えています。MapperORMについてはActiveAndroidを採用しており、以下のエントリで詳しく述べています。クックパッド開発者ブログクックパッドアプリはその性質上マスターデータがサーバーサイドにあり、アプリのデータはそのほとんどキャッシュです。そこで簡単に使えるということを重視してActiveAndroidを使っています。ActiveAndroidの開発は停滞しており、issueやpull-requestは放置されていますから、ActiveAndroidの未来は明るくなさそうです。将来的にローカルのデータベースを使った機能を拡充したいことを考えると、ORMについてはそろそろ刷新する必要があると感じています。Loggingクリックイベントなどのメトリクスのログ収集のためのロギングライブラリは、自社で開発したものを使っています。クックパッド開発者ブログPureeは継続して開発しており、現在のv3ではAPIはよりシンプルになり、パフォーマンスも改善しています。必要に応じて自社でライブラリを開発し、メンテナンスしていくという選択が有効なこともあります。FragmentFragmentはAndroid組み込みのandroid.app.Fragmentではなくサポートライブラリのandroid.support.v4.app.Fragmentを使っています。これは、サポートライブラリのFragmentは最新の機能をすべて使えるのに対して、組み込みのFragmentで使える機能はアプリのminSdkVersionに依存するからです。安定性という意味でもサポートライブラリのFragmentを選択する理由があります。OSのリビジョンに依存します。組み込みのFragmentを使うかぎり、Fragmentの実装のリビジョンを指定できません。それならば、バージョンを指定して使えるサポートライブラリのFragmentのほうが確実に挙動を予測できます。まとめ本エントリでは、Android版クックパッドで採用している技術について解説しました。個々の技術は成功したり失敗したりしていますが、たとえ失敗したとしても反省をいかしつつ次の10年を気持ちよく開発できるような技術選択を心がけています。2019夏メディアプロダクト開発部の安部(@STAR_ZERO)です。targetSdkVersion...2016-10-04iOSアプリの継続的デリバリーへの取り組みについての勉強会を開催しました技術部モバイル基盤グループの三木(@giginet)です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。