http://blog.csdn.net/zwj0403/archive/2010/12/05/6056990.aspx
現在我們嘗試從最開始的啟動流程來熟悉 and
roid camera 的整體 framework 流程 :
首先從上圖的各個步驟來逐一分析流程，後續會根據具體的一些點進行内容的添加和擴充：
- Camera.java
packages/apps/camera/src/com/android/
最上層的應用就是從這個檔案開始。
該檔案集中了整個 android 上層應用的所有相關内容，當然更多的則為界面的代碼實作。
如果出現了 camera 應用界面的問題 ( 當然除了 camera 拍攝區域内容外 ) ，可以從 android 的代碼入手。
- Camera.java
frameworks/base/core/java/android/hardware/
該檔案中主要是對 native 函數接口的調用，當然也包括一些本地的函數實作。
也可以認為該檔案是實作了從 java 層調用 c++ 層代碼函數接口。
也就是我們需要去了解的一點 JNI 機制。
- android_hardware_Camera.cpp
該檔案就是 JNI 的 c++ 層的代碼實作。
通過 camera 的類執行個體來調用 camera 類的相關接口。
- Camera.cpp/Camera.h
對于上層應用來說， camera.cpp 是最為直接的函數調用和實作。
繼承于 ICameraClient 類 , 典型的 Client 端的接口執行個體。
- BnCameraClient/BpCameraClient
IPC 通訊所需的函數接口實作，繼承于 ICameraClient 類。
- ICameraClient.cpp/ICameraClient.h
Client/Service 模式下的 Client 端實作
- ICameraService.cpp/ICameraService.h
Client/Service 模式下 service 端實作
- BnCameraService/BpCameraService
IPC 通訊所需的函數接口實作，繼承于 ICameraService 類。
- CameraService.cpp/CameraService.h
繼承于 BnCameraService 類。
是對 BnCameraService 函數接口的實作，其本質也是對 CameraService 的内部類 Client 函數接口的調用。
- Client(CameraService 内部類 )
該類才是真正的底層函數實作，其通過 openCameraHardware() 得到 camera 硬體執行個體對象進行操作。
其繼承于 ICamera 類 , 是對 ICamera 類函數接口的實作。
接下來，我們通過對流程的步步分析來将 camera 整體串接起來 :
1． 首先則看看 camera.java 的 onCreate 函數入口，針對 android 的所有應用， onCreate 函數入口作為跟蹤和了解應用架構的首選。
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
devlatch = new CountDownLatch(1);
CountDownLatch() 關于這個類，可以簡單的了解為它是用來線程之間的等待處理，當然這裡采用的計數為 1 ，則可以簡單了解為一個計數開關來控制調用了 tlatch.await() 函數的程序，方式就是将 devlatch 的計數減為 0(countDown() ) 。
這裡啟動了一個線程用來打開 camera 服務，而打開過程則比較費時 ( 一般在 2s 左右 ) ，故單獨啟用一個線程避免應用線程阻塞。
Thread startPreviewThread = new Thread(new Runnable() {
CountDownLatch tlatch = devlatch;
public void run() {
try {
mStartPreviewFail = false;
ensureCameraDevice();
// Wait for framework initialization to be complete before
// starting preview
try {
tlatch.await();
} catch (InterruptedException ie) {
mStartPreviewFail = true;
}
startPreview();
} catch (CameraHardwareException e) {
// In eng build, we throw the exception so that test tool
// can detect it and report it
if ("eng".equals(Build.TYPE)) {
throw new RuntimeException(e);
}
mStartPreviewFail = true;
}
}
});
startPreviewThread.start();
在這裡，需要跟進 ensureCameraDevice(); 該函數，可以看到其實作為：
private void ensureCameraDevice() throws CameraHardwareException {
if (mCameraDevice == null) {
mCameraDevice = CameraHolder.instance().open();
mInitialParams = mCameraDevice.getParameters();
}
}
目前 mCameraDevice() 執行個體為 null, 則會調用 CameraHolder.instance().open() 函數來建立 mCameraDevice 對象執行個體。
private android.hardware.Camera mCameraDevice;
跟進 CameraHolder.instance().open() ，進入到了 CameraHolder 類中：
public synchronized android.hardware.Camera open()
throws CameraHardwareException {
Assert(mUsers == 0);
if (mCameraDevice == null) {
try {
mCameraDevice = android.hardware.Camera.open();
} catch (RuntimeException e) {
Log.e(TAG, "fail to connect Camera", e);
throw new CameraHardwareException(e);
}
mParameters = mCameraDevice.getParameters();
} else {
……
下面大概介紹下我對 CameraHolder 的了解：
1 、 CameraHolder 對 mCameraDevice 執行個體進行短暫的保留 (keep() 函數中可以設定這個保留時長 , 一般預設為 3000ms) ，避免使用者在短暫退出 camera 又重新進入時，縮短 camera 啟動時長 ( 正如之前所說，打開 CameraDevice 時間較長 )
2 、 CameraHolder 并有一個關鍵的計數 mUsers 用來保證 open() 和 release() 的配套調用，避免多次重複釋放或者打開 ( 上層應用的保護措施之一 ) 。
2． 第一步的完成，進而跳轉到了 android.hardware.Camera 類中的 open() 函數接口調用。
public static Camera open() {
return new Camera();
}
靜态函數，也就可以通過類名直接調用， open() 函數中去建立一個 Camera 的執行個體。
Camera() {
mShutterCallback = null;
mRawImageCallback = null;
mJpegCallback = null;
mPreviewCallback = null;
mPostviewCallback = null;
mZoomListener = null;
Looper looper;
if ((looper = Looper.myLooper()) != null) {
mEventHandler = new EventHandler(this, looper);
} else if ((looper = Looper.getMainLooper()) != null) {
mEventHandler = new EventHandler(this, looper);
} else {
mEventHandler = null;
}
native_setup(new WeakReference<Camera>(this));
}
在 Camera 構造函數中有這個關鍵的一步 , 最開始的一些 callback 可以認為它們最終被底層調用到 ( 至于具體流程後面會講到 ) 。 EventHandler 和 Looper 我們暫時跳過，知道它是消息處理就行了。最後也就是最為關鍵的函數接口調用： native_setup
private native final void native_setup(Object camera_this);
典型的 native 函數接口聲明，說明并非 camera 類的本地函數實作，也就意味着會通過 JNI(Java Native Interface) 調用對用 C++ 檔案中的函數接口。
3． 通過代碼搜尋，或者如果你清楚 JNI 檔案路徑也可以去該路徑下找。
其實這邊有個小技巧，雖然不一定都通用，但可以試試看：
java 類的 package 名往往可以作為尋找相應 JNI 檔案的途徑：
package android.hardware;
則就可以通過 android.hardware. camera.cpp 來尋找 ( 其實還是歸咎于 android 的規範命名規則 ) 。
跳轉到 android_hardware_Camera.cpp 中尋找 native_setup() 所對應的 JNI 函數接口：
static JNINativeMethod camMethods[] = {
{ "native_setup",
"(Ljava/lang/Object;)V",
(void*)android_hardware_Camera_native_setup },
{ "native_release",
"()V",
(void*)android_hardware_Camera_release },
{ "setPreviewDisplay",
"(Landroid/view/Surface;)V",
(void *)android_hardware_Camera_setPreviewDisplay },
……
而 camMethods[] 在什麼時候映射的那？繼續看：
int register_android_hardware_Camera(JNIEnv *env) {
…..
// Register native functions
return AndroidRuntime::registerNativeMethods(env, "android/hardware/Camera",
camMethods,NELEM(camMethods));
}
最終在 AndroidRuntime.cpp 中被調用：
REG_JNI(register_android_hardware_Camera),
說明如果我們自己要添加 JNI 接口實作的話，這些地方也需要添加相應的代碼 ( 具體在 AndroidRuntime.cpp 的細節我沒深看，也不做介紹 ) 。
簡單介紹： JNINativeMethod 的第一個成員是一個字元 串，表示了 JAVA 本地調用方法的名稱，這個名稱是在 JAVA 程式中調用的名稱；第二個成員也是一個字元串，表示 JAVA 本地調用方法的參數和傳回值；第三個成員是 JAVA 本地調用方法對應的 C 語言函數 。
跟進觀察 android_hardware_Camera_native_setup() 函數的實作：
// connect to camera service
static void android_hardware_Camera_native_setup(JNIEnv *env, jobject thiz, jobject weak_this)
{
sp<Camera> camera = Camera::connect();
if (camera == NULL) {
jniThrowException(env, "java/lang/RuntimeException",
"Fail to connect to camera service");
return;
}
….
}
初步可以認為 Camera::connect() 的函數調用時傳回了一個 Camera 的執行個體對象。
4． 通過上述的跟進流程來到了針對上層應用而言最為直接的類： camera.cpp ：
對 Camera::connect 函數的調用如下：
sp<Camera> Camera::connect()
{
LOGV("connect");
sp<Camera> c = new Camera();
const sp<ICameraService>& cs = getCameraService();
if (cs != 0) {
c->mCamera = cs->connect(c);
}
if (c->mCamera != 0) {
c->mCamera->asBinder()->linkToDeath(c);
c->mStatus = NO_ERROR;
} else {
c.clear();
}
return c;
}
首先是建立一個 camera 對象執行個體，然後通過調用 getCameraService() 去取得 ICameraService 的服務執行個體：
// establish binder interface to camera service
const sp<ICameraService>& Camera::getCameraService()
{
Mutex::Autolock _l(mLock);
if (mCameraService.get() == 0) {
sp<IServiceManager> sm = defaultServiceManager() ;
sp<IBinder> binder;
do {
binder = sm->getService(String16("media.camera"));
if (binder != 0)
break;
LOGW("CameraService not published, waiting...");
usleep(500000); // 0.5 s
} while(true);
if (mDeathNotifier == NULL) {
mDeathNotifier = new DeathNotifier();
}
binder->linkToDeath(mDeathNotifier);
mCameraService = interface_cast<ICameraService>(binder);
}
LOGE_IF(mCameraService==0, "no CameraService!?");
return mCameraService;
}
這邊就涉及到了 ServiceManager() 對服務的管理，在這之前 Camera 的服務已經注冊到了 ServiceManager 中，我們可以通過服務字串 (media.camera) 來獲得 camera service( 其本質得到的是 CameraService 的執行個體對象，雖然通過類型上溯轉換成父類ICameraService ，對 ICameraService 對象的函數調用本質是調用到了 CameraService 的函數實作 ) 。
在得到 camera service 後，傳回之前的步驟：當得到的 cs 即 cameraservice 執行個體存在時，通過調用 cs->connect(c) 去得到 ICamera 執行個體，并指派給了 camera 執行個體的一個類成員 ICamera mCamera ：
if (cs != 0) {
c->mCamera = cs->connect(c);
5． 接下來則涉及到ICamraService 的相關調用關系，其實這個地方需要去弄清楚一些函數接口的實作在具體哪些檔案中，因為存在較多的虛函數。
繼續流程，上一步走到了 cs->connect() ，也就是 ICameraService 的 connect() 函數接口。
class ICameraService : public IInterface
{
public:
enum {
CONNECT = IBinder::FIRST_CALL_TRANSACTION,
};
public:
DECLARE_META_INTERFACE(CameraService);
virtual sp<ICamera> connect(const sp<ICameraClient>& cameraClient) = 0;
};
可以發現該connect() 接口為一個純虛函數，需要 ICameraService 的子類對該接口進行實作，進而對connect() 的調用則會映射到 ICameraService 子類的具體實作。
關于 ICameraService 的執行個體問題，目前暫時跳過 ( 後面馬上就會講到 ) ，簡單認為這個時候會調用到其一個子類的實作：
class BpCameraService: public BpInterface<ICameraService>
{
public:
BpCameraService(const sp<IBinder>& impl)
: BpInterface<ICameraService>(impl)
{
}
// connect to camera service
virtual sp<ICamera> connect(const sp<ICameraClient>& cameraClient)
{
Parcel data, reply;
data.writeInterfaceToken(ICameraService::getInterfaceDescriptor());
data.writeStrongBinder(cameraClient->asBinder());
remote()->transact(BnCameraService::CONNECT, data, &reply);
return interface_cast<ICamera>(reply.readStrongBinder());
}
};
BpCameraService 為代理類，其主要用途為 Binder 通訊機制即程序間的通訊 (Client/Service) ，最終還是會調用 BnCameraService 的具體實作，即：
status_t BnCameraService::onTransact (
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case CONNECT: {
CHECK_INTERFACE(ICameraService, data, reply);
sp<ICameraClient> cameraClient
= interface_cast<ICameraClient>(data.readStrongBinder());
sp<ICamera> camera = connect(cameraClient);
reply->writeStrongBinder(camera->asBinder());
return NO_ERROR;
} break;
default:
return BBinder::onTransact(code, data, reply, flags);
}
}
而BnCameraService ( 為實作類 ) 類繼承于ICameraService ，并且也并沒有對connect() 純虛函數進行了實作，同樣意味着其實該調用的實質是 BnCameraService 的子類實作。
畢竟虛函數的調用沒有執行個體肯定是沒有意義的，說明我們需要找到對 connect() 純虛函數的實作子類即繼承于 BnCameraService 。
6． 結合上面所述，可以尋找到了繼承于BnCameraService 的子類CameraService.cpp ：
這時雖然找到了CameraService 該類，但是你肯定會問到該類執行個體的建立在什麼地方哪？再後頭看 CameraService 啟動注冊的地方：
int main(int argc, char** argv)
{
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p", sm.get());
AudioFlinger::instantiate();
MediaPlayerService::instantiate();
CameraService::instantiate();
AudioPolicyService::instantiate();
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
這個 main 函數位于 main_mediaserver.cpp 中，而 mediaserver 是在系統開始的時候就啟動起來的 server 端（MediaServer ，在系統啟動時由 init 所啟動，具可參考 init.rc 檔案 ），進而将相關的服務也建立了執行個體。
跟進 CameraService::instantiate() 函數實作，可以發現：
void CameraService::instantiate() {
defaultServiceManager()->addService(
String16(" media.camera "), new CameraService() );
}
建立了一個 CameraService 執行個體 ，并給定了 CameraService 的服務字串為 ”media.camera” ，而之前在通過 ServiceManager 擷取 CameraService 的時候，所調用的接口為binder = sm->getService(String16("media.camera")); ，兩者保持了一樣的字元串。
if (mCameraService.get() == 0) {
sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder;
do {
binder = sm->getService(String16("media.camera"));
if (binder != 0)
break;
LOGW("CameraService not published, waiting...");
usleep(500000); // 0.5 s
} while(true);
if (mDeathNotifier == NULL) {
mDeathNotifier = new DeathNotifier();
}
binder->linkToDeath(mDeathNotifier);
mCameraService = interface_cast<ICameraService>(binder);
}
結合上述分析，此處的binder 對象其實為CameraService 類執行個體 ( 多态類型轉換 ) 。
interface_cast<ICameraService>(binder) 宏映射，需要展開：
template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
return INTERFACE::asInterface(obj);
}
INTERFACE::asInterface(obj); 宏映射，繼續展開可得：
sp<I##INTERFACE> I##INTERFACE::asInterface(const sp<IBinder>& obj) /
{ /
sp<I##INTERFACE> intr; /
if (obj != NULL) { /
intr = static_cast<I##INTERFACE*>( /
obj->queryLocalInterface( /
I##INTERFACE::descriptor).get()); /
if (intr == NULL) { /
intr = new Bp##INTERFACE(obj); /
} /
} /
return intr; /
}
( 其上的宏展開都是在 IMPLEMENT_META_INTERFACE(CameraService, "android.hardware.ICameraService"); 中實作的 )
此處又建立了一個BpCameraService (new Bp##INTERFACE) 對象并将binder 對象 (obj) 傳入到 BpCameraService 的構造函數中。
雖然擷取的時候通過多态将 CameraService 執行個體轉換成了 BnCameraService 也進一步解釋了為什麼 ICameraService 子類 BnCameraservice 中的 connect 函數實質會調用到 CameraService 中函數實作了。
于是就調用到了 CameraService 的 connect 函數接口：
sp<ICamera> CameraService::connect(const sp<ICameraClient>& cameraClient) {
…..
// create a new Client object
client = new Client(this, cameraClient, callingPid);
mClient = client;
if (client->mHardware == NULL) {
client = NULL;
mClient = NULL;
return client;
}
…..
}
建立了一個 Client 執行個體對象，并将該執行個體對象指派給 CameraSevice 的類成員 mClient, 友善其實函數接口對 Client 的調用。
在這之前需要提及它的一個内部類 Client ，該類才是最為關鍵的函數實作 ,CameraService 的一些接口都會調用到其 Client 執行個體的具體函數。
7． 那麼現在的關鍵就是 Client 類了·進一步跟進：
CameraService::Client::Client(const sp<CameraService>& cameraService,
const sp<ICameraClient>& cameraClient, pid_t clientPid)
{
…..
mCameraService = cameraService;
mCameraClient = cameraClient;
mClientPid = clientPid;
mHardware = openCameraHardware();
}
将 cameraService 和 cameraClient 的執行個體分别指派給了 Client 的類成員變量。
另外 openCameraHardware() 是值得注意的地方，也就是連接配接上層應用和底層驅動的關鍵，通過調用 openCameraHardware() 得到了一個 CameraHardwareInterface 執行個體對象，并指派給自己的類成員： `
sp<CameraHardwareInterface> mHardware;
對 hardware 的操作就是通過該對象完成的，是以說真正意義上的功能實作其實就是在這裡，即 client 類的函數接口調用。
對于 hardware 的東東咱們暫時不去關注吧。
那麼我們再次仔細研究下 Client 類的繼承關系 ( 這些繼承關系很容易混亂，涉及到較多的多态類型轉換 ) ，這個其實往往都很關鍵：
Client 繼承于 BnCamera ，而 BnCamera 則繼承于 ICamera ，也就是說 Client 繼承了 ICamera, 實作了 ICamera 中的函數。
進而發現，原來繞一個大圈，把最開始的圖簡化下：
8． 除此之外還有兩個步驟或許需要去研究下：
先從單一函數去跟進，看具體一些 callback 的實作流程：
// callback from camera service
void Camera::notifyCallback(int32_t msgType, int32_t ext1, int32_t ext2)
{
sp<CameraListener> listener;
{
Mutex::Autolock _l(mLock);
listener = mListener;
}
if (listener != NULL) {
listener->notify(msgType, ext1, ext2);
}
}
這是 Camera 類中一個 callback 函數實作，但其本質在哪？先看 camera 類的繼承關系：
通過以上的繼承關系，繼續跟進其父類 ICameraClient :
class ICameraClient: public IInterface
{
public:
DECLARE_META_INTERFACE(CameraClient);
virtual void notifyCallback(int32_t msgType, int32_t ext1, int32_t ext2) = 0;
virtual void dataCallback(int32_t msgType, const sp<IMemory>& data) = 0;
virtual void dataCallbackTimestamp(nsecs_t timestamp, int32_t msgType, const sp<IMemory>& data) = 0;
};
其中 notifyCallback() 又是純虛函數 , 則同樣說明實作在其子類 BpCameraClient 中：
// generic callback from camera service to app
void notifyCallback(int32_t msgType, int32_t ext1, int32_t ext2)
{
LOGV("notifyCallback");
Parcel data, reply;
data.writeInterfaceToken(ICameraClient::getInterfaceDescriptor());
data.writeInt32(msgType);
data.writeInt32(ext1);
data.writeInt32(ext2);
remote()->transact(NOTIFY_CALLBACK,data, &reply, IBinder::FLAG_ONEWAY);
}
然後通過 Binder 通訊調用到 BnCameraClient 中實作：
status_t BnCameraClient::onTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case NOTIFY_CALLBACK: {
LOGV("NOTIFY_CALLBACK");
CHECK_INTERFACE(ICameraClient, data, reply);
int32_t msgType = data.readInt32();
int32_t ext1 = data.readInt32();
int32_t ext2 = data.readInt32();
notifyCallback(msgType, ext1, ext2);
return NO_ERROR;
} break;
….
}
進而調用到了 Camera.cpp 中的函數實作了，但或許你有疑問，這些 callback 是涉及到一些驅動的 callback ，哪怎麼跟驅動聯系起來那？
結合之前對 hardware 接口調用的類 Client ，進一步可以發現 callback 的處理同樣是在 Client 類執行個體化的時候：
CameraService::Client::Client(const sp<CameraService>& cameraService,
const sp<ICameraClient>& cameraClient, pid_t clientPid)
{
…..
mHardware->setCallbacks( notifyCallback ,
dataCallback,
dataCallbackTimestamp,
mCameraService.get());
…..
}
調用了 mHardware 将 callback 傳入，但此處的 notifyCallback 并不是 camera.cpp 中的函數，而是 client 類的 notifyCallback 函數。
再繼續看 client 類中的 notifyCallback 函數實作：
void CameraService::Client::notifyCallback(int32_t msgType, int32_t ext1,int32_t ext2, void* user)
{
…..
default:
sp<ICameraClient> c = client->mCameraClient;
if (c != NULL) {
c->notifyCallback(msgType, ext1, ext2);
}
break;
…..
}
CameraService::Client::Client(const sp<CameraService>& cameraService,
const sp<ICameraClient>& cameraClient , pid_t clientPid)
{
….
mCameraService = cameraService;
mCameraClient = cameraClient ;
….
}
通過得到 ICameraClient 執行個體進而調用到了具體的對象 Camera 的 notifyCallback() 函數。這個地方估計會遇見跟 ICameraService 函數調用一樣的問題， ICameraClient 函數調用所需要的函數執行個體在哪？
記得上述 ICameraService 講到的 connect() 函數嘛？其中有一個參數不能被忽略掉的，就是 ICameraClient ，但它在真正傳入的時候卻是一個 ICameraClient 子類 camera 的執行個體對象。
CameraService:
sp<ICamera> CameraService::connect(const sp<ICameraClient>& cameraClient)
{
…..
// create a new Client object
client = new Client(this, cameraClient , callingPid);
…..
}
Client:
這樣就清楚了，其實 Client 在調用設定 callback 的調用最終還是調用到了 camera.cpp 中的 callback 函數，進而将具體内容通過 callback 回報給上層應用做出相應的處理。