Androidのbinderのメモ

koba @tetsu_koba

initとZygoteはだいたいわかった。binderとかActivityServiceManagerが謎なので誰か説明して欲しい。

koba @tetsu_koba

概要を頭で理解したところで止まっていて、まだカラダで理解できていないのですよ。まだ目に鱗が張り付いたまま。 @magoroku15 binderはサーバプロセスとの間のRPCフレームワークです。....

八丁堀マゴロク亭 @magoroku15

binderはサーバプロセスとの間のRPCフレームワークです。一般のOSモデルではシステムコールを経てカーネルの共通サービス呼び出しますが。android APIの一部はbinderを経て他のユーザプロセス内部の関数を呼び出します。てなのを次々回LTで @tetsu_koba

八丁堀マゴロク亭 @magoroku15

言い換えるを垂直方向の呼び出しがシステムコール、水平方向の呼び出しがAndroid API(の一部) 水平には直接呼べないのでbinderを経由してＵの字で呼び出します。

八丁堀マゴロク亭 @magoroku15

RPCとIDLの焼き直しがbinderとAIDL

koba @tetsu_koba

RPCとIDLを勉強して外堀を埋めればいいのかな。

koba @tetsu_koba

いや、誰かのつぶやきで教えてもらった。 @androidzaurus うぉぉ。なんだこの良記事。あとでじっくり読む。発掘者はてつこばさん。 http://htn.to/qPxajR

koba @tetsu_koba

残念ながら http://www.openbinder.org/　のページは今は失われているらしい。変なロシア語っぽいものしか表示されない。

koba @tetsu_koba

字が細かい英文のサイトは読んでると集中力が続かなくなる。こんなときはブラウザの 表示 > ズーム > 拡大　を4回くらい押してプレゼンのスライド並みのデカイ文字にして読む。

koba @tetsu_koba

素晴らしい。openbinder.org が保全されている。 @androidzaurus http://replay.waybackmachine.org/20061205015100/http://openbinder.org/

koba @tetsu_koba

わかった！　見えた！ アハ体験だ。Binderによるリモートプロシジャーコールを少しカラダで理解した。

koba @tetsu_koba

ActivityManagerNative.getDefault().startActivity からプロセスをまたいで ActivityManagerService＃startActivity が呼ばれるまでの行程をソースコードで追ってみた。そしたらbinderが理解できた。

koba @tetsu_koba

binder: どのプロセスで実行されるのかは気にしなくてよい。もしもそれが自分のプロセスの中にあるものだったらプロセス間通信は行われずに直接呼出しになる。賢い。

koba @tetsu_koba

ドミノ倒しのように理解の範囲が広がっていく。これは快感。

koba @tetsu_koba

ソースコードを読むときの三種の神器はgrep, find, emacs。

koba @tetsu_koba

TLS(Thread Local Storage) を上手に使えば、スレッド間の排他制御を減らせるということか。なるほど。

koba @tetsu_koba

プロセス内で一回だけopenして、そのfdを複数のスレッドでロックせずに共有して使うというのは普通はダメな気がするけど。

koba @tetsu_koba

Androidのbinderはいろいろ工夫されてるのがわかって面白い。初めはこんなの既存のソケットを使っても同じじゃんと思っていたけど。なるほどね。

koba @tetsu_koba

似たようなプロセス間通信でもD-Busはsocketの上に構築されているので、binderのように独自のカーネルドライバは必要としない。なぜbinderはこんな実装になっているのか？

koba @tetsu_koba

Androidではbluetooth用にD-Busも載っている。

koba @tetsu_koba

socketの場合カーネルの内部状態はfdに紐付けされてる。だから複数スレッドで使うときにはスレッドごとにopenしてfdを取得するべき。binderの場合は内部状態はpidに紐付けされている。userland側の状態もTLSを使うことでスレッド間の排他制御が不要になる。

koba @tetsu_koba

その代わりにbinderではひとつのスレッドでは複数のセッションは張ることはできない。ユーザープログラムが自分で直接/dev/binderを扱うことは想定していないと思う。必ずライブラリを経由して使う。

koba @tetsu_koba

binderのサービスをどのプロセスが提供しているかを管理しているのが/system/bin/servicemanager 昔はこれは/system/bin/runtime でやっていたらしいが変更された。

koba @tetsu_koba

"Binder Thread #2" などの名前のスレッドがリモートでのメソッド実行の要求を受け付けるサーバスレッド。受付待ちのスレッドの数が0にならないように必要に応じてスレッド数が増える。受付タイムアウトになるとスレッドを減らすが最低1つは残す。