androidの中核であるframework周辺を読んで思ったこと。

• zygote起動していきなりjavaの世界に移り、本当にnativeが必要なとき *0 以外はjavaで動かす
  • 作者のjava愛を感じた。単に楽をしようとすると、こうなるのかもしれないけど
• androidのdalvik+frameworkという構成って、jscore+domのwebkitとやりたいこともやっていることも根源的には同じ
  • 世の中のフレームワークとHTMLの世界が近づきすぎてしまったんだよね。AndroidやiPhoneが目指す世界より、Chrome OSやWebOSが目指す世界が実装的にも重複がなく美しいのは間違いない
  • ただ、HTML5ではまだAndroidやiPhoneのシステムの代替に成り得るほどの思想 *1 も実装も無いので、Chrome OSが天下を取れるとしてもさらにその先の時代なんだろう
• 全体的に効率最重視ではなく、コードの最終的な整合性を重視している？
  • 速度の要求されるイベントハンドリングや描画においても、Binderでプロセス横断しまくる仕組みであり、ms単位で速度を削ろうとか、リアルタイム性を上げようという意志が感じられない
  • いや、経過時間に関するLOGをかなり吐くようにはなっているので、パフォーマンスには相当気を使ってコーディングしているのは確か。ただ枠組自体の遅さがどうしようもないというか
  • イベントキューにも優先度とかないのも硬直する原因か？
  • ただし、そういう細かい気遣いが仮にできても、stop the worldなgcが硬直の支配的な要因ぽいからやはりiPhone的操作感への道は遠い
  • おそらく全ての遅延を潰す無理目な高速化を頑張るくらいなら、その時間を機能向上に繋げ速度はハードの能力に任せるのが正しい戦略だろうし、実際そうやっているのだろう
• と言いつつ、やっぱ読むだけじゃ分からん。最適化の話はログ吐いたりプロファイルして数字出さないとボトルネックもよく分からないし

dalvikあたりはadamrockerさんが一部解説していて勉強になります。
http://www.adamrocker.com/blog/246/overview-of-the-dalviks-gc.html
http://www.adamrocker.com/blog/248/overview-of-the-dalviks-object-management.html

アプリには直接関係ないけど、プロセス間通信を担うbinderは元々BeとPalmで開発されたものなのだそうな。
http://en.wikipedia.org/wiki/OpenBinder
詳しくはここ。

ざっくりとしか把握していないけど、ポイントは、

• スレッドプールを作ってスレッドマイグレーション *2 をエミュレートする
• オブジェクトのプロセス間のマッピングを行う

なのかな。
ただ、他のIPC、例えばCOMでも似たことはできると思うので *3 、根本的な違いはなんだと言われれば使い方を限定して単純化したところなのでは。
COMなんて覚えなきゃいけない概念が多くて教育コストが掛かりそうだけど、BinderはIPCであることすらあまり意識せずに扱える。単純にすれば高速化もやりやすい。

って深く知ればもっと違いが見えてくるのかもしれませんが。
ということで、勉強不足ですまんかった。