android binder 简单分析

前段时间刚看了binde相关的文章，近期又看了一下，好像跟没看过一样

网上文章分析的都太长，太复杂，能看完以及耗费了很大力气，完全记不住

我就来个简单的

首先客户端需要一个binder来生成一个bpbinder，这个binder可以来自 servicemanager(servicemanage.getservice("powerservice"))，也可以来自ams (binderservice)

生成的binder后，这个bpbinder就可以装填 parcal数据利用系统调用接口和内核交互，驱动端利用共享内存来和服务端传输这个parcal内容以提高传输效率，服务端是个死循环，收到唤醒后，立刻处理并返回相应的结果。

native部分就三步
1 是准备工作： binder数据不是直接传输，IPCThreadState对请求驱动流程进行了封装(transact)，先类比为各个binder线程。ProcessState对交互环境（打开binder驱动，准备好内存映射）进行了简单封装，可以类比进程的aplacation context，bpbinder则又增加了binder对应的index的封装（systemserver对应的是0）
2 是获取binder：先获取bpbinder，再new 一个binder的代理类：BpServiceManager（用到了函数宏）

3 就是拿着这个binder进行接口请求，具体就是用自己的IPCThreadState调用封装好的请求流程就行了，完了，客户端请求结束了

看下服务端，有两个服务端，一个systemserver（太简单，省咯），一个各个server
这个更加简单 ：还是ProcessState 对环境进行初始化（打开binder，启动子线程）然后 IPCThreadState维护一个for循环处理消息（joinThreadPool）
调用服务端重写后的binder里面的回调函数。

流程就是这么个流程，主要是掌握一些重要的知识点
1 oneway（防止阻塞，使用要小心，短时间内请求过多也是会爆，因为他是排队到一个队列里等服务端完成后依次处理的，且不新增新的线程）
2 in，out，inout，(PARCELABLE_WRITE_RETURN_VALUE 和 out，inout搭配使用防止泄露)
3 linktodeath（往往客户端传一个空的binder，方便服务端跟踪客户端的生命周期

   binderDied回调里面要注意释放对应的binder，防止被外部持有导致内存泄露

）
4 systemserver里面经常用到清除和恢复uid，pid的权限，防止多重调用导致的权限不足问题和权限改变问题(clearCallingIdentity,restoreCallingIdentity)

5 binder谁发的，执行在谁的进程中（如果服务端调用客户端的callback binder的话，则执行在客户端进程）

总结：对于比较难的知识点，需要一定的学习方法来辅助，首先大致了解，并找出哪些知识点需要提前搞明白，其次第一遍可以囫囵吞枣，进一步发现一些知识点盲区，然后再提前搞明白，然后再精读，如此循环阅读两到三次，则可破。

这篇文字的目的就是对应第一步，大致了解。