Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Androidアプリエンジニアの基礎知識

 Androidアプリエンジニアの基礎知識

Cookpad.apk #2 登壇資料
https://cookpad.connpass.com/event/117054/

こやまカニ大好き

February 18, 2019
Tweet

More Decks by こやまカニ大好き

Other Decks in Programming

Transcript

  1. Androidアプリエンジニアの
    基礎知識
    こやまカニ大好き
    1

    View Slide

  2. 自己紹介
    こやまカニ大好き(@nein37)
    モバイル基盤部所属
    社内全Androidプロジェクトの開発効率化と技術サポート
    minSdkVersion 上げたりモジュール分割したりしてます
    2

    View Slide

  3. 話す内容
    ● チームとしてのAndroidアプリ開発
    ● Androidアプリエンジニアに期待される役割
    ● 開発効率化のためのベストプラクティス
    参考資料:Android開発をする上で知っておいてほしいなと思うこと
    http://nein37.hatenablog.com/entry/2018/03/19/010720
    3

    View Slide

  4. チームとしてのAndroidアプリ開発
    以下のような状況を想定しています
    ● 比較的新しい/小規模なサービス
    ● Androidのネイティブアプリを開発中 /開発予定
    ● チーム内のAndroidエンジニアはまだ少ない
    さらに進んだ状況に関しては DroidKaigi 2019 で「アプリをさらに成長させるための技術戦略」
    という素晴らしい発表がありました
    https://blog.shoheikawano.com/entry/look_back_droidkaigi_2019
    4

    View Slide

  5. ● Android に詳しい
    ● Android アプリを実装できる
    ● Android に関する意思決定をサポートできる
    Android エンジニアに期待される役割
    5

    View Slide

  6. Androidに詳しい #とは
    6

    View Slide

  7. ● 古いOSがいつまでも現役
    ● 端末によって解像度やDPIが異なる
    ● 端末によって挙動が異なる
    ● マテリアルデザイン大変そう
    といった不安を正しい知識で払拭できる
    Android に詳しい #とは
    7

    View Slide

  8. ● 完全に事実
    ○ 2013年リリースのOSがシェア8%もある
    ● 古いOSにもある程度はバックポート可能
    ● 新OSで急に挙動が変更されないような仕組みがある
    ○ targetSdkVersion を上げなければある程度大丈夫
    ● OSごとの挙動の違いは公式ページに詳しく書いてある
    ○ https://developer.android.com/about/versions/pie/
    → Lollipop (2014〜)くらいまでなら大きな苦労なくサポート可能
    古いOSがいつまでも現役
    8

    View Slide

  9. ● 端末によってディスプレイが異なるのは事実
    ● この違いを埋めるための仕組みも同時に用意されている
    ● DP+ConstraintLayoutで組んでいれば端末ごとの差異はほぼ解消できる
    端末によって解像度やDPIが異なる
    9
    画像出典 : The Android Screen Fragmentation Myth

    View Slide

  10. ● 問題の切り分けが重要(端末なのか、OSなのか)
    ● 本当に端末ごとの挙動が大きく異なる部分は限られている
    ○ Bluetooth、カメラなどのハードウェア周り
    ○ WebView(Android 4.4未満)
    ● WebViewに関しては Android 5.0 から挙動が揃うようになった
    ● クックパッドアプリでは minSdkVersion 21 化して以降
    特定の端末のみに依存する問題は激減した
    端末によって挙動が異なる
    10

    View Slide

  11. ● Material Components を利用するとある程度までは導入できる
    ● 完全にマテリアルデザインを再現しようとすると死ぬ
    ○ ライブラリがドキュメントの挙動を完全には再現してくれない
    ● マテリアルデザインが導入されたのは API level 21 から
    ○ それ以前のバージョンへのバックポートは完璧ではない。
    ● Material Theming は一度触っておいたほうが良い
    ○ マテリアルデザインっぽいカスタムテーマを作れるデザインツール (公式)
    マテリアルデザイン大変そう
    11

    View Slide

  12. Android アプリを
    実装できる #とは
    12

    View Slide

  13. サービス開発はリリースサイクルをできるだけ速く回し続けることが重要。
    個人の速度だけでなくチームとして速度を落とさない工夫が必要。
    ● なぜアプリへのアーキテクチャ導入が行われているのかを理解する
    ● テストの種類を理解し実装する
    ● ドキュメントを残す
    ● ライフサイクルやFragment遷移まわりをきちんと理解する
    Android アプリを実装できる #とは
    13

    View Slide

  14. ● どのアーキテクチャであっても関心の分離を目的としている
    ● Fragment/Activity からロジックを分離することでOSから開放される
    ● 他のメンバーの作業時にどこを見ればよいのかがわかりやすくなる
    なぜアプリへのアーキテクチャ導入が行われて
    いるのか
    14

    View Slide

  15. ● ユニットテスト、インストルメントテスト、 Firebase Test Lab
    ● 端末をポチポチ触ってテストする時間を削減できる
    ● CIなどでテスト結果のログを残すことで後の調査の時間も削減できる
    ● 他のメンバーの作業時にテストを実行し挙動をチェックできる
    テストの種類を理解し実装する
    15

    View Slide

  16. ● あるいはすでにドキュメントが存在するものを最大限活用する
    ● ちゃんとしたドキュメントでなくてもIssueへのコメントなども後々役に立つ場合が
    ある
    ● メンバー加入時など作業時間短縮につながる部分は大きい
    ドキュメントを残す
    16

    View Slide

  17. ● アプリが複雑化するとネストされたFragmentが頻出するようになる
    ○ タブ、ViewPager、
    ● よく理解しないまま実装すると障害対応などで時間を浪費する
    ● 必要になったときにドキュメントを読む癖をつける
    ライフサイクルやFragment遷移まわりをきちん
    と理解する
    17

    View Slide

  18. Android に関する意思決定
    をサポートできる #とは
    18

    View Slide

  19. Androidアプリの運用に関する機能や数字を知り、意思決定に反映することができる
    ● サポートすべきバージョン
    ● 検証端末はどうすれば良いのか
    ● アプリの統計情報はどこを見れば良いのか
    Androidに関する意思決定を
    サポートできる #とは
    19

    View Slide

  20. ● 公式ページに月次のシェア が公開されている(が昨年から止まっている…)
    ● 公式が発表しているOSのバージョンシェアよりもアプリのシェアを見たほうが正
    確(Playコンソールで見られる)
    ● 「開発のしやすさ」は速度の根拠になります
    ● 大部分ではAPI 21 が大きな転換点になっている
    ○ マテリアルデザイン導入 (によるView属性拡張)
    ○ TLS関連(OkHttp も 5.0 未満はサポートを切った )
    ○ VectorDrawable や RippleDrawable など便利系
    サポートすべきOSバージョン
    20

    View Slide

  21. ● ディスプレイ設定や開発者オプションを使うと表示領域サイズやノッチの有無を
    変更可能
    ● スマートフォンの動作確認に関してはPixel3に加え、リリース前レポートや
    FirebaseTestLabsを活用することで大体カバー可能
    ● 設定アプリはメーカーごとのカスタマイズが激しいため、シェアが大きいメーカー
    ごとに1機種ずつあったほうがユーザーサポート目的では良い
    検証端末はどうすれば良いのか
    21

    View Slide

  22. ● Playコンソールのダッシュボードに大量の情報があります
    ○ OSバージョンごとのシェア、インストールユーザーの推移など
    ○ 最近は日本語のレビュー解析機能も改善されてきました
    ● 統計内容、利用のためのヒントはヘルプページにも書いてあります
    ○ Android Developers の Google Play ページ
    ○ 戦略(Strategies) というページも有用
    ○ Playコンソールヘルプ
    アプリの統計情報はどこを見れば良いのか
    22

    View Slide

  23. 開発効率化のための
    ベストプラクティス
    23

    View Slide

  24. 実はほとんど公式ページに書いてあるので最大限活用する
    ● 公式ページにそのまま Best practices という項目がある
    ● Jetpackを活用することでドキュメント作業を簡略化できる
    ○ Jetpackに含まれているもの一覧を知っているだけでも役に立つ
    ○ Google Samples に大量のサンプルがある
    ○ アーキテクチャに関しても非常に詳しく書いてある
    ● Codelabs を活用することで新しい技術を簡単に学べる
    ○ 新しいサービスや機能を実際の挙動を試しながら学べるのでとても効率が良い
    開発効率化のためのベストプラクティス
    24

    View Slide

  25. 他社事例は参考にできることも多い
    ● 公式サイト内のNewsから最新のニュースが配信されている
    ○ 開発関連だけでなく各種サービスの成功事例や課金に関するコンテンツも配信されている
    ● 公式サイト内のGooglePlayに最新のGooglePlay活用方法が書かれている
    ○ マーケティングに関する事例も多数配信されている
    開発効率化のためのベストプラクティス
    25

    View Slide

  26. Googleが教えてくれないこと
    ● 具体的なデザインリソース運用方法など
    ○ 皆悩んでいるので他社事例を参考にすると良い
    ○ 弊社テックブログでも何度か記事にしました 記事1 記事2
    ○ Kyashさんの技術ブログが非常に詳しくて参考になります
    ● BLEとかカメラとかTVとかで端末依存問題があるんですが…
    ○ DroidKaigi とかで辛い話知見が聞けます
    ○ いつもありがとうございます
    開発効率化のためのベストプラクティス
    26

    View Slide

  27. Androidはよくわからない怖いプラットフォームではなく、非常に個性豊かな奥行きの
    あるプラットフォーム。
    様々な端末とユーザーに最速で価値を届けられるように頑張っていきましょう。
    これからも弊社での事例を中心に開発効率化のための知見を共有していきます。
    まとめ
    27

    View Slide