Cookpad.apk #2 登壇資料 https://cookpad.connpass.com/event/117054/
Androidアプリエンジニアの基礎知識こやまカニ大好き1
View Slide
自己紹介こやまカニ大好き(@nein37)モバイル基盤部所属社内全Androidプロジェクトの開発効率化と技術サポートminSdkVersion 上げたりモジュール分割したりしてます2
話す内容● チームとしてのAndroidアプリ開発● Androidアプリエンジニアに期待される役割● 開発効率化のためのベストプラクティス参考資料:Android開発をする上で知っておいてほしいなと思うことhttp://nein37.hatenablog.com/entry/2018/03/19/0107203
チームとしてのAndroidアプリ開発以下のような状況を想定しています● 比較的新しい/小規模なサービス● Androidのネイティブアプリを開発中 /開発予定● チーム内のAndroidエンジニアはまだ少ないさらに進んだ状況に関しては DroidKaigi 2019 で「アプリをさらに成長させるための技術戦略」という素晴らしい発表がありましたhttps://blog.shoheikawano.com/entry/look_back_droidkaigi_20194
● Android に詳しい● Android アプリを実装できる● Android に関する意思決定をサポートできるAndroid エンジニアに期待される役割5
Androidに詳しい #とは6
● 古いOSがいつまでも現役● 端末によって解像度やDPIが異なる● 端末によって挙動が異なる● マテリアルデザイン大変そうといった不安を正しい知識で払拭できるAndroid に詳しい #とは7
● 完全に事実○ 2013年リリースのOSがシェア8%もある● 古いOSにもある程度はバックポート可能● 新OSで急に挙動が変更されないような仕組みがある○ targetSdkVersion を上げなければある程度大丈夫● OSごとの挙動の違いは公式ページに詳しく書いてある○ https://developer.android.com/about/versions/pie/→ Lollipop (2014〜)くらいまでなら大きな苦労なくサポート可能古いOSがいつまでも現役8
● 端末によってディスプレイが異なるのは事実● この違いを埋めるための仕組みも同時に用意されている● DP+ConstraintLayoutで組んでいれば端末ごとの差異はほぼ解消できる端末によって解像度やDPIが異なる9画像出典 : The Android Screen Fragmentation Myth
● 問題の切り分けが重要(端末なのか、OSなのか)● 本当に端末ごとの挙動が大きく異なる部分は限られている○ Bluetooth、カメラなどのハードウェア周り○ WebView(Android 4.4未満)● WebViewに関しては Android 5.0 から挙動が揃うようになった● クックパッドアプリでは minSdkVersion 21 化して以降特定の端末のみに依存する問題は激減した端末によって挙動が異なる10
● Material Components を利用するとある程度までは導入できる● 完全にマテリアルデザインを再現しようとすると死ぬ○ ライブラリがドキュメントの挙動を完全には再現してくれない● マテリアルデザインが導入されたのは API level 21 から○ それ以前のバージョンへのバックポートは完璧ではない。● Material Theming は一度触っておいたほうが良い○ マテリアルデザインっぽいカスタムテーマを作れるデザインツール (公式)マテリアルデザイン大変そう11
Android アプリを実装できる #とは12
サービス開発はリリースサイクルをできるだけ速く回し続けることが重要。個人の速度だけでなくチームとして速度を落とさない工夫が必要。● なぜアプリへのアーキテクチャ導入が行われているのかを理解する● テストの種類を理解し実装する● ドキュメントを残す● ライフサイクルやFragment遷移まわりをきちんと理解するAndroid アプリを実装できる #とは13
● どのアーキテクチャであっても関心の分離を目的としている● Fragment/Activity からロジックを分離することでOSから開放される● 他のメンバーの作業時にどこを見ればよいのかがわかりやすくなるなぜアプリへのアーキテクチャ導入が行われているのか14
● ユニットテスト、インストルメントテスト、 Firebase Test Lab● 端末をポチポチ触ってテストする時間を削減できる● CIなどでテスト結果のログを残すことで後の調査の時間も削減できる● 他のメンバーの作業時にテストを実行し挙動をチェックできるテストの種類を理解し実装する15
● あるいはすでにドキュメントが存在するものを最大限活用する● ちゃんとしたドキュメントでなくてもIssueへのコメントなども後々役に立つ場合がある● メンバー加入時など作業時間短縮につながる部分は大きいドキュメントを残す16
● アプリが複雑化するとネストされたFragmentが頻出するようになる○ タブ、ViewPager、● よく理解しないまま実装すると障害対応などで時間を浪費する● 必要になったときにドキュメントを読む癖をつけるライフサイクルやFragment遷移まわりをきちんと理解する17
Android に関する意思決定をサポートできる #とは18
Androidアプリの運用に関する機能や数字を知り、意思決定に反映することができる● サポートすべきバージョン● 検証端末はどうすれば良いのか● アプリの統計情報はどこを見れば良いのかAndroidに関する意思決定をサポートできる #とは19
● 公式ページに月次のシェア が公開されている(が昨年から止まっている…)● 公式が発表しているOSのバージョンシェアよりもアプリのシェアを見たほうが正確(Playコンソールで見られる)● 「開発のしやすさ」は速度の根拠になります● 大部分ではAPI 21 が大きな転換点になっている○ マテリアルデザイン導入 (によるView属性拡張)○ TLS関連(OkHttp も 5.0 未満はサポートを切った )○ VectorDrawable や RippleDrawable など便利系サポートすべきOSバージョン20
● ディスプレイ設定や開発者オプションを使うと表示領域サイズやノッチの有無を変更可能● スマートフォンの動作確認に関してはPixel3に加え、リリース前レポートやFirebaseTestLabsを活用することで大体カバー可能● 設定アプリはメーカーごとのカスタマイズが激しいため、シェアが大きいメーカーごとに1機種ずつあったほうがユーザーサポート目的では良い検証端末はどうすれば良いのか21
● Playコンソールのダッシュボードに大量の情報があります○ OSバージョンごとのシェア、インストールユーザーの推移など○ 最近は日本語のレビュー解析機能も改善されてきました● 統計内容、利用のためのヒントはヘルプページにも書いてあります○ Android Developers の Google Play ページ○ 戦略(Strategies) というページも有用○ Playコンソールヘルプアプリの統計情報はどこを見れば良いのか22
開発効率化のためのベストプラクティス23
実はほとんど公式ページに書いてあるので最大限活用する● 公式ページにそのまま Best practices という項目がある● Jetpackを活用することでドキュメント作業を簡略化できる○ Jetpackに含まれているもの一覧を知っているだけでも役に立つ○ Google Samples に大量のサンプルがある○ アーキテクチャに関しても非常に詳しく書いてある● Codelabs を活用することで新しい技術を簡単に学べる○ 新しいサービスや機能を実際の挙動を試しながら学べるのでとても効率が良い開発効率化のためのベストプラクティス24
他社事例は参考にできることも多い● 公式サイト内のNewsから最新のニュースが配信されている○ 開発関連だけでなく各種サービスの成功事例や課金に関するコンテンツも配信されている● 公式サイト内のGooglePlayに最新のGooglePlay活用方法が書かれている○ マーケティングに関する事例も多数配信されている開発効率化のためのベストプラクティス25
Googleが教えてくれないこと● 具体的なデザインリソース運用方法など○ 皆悩んでいるので他社事例を参考にすると良い○ 弊社テックブログでも何度か記事にしました 記事1 記事2○ Kyashさんの技術ブログが非常に詳しくて参考になります● BLEとかカメラとかTVとかで端末依存問題があるんですが…○ DroidKaigi とかで辛い話知見が聞けます○ いつもありがとうございます開発効率化のためのベストプラクティス26
Androidはよくわからない怖いプラットフォームではなく、非常に個性豊かな奥行きのあるプラットフォーム。様々な端末とユーザーに最速で価値を届けられるように頑張っていきましょう。これからも弊社での事例を中心に開発効率化のための知見を共有していきます。まとめ27