Android系统Framework层源码分析

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&方法论5.2AudioFlinger中的对象5.3AudioPolicyService实例5.4audio_control_block_t分析5.5学习并实践DesktopCheck大纲（接上）•六Surface系统重难点分析6.1来之不易的Activity6.2乾坤大挪移——如何与SurfaceFlinger建立联系？6.3生产者和消费者之间的纽带6.4SurfaceFlinger的工作流程分析6.5Transaction分析6.6CameraService中的严重bug6.7PageFlip过程分析一JNI重难点分析1JNI是什么？JavaNativeInterface2JNI在程序中有什么作用？白话：•Java代码通过JNI调用Native(C/C++)写的函数•Native(C/C++)的函数操作Java层的函数(调用函数或者操作对象)1.1注册方法的选择什么是注册？Java中定义的native函数如何找到Native层对应的函数？如何关联这两个函数？两种方法：1静态法2动态法静态法：很简单，就是找根据一定的函数命名规则，在so库中搜索对应的函数。native_init------Java_android_media_MediaScanner_native_1init静态法标准步骤：1.先编写Java代码，然后编译生成.class文件2.使用Java的工具程序javah，如javah–ooutputpackagename.classname，这样它会生成一个叫output.h的JNI层头文件。其中packagename.classname是Java代码编译后的class文件，而在生成的output.h文件里，声明了对应的JNI层函数，只要实现里面的函数即可。静态方法工作原理探析及其弊端工作原理•当Java层调用native_init函数时，它会从对应的JNI库Java_android_media_MediaScanner_native_linit，如果没有，就会报错。如果找到，则会为这个native_init和Java_android_media_MediaScanner_native_linit建立一个关联关系，其实就是保存JNI层函数的函数指针。以后再调用native_init函数时，直接使用这个函数指针就可以了。弊端：1.需要编译所有声明了native函数的类。只有生成了.class文件后，才能交由javah工具。2.默认的Native函数名字巨长......3.第一次调用某个native函数的时候，需要搜索so库中对应的Native函数。（估计是用dlsym来获得Native函数的函数指针吧！）动态方法亲，您们从前面静态方法的介绍中看到了什么？native函数和JNI层的函数，不就是找一函数指针嘛？“不找贵的，只找对的......”关键数据结构：JNINativeMethod如何注册？QuickQuestion：1什么时候，在哪儿注册JNINativeMethod数组？Answer：在一个特殊的native函数中......Quesiton：这个特殊的native函数又是在什么时候，在哪儿注册的？Answer:鸡生蛋？蛋生鸡？......当Java层通过System.loadLibrary加载完JNI动态库后，紧接着会查找该库中一个叫JNI_OnLoad的函数，如果有，就调用它，而动态注册的工作就是在这里完成的。1.2垃圾回收例子：可以在别的函数使用这个save_thiz吗？引用计数的作用呢？JNI提供三种类型的引用，足够满足亲们的需求了！LocalReference：本地引用。在JNI层函数中使用的非全局引用对象都是LocalReference。它包括函数调用时传入的jobject、在JNI层函数中创建的jobject。LocalReference最大的特点就是，一旦JNI层函数返回，这些jobject就可能被垃圾回收。GlobalReference：全局引用，这种对象如不主动释放，就永远不会被垃圾回收。WeakGlobalReference：弱全局引用，一种特殊的GlobalReference。在运行过程中可能会被垃圾回收。所以在程序中使用它之前，需要调用JNIEnv的IsSameObject判断它是不是被回收了。调用NewStringUTF创建一个jstring对象，它是LocalReference类型。有可能内存不够用……强烈建议，及时回收LocalRef……mEnv-DeleteLocalRef(pathStr);Soeasy？NotReally！JNI最好的参考资料，一切尽在不言中….《JavaNativeInterfaceSpecification》1.从网上下载PDF2.JDK文档中也有(可下载chm版的，查询方便……)二init重难点分析Android对init进行了大规模改进……，但还是少不了要解析配置文件init.rc。所以，init的破解关键在init.rc的解析代码中，解析功能在parser.c2.1keywords.h的用法声明一些Action函数定义KEYWORD宏,四个参数，却只用到第一个参数使用KEYWORD宏,得到一个枚举：enum{K_UNKNOWN,K_class,K_on……}两次includekeywords.hInteresting:includekeywords.htwotimes?Whatdoweget?第一次包含：得到枚举定义和一些函数重新定义KEYWROD宏四个参数全用上了定义一个结构体数组keyword_info再次包含keywords.h实际上是以枚举定义的元素为数组索引，填充keyword_info数组（用新的KEYWORD宏）Result：明白了？奇技淫巧乎？2.2用好“DllMain函数”——客户端Property读取的实现Android平台提供系统级别的属性管理和控制类比Windows平台上的“注册表”：可以存储一些类似key/value的键值对。作用：一般而言，系统或某些应用程序会把自己的一些属性存储在注册表中，即使下次系统重启或应用程序重启，它还能够根据之前在注册表中设置的属性，进行相应的初始化工作。Diveintocode这个变量由bioniclibc库输出，有什么用呢？Android想要做什么？---（目的）1属性区域是由init进程创建2希望其他进程也能快速读取属性区域里的内容Android怎么做到？---（方法）1属性区域创建于共享内存上2客户端进程不知不觉得映射这块内存利用了gcc的constructor属性，这个属性指明了一个__libc_prenit函数，当bioniclibc库被加载时，将自动调用这个__libc_prenit，这个函数内部就将完成共享内存到本地进程的映射工作。Diveintocodeconstructor属性指示加载器加载该库后，首先调用__libc_prenit函数。这一点和Windows上动态库的DllMain函数类似AnyQuestionsaboutinit?四Android常用类重难点分析代码中漫天可见的RefBase、spandwp到底是什么？Inmyopinion：1Refbase类似MFC的CObject，为C++对象之始祖。2sp非smartpointer，而是strongpointer，wp为weakpointer。3三者协同组建AndroidC++对象生命周期的管理和控制机能。Let’sdiveintocode……3.1SampleOne:初识影子对象//A没有任何自己的功能//sp，wp对象是在{}中创建的，下面将先创建sp，然后创建wp//大括号结束前，先析构wp,再析构spDiveintoCode类A从RefBase中派生。使用的是RefBase构造函数mRefs是RefBase的成员变量，类型是weakref_impl,暂且称之为影子对象//强引用计数，初始值为0x1000000//弱引用计数，初始值为0//该影子对象所指向的实际对象QuickQuestion：见到mStrong和mWeak,是否嗅到蛛丝马迹？发现影子对象成员中有两个引用计数？一个强引用，一个弱引用。如果知道引用计数和对象生死有些许关联的话，就容易想到影子对象的作用了。sp的构造//mRefs就是刚才RefBase构造函数中new出来的影子对象调试版的：这几个函数将donothing!//原子操作，影子对象的弱引用计数加1continueincStrong//刚才增加了弱引用计数，再增加强引用计数//下面函数为原子加1操作，并返回旧值。所以c=0x1000000，而mStrong变为0x1000001//如果c不是初始值，则表明这个对象已经被强引用过一次了//下面这个是原子加操作，相当于执行refs-mStrong+（-0x1000000）,最终mStrong=1如果是第一次引用，则调用onFirstRef，这个函数很重要，派生类可以重载这个函数，完成一些初始化工作。sp构造后的结果:sp的出生导致影子对象的强引用计数加1，弱引用计数加1wp的构造//调用pA的createWeak,并且保存返回值到成员变量m_refs中//调用影子对象的incWeak，将导致影子对象的弱引用计数增加1wp构造后的结果:影子对象的弱引用计数将增加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//mFlags为0，所以会通过deletethis把自己干掉//注意，此时弱引用计数仍为1deletethis自杀行为没有把影子对象干掉但我们还在decStrong中//调用前影子对象的弱引用计数为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。生死魔咒-