Androidアプリ開発で気をつけたいポイント４つ
基本的に最近関わったプロジェクトでの反省点ですが組織批判や個人批判をするものではありません。
まず、パフォーマンス的な観点から
1、扱うデータ、画面が増えた場合。
- 画面数が10
- データのテーブル数が10
- 各テーブルのデータフィールドが一つでも30
- 扱うリストが３つ
を超た場合
一つでも超えたら注意です。炎上する気がします。
感覚的な問題で悪いのですが、画面数が多いとデータの取り扱いの考慮漏れが仕様レベルで頻発している気がします。テーブル数も複雑化すればするほど、あとでこうしなければOOM（out of memory)やANR(application not responding)の問題が回避できなくて大幅な変更が必要。なんてことが割りと簡単に発生します。マジで。
さらにコード量も必然と増えますから、バグによる修正でのコスト増大も考えられます。なので画面数、データ量が増えるとコストも指数関数的とはいかなくても二次関数的に増える事と考えてください。
対策
- 画面数を少なくする。
目的とそれを達成するための必要十分条件を再確認し、作る側のエゴで画面が増大していないかをチェックする。画面数が減れば自然とデータの総数が減るので、わりと安全なマージンをもって開発が可能になる。
- どうしても超えてしまったら、問題発生を覚悟する
Androidの開発自体が割りと低コストで見積もってしまいがちだと思うので、問題発生になりそうな箇所を予め特定しておいて、充分なマージンを確保する。
- 一度にメモリ上に展開するデータのサイズを小さくするよう設計する。
各処理フローの先頭（フロー遷移はFragmentで行う、データはFragmentActivityが持つ、処理フロー間のデータ連携は永続化データにより行う、だだし必要であれば永続データの暗号化・復号化処理は自前でする必要あり）、または各画面に必要なデータだけを受け取る様にし、できるだけ不要なデータを長期でヒープ上に保持しないように設計すべきです。シングルトンに丸投げしてメモリ上に全部持ちなんてことはしないようにしましょう。それは悪い設計です（特にAndroidにとっては）。またシングルトンをAndroidで扱う上での問題（中断時に全て破棄される場合がある）も別途発生します(nullだったらフローの最初にもどしたり、通信発生させるかさせないかのチェックとかめんどくさい)
- 各データフィールド(というかテーブル)毎ライフサイクルを明確にする。
- どのフローではnullで、どこからはnullではないのか。
- そもそもnullがあり得るかあり得ないか。
- 最初のデータフィールド生成はどこか。（最初はクライアント=アプリ側で生成したデータを登録に使うことが多い）
次はレイアウトに関わる事。コスト的な観点とか。
2、画面解像度の問題
どのように対応するかは画面の特性に依存しますが、過小評価していいポイントではありません。
Androidでのレイアウトは基本、画面の縦横比や解像度の違いの吸収を考慮するために以下のポイントでレイアウトを作成します。
- 比率(LinearLayoutのweightを利用)を使い上手く画面にすべて表示されるように作成
- 最小構成をdpサイズで指定してScrollView上にリスト形式で作成
- 一枚絵をアスペクト比を維持しながら拡大縮小させるように作成し、縦に余る部分は伸縮させる余白やUIを作成する
その際のレイアウトで難しいのは
- 9patchとして作成された画像パーツを9patch画像サイズ以下に縮小
伸縮させない部分の画像が重なる
- mdpi、hdpi、xhdpiなどの画素密度グループが異なる場合の文字サイズにspを使っていて各パーツにはdp指定を使っていた場合のバランス調整
spはOS側の設定（文字サイズの大・中・小）に左右されていて、バランスが崩れる要因になりやすい（がユーザを老若男女に合わせた時は文字サイズはsp指定が望ましい）
- 縦横比を維持したままの画像のサイズ調整
(参考:横幅に合わせた画像のサイズ調整について)
があげられます。
対策
- レイアウトxmlを作る人とレイアウトをデザインを作るデザイナーは一人もしくは、別々でも最初の画面イメージ作成時に頻繁に意見交換をする
これって意外とやってないんですよね。ですけど、google playにリリースを目指して作る上では、対応端末のことを考えられる人の知識が必要です。画面の縦横比率とmdpi〜xhdpi毎の画像のサイズを計算した発注ができるかできないかで発注する画像の数や作成方法が変わりますし、メンテナンスコストも変わってきます。Androidに合わせたUI設計というのもとてもユーザビリティの観点から重要になります。
- 対応端末を早めの段階で特定しておく
厳密でなくていいです。縦横比からみてどの比率までなら同じレイアウトでサポート可能なのかを予め区切っておく必要があります。またレイアウトを実装する人には対応画面の比率の情報は伝えてください。またデザイナーさんとレイアウト(xml)を実装する人の間で入念な確認が必要です。(間違ってもiOSベースでレイアウトを作成しようなんて考えないでください、ユーザビリティ上の問題や、比率が違う際のレイアウトの崩れで画面一つのレイアウト作成にかけるコストが増大します2倍くらい)
- 各UIパーツ毎にサイズを定義したdimens.xmlでの定義を作成し、各UIパーツ単位で解像度の違いを吸収する
アタリマエのことなんですけど、全部一括返還とかでdp指定してるところを置換処理でサイズ変更対応なんてことしてると、まず管理が大変なので置換処理をミスってしまうと結構コスト増になります。さらに一括で返還がうまく言ってもレイアウトが崩れる問題も付随してきます。
大部分はコード上でサイズ指定する対応はもってのほかです。レイアウト上で管理されない画面ほど、のちのレイアウト修正のコストが増大します。
3、最小限リリース範囲を決めておく
これは開発のスタイルや、企業向けシステム作成ではな話が変わってくるのですが、通常の一般ユーザ向けにアプリをリリースする前提で考えるなら、期間内に出来なかった場合も考えて、どの程度なら最初のリリースを行っても大丈夫かを定義しておく必要があると僕は考えています。それによって作業の優先度も変わってきます。これは企業向けで作っているシステムの開発やパッケージ化されたコンシュマーゲーム開発をされてきた方々にはあまりない考え方だと思いますが、最初から考えたものを全部盛り込んだものを出すよりも、売れるか売れないかを左右するコアのコンテンツに対する市場の反応からのフィードバックに対して、戦略をもって対応することが市場で勝ち残るための運営上の最低限の基本的な戦略で、それに対応するための考え方です。
更に言うと、フィードバックで対応する範囲（しない範囲）も決めておくべきです。想定される変更範囲を特定が必要です。課金コンテンツの追加・変更、機能拡張（ここが一番難しそうですが）、UIの調整、コンテンツの処理フロー、他サービス（アプリ）との連携方法、他サービスとの連携に近いですが、SNSを使った口コミプロモーション方法。ここが考慮されていなければ、大部分がフィードバックによる変更に多大な影響を受けてしまいがちです。逆に考慮されていれば、考慮を盛り込んで必要最小限の設計をすればいいわけですから、少し設計でコスト増になっても予算配分的に充分回収出来る範囲で開発できるはずです。まぁそもそもアプリが売れるか売れないかという問題がありますが。収益を回収できる確率を上げるための「最小リリース」と「効果的な改善戦略」というポイントはとても実用的な戦略だと思っています。個人的にはアプリリリースが迫っている中で、成長プランを複数設定していなくて、さらに他と同じでいいやとか考えている会社って正直アリかナシかといわれたら「無いわー」って答えます。
とりあえず今売れているアプリがどういう成長過程をたどっているのか、できれば最低10パターンはほしいところですね。そこからシナリオを何個かつくるのも開発と平行してやっていくべきだと思います。
4、通信のタイミングは早めに決めておく
あーでもないこーでもないとふらふらしてると設計段階から通信を想定しなかっただの、不要なコードが紛れ込むだの、変更を許容しないから全部改変、などメンテナンスが大変になります。
最低限最新の情報が必須になる部分とそうではない部分、ユーザが変更したデータの更新によるデータ同期が必要になるポイントを絞っておくと設計と実装でコストが余計に増える確率は減ると思います。
んで、これらはプロジェクト全体で共有されている必要があります。
細部の実装の設計にも影響が出てくるからです。最低限開発者が知らなくていいのは各種方面との契約詳細、法律に関わることでしょうか。
とりあえずこんな感じかなー。適当で申し訳ない。
文自体や、考え方、細かな勘違いにツッコミがあればよろしくお願いします。
