进程间通信
Binder是IPC进程间通信的一种机制
1.png
2.png
传统IPC
1通过copy_from_user 复制到内核空间
2再通过copy_to_user复制到另一个进程
复制了两次
Binder作用
3.png
Binder
1通过copy_from_user 复制到内核空间
2通过mmap映射，同时映射到同一块物理地址
复制了一次
4.png
安全性
为每个app分配UID
同时支持实名和匿名
源码分析
AIDL源码分析
5.png
aidl相当于快递小哥，Binder相当于站点。
代码举例
服务端
6.png
9.png
客户端
7.png
8.png
10.png
11.png
1客户端如何获取aidl遥控器？
2通过这个遥控器是如何调到服务端的 ？
3服务端如何处理？
首先在客户端 connection对象里要拿到xxxAidl对象
xxxAidl = IxxxAidl.Stub.asInterface(service)
asInterface源码
12.png
首先判断iin是否在同一个进程，否直接返回proxy服务端代理类
13.png
使用时直接
xxxAidl .addPerson(...)
xxxAidl .getPersonList();
他是如何跑到服务端的呢？直接点击方法，进入Aidl.java (此方法在上图的Proxy里)
14.png
首先进行数据打包，再去请求服务端
mRemote.transact(Stub.TRANSACTION_xxx,_data,_reply,0);
通过“mRemote.transact”请求Binder，
Binder经过处理（C/C++层）后调用onTransact()方法
进入服务端Stub 里
15.png
找到调用的哪个方法后，最后调用“this.xxx(...)”即会跑到实现类中调用。即服务端中的方法。
16.png
流程图
17.png
proxy负责发送，stub负责接收
Binder源码分析
binderService如何绑定服务？
binderService(...)方法最终会跑到ContextImpl.java里
18.png
往Common里走
19.png
因为系统服务有很多，有个特殊的服务叫AMS类似中介
上图getDefault()返回了IActivityManager，拿到AMS服务.
IActivityManager extends IInterface
注：IActivityManager相当于ILeoAidl（ILeoAidl也是继承 IInterface）
往后AMS.binservice（...）类似AIDL，会跑到Proxy里
20.png
binservice实际上调用了Proxy里的binservice
21.png
22.png
mRemote.transact(...)和Aidl一模一样
看流程图 transact（）后 会调用Stub中的方法，这里的Stub是ActivityManagerNative，里面有onTransact（）方法
23.png
ActivityManagerService 继承自ActivityManagerNative
相当于
Service 继承自Stub
调用到里面的binderService
24.png
往里走
25.png
往下
26.png
如上图 创建了服务
27.png
28.png
r.app.thread.scheduleBinderService是ActivityThread。java里的
29.png
调用Handler的sendMessage（H.BIND_SERVICE,s）
30.png
获取住的服务后，之前没绑定调用onBind；之前绑定了，调用onreBind。
没绑定然后跑回AMS里的publishServerce（）方法
31.png
进入ActivityService
32.png
33.png
c.conn.connected就会调用到客户端的onServiceConnected()
