多様性ゆえの混沌～発見！バグランド

Android でゲーム作ろうと思ったら本当に泣けますよ。 いくらプログラムがバグっていなくても、微妙な差ってやつが機種毎に存在するから。 しかも今回の話は非常に興味深いことに、新しくて高性能なものがダメだっていう逆転現象を示していますから。

エントリーするのは以下の4選手です。
Galaxy Nexus （エミュレーター＝ヴァーチャルデバイス API 23 / Android 6.0）
LGE Nexus 5X 　（実機 API 23 / Android 6.0）
SHARP SH-02H 　（実機 API 22 / Android 5.1.1）
SONY SO-02F 　（実機 API 19 / Android 4.4.2）
エミュレーターっていうのは Eclipse とか Android Studio が再現する疑似マシーンですな。 Windows のパソコン上でアンドロイドの世界をシミュレートするわけです。 こういう回りくどいことをするとマシーンにかかる負荷が高いので、速度なんかは遅くなります。 しかし、パソコンさんの CPU（Core i5-6300U / RAM 8GB）がスマホの CPU より遥かに高性能であることを考えると、この勝負、まだまだわかりませんよ。

じゃあ何で勝負するかっていうと、私が開発中のゲーム「ダンジョジョの奇妙な探検」を実行したときの FPS です。 と、いっても 1秒10コマくらいに制御しているので劇おそなんですが…。 最初に断っておくと、四天王の中で最弱であるエクスペリア（単に古いバージョンだからですよ、中傷じゃなくて）さんですら、 スペック的には簡単にクリア。 1秒20コマでも楽勝でした。 じゃあ、1秒10コマであるなら、シャープさんもLGさんもヴァーチャルデバイスさんも余裕、余裕。 「朝飯前」どころか「新聞配達前」だバカ野郎！　と、思うでしょ？　しかし、そういった思い込みは思い込みにしか過ぎないのです。 我々は分かっているつもりで、分かっていないことだらけです。 実際にやってみることで意外な発見が意外とあるものです。

まずは標準記録のヴァーチャルデバイス選手から見ていきましょう。 8～9といったところですね。 写真（スクリーンショット）はごちゃごちゃしてますが、水色の四角で囲っている部分に描画速度を表示 しているわけです。 そこ以外は見るべき点はありません。

次に、LGE ネクサス5X選手。ネクサス選手はグーグルさんが標準機として提供するものですから、こういったリファレンス機でまともに動けば 設計者はドヤ顔できます。 実際には「動かへんのやったら、そのスマホのクセが悪いねん」と、UNKOユーザーに言えないのが客商売の辛さですが…。 で、ネクサス選手も7～9といったところですね、大差はありません。

次、シャープのアクオス選手。 問題児っぽいイメージが定着したシャープですが、携帯に写メ付けたのはこの方が元祖です。 目の付け所がシャープです。 スマホの製造販売も頑張っていて、2016年春モデル＝コンパクト部門の中では地味に最優秀であると思います、個人的には。 最大の特徴は薄いボディーとプラスチックな素材から生まれる体感的な軽さです（マシンの性能ちゃうんかい…）。 まあ正直なところ、しばらく使ってみた実感として悪いマシーンではないと思います。 しかし、どうしたことでしょうか？　、5～8とステージによってはかなり悪いスコアを記録しています 。 実際、4とか5になると処理落ちを嫌でも体感できるので「動き悪いな、こりゃ」と思うユーザーが大半でしょう。超マイナスイメージです。

最後にエクスペリア選手（SO-02F）。 国産アンドロイドの旗手、SONYさんのチョイ古モデルですね、2013～2014年発売くらいですね。 早い、早いぞ。10～11、他の追随を許しません。 11なんて数字は瞬間的であっても、他の方々はマークできません。 奴は四天王の中で最弱どころか圧倒的に最強・最速です。

茶番を読むのもしんどいと思いますので、先に答えを書きますが、 「背景を合成している場合、アクオス選手だと遅くなります」。 背景の合成って言っても、床部分と壁部分が別々にあるものを重ね描きしているだけです。 ただ、大きめサイズの画像であるということ、透過部分の面積が大きいこと、これがパフォーマンスの低下に影響していると思われます。 なぜなら、アクオス選手でも背景が一枚もののステージだと遅くならないからです（それでもエクスペリアより若干遅いんだけどね）。 上の画像は透過部分(alpha)の割合が非常に高いですよね。これが、描画の際に負担になっているのです。

この透過部分が多い画像をやめて、透過部分ナシの一枚絵に変更したところ、アクオスさんもスピードアップしました。 背景に限らず、モンスターのグラフィックにも透過が使われています（サイズが小さいので影響も小さいが…）。 アクオス選手の場合、この透過部分の処理が目立って苦手なようですね。 こういったメーカーのクセ、機種固有のクセっていうのがあるんです。 しかも、アンドロイドがバージョンアップしてキットカット(K)、ロリポップ(L)、マシュマロ(M)…と進化するたびに状況は変わります。 正確にはバージョンアップに対応したマシンが各メーカーから発売されることによって、クセの勢力図が一変します。 ネクサスと売れ線の機種（Sumsung の Galaxy とか）でデバッグして、その他大勢には目をつぶる…、 あるいはプログラム的に極力複雑なことをしないでクセによるばらつきを吸収するようなデザインを目指す。 個人製作なら好きなようにやればいいでしょう。 ただし、UNKOユーザーから「動かないから星1個」とレビューされる危険性は付きまといます。すげーストレス。

ここまで読まれた方は「じゃあ何かい？　アンドロイドは 4.X 時代の方が今より高性能だったとでも言いたいのかい？ 」と思うことでしょう。 しかし、そう云うことではないんです。 描画機能も含めて性能は後発の 5.X 6.X の方が高いことは間違いありません。 で、そういう最新のバージョンで推奨されるプログラミング技術というものがありますが、私のように5年遅れて Surfacce View を使い始めるような 旧人類もいるわけです。 旧人類の書いた旧コードを最新のマシーンで実行すると、何かがかみ合わずにチグハグ…。結果、「逆に遅いよ」という出来事だって起こり得るんだと。 右のタイヤをインチアップしてスポーツ仕様に変えたのなら、左のタイヤも同様にせねばなりません。 右側をハードの新旧、左側をコードの新旧と考えれば、バランスって大事ですよね。 まあ多様性ゆえのカオスと言えましょう。 当然のことながら、iPhone のアプリ開発であればこんな面倒なことは起こらないはずです。

Surface View は Android で描画する方法の一つです。 マルチスレッドであり、走らせているプログラム本体とは独立して動きます。 と、いうことはですね…、毎秒10コマ表示したいところが毎秒5コマしか表示されなくても、 裏では同じようにメインプログラムが動いているわけです。 なので、例えば4秒間である値が0から1,000まで育つとしますと、 毎秒10コマだろうが毎秒5コマだろうが4秒間で1,000に達するのです。 ただし、見かけ上では前者が数字を 25,50,75,100…　と刻んでいくのに対して後者だと　50,100,150,200…　と刻んでいきます。 例えばシューティングゲームで敵いっぱい出てきて画面が遅くなった、という場合は実際に弾が画面の端から端まで到達する時間も遅くなる ことでしょう。 ある意味スローモーションモードなので難易度が優しくなります。 これとは違って、画面表示がモッサリでも弾が画面の端から端まで到達する時間は変わらない、ということです、Surface View　ってやつは。