第五章 Android系统Framework层源码分析.pptVIP

3.2 题外话——无所不用其极 我的烦恼： 1 RefBase,sp和wp：共两个文件，1千行左右的代码。--不多，真正参与分析的代码应该不到400行。 2 判断极为复杂，打log也不方便，影响整个系统。——对于这类逻辑复杂的代码，打log实为下策。 冥思苦想……，any good ideas? 我的解决办法： 1 直观想法，要是能够调试该多好！ 问题：部署gdbserver?——太麻烦 2 生猛一点：代码多且简单,不存在依赖关系，不如…… 既然它的代码不多而且简单，那何不把它移植到台式机的开发环境下， 整一个类似的RefBase呢？步骤： 1 用Visual Studio，编译和调试代码。 2 至于原子操作，Windows平台上有很直接的InterlockedExchangeXXX与 之对应。 3 Linux平台上，不考虑多线程的话，将原子操作换成普通的 非原子操作 4 如果你够猛的话，用汇编来实现常用的原子操作。 Tips： 如果把破解代码看成是攻城略地的话，必须学会灵活多变， 而且应力求破解方法日臻极致！ 四 Binder重难点分析 BinderBinder听烦了没？见恶心了没？ 有木有？有木有啊？？ 要是今天听了讲座，还没搞懂，哥伤不起啊... 伤不起 Binder本质： 和Socket，Pipe一样，是一种IPC机制 为什么觉得难？或者代码看得头疼... 完全拜Android所赐，因为它把业务逻辑和通信逻辑混杂在一起了 OK,let’s RTFSC 4.1 时空穿越魔术揭秘 获得一个ProcessState实例 调用defaultServiceManager，得到一个IServiceManager 这么重要的函数，放在这里... 有木有看走眼的时候？ BIDNER_VM_SIZE定义为(1*1024*1024) - (4096 *2) = 1M-8K mmap映射一块内存 //打开/dev/binder设备 //通过ioctl方式告诉binder驱动，这个fd支持的最大线程数是15个 ProcessState创建的结果： 1 打开/dev/binder设备，这就相当于与内核的Binder驱动有了交互的通道。 2 对返回的fd使用mmap，这样Binder驱动就会分配一块内存来接收数据。 由于ProcessState的惟一性，因此一个进程只打开设备一次。 defaultServiceManager分析 //真正的gDefaultServiceManager是在这里创建的。 handle值为0 以0为变量，创建一个BpBinder //返回BpBinder(handle)，注意，handle的值为0 BpBinder分析 //handle是0 //另一个重要对象是IPCThreadState，我们稍后会详细讲解。 What is BpBinder？ BpBinder和BBinder都是Android中 与Binder通信相关的代表，它们都从IBinder类派生 I have a question： 如果说BpBinder和通信有关，是否能看到 类似send,write或者和binder设备交互的函数？ Sorry,IBinder家族的代码中不能找到任何 与binder设备相关的代码 障眼法——interface_cast if (interface_cast == dynamic_cast || interface_cast == static_cast) { 如何把BpBinder*类型转换成IServiceManager*类型？ } Binder理解的重点：区分业务和通信 BpBinder和通信相关， 通过interface_cast转换成IServiceManager 这几个是ServiceManager所 提供的业务函数 梦回MFC？关键无比的宏！ 有DECLARE，就有IMPLEMENT…… So,how to “cast” Bpbinder* to IServiceManager*? 终于，业务和通信这两个对象搞到一起去了…… 通过DECLARE和IMPLEMENT这一对媒婆做到的…. 注意，这里有两个对象…. 不是家人，不进一家门……. mRemote指向BpBinder 思考一下： 1 BpServiceManager与BpBinder结合，参与Binder通信 2 BnServiceManager直接从BBinder派生，参与Binder通信 as we said before: BpBinder等IBinder家族中找不到和binder设备通信的代码， 那么，通信层是如何完成通信工作的呢？ Dive into code Android系统Fram