This document written: 2014-05-23 .. 2014-05-31
第 4 章の最後に著者の Mario 先生は、「ベストプラクティス」と題打って、Android の Dalvik VM のパフォーマンス上、避けるべきいくつかのポイントについて完結に列挙しているが、意外とこういう話は貴重だと思う。
+ 演算子を使うことも避け、StringBuffer クラスを使う。ボックス化されたプリミティブ型（Integer 等）の使用は避ける（理由については『Effective Java』を参照）。SparseArray は元より、StringBuffer というものも使ったことがなかったりするので、結構、目から鱗だ。
自分は元々、スクリプト言語として Perl を良く使っていたので、メモリーの消費を少しでも抑えようと、ローカル変数の生成を避けて、変数の使い回しをするようなコーディングスタイルが好きだった。しかし、Java を勉強していて、むしろ Java では使い回しを避けてどんどんオブジェクトを使い捨てるようなスタイルが推奨されていたため、Android でもそのようなスタイルを積極的にとっていた。確かに、変数を使い回していると、元の値が不測のエラーを引き起す可能性もあるし、そもそも離れた場所で宣言された変数を追うのはコードの見通しを悪くする。Java で推奨されるのは、できるだけ遠くに変数が散らばらないようにするためだろう。また、最近の Java VM はガベージコレクションの性能もかなり上がっていて、メモリーの浪費について、あまり気にしなくともいいという話も見掛けた。もちろん、Dalvik ではない、普通の PC 用の Java VM の話なのだろうが。
しかし、Android のゲームプログラミングにおいては、オブジェクトをどんどん使い捨てにしたら、ガベージコレクションへと突っ走ってしまうので、そういう観点からすると、Perl で行っていたように、メモリーの消費をできるだけ抑えた節約スタイルのコーディングがパフォーマンス的には最良の選択だというわけだ。
もちろん、上記のポイントは絶対ルールではなくて、主にパフォーマンス上の理由だったりするので、あらゆる場面で厳守するものではない。基本的に、メインループと関係するものが対象となるだろう。実際にマリオ先生のフレームワークにおいても、ただの初期化ルーチンだとかにおいては、普通に文字連結で + 演算子など使っているし、getter/setter にしてもそうだ。