写真のギャラリーアプリなどで、四角い画像をタイル状に並べているものが数多くあります。
こういった画面は Android なら GridView というものを使って簡単に作ることができます。
しかし、なにも考えずにアプリを作ると死ぬほど遅い、重い、スクロールがかくつく、最後には OutOfMemoryError で死にます。
1. getView() 内で処理をしない
GridView の一つ一つの Item を表示するのが getView() というメソッド。
ここでの処理が重ければ重いほどスクロールはカクツキ、快適度はさがる。
2. ViewHolder を使う
findViewById() 、 inflate() は遅いので View は出来るだけ使い回す
3. スクロール中は別スレッドで処理をしない
スクロール中にコンテキストスイッチが発生するのもカクツキが発生します。スクロール中は Object#wait させておくのが無難。
4. View の数を減らす
RelativeLayout の中に ImageView や CheckBox や TextView があればやめて、 3 つ内包したカスタム View をつくりましょう。
5. View の処理をやめる
ImageView の便利機能とかあるけどあれすら遅いのでカスタム View をつくって Canvas.drawBitmap するだけの View をつくりましょう。
6. GC を起こさないようにする
Bitmap#recycle のように、明示的にメモリ開放ができるメソッドがあるならばそれを使いましょう。
SoftReference は甘えです。 GC が起きた結果遅くなるのをあなたは理解していますか？
7. スレッドを作らないようにする
new Thread のコストは非常に高いです。適切に wait をする Thread を onCreate あたりで生成、待機させておき、スレッド処理が必要な場合はそのスレッドにお願いすると良いでしょう。間違っても仕事が出来てからスレッドを生成してはいけません。
8. インスタンスを作らないようにする
new Thread もそうですが、 new XXXX というものはメモリの確保やコンストラクタの処理を行なうコストがありますので、オブジェクトの再利用を出来るだけ行なうようにしましょう。間違ってもインスタンスが欲しくなってから生成してはいけません。
9. メモリを確保しないようにする
メモリを確保しようとすると GC が起きやすくなります。また、 JavaHeap のメモリ確保は十分に遅い。出来ればメモリは事前に確保しておき、それを使い回すようにしましょう。
10. 待ち合わせしないようにする
synchronized や Lock のような待ち合わせ機構を UI Thread 側で利用するとその分遅くなってしまいますので出来る限り使うのを避けましょう。
別スレッドならこの限りではありません。
