Battery Historian (GitHub) というツールがある。Android の bugreport  dump を時系列に可視化してくれる。名前からもわかるようにバッテリーの浪費をチェックするためのツールだが、結果としてシステムの挙動を longitudinal かつ holistic に眺める役に立つ。Systrace のように細かいことはわからないが、そのぶん広い時間の幅をカバーしてくれる良さがある。なんだかわからない性能バグがやってきたら、とりあえず軽く Historian をチェックする。

このツール何がすごいかというと、必要な情報はぜんぶ bugreport dump から集めているところだよな。

Android の bugreport dump はすごいアドホックな非構造テキストデータの塊で、基本的には logcat  バッファの中身と dumpsys にはじまるいくつかの inspection 系コマンドの実行結果が詰まっている。ないよりはマシだが、しょうじき大したデータではない。Historian はそのしょぼいデータをまあまあいい感じに可視化し、なんらかの知見を引き出している。もちろん中の人が作っているので Historian 自体の必要に応じ OS が収集しているデータもあるだろうが (batterystats とか), それにしてもこのしょぼい中がんばったなと感心する。

常識的に考えたら Android がやるべきことはシステムの活発度に応じ粒度を変えながら iostats やら vmstats 的なデータを構造化した状態で time series 用 ring buffer のストレージにダンプし続け, かつそのストレージを様々な subsystem から書き込めるよう公開し、システム全体の時系列のロードを常時収集のうえ bugreport に含めることである。ぜんぶ proto なサーバ側を見よ。

しかし Android にそうした大局的なまともさは期待できない。(いいかげんやってもバチはあたらないとおもうが。) かわりに正しい問題を見定めたビジョンと実力のある現場のエンジニアが手持ちの時間の中でギリギリできることをやる。その結果が Historian なのだろう。（きっと。）これは Android 的だなと思う。Systrace も似たような雰囲気あるでしょ。

こうしたツールやシステムに対する自分の気分は複雑。ギリギリじゃなくてちゃんとまともにやれと思う一方、まともにやろうと人を集めて作ると大げさで使えないゴミの負債を生んでしまうのではという恐怖心もある。オープンソースな世界だと市場原理でいいやつが残る期待があるけれど、企業のコードベースというのは計画経済で、かつオープンなプラットフォームだと一度入れてしまったものはゴミでもなかなか切り捨てられない (例: renderscript)。あんまりムリに背伸びはしないでくれよな、などと思ってしまう。我ながら上から目線な上に余計なお世話にもほどがありますが・・・。

Android に限らず、しょぼいが便利な内製、製品固有のツールやライブラリが本腰を入れたプロジェクトとして書き直されゴミ化する様を何度も見てきた。そのせいで警戒心がある。しょぼいツールに資源が投入された結果よくなった例もきっとあるのだろうけれど。

個人的な意見としては、問題意識のあるプログラマがヒマを見つけて気の利いたツールの萌芽を作り、それに気づいた周りのプログラマが手を貸し育てていく、というパターンが内製ツール成功の定石。Android のひとたちにはきっとヒマが足りてない。これも余計なお世話だが。

プログラマは適度にヒマにしておくのがよい。ヒマの大半は無駄に使われるだろうけれど、時々生まれる成果はトップダウンには置き換えられないものだから、それに免じて見逃してちょいだい。と思う。そういう意味で優秀なプログラマほどヒマなほうが良い。