Androidアプリ開発における端末多様性の問題 (2)

前回「互換性については注意すべき点を踏まえて設計段階で気を付けていれば、ほとんど問題出ないよ」的なことを書きましたが、今回は「100だの200だの端末出てるのに検証どうするんだ」という話。


■いきなり結論
 結論を言いますと「全検証なんて元より非現実的なんだから、動作確認環境だけ示しておいて動作『保証』はするな、サポートのために手元に置く端末は比較的少なくても可能」ですかね。
 だいたい「検証しないとサポートなんて云々」とかいうバカな人が(特に日本では)散見されますが、現実問題としてPCでもガラケーでもiOS向けですら全検証なんてしていないでしょう?
 また、クオリティアップのコストパフォーマンスとしても割に合いません。
■その心
 「全端末で検証」したからといってバグは無くならないし、恐らく減りもしません。
 Android程度の互換性を持つ環境であれば、互換性に起因する問題が起こるよりもそれ以外のバグの方が圧倒的に多いです。
 こういう状況下では98%のクオリティまではすぐに行きますが、これを99%に上げたい時に全端末検証とかしても99%にはなりません。恐らくほとんど成果がない上に、そこに掛けたコストによって他のクオリティアップ機会を失います。
 そのリソースはUIの使いやすさとかそういう検証に回すべきです。リソースは無限ではありません。
 ちなみにある程度人海戦術で検証する価値のある点としては「(通信をするアプリにおける)様々な弱電界・圏外パターン」があります。暇があったらそいいうとこを手厚く検証しましょう。
 繰り返します。リソースは無限ではありません。
■機種依存のバグ報告が来たらどうするの
 経験則では報告の99%は機種依存ではありません。たとえユーザが「機種Aでは動いたが機種Bでは動かない」と言ってきても、です。
 きちんと再現条件を確認しやすいような報告手段を用意して下さい。検証がどうこうよりそっちの方が重要です。サポートの最大の敵は誤報告です。
 そこまでスクリーニングした上でまだ残る場合、機種依存または機種ごとに再現性が著しく異なるバグである可能性は否定できません。この場合は「見捨てる」か「エスパー対応」か「実機を入手」の三択くらいになります。エスパー対応するにはユーザの協力が不可欠ですが、まあユーザが非協力的(というか誤報告連発)だと実機あってもアウトという現実も。
■実際の検証方法
 Tuboroidのような事例に関して言えば極論言えばHT-03Aを1機でもいけますが、どの程度のクオリティを求めるか、どの程度のサポートを行うかによって変わってきます。
 ただし1機で通信を伴うアプリを作る時は「3GとWiFiが両方使える端末」を選んで下さい。前述しましたが圏外処理の検証はとても重要で、実際に持ち歩いてみないと分からないことが多いです。エミュではまず網羅できません。
 端末が1台の時、基本的な検証をエミュで行い、「実機」でないと出来ない検証をその1台でやることになります。
 エミュでは、解像度ごとのレイアウト確認と、OSバージョンごとの初歩的な動作確認が可能です。Android端末をハード丸ごとエミュレーションしているので再現性は非常に高いですが、かなり重いことと、入力系が比較的貧弱なことが弱点です。当然ながらマルチタッチの検証なども難しくなります。またOpenGLや動画関係も苦手です。
 実機では、他アプリとの連携や、実網で通信が不安定な時の検証を行います。またUIそのものの使いやすさのチェックも重要です。
 細かい注意点としてはアプリがSDK4開発であれば普段使うAVD(エミュ設定)か実機のどちらかはAndroid1.6にしておくべきです。1.6→2.1で増えるバグはほとんどないですが、1.6→2.1でバグが減ることはしばしばあります。このため環境が2.1ばかりだと2.1で直った1.6のバグを踏んで爆死する可能性が否定できません。
 実際にTuboroid程度のアプリであればこんな感じに開発・検証1人で実機1台とエミュだけであの程度の互換性は叩き出せます。まあ俺に出来るんだから誰にでも出来ますよ。
■複数台用意する場合の指針
 俺自身が複数台の実機が必要になったことはないので(持ってないわけじゃないけど)、ここからはある程度想像で補っている部分もありますが、複数台用意する場合は以下のような点に気を付けてなるべく「被らない」ように持つといいと思います。
・トラックボールやキーボードの有無、マルチタッチサポートの有無
 複数台用意するなら色々な入力方法の端末があった方が検証幅が広がります
・第一世代と第二世代
 いわゆる第一世代端末(MSM72xx)と第二世代(snapdragonまたは相当品)は両方あった方がいいと思います。
 APIレベルでは完全互換でもスレッド周りのデバッグはCPU速度に応じて再現性が不規則になりがちです。
 またOpenGLの検証では恐らくこの2つの世代は必須です。第一世代=OpenGL ES 1.x、第二世代=OpenGL ES 2.x、とハードレベルではっきり分かれています。2Dだから1.xと割り切って第一世代端末しか用意しない、または2.xと割り切って第一世代切り捨て、とすることも不可能ではないと思いますが……。
 Xperiaはハードが第二世代ですがOS(1.6)が第一世代なので検証端末としては向かないっでしょう。
・GPU違い(ATI系、PowerVR系)
 クアルコムのチップセット(MSM~とかQSD~とか)はATI系ですが、Samsung端末はPowerVR系です。
 こないだのGDDで聞いた分には気を付けていれば大丈夫っぽいのですが、もしかすると両方持ってた方が保険になるのかもしれません(曖昧)
・もっと色々端末用意したい
 ここから先は「互換性」よりも「物理形状の違いによる使い勝手の差」を幅広くとった方がいいと思います。
 つまり、「大きい端末」と「小さい端末」の使い勝手の違いとか、「デフォルト縦長画面」と「デフォルト横長画面」の使い勝手の違いとか、「(dip換算で)画面の狭い端末」と「広い端末」の違いとか、そういうのです。タブレット型なんかも視野に入ってきます。
 例えばQVGA端末で使いやすいからと四隅にボタンを設置したら4.3インチFWVGA端末では地獄みたいな問題をチェックするために集める感じですね。
 この辺の端末で実際に使ってみて使いにくかったら「より幅広く無難なUIに変更する」「リソースを分ける」「設定で切り替え可能にする」などの対応を検討します。
■まとめ
 端末を何台用意するかはどの程度のクオリティ・サポートを求めるかによって変わってきます。
 しかし、互換性のために用意しなければならない台数はさほど多くありません。今なら4機くらいあればエミュ検証との組み合わせで、世界中のAndroidMarketコンパチ認定端末について99%の互換性を確保することは可能だと思います。まあシェアの大きい端末を優先的に用意しておくのも手です。
 それ以上の台数を用意する意味はひとえに「フォームファクタの差による実使用感」の検証がメインになります。互換性云々よりこっちが重要です。とはいえこの辺の作り込みはどのくらい気にするかの問題ですけどね。

“Androidアプリ開発における端末多様性の問題 (2)” への1件の返信

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です