一つ前の作業で Executor をフックすると既存のコードへの変更を小さく大局的な挙動をいじれるとわかったので、当初考えていた高速化を Executor 中心で実装してみる。Handler のようなゴミを直接使わずほぼすべての場所に Executor を配備仕切った序盤のプログラマは偉かった。しかし platform の API が Handler を要求してきて殺意。

いちおう design doc を書いて流し、大きな push back が無いことを確認。実際にコードを書いて試してみると・・・まあまあ速くなった。めでたい。コードを整理してレビューに出す。

レビューを待ちつつ次の手を考える。色々やりたいことはあるが、当面は UI Thread の高速化に注力しよう。複数の device / build flavor の組み合わせで Systrace のダンプを集める・・・のをいいかげん少しは自動化したいので Colab で適当なコードを書く。Systrace 開始、アプリ起動、Systrace 終了待ち、アプリ終了。ファイルを HTTP reachable な場所にコピーしてリンクを返す。これでブラウザから一撃で Systrace を取って表示されたリンクをクリックして結果が見られる。これよくね？100 年前から colab 化しておくべきだった・・・。

ダンプを眺めていると、当初の予定に反し UI Thread の外側にひどいコードをみつけてしまう。これなぜ自分のベンチマークは検出してくれなかったのだろうか・・・というと、レビュー中の自分の変更が入る前はスレッドの隙間に隠れていたのが暴かれてしまったのだろう。逆にいうと自分の高速化の効果はこの最近の変更のせいで目減りしてしる可能性がある。許すまじ。

一方、問題の変更はまだ Release flavor では有効になっていないので、自分の変更 (フラグなし) をさっさとコミットしたうえで あれらが Release flavor に来るのを待ち、flag flip のタイミングでベンチマークが検出するまで知らん顔しておくのも手かもしれない。どうしたものか。まあ自分の変更が入ってから考えよう。

Dev flavor と Release flavor の結果もやや違う。ベンチマークの結果も違うので当たり前ではあるが、Dev ばかり見てるのはよくない。

そしてデバイス間の差も大きい。やはり場当たり的なチューニングはもう限界で、なんらかのヒントに基づきコード自身がスケジューリングを最適化してくれないと厳しい。しかし今年の締め切り内にそれは無理げ。ほんとに？真の優先度はどうあるべきか・・・。

それはさておきどうも UI Thread に注力はまだ若干早そうな雰囲気。

といった見通しを得るにあたり colab は必須だったので、やはり 100 年前から使うべき。