Android深入浅出之Binder机制Word格式.docx
《Android深入浅出之Binder机制Word格式.docx》由会员分享，可在线阅读，更多相关《Android深入浅出之Binder机制Word格式.docx（34页珍藏版）》请在冰豆网上搜索。
//FT，就这么简单？
？
//获得一个ProcessState实例
sp<
ProcessState>
proc（ProcessState:
:
self（））;
//得到一个ServiceManager对象
sp<
IServiceManager>
sm=defaultServiceManager（）;
MediaPlayerService:
instantiate（）;
//初始化MediaPlayerService服务
ProcessState:
self（）->
startThreadPool（）;
//看名字，启动Process的线程池？
IPCThreadState:
joinThreadPool（）;
//将自己加入到刚才的线程池？
}
其中，我们只分析MediaPlayerService。
这么多疑问，看来我们只有一个个函数深入分析了。
不过，这里先简单介绍下sp这个东西。
sp，究竟是smartpointer还是strongpointer呢？
其实我后来发现不用太关注这个，就把它当做一个普通的指针看待，即sp<
======》IServiceManager*吧。
sp是google搞出来的为了方便C/C++程序员管理指针的分配和释放的一套方法，类似JAVA的什么WeakReference之类的。
我个人觉得，要是自己写程序的话，不用这个东西也成。
好了，以后的分析中，sp<
XXX>
就看成是XXX*就可以了。
2.1ProcessState
第一个调用的函数是ProcessState:
self（），然后赋值给了proc变量，程序运行完，proc会自动delete内部的内容，所以就自动释放了先前分配的资源。
ProcessState位置在framework\base\libs\binder\ProcessState.cpp
self（）
if（gProcess!
=NULL）returngProcess;
---->
第一次进来肯定不走这儿
AutoMutex_l（gProcessMutex）;
--->
锁保护
if（gProcess==NULL）gProcess=newProcessState;
创建一个ProcessState对象
returngProcess;
看见没，这里返回的是指针，但是函数返回的是sp<
xxx>
，所以
//把sp<
看成是XXX*是可以的
再来看看ProcessState构造函数
//这个构造函数看来很重要
ProcessState:
ProcessState（）
:
mDriverFD（open_driver（））----->
Android很多代码都是这么写的,稍不留神就没看见这里调用了一个很重要的函数
mVMStart（MAP_FAILED）//映射内存的起始地址
mManagesContexts（false）
mBinderContextCheckFunc（NULL）
mBinderContextUserData（NULL）
mThreadPoolStarted（false）
mThreadPoolSeq
（1）
if（mDriverFD>
=0）{
//BIDNER_VM_SIZE定义为（1*1024*1024）-（4096*2）1M-8K
mVMStart=mmap（0,BINDER_VM_SIZE,PROT_READ,MAP_PRIVATE|MAP_NORESERVE,
mDriverFD,0）;
//这个需要你自己去manmmap的用法了，不过大概意思就是
//将fd映射为内存，这样内存的memcpy等操作就相当于write/read（fd）了
}
...
最讨厌这种在构造list中添加函数的写法了，常常疏忽某个变量的初始化是一个函数调用的结果。
open_driver，就是打开/dev/binder这个设备，这个是android在内核中搞的一个专门用于完成
进程间通讯而设置的一个虚拟的设备。
BTW，说白了就是内核的提供的一个机制，这个和我们用socket加NET_LINK方式和内核通讯是一个道理。
staticintopen_driver（）
intfd=open（"
/dev/binder"
O_RDWR）;
//打开/dev/binder
if（fd>
....
size_tmaxThreads=15;
//通过ioctl方式告诉内核，这个fd支持最大线程数是15个。
result=ioctl（fd,BINDER_SET_MAX_THREADS,&
maxThreads）;
}
returnfd;
好了，到这里Process:
self就分析完了，到底干什么了呢？
打开/dev/binder设备，这样的话就相当于和内核binder机制有了交互的通道
映射fd到内存，设备的fd传进去后，估计这块内存是和binder设备共享的
接下来，就到调用defaultServiceManager（）地方了。
2.2defaultServiceManager
defaultServiceManager位置在framework\base\libs\binder\IServiceManager.cpp中
defaultServiceManager（）
if（gDefaultServiceManager!
=NULL）returngDefaultServiceManager;
//又是一个单例，设计模式中叫singleton。
{
AutoMutex_l（gDefaultServiceManagerLock）;
if（gDefaultServiceManager==NULL）{
//真正的gDefaultServiceManager是在这里创建的喔
gDefaultServiceManager=interface_cast<
（
getContextObject（NULL））;
returngDefaultServiceManager;
-----》
gDefaultServiceManager=interface_cast<
self，肯定返回的是刚才创建的gProcess，然后调用它的getContextObject，注意，传进去的是NULL，即0
//回到ProcessState类，
IBinder>
getContextObject（constsp<
&
caller）
if（supportsProcesses（））{//该函数根据打开设备是否成功来判断是否支持process，
//在真机上肯定走这个
returngetStrongProxyForHandle（0）;
//注意，这里传入0
----》进入到getStrongProxyForHandle，函数名字怪怪的，经常严重阻碍大脑运转
//注意这个参数的命名，handle。
搞过windows的应该比较熟悉这个名字，这是对
//资源的一种标示，其实说白了就是某个数据结构，保存在数组中，然后handle是它在这个数组中的索引。
就是这么一个玩意儿
getStrongProxyForHandle（int32_thandle）
result;
AutoMutex_l（mLock）;
handle_entry*e=lookupHandleLocked（handle）;
--》哈哈，果然，从数组中查找对应
索引的资源，lookupHandleLocked这个就不说了，内部会返回一个handle_entry
下面是handle_entry的结构
/*
structhandle_entry{
IBinder*binder;
Binder
RefBase:
weakref_type*refs;
-->
不知道是什么，不影响.
};
*/
if（e!
=NULL）{
IBinder*b=e->
binder;
-->
第一次进来，肯定为空
if（b==NULL||!
e->
refs->
attemptIncWeak（this））{
b=newBpBinder（handle）;
--->
看见了吧，创建了一个新的BpBinder
e->
binder=b;
result=b;
}....
returnresult;
返回刚才创建的BpBinder。
//到这里，是不是有点乱了？
对，当人脑分析的函数调用太深的时候，就容易忘记。
我们是从gDefaultServiceManager=interface_cast<
升级会员 