なるようになるかも

力は多くの場合、その人の思いを超えない。

「Android を支える技術 <I>」を読んだ。

この本いいよね…。

今 <II> も読んでるんですけれど、「uid ってどこで作られてるの?」っていう5年くらい疑問だったところが解決されてとても嬉しい。gid は意味なさそうなのになんで設定されてるの?っていうところまでは書いてなかったけど。

この本はものすごく技術書なんだけど、それでいて単純に読み物としても非常に面白いのですよね。

ガラケー時代の組み込みのようなアプリを作ってきた世代と、AndroidiOS でアプリを作り始めた世代の架け橋みたいな感じの内容というか、まさに自分が Linux カーネルとかいまいち分からず、Andorid のソースコードを読み解こうとしても低レイヤの世界で何が起きているのか完全に分かっていなかったところがあって、この本の内容はクリティカルヒットな感じでした。

ただ、アプリ開発しているような世代の人も、いまやスマートフォンコモディティ化して、アプリ開発の大規模化や長期化が進んだことで、「どうやってアプリを差別化してバリューを生み出すか」とか「どういう設計にすればアプリを保守していけるのか」みたいな、もっと上位レイヤな方向に興味が向かっていると思うのですよ。

この本がそういう方向で役に立つということはきっとなくて、でも、だからこそ、今このタイミングで、この熱量の Android 本が出てくるというところが感無量ですよね。

以下、サブタイトルが気になったので思うところを。

Project Butter

Android が「60 fps を実現するモダンな GUI エンジン」を目指していたのかというと、別にそうでもなかった気がします。

2.X 時代は GC で普通に固まってたから、Stop The World を回避するためにオブジェクトを作り置きするのが基本だったし、それで処理落ちを頑張って減らしたら実は液晶が 56fps しか出ないことを知って悲しみにくれたりしてました。

「ぬるぬるな iOS に対して Android はもっさり」が半ば諦めとして定着していたなかで、いよいよ Google が本気を出して改善に取り組みました。それが、Project Butter と呼ばれるものです。

しかしながら、この本では全然出てこない気がします。というのも、Project Butter が大々的に謳われていた JB の扱い自体がヒドいのです。曰く、「通常の使用に耐えなくなる」とか「停滞感と閉塞感」とか「開発者も普通っぽい」とか。

しかし、垂直同期が取れる Choreographer クラスが登場したのは JB です。それまでの Android は、なんと垂直同期なしでダブルバッファリングをしていたのです!バックバッファとフロントバッファの切り替えは何のタイミングでやってたの…?

これとは別に、トリプルバッファリングの仕組みも出てきました!(P233 を見るとこっちが現行の動きみたいですね)

垂直同期を取ってダブルバッファリングで描画する方法は、描画命令が 16ms 以内で収まる場合には理想的な 60fps になりますが、少しでも描画が間に合わなくなると、前フレームの描画でバックバッファがロックされている関係で、一気に 30fps に落ち込んでしまうという欠点もあるのです。

半分のフレームになるので、処理落ちした途端にガクガクになったように見えます。

これを抑制するのがトリプルバッファリングです。描画可能なバッファを常に裏に 2 枚持つことで、処理落ちでジャンクフレームが生まれても、フレーム落ちを滑らかにして分かりにくくする、という技術です。当然、画面 1 枚分の余計なフレームを描画するために、無駄な GPU とメモリを消費します。

JB の評判がすこぶる悪かったのは、そういう富豪的な改善方法に問題があったからなのでしょう。

Project Svelte

これに対して、機能を維持しつついかに軽量化するかというのが Project Svelte です。

この本にも KitKat で劇的に立て直したという話が出てきますが、その過程がとても面白いのです。メモリが 512 MB の改造 Nexus 4 を作って、開発チームはそれを個人の端末として日常的に使ったとかどうとか(KitKat開発者が語る、Android軽量化の裏話)。

これは現在進行形で、Android O でも引き続いてバックグラウンド処理の取り締まりなどで強化されていっています。

しかし、裏でどんだけ電力食おうが許される野放図な感じとか、暗黙の Intentでゆるくアプリ同士が繋がるのは、Android の魅力でもあったと思うので、どんどん世知辛くなっていくのは、ちょっとだけ寂しい感じもしますね。

なお、普段使いは iPhone なので、Pixel が日本で発売されるまでは、この辺実際どんな感じなのか知りません!

追記

<II> も読み終わりました。

アプリケーションの世界で閉じている iOS に対して、ActivityServiceContentProvider というコンポーネント単位で横断して連携できるアプリを、Intent という共通したメッセージングで行えるところが Android のよさだと思っていて、ちょっと Activity と画面遷移の話に寄りすぎかなぁという感想もあったりしましたが、おもしろかったです。

もうちょっと Linux カーネル力があれば理解度が上がったのになぁ…。

ところで、<I> の6章のグラフィクスアーキテクチャの話については、AOSP の Porting - Graphics を読むとより面白い気がします。おすすめ。