http://atnd.org/events/15437
以下めも
■Inter-process communication of Android
@tetsu_koba (Tetsuyuki Kobayashi)
LinuxCon
Androidのプロセス間通信
メソッドのインボケーション
ashmen
system propertiesの管理が面白い
起動時のPSコマンド（途中省略）
３０個のプロセス
→２００個のスレッド
互いに通信するプロセス
概念図
Activityが起動するときはマネージャーからの指示で動く
他のシステムとやり取りして動いてる
→カーネルが提供するシステムコール
プロセス間通信の抽象的な度合い
Binderが一番濃い
AIDLがマップ
Intentが一番抽象的
ashmem
→共有メモリ
Intentに関して
リクエストはキューイングされる
→順番に実行されるからマルチスレッドは簡単
かなりパワフル
inter process method呼び出しで実装される
Intent
loosely coupling
とりあえず投げるだけの実装
→システム内で適切なのが処理してくれる
→Actionでもっと面白い動作ができる
View + "http://〜" → ブラウザが起動
VIEW + "geo:0,0?q=Tokyo"
システムサービスで使われている
メソッド間呼び出しはマルチで呼ばれる
→マルティスレッドを考える
AIDLつかうよ
インターフェースを利用したメソッド呼び出し
callerとcaleeの関係
インターフェースで実装は切り離される
どうやってつながってる？
プロセス間はカーネルのバインダーを使う
proxyでメソッド間を呼び出す
BinderThreadが待ってる
ビットシーケンスをjavaのオブジェクトの形になおしてcalleeを呼ぶ
returnValeeは逆の処理を行ってcallerへ渡す
android.os.parcel
オブジェクト知り洗いジェーションを伝統的には使うがandroidは違う
メモリ空間も別
flatten
立方体をバラしてFAXで送って、受信側で組みたてるイメージ
UMLで表した形
ProxyとStubがinterfaceを実装
CallerはInterfaceを知ってる。
CalleeはStubを実装している。
みするとバグがよくわからなくなる
→AIDLを利用して解決している
→ProxyとStubは自動的に生成される
プロセス間メソッド呼び出しの例
Activiyがポーズするときの例
１、schedulePauseActivity
２、binderThreadが待ち受ける
３、Looperで実行する
Binderはカーネルのデバイスドライバ
/dev/binder
特定用途にチューニングされている
マルチスレッドに特化している
socketと比較
伝統的 rmi
ソケットで呼び出し
なぜ特別なドライバを用意したのか？
どこまでよみかきしたのか？
binderはプロセスごとに保持される
FDを同じプロセスごとに共有できる
よみかきはどうする？
ソケットはstream
バインダーは一度のioctlでよみかき
オーバーヘッドが減る
ネットワーク
透過性はある
バインダーはローカルのみ
ioctlでトランザクション
ストラクチャでw/rのバッファがある
→一回ですむ
ローカルに特化しているから
プロセスA プロセスB
メモリは別空間
→カーネルが管理してあげる必要がある
→カーネルへコピー
スケジューリングして別プロセスでコピーする
memcpyみたいなもん
もどるときは同じようなことを逆向きにする
ashmem
Android / Anonymous SHared MEMory
pin / unpinというAPIが特徴
→メモリ管理でよく出る言葉
→コルクボードで虫ピンで指す
→風で飛ばない
ただ置いてある
→風でふっとぶ
create_regionで作る
pinされたメモリは消えない。
pinされていないメモリは再利用される
キャッシュはunpinされて保持される
→システムメモリが足りなくなってきたらカーネルが判断して開放される
システムプロパティ
キーパーリューストア型のデータベース
すべてのプロセスで共有
initが代表
その他はコピー
書き換えるときはinitへ要求する
froyoまではashmemで実装されていた
神社では標準のシステムコールだけで実装された
→ashmem使う必要なかった
getprop
どんなプロパティがあるか確認できる
ro.*はリードオンリー
init.svc.*はinitが作ったサービスの動作状況確認ができる
ctl.start / ctl.stopは特別
サービスをスタート／ストップするのに使用される
システムプロパティの構造
/dev/__properties__
テンポラリファイル
init → mmap(r/w)
他→ mmap(r/o)
書き換え方
initへsocket経由で送信する
変更したら他のプロセスへ伝播する
Android以外でもいける
実装
システムコールで生成
ファイルサイズを確定
initではr/wでmmap
一旦FDを閉じる
同じものをr/oで開く
環境変数へFDを保持すると他のプロセスへ反映される
子プロセスには直接各方法がない
unlinkすることで削除する
→ファイルを開いてアクセスする方法がなくなる
→init経由でアクセスすることしかできなくなる
参考例
デモは無し
会場での質問
まごろくさんが質問
binderはBeOSから来ている？
→Androidからだから、よく知らない。違うらしい。
村上さん：Binderはメッセージキューの代替？
IPC
中途半端な状態でプロセスが死んだ
ちゃんと処理するハンドラが用意されている
binderはsocketより使いやすい？
→単独であるわけじゃない
用途を実現する為に実装されているから必要以上な処理は実装されていない。
汎用な通信をカーネルで用意するからユーザーランドで使ってくれよ！
突き詰めるとローカルならメモリコピーで通信できるじゃん
■SurfaceFlingerのコードを雰囲気で読んでみた
@cooseezzz くーしーさん 組込み系な人
端末いっぱいな人 ８台
C、アセンブラな人
まごろくさんのディスプレイサブシステムで質問したら調べて発表してとなった
コードを追いかける発表
SurfaceFlingerはC++
2.2.2_r1参照
SFとは？
Process
system_serverプロセス内のスレッド
出てきたスレッドいっぱいで手が回らない
Function
複数のサーフェイスを重ねあわせてフレームバッファを構成する機能
Interface
アプリからのつなぎはSurfaceに関するリクエストをBinder経由で受け付ける
HAL層はgralloc党を経由してashmem、pmemを使ってる
前回のまごろくさんの資料の引用
アプリからSurfaceへ何らかの操作
Binder経由でSFへリクエスト
SFはSurfaceの関係を処理してフレームバッファへ投げている
SurfaceとLayer
アプリ側ではSurface、SFではLayerとして対応している（たぶん）
Region
Surface、やLayerの矩形領域に関する情報
おしながき
JNI〜Surface関連のメソッド呼び出しの流れ
SFの起動からthreadloopまで
native関数の登録
frameworks/base/core/jni/android_view_surface.cpp
まずサーフェイスセッションの接続を確立する処理をする
その後、サーフェイスに関する処理を行う
gSurfaceMethods
Java側とNative側をヒモ付している
JavaのSurfaceクラス
Native側に対応するメソッドが書かれている
Surface_init
SurfaceComposerClient* client
client->createSurfaceからSurfaceFlinger::createSurfaceに繋がっている？
軽い気持ちじゃ・・・
ソース解説
sp
ストロングポインタ
弱い参照、強い参照
→読み飛ばす
NUM_BUFFERは２
Androidはダブルバッファ
SFの起動からthreadloopまで
/main_surfaceflinger.cpp
readyToRun
ディスプレイ関連の初期化
OpenGL ES関連の初期化
起動アニメーションの開始
property_set("ctl.start", "bootanim");
初期化内のTips
property_get("ro.sf.lcd_density", 〜)が定義されてなかったら160dpiで初期化してる
threadloop
handlePageFlip
lockPageFlip
SharedBufferをロックしてフロントバッファとして扱う
Layer枚にSharedBufferを２面もつ
dirtyな領域を計算する
dirtyはコードでよく出てくる。どうゆう状態を指すかはっきりとはわからなかった。
Layerの矩形の幅、高さの変化を確認する
drawingStat()とcurrentStat()
可視領域の再計算の準備をフラグをtrueにして行う
テクスチャの更新
reloadTexture();
これらの処理を各Layerに行う
computeVisibleRegions()
上にあるLayerから順にopaqueRegion（不透明）、visibleReqion（半透明含む）、coverdReqion（覆われて見えない）の分類
オペック
handleRepaint
Dirtyな領域の更新方法を決める
デバイス情報？をもとに決定
部分更新でOK：mDirtyRegion.set(mInvalidRegion.bounds())
全体：mDirtyRegion.set(hw.bounds())
composeSurfaces()中でLayer毎に以下を行う
現描画の取り消し
可視領域に対して描画
hw.compositionComplete
フレームバッファの準備が完了したことをハードへ通知
fdDev->compsitionComplete()
この先でHAL層の関数に繋がる
fdDevの先にある物
gralloc.h
framebuffer.cpp
unlockClient
SharedBufferStackのアンロックをLayer毎に実行
postFramebuffer()
fdDev->
HAL層へ繋がっている
threadloop else節
else節は1/60秒スリープ
elseじゃないほうでVSYNCするか等は多分HAL層以下に依存する
S*社端末など、ベンチマークで３０FPSしかでないものもある
サムスンは違う。
旧Xperiaは３０FPS。
電池持ちを良くするため？
SHの端末もベンチをすると遅い
描画が間に合わないから？らしい
質疑
前半と後半でどっちが時間かかる？
前半はBinderの仕組みじゃないかな？
Surface アプリに割り当てる画面だけど、LayeyとSurfaceとのかかわりはどうなってるの？
対応はしているはず。ソースないでLayerのソースなのにSurfaceのコメントが出てくる。
よくわからない。
20分で理解できるわけがないandroidのカメラサブシステム
@magoroku15 with @pakuqi
会議アプリ
GoToMetting
結構複雑
さわりだけ行っていく
何？
３つの機能
静止画の撮影
動画の録画
ファインダービューの取得
プレビュー。ARとかプレビューに画像処理する場合はこれを利用する
うえ２つはプログラマには解放されていない
ハード依存とAPI
共通のAPIを機種毎に異なるハードで実装
カメラはメーカー最後のフロンティア
レイヤを分けて設計実装
調べ方
BeagleBoardでのUVCカメラの動作をトレースするのが近道
0xdroidまたは天使ちゃんのWebサイトへ
レイヤ
Camera Service
MediaServerの１スレッド
Camera HardwareIF
AndroidHALのIF部。機種依存はない
Camera Hardware
HAL部 機種依存する
オープンソースはフェイクになっている
カメラで静止画とると変な画像がとれるのはそのせい
V4LCamera
V4Lのラッパ＋インターフェース
全体構成
Java
JNI
上はJava
縦は空間
アプリはJavaからJNIへ行ってSystemServerとかの空間へ行く
SufaceFlingerでカメラ映像が合成されて吐き出される
V4L2
歴史ある
QBUFという構造を使う
ストリーミングスタート
上位と関係なくストリーミングする
Camera Hardware
ioctlでデキューする
GrubRawFrame
mRawHeapに上がってくる
YUV
動画にYUVで使う
静止画としてJPEGで使う
プレビュー用にRGBで使う
mPreviewHeap
mRecord***
Camera Serviceで撮ってきたのとSystemServerとで撮ってきた画像を共有している
SkiaもSystemServerと共有している
MediaPlayerServiceのバッファにもYUVが共有されている。POSTしてる。
今日のはサンプル用の実装になってる。
HTCはもっと賢い実装をしている
Camera Hardwareの機能はDSP化できる
上級者向けの課題
HTC商用機のLinuxカーネル
HTC developer
http://developer.htc.com/
DSPを利用した画像処理
ドライバの構成
カーネルインターフェース
メールボックスを利用したDSPからRPC
frameworks/base/camera/libcameraservice/
hardware/msm7k/libcamera
■Javascript PC Emulator
@roishi2j2
Javascript上でPC Linuxが動く
カーネルとかファイルシステムはキャッシュされている
１１秒ほどで起動
gccがない
tccでコンパイルする
hello.cはHello World
ファイルのアップロード方法がわからない
クリップボードでアップロード出来るらしい
emacsが動く
viも動く
Androidでも動く
Froyo以降のブラウザが必要
N１（2.3.4)で動く
旧ペリアは無理(2.1)
Androidのエミュレータでも動かす
１０分くらいで立ち上がるｗ
qemuの作者
ファブリース・ベラール
ソースをのぞく
トップページのHTMLソースをのぞく
function test_typed_arrays()が本体
window.Uint8Array〜を試している
レジスタのアクセスを試す
cpux86_ta.js
caseがいっぱい出てくる
ソースのほとんどがswitch文
最初のほうはレジスタ宣言
仮想メモリもサポートしている
フィジカルメモリはArrayBuffer
どの回路モジュールに処理を渡すかのcase文がいっぱい
フローティングポイントは未サポート
switch文の山だから最適化はされていない
x86の仕様をそのままソースにした形
プロセスはinitとシェルだけ
メモリは１４MB
ソースは１６MB
/binとか/usr/sbinにはいろいろコマンド入ってる
wget入ってるけどカーネルがネットワーク未対応ｗ
コマンドはbusybox
proc/cpuinfo
model name : pentium MMX
bogomips : 20.22
fpu : no
term.js
ターミナルエミュレータ
ぐじゃぐじゃでよくわからない
カスタマイズ方法
jslinux.jsをいじる
params.mem_size メモリサイズ
pc.load_binary()
vmlinux86.bin カーネル
root.bin ルートファイルシステム
linuxstart.bin ブートローダー
javascriptの配列の最大値はいくつ？
デバイスドライバはほとんど入っていない
HDD、シリアルデバイスですら未対応
Androidを動かす場合はカーネルがデブる
質疑
JSの整形方法
emacsのマクロとかだけ。ツールは使っていない。
；で改行、中括弧
てつこばさんの発表の前半で出来上がる
jslinuxを起動したchromeタブのメモリサイズ
５０MB
思ったよりも食っていない
■Gerritで始めるGoogle式レビュー
@myb1126
6/11(土曜）
もくもく会
関内の平沼レストハウス
Gerritはgitを基本としたレビューツール
gerrit2とは？
Google謹製のソースコードレビューシステム
特徴
マルチレポジトリ
ワークフロー込み
様々な認証サポート
Apacheのサポートしている認証/Open ID / LDAPなどなど
簡単なセットアップ
java -jar gerrit.war initだけでGit Server / SSH Server / HTTP Server同梱
EgitにGerritの文字がある
開発者・レビューする人・保守する人
repoで落としたりアップしたりする
特徴
権限のある全てのプロジェクト、ブランチのコミットがおえる
ポイント制
レビュワーにポイントもらってく。
Verifierに最終決定権がある。採用するかを決められる
repo
mydroid/repoを読む
Defaults.xml
基本的にこれの内容にしたがってシンクする
Manifests/
Default.xml
3.0-base.xml 多分まだGPL部分のコミット？
3.1-base.xml 同上
Projexts/
質疑
repoコマンドを使いこなすための資料はなにかある？
androidのやつ（ソース。アンドロイド。コム）
0 件のコメント:
コメントを投稿