2011年6月5日日曜日

【半リアルタイム】横浜Androidプラットフォーム部第9回勉強会のメモ

ATND
http://atnd.org/events/15437

以下めも




■Inter-process communication of Android
@tetsu_koba (Tetsuyuki Kobayashi)

LinuxCon
Androidのプロセス間通信
メソッドのインボケーション
ashmen
system propertiesの管理が面白い

起動時のPSコマンド(途中省略)
30個のプロセス
→200個のスレッド
互いに通信するプロセス

概念図
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がポーズするときの例
1、schedulePauseActivity
2、binderThreadが待ち受ける
3、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 くーしーさん 組込み系な人

端末いっぱいな人 8台
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は2
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を2面もつ
 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*社端末など、ベンチマークで30FPSしかでないものもある
  サムスンは違う。
  旧Xperiaは30FPS。
   電池持ちを良くするため?
  SHの端末もベンチをすると遅い
   描画が間に合わないから?らしい

質疑
 前半と後半でどっちが時間かかる?
  前半はBinderの仕組みじゃないかな?
  
 Surface アプリに割り当てる画面だけど、LayeyとSurfaceとのかかわりはどうなってるの?
  対応はしているはず。ソースないでLayerのソースなのにSurfaceのコメントが出てくる。
  よくわからない。


20分で理解できるわけがないandroidのカメラサブシステム
@magoroku15 with @pakuqi

会議アプリ
 GoToMetting

結構複雑
さわりだけ行っていく

何?
 3つの機能
  静止画の撮影
  動画の録画
  ファインダービューの取得
   プレビュー。ARとかプレビューに画像処理する場合はこれを利用する
 うえ2つはプログラマには解放されていない
 
 ハード依存とAPI
  共通のAPIを機種毎に異なるハードで実装
   カメラはメーカー最後のフロンティア
  レイヤを分けて設計実装

 調べ方
  BeagleBoardでのUVCカメラの動作をトレースするのが近道
  0xdroidまたは天使ちゃんのWebサイトへ

レイヤ
 Camera Service
  MediaServerの1スレッド
 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が動く
カーネルとかファイルシステムはキャッシュされている
11秒ほどで起動
gccがない
tccでコンパイルする
hello.cはHello World
ファイルのアップロード方法がわからない
 クリップボードでアップロード出来るらしい
emacsが動く
viも動く
Androidでも動く
 Froyo以降のブラウザが必要
 N1(2.3.4)で動く
 旧ペリアは無理(2.1)
Androidのエミュレータでも動かす
 10分くらいで立ち上がるw
qemuの作者
 ファブリース・ベラール
ソースをのぞく
 トップページのHTMLソースをのぞく
 function test_typed_arrays()が本体
 window.Uint8Array〜を試している
  レジスタのアクセスを試す
 cpux86_ta.js
  caseがいっぱい出てくる
  ソースのほとんどがswitch文
  最初のほうはレジスタ宣言
  仮想メモリもサポートしている
  フィジカルメモリはArrayBuffer
  どの回路モジュールに処理を渡すかのcase文がいっぱい
  フローティングポイントは未サポート
  switch文の山だから最適化はされていない
   x86の仕様をそのままソースにした形
  プロセスはinitとシェルだけ
  メモリは14MB
   ソースは16MB
  /binとか/usr/sbinにはいろいろコマンド入ってる
  wget入ってるけどカーネルがネットワーク未対応w
  コマンドは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タブのメモリサイズ
  50MB
  思ったよりも食っていない


■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 件のコメント:

コメントを投稿