ベンチマークではよくcold startとwarm startを区別する。Warm startというのはキャッシュとかに欲しいものが入っている状態。Cold startは初回起動などでなんの準備もできていないケース。多くの高速化はwarm start をターゲットにしている。なぜなら事前に準備のできるwarm startの方が成果を出しやすいから。

あるときAndroidはデスクトップよりもwarm startしにくいことに気づいた。ディスクもメモリも帯域も少ないからキャッシュの使いどころが難しい。たとえばキャッシュをprewarmすべく裏で色々なものをダウンロードしておきたくても、下手にやるとユーザの帯域を浪費して苦情が来たりする。オンメモリのキャッシュも難しい。メモリ上に色々抱えているとプロセスが殺されやすくなる。だからうかつにデータをpreloadできない。どのみちメモリの少ないデバイスではforeground以外のアプリはすぐに殺されてしまう。事前に蓄える余裕がない。

最近、必要なファイルを少し早めにpreloadするコードを書いた。リリース後に速度をモニタリングしてみると、手元の計測よりずっと速くなっている。測定方法を間違えたかと不安になったあと、別の仮説に思い至った: ファイルのpreloadは、そのファイルがOSのpage cacheに載っていない方が効き目が大きい。自分の手元のベンチマークは同じシナリオを繰り返し実行し合計をとっていたけれど、おそらく初回以降はprefetchするファイルがOSによってcachedだった。つまりwarm startを計測していた。でもユーザの手元ではファイルがpage cacheから追い出されたcold startが支配的、なのではないか。ほんとはpage cacheの有無を記録して実証したいがそれを知るすべがない。無念。

ベンチマークのスクリプトにpage cacheをクリアするcoldオプションを足そう。

追記

ベンチマーク結果（実行時間）がめちゃ安定した。おすすめ・・・といいたいところだけれど root  をとったデバイスじゃないとだめなのが惜しい。adb とかでできるとよいのにね。