死んでしまったOSたちへというのを読んだ。今Aから始まる名前の会社がどうなっているかは知らない。
僕が携帯電話端末の開発をやっていたころ、いろんなところでモバイルOS、というかプラットフォームを開発しなければいけないという話が挙がっていた。ただ、当時期待されていたことを行うには開発者の力量もヒトモノカネのリソースが足りなかったり、それにも関わらず方向性が二転三転するなどでリソースを無駄にしたりして、結局うまくいかなかった。
日本の家電メーカの場合、事業部が赤字転落するなどで、すぐにプラットフォームを作るどころではなくなってしまう。あれは非常に良くない。
Androidは特に1.5から3.0あたりまでの開発スピードが物凄かったと思う。iPhone登場を受けてのタッチUI対応・高解像度ディスプレイモデルに向けたマルチDPIへの対応、そしてJIT、Cocurrent GC対応、GPUによるハードウェアレンダリングを短期間で難なく実現してきたときは本当にびっくりした。ああいうのは世界トップクラスの技術者を引っ張ってこれる組織でないと無理だ。
話は変わってAndroidのソースの中には、正直初心者から中級者くらいまでの人には読めたもんじゃないコードがいっぱいある。
具体的にはAndroidで動く全てのアプリをコントロールするActivityManager、その中心になるActivityManagerService.javaというファイルを見てみればいい。この1つのpublic classのソースファイルは2万行を超えており、もう数えるのが嫌になるくらいのinner classがあり、500行を超えるメソッドが複数ある。他にもViewRootImpl.javaというクラスのperformTraversalsというメソッドがある。これは画面に表示されているUI部品の描画処理の根幹を成すメソッドなのだが800行近くあり、「1つのクラスは1000行までにしましょう」とか真面目に言ってる人が見たら発狂してしまうかもしれない。しかもこれらは最近こうなったわけではなく、僕が初めて見たGingerBreadやICSのころからずっとこんな感じなのだ。
これは、「俺たちの優先度はこの部分のコードを綺麗にすることではないんだ。ここは放置しておいても近い将来には問題にならないんだ」という取捨選択のもとに汚いまま放置されているのだと理解している。それか本当に複雑で最適解がこれなのかもしれない(つまりクラスやメソッドを分割してラビオリ化するよりは長いメソッドでコードの流れの追いやすさを重視した結果ということだ)。とにかくたとえばここで語られてるメソッドを短くしましょう、を教条的に信じている人が書いた綺麗なコードよりも、この全くよくわからないperformTraversals()のほうが数千万倍も使われているというのが事実なのだ。
僕がAndroidのコードをいじっていたのはICSあたりまでだったので、JellyBeansで採用されたProject Butterが結局どういうものなのかちゃんとわかっていないかもしれない。その他のグラフィックス関連についてもおおよそ理解しているつもりだけど僕の知らない工夫がいっぱいあるのかもしれない。とりあえず「Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム」は予約した。
