Android系统Framework层源码分析.ppt

Android系统Framework层源码分析（深入理解Android重难点解析）,主讲人邓凡平,大纲,一JNI重难点分析1.1注册方法的选择1.2垃圾回收二init重难点分析2.1keywords.h的有趣用法2.2用好“DllMain函数”客户端Property读取的实现三Android常用类重难点分析3.1RefBase、sp和wp3.2题外话无所不用其极四Binder重难点分析4.1时空穿越魔术揭秘4.2Binder和线程的关系五Audio系统重难点分析5.1AudioTrack,Soeasy？NotReally！,JNI最好的参考资料，一切尽在不言中.JavaNativeInterfaceSpecification从网上下载PDFJDK文档中也有(可下载chm版的，查询方便),二init重难点分析,Android对init进行了大规模改进，但还是少不了要解析配置文件init.rc。,所以，init的破解关键在init.rc的解析代码中，解析功能在parser.c,2.1keywords.h的用法,两次includekeywords.h,Interesting:includekeywords.htwotimes?Whatdoweget?,第一次包含：得到枚举定义和一些函数,定义一个结构体数组keyword_info,再次包含keywords.h实际上是以枚举定义的元素为数组索引，填充keyword_info数组（用新的KEYWORD宏）,Result：,明白了？奇技淫巧乎？,2.2用好“DllMain函数”客户端Property读取的实现,Android平台提供系统级别的属性管理和控制,类比Windows平台上的“注册表”：可以存储一些类似key/value的键值对。作用：一般而言，系统或某些应用程序会把自己的一些属性存储在注册表中，即使下次系统重启或应用程序重启，它还能够根据之前在注册表中设置的属性，进行相应的初始化工作。,Diveintocode,Android想要做什么？-（目的）1属性区域是由init进程创建2希望其他进程也能快速读取属性区域里的内容,Android怎么做到？-（方法）1属性区域创建于共享内存上2客户端进程不知不觉得映射这块内存,Diveintocode,AnyQuestionsaboutinit?,四Android常用类重难点分析,代码中漫天可见的RefBase、spandwp到底是什么？,Inmyopinion：1Refbase类似MFC的CObject，为C+对象之始祖。2sp非smartpointer，而是strongpointer，wp为weakpointer。3三者协同组建AndroidC+对象生命周期的管理和控制机能。,Letsdiveintocode,3.1SampleOne:初识影子对象,/A没有任何自己的功能,/sp，wp对象是在中创建的，下面将先创建sp，然后创建wp,/大括号结束前，先析构wp,再析构sp,DiveintoCode,类A从RefBase中派生。使用的是RefBase构造函数,QuickQuestion：见到mStrong和mWeak,是否嗅到蛛丝马迹？,发现影子对象成员中有两个引用计数？一个强引用，一个弱引用。如果知道引用计数和对象生死有些许关联的话，就容易想到影子对象的作用了。,sp的构造,/mRefs就是刚才RefBase构造函数中new出来的影子对象,/原子操作，影子对象的弱引用计数加1,continueincStrong,/刚才增加了弱引用计数，再增加强引用计数,/下面函数为原子加1操作，并返回旧值。所以c=0 x1000000，而mStrong变为0 x1000001,/如果c不是初始值，则表明这个对象已经被强引用过一次了,/下面这个是原子加操作，相当于执行refs-mStrong+（-0 x1000000）,最终mStrong=1,sp构造后的结果:sp的出生导致影子对象的强引用计数加1，弱引用计数加1,wp的构造,/调用pA的createWeak,并且保存返回值到成员变量m_refs中,/调用影子对象的incWeak，将导致影子对象的弱引用计数增加1,wp构造后的结果:影子对象的弱引用计数将增加1，所以现在弱引用计数为2，而强引用计数仍为1wp中有两个成员变量，一个保存实际对象，另一个保存影子对象.sp只有一个成员变量用来保存实际对象，但这个实际对象内部已包含了对应的影子对象,wp的析构,/调用影子对象的decWeak，由影子对象的基类实现,/把基类指针转换成子类（影子对象）的类型，这种做法有些违背面向对象编程的思想,/原子减1，返回旧值，c=2，而弱引用计数从2变为1,如果c为1，则弱引用计数为0，这说明没有弱引用指向实际对象，需要考虑是否释放内存,OBJECT_LIFETIME_XXX和生命周期有关系.比较难分析.,wp析构后，弱引用计数减1。但由于此时强引用计数和弱引用计数仍为1，所以没有对象被干掉，即没有释放实际对象和影子对象占据的内存。,sp的析构,/注意，此时强弱引用计数都是1，下面函数调用的结果是c=1，强引用计数为0,/调用前影子对象的弱引用计数为1，强引用计数为0，调用结束后c=1，弱引用计数为0,/这次弱引用计数终于变为0，并且mFlags为0，mStrong也为0,/注意，实际数据对象已经被干掉了，所以mRefs也没有用了，但是decStrong刚进来/的时候就保存mRefs到refs了，所以这里的refs指向影子对象,Sample1sumup:,RefBase中有一个隐含的影子对象，该影子对象内部有强弱引用计数。sp化后，强弱引用计数各增加1，sp析构后，强弱引用计数各减1。wp化后，弱引用计数增加1，wp析构后，弱引用计数减1。,完全彻底地消灭RefBase对象，包括让实际对象和影子对象灭亡，这些都是由强弱引用计数控制的，另外还要考虑flag的取值情况。当flag为0时，可得出如下结论：,强引用为0将导致实际对象被delete。弱引用为0将导致影子对象被delete。,生死魔咒-extendObjectLifetime,有什么用？,1flags为0，强引用计数控制实际对象的生命周期，弱引用计数控制影子对象的生命周期。强引用计数为0后，实际对象被delete。所以对于这种情况，应记住的是，使用wp时要由弱生强，以免收到segmentfault信号。2flags为LIFETIME_WEAK，强引用计数为0，弱引用计数不为0时，实际对象不会被delete。当弱引用计数减为0时，实际对象和影子对象会同时被delete。这是功德圆满的情况。3flags为LIFETIME_FOREVER，对象将长生不老，彻底摆脱强弱引用计数的控制。所以你要在适当的时候杀死这些老妖精，免得她祸害“人间”。,3.2题外话无所不用其极,我的烦恼：1RefBase,sp和wp：共两个文件，1千行左右的代码。-不多，真正参与分析的代码应该不到400行。2判断极为复杂，打log也不方便，影响整个系统。对于这类逻辑复杂的代码，打log实为下策。冥思苦想，anygoodideas?,我的解决办法：1直观想法，要是能够调试该多好！问题：部署gdbserver?太麻烦2生猛一点：代码多且简单,不存在依赖关系，不如,既然它的代码不多而且简单，那何不把它移植到台式机的开发环境下，整一个类似的RefBase呢？步骤：1用VisualStudio，编译和调试代码。2至于原子操作，Windows平台上有很直接的InterlockedExchangeXXX与之对应。3Linux平台上，不考虑多线程的话，将原子操作换成普通的非原子操作4如果你够猛的话，用汇编来实现常用的原子操作。,Tips：如果把破解代码看成是攻城略地的话，必须学会灵活多变，而且应力求破解方法日臻极致！,四Binder重难点分析,Binder.Binder.听烦了没？见恶心了没？,有木有？有木有啊？,要是今天听了讲座，还没搞懂，哥伤不起啊.伤不起.,Binder本质：和Socket，Pipe一样，是一种IPC机制,为什么觉得难？或者代码看得头疼.完全拜Android所赐，因为它把业务逻辑和通信逻辑混杂在一起了.,OK,letsRTFSC.,4.1时空穿越魔术揭秘,获得一个ProcessState实例,调用defaultServiceManager，得到一个IServiceManager,BIDNER_VM_SIZE定义为(1*1024*1024)-(4096*2)=1M-8Kmmap映射一块内存,/打开/dev/binder设备,/通过ioctl方式告诉binder驱动，这个fd支持的最大线程数是15个,ProcessState创建的结果：1打开/dev/binder设备，这就相当于与内核的Binder驱动有了交互的通道。2对返回的fd使用mmap，这样Binder驱动就会分配一块内存来接收数据。由于ProcessState的惟一性，因此一个进程只打开设备一次。,defaultServiceManager分析,handle值为0,以0为变量，创建一个BpBinder,/返回BpBinder(handle)，注意，handle的值为0,BpBinder分析,WhatisBpBinder？,BpBinder和BBinder都是Android中与Binder通信相关的代表，它们都从IBinder类派生,Ihaveaquestion：如果说BpBinder和通信有关，是否能看到类似send,write或者和binder设备交互的函数？,障眼法interface_cast,if(interface_cast=dynamic_cast|interface_cast=static_cast)如何把BpBinder*类型转换成IServiceManager*类型？,Binder理解的重点：区分业务和通信,BpBinder和通信相关，通过interface_cast转换成IServiceManager,梦回MFC？关键无比的宏！,有DECLARE，就有IMPLEMENT,So,howto“cast”Bpbinder*toIServiceManager*?,终于，业务和通信这两个对象搞到一起去了通过DECLARE和IMPLEMENT这一对媒婆做到的.注意，这里有两个对象.,不是家人，不进一家门.,思考一下：1BpServiceManager与BpBinder结合，参与Binder通信2BnServiceManager直接从BBinder派生，参与Binder通信,aswesaidbefore:BpBinder等IBinder家族中找不到和binder设备通信的代码，那么，通信层是如何完成通信工作的呢？,