Android開発をする上で知っておいてほしいなと思うこと 2
上記の記事の続き。 開発時に引っかかりがちないくつかの注意点と、リリース時に知っておいたほうが良いと思うことについてまとめてみる。
開発時の知見
主にチーム開発時の注意点と標準ツールの活用、よく嵌りがちな落とし穴について。 前回記事の アプリの実装について でも少し触れていたが、もう少し広い範囲について必要だと思うことを書いてみた。
チーム開発の注意点
他の開発者と開発環境を揃えることで開発を効率化できる他、他のメンバーに自分の変更による差分をチェックして貰う必要がある。 また、Android開発者ではない人に対する技術的な説明もできたほうが良い。
- ビルド設定を整備する
- productFlavors, buildTypes でビルド設定を定義しておくと共通言語化できて開発時に役立つ
- よくある例： productFlavors で本番/開発の環境切り替え、 buildTypes で proguard の有無や署名設定などを切り替える
- ビルド設定ごとに applicationId を変更すると共存できるようになる
- その際アイコンやアプリ名も変更しないと区別がつかなくなるので注意する
- リソース定義について共通認識を作っておく
- リソースで提供できるコンテンツの種類、代替リソースの提供方法について人に説明できるレベルで知っておく
- 特にスタイルとテーマについて予めルールを作っておけると良い
- 具体的な方法論は公式ドキュメントには書いていないので先人の知恵を活用する
- デザイナーとのやりとりについて考える
- 「サイズ指定はdpで」だけでは不十分で、アプリが想定している画面サイズ(dpでみた解像度)を説明する必要がある
- 360dp以外の画面が存在すること、それらの端末で拡縮する部分についてわかるような指定をしてもらうようにする
- Vector画像リソースが利用できることを把握する
- 9patchの拡大ルールについて把握する
- 意外と注意点が多く、向かない用途もある
- 変更差分ごとにレビュアーが手元で確認できるようにする
- 開発者がapkをインストールして見せに行く方法では時間効率が悪すぎる
- DeployGate などでPRごとに配信するように設定すると良い
- 開発用サーバの用意などで常にレビュアーが変更内容について確認しやすいようにする
raw/やassets/を利用したデバッグ用の画面の用意なども検討する- コードを変更せずにデバッグメニューでAndroidアプリの動作を変更する - Qiita
標準ツールの活用
Android Sdk(とそこからダウンロードできる各種ツール)とAndroid Studioに付属しているデバッグ機能について。
- 最新機能のチェック
- コマンドラインツール
- APK Analyzer
- APKに含まれているリソースの確認やAndroidManiest定義の確認が簡単にできる
- Android Profiler
- CPU、メモリ、ネットワークなどのリソース消費がリアルタイムでわかる
- Layout Inspector
- 実行中アプリのレイアウト階層をみる時に使うやつ
- Hierarchy Viewer
- Layout Inspector と似たツール(こちらが古い)
- レイアウト描画時のパフォーマンス計測をしたいときに使う(そのうち Layout Inspector に統合されそう)
標準ツールではないがstetho などのデバッグ用ツールについても知っておくとより良い。
よく嵌まる落とし穴
- Auto Backup
- uses-feature の暗黙的設定
- 一部の uses-permission 設定は自動的に対応したデバイス機能の uses-feature 設定を追記する
- 通常あまり問題にならないが、AndroidTV向けの実装を同一apkに同梱する場合などに問題が起きる
リリース時に知っておいたほうが良いこと
リリース時にチェックしておくべき項目やアプリの公開に関する設定項目のうち知っておいたほうが良い項目についてまとめる。 基本的にほとんどの内容は Android Developers に書いてあるが、Playコンソールの新機能についてはPlay Console ヘルプ(英語版)のほうが詳しい時もある。 Playコンソールに関して迷ったり疑問に思ったらまずは公式のヘルプをあたってみると良い。
- Distribute on Google Play
- リリースに関する基本的な項目は Distribute 以下にある
- アプリのリリース前に一度は見ておいた方が良い
- Core app quality
- アプリが満たしておくべき品質のリスト
- 特に戻るボタンの動作の一貫性などは実装時から気をつけておいたほうが良い
- Launch checklist
- アプリ公開時に必要な項目のチェックリスト
- 必須項目ばかりではないが、知識として知っておいたほうが良いこともある
- Release updates progressively
- 段階的リリースでは公開率を段階的に上げるだけでなく問題のあるリリースを途中で中止することができる
- 問題なければ再開することもできる
- モバイルアプリは簡単にロールバックできないので、公開時のリスクを抑える方法として有用
- 段階的リリースでは公開率を段階的に上げるだけでなく問題のあるリリースを途中で中止することができる
- Run alpha and beta tests | Android Developers
- アルファ/ベータリリースについての説明
- インストールまでにユーザー操作が必要なため若干利用し辛い印象がある
- 後述のリリース前クラッシュレポートとあわせて一般向けではなく社内向けの開発版配信として使うのも良いかもしれない
- Use pre-launch and crash reports
- アルファ/ベータリリースとしてapkをアップロードすることでリリース前クラッシュレポートを利用できる
- Firebase Test Lab と同様のものだが、リリースフローの一貫に組み込むことができるのは便利
- Engage
- より利用されるアプリにする方法のまとめ
- どれでも利用できるというわけではないが、リンク先も含めて知識として有用
- Grow
- ユーザー数を増やす方法のまとめ
- Developer stories
- 成功者のストーリー一覧 -InstantApps でドーンみたいな話だけでなくPlayコンソールの細かいA/Bテストを繰り返したという話も乗っていてわりと実用的
まとめ
これで当初書きたかった内容は大体書いた。 ここまで書いてきた内容を振り返っても Android Developers は開発〜リリースまでを支えてくれる優秀な公式ドキュメントだと思えるので、安心して頼っていけそう。
