アプリで予期せぬ通信が発生し、不本意な帯域を使っている。そんなバグを直そうとまずは network traffic を記録する instrumentation を足してみる。今までも Log に URL をダンプするフラグみたいのはあったけれど、もうちょっとマシなものが欲しい。

最初は HTTP の API 前後をフックして記録してみたが、それだけでは不十分と気付き TrafficStats も併用することにした。コードの中で適当な処理の開始と終了のタイミングをマークし、その間の traffic を求める。ついでにテストオプションで起動時から現在までの traffic も記録できるようにする。

HTTP の API をフックするだけだと不安だった理由はいくつかある。一つは response のヘッダに Content-Length が入ってないことがあり、そのとき圧縮展開前の body の長さを知るのは難しそうだったこと。あとは依存しているライブラリの奥の方で自分の知らない HTTP ライブラリなどを使われるとフックしきれない心配があったこと。そして WebView みたいなネイティブコード内の出来事も記録したかったこと。TrafficStats は OS から値を読むので漏れなくデータがとれる。誰かが QUIC で UDP を話しはじめると詰んでしまうけれど・・・。

最初は記録したデータを analytics のインフラに送り集計しようとぼんやり思っていたけれど気が乗らず、かわりにテスト用の Activity をひとつ足してしょぼい Dashboard にしてみた。けっこう良い。もともと analytics 側で何らかのクエリを書き anomaly を探す気でいた。けれど現状の理解が足りていないせいで前提となる normal な挙動をわかっていなかったと気づく。

アプリの状態を観察する仕組みは、一番素朴なプレインテキストのログをさておくと Stetho みたいになんとかワークステーションで表示しようとしたり analytics にデータを飛ばして集計したりしたくなる。でもアプリに UI をつけるのが良い場合も多い。何かを試して結果を見る iteration も速いし、Dogfood build に同じ UI を入れておけばバグ報告をしてくれた人に情報収集を頼んだりできる。USB ケーブルを刺し adb bugreport してくれ、とはなかなか言えない。そして bugreport のダンプに必要な情報が含まれているとも限らない。とはいえ Activity#dump()  は、それはそれで実装しておきたい。

などと思いつつ Jake Wharton のサンプルアプリ u2020 を眺めていたらすごいがんばったかんじの dashboard が実装されたいた。さすがだ。自分のチームは弱小のためこのへんがいまいち整備されてない。社内のでかい/新しいアプリは色々工夫してるのだろう。誰かに知見を集めて欲しいもんです。と、ここに書いても仕方なし。