写给Android App开发人员看的Android底层知识合集（1-8）

写给Android App开发人员看的Android底层知识合集（1-8）

转自包老师：http://www.cnblogs.com/Jax/p/6864103.html

写给Android App开发人员看的Android底层知识（1）

 （一）引言
早在我还是Android菜鸟的时候，有很多技术我都不太明白，也都找不到答案，比如apk是怎么安装的，比如资源是怎么加载的。
再比如说，每本书都会讲AIDL，但我却从来没用过。四大组件也是这个问题，我只用过Activity，其它三个组件，不但没用过，甚至连它们是做什么的，都不是很清楚。
      之所以这样，是因为我一直从事的是电商类App开发工作，对于这类App，基本就是由列表页和详情页组成的，所以我们每天面对的是Activity，会写这两类页面，把网络底层封装的足够强大就够了。
绝大多数App开发人员，都是如此。
但直到接触Android的插件化编程和热修复技术，才发现只掌握上述这些技术是远远不够的。
 
（二）还是引言
市场上有很多介绍Android底层的书籍，网上也有很多文章，但大都是给ROM开发人员看的，动辄贴出几页代码，不适合App开发人员去阅读学习。
我曾经在微信中问过老罗和老邓，你们写的书为什么我们App开发人员看不懂啊，他们就呵呵了，跟我说，他们的书就是写给ROM开发人员看的。
于是，这几年来，我一直在寻找这样一类知识，App开发人员看了能有助于他们更好的编写App程序，而又不需要知道太多这门技术底层的代码实现。
 
这类知识分为两种。
      一种是知道概念即可，就比如说Zygote，其实App开发人员是不需要了解Zygote的，知道有这么个东西是“孕育天地”的就够了，类似的还有SurfaceFlinger、WMS这些概念。
       还有一种是需要知道内部原理，就比如说Binder。关于Binder的介绍铺天盖地，但对于我们App开发人员，需要了解的是它的架构模型，只要有Client和Server，以及SM就足够了。
      四大组件的底层通信机制都是基于Binder的，我们需要知道每个组件中，分别是哪些类扮演了Binder Client，哪些类扮演了Binder Server。知道这些概念，有助于我们App开发人员进行插件化编程。
 
（三）目录
我这个系列的文章，已经写好了下面的内容，会在接下来的每天发布一篇，共计8篇，看了这8篇文章，就可以迈进Android插件化的大门了。
   Binder
   AIDL
   AMS
   Activity
   Service
   ContentProvider
   匿名共享内存
   BroadcastReceiver
   PMS及App安装过程
 
Android底层知识，还应该包括以下内容，但是和插件化关系不大，也不是我擅长的领域，所以我只列出了大纲，没有继续写下去：
   View和ViewGroup
   Message、Looper和Handler
   权限管理
   Android SDK工具内部原理
 
有兴趣的同学，可以按照我这个思路继续写下去，记得，一，少贴代码。多画图，二，一定要有趣。
 
       接下来就详细讲那些App开发人员需要知道的Android底层知识。
 
       （三）Binder
       Binder是为了解决跨进程通信。
关于Binder的文章实在是太多了，每篇文章都能从Java层讲到C++层，App开发人员其实是没必要了解这么多内容的。我们看对App开发有用的几个点：
1）首先，Binder分为Client和Server两个进程。
注意，Client和Server是相对的。谁发消息，谁就是Client，谁接收消息，谁就是Server。
      举个例子，两个进程A和B之间使用Binder通信，进程A发消息给进程B，那么这时候A是Binder Client，B是Binder Server；进程B发消息给进程A，那么这时候B是Binder Client，A是Binder Server——其实这么说虽然简单了，但还是不太严谨，我们先这么理解着。
 
2）其次，我们看下面这个图（摘自田维术的博客），基本说明白了Binder的组成解构：
 
 
 
图中的IPC就是进程间通信的意思。
图中的ServiceManager，负责把Binder Server注册到一个容器中。
      有人把ServiceManager比喻成电话局，存储着每个住宅的座机电话，还是很恰当的。张三给李四打电话，拨打电话号码，会先转接到电话局，电话局的接线员查到这个电话号码的地址，因为李四的电话号码之前在电话局注册过，所以就能拨通；没注册，就会提示该号码不存在。
      对照着Android Binder机制，对着上面这图，张三就是Binder Client，李四就是Binder Server，电话局就是ServiceManager，电话局的接线员在这个过程中做了很多事情，对应着图中的Binder驱动
 
3）接下来我们看Binder通信的过程，还是摘自田维术博客的一张图：
 
 
      
       注：图中的SM也就是ServiceManager。
 
       我们看到，Client想要直接调用Server的add方法，是不可以的，因为它们在不同的进程中，这时候就需要Binder来帮忙了。
首先是Server在SM这个容器中注册。
其次，Client想要调用Server的add方法，就需要先获取Server对象， 但是SM不会把真正的Server对象返回给Client，而是把Server的一个代理对象返回给Client，也就是Proxy。
然后，Client调用Proxy的add方法，SM会帮他去调用Server的add方法，并把结果返回给Client。
 
       以上这3步，Binder驱动出了很多力，但我们不需要知道Binder驱动的底层实现，涉及到C++的代码了——把有限的时间去做更有意义的事情。
 
       App开发人员对Binder的掌握，这些内容就足够了。
 
       是时候总结一波了：
学习Binder，是为了更好的理解AIDL，基于AIDL模型，进而了解四大组件的原理。
理解了Binder，再看AMS和四大组件的关系，就像是Binder的两个进程Server和Client通信。
 
       （四）AIDL
       AIDL是Binder的延伸。一定要先看懂我前面介绍的Binder，再来看AIDL。要按顺序阅读。
       Android系统中很多系统服务都是aidl，比如说剪切板。举这个例子，是为了让App开发人员知道AIDL无处不在，和我们距离非常近。
 
       AIDL中需要知道下面几个类：
   IBinder
   IInterface
   Binder
   Proxy
   Stub
 
       当我们自定义一个aidl文件时（比如MyAidl.aidl，里面有一个sum方法），Android Studio会帮我们生成一个类文件MyAidl.java，如下图所示：
 
 
   
MyAidl.java这个生成文件中，包括MyAidl接口，以及Stub和Proxy两个实现了MyAidl接口的类，其中Stub是定义在MyAidl接口中的，而Proxy则定义在Stub类中。
      我曾经很不理解，为什么不是生成3个文件，一个接口，两个类，清晰明了。都放在一个文件中，这是导致很多人看不懂AIDL的一个门槛。其实Android这么设计是有道理的。当有多个AIDL类的时候，Stub和Proxy类就会重名，把它们放在各自的AIDL接口中，就必须MyAidl.Stub这样去使用，就区分开了。
 
       对照这张图，我们继续来分析，Stub的sum方法是怎么调用到Proxy的sum方法？然后又调用另一个进程的sum方法的？
       起决定意义的是Stub的asInterface方法和onTransact方法。其实这个图没有画全，把完整的Binder Server也画上，就应该是这样：
 
 
 
       1）先从Client看起，对于AIDL的使用者，我们这么写程序：
MyAidl.Stub.asInterface(某IBinder对象).sum(1, 2);         //最好在执行sum方法前判空。
 
       asInterface方法的作用是判断参数——也就是IBinder对象，和自己是否在同一个进程：
   是，则直接转换、直接使用，接下来就跟Binder跨进程通信无关啦；
   否，则把这个IBinder参数包装成一个Proxy对象，这时调用Stub的sum方法，间接调用Proxy的sum方法。
return new MyAidl.Stub.Proxy(obj);
      
       2）Proxy在自己的sum方法中，会使用Parcelable来准备数据，把函数名称、函数参数都写入_data，让_reply接收函数返回值。最后使用IBinder的transact方法，把数据就传给Binder的Server端了。
mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0); //这里的mRemote就是asInterface方法传过来的obj参数
      
 
———————我是Binder分界线—————－
 
       3）Server则是通过onTransact方法接收Client进程传过来的数据，包括函数名称、函数参数，找到对应的函数，这里是sum，把参数喂进去，得到结果，返回。
       所以onTransact函数经历了读数据-->执行要调用的函数-->把执行结果再写数据的过程。
 
       下一篇文章要介绍的四大组件的原理，我们都可以对照着AIDL的这张图来看，比如说，四大组件的启动和后续流程，都是在和ActivityManagerService（简称AMS）来来回回的通信，四大组件给AMS发消息，四大组件就是Binder Client，而AMS就是Binder Server；AMS发消息通知四大组件，那么角色就互换。
      
       那么四大组件中，比如说Activity，又是哪个类扮演了Stub的角色，哪个类扮演了Proxy的角色呢？这也是我下一篇文章要介绍的，包括AMS、四大组件各自的运行原理。
 
       好戏即将开始。
写给Android App开发人员看的Android底层知识（2）
（五）AMS
如果站在四大组件的角度来看，AMS就是Binder中的Server。
      AMS全称是ActivityManagerService，看字面意思是管理Activity的，但其实四大组件都归它管。估计是Android底层开发人员先写了ActivityManagerService用来管理Activity，后来写Service、Receiver、CP的时候发现代码都差不多，于是就全都用ActivityManagerService，但是却忘记改名字了——我也是猜的，纯属八卦。
 
由此而说到了插件化，我记得16年和Lody、张勇、林光亮一起吃夜宵的时候，我当时问了困惑已久的两个问题：
1）App的安装过程，为什么不把apk解压缩到本地，这样读取图片就不用每次从apk包中读取了——这个问题，我们放到PMS那一节再详细说。
2）为什么Hook永远是在Binder Client端，也就是四大组件这边，而不是在AMS那一侧进行Hook。
 
这里要说清楚第二个问题。就拿Android剪切板举例吧。前面说过，这也是个Binder服务。
      AMS要负责和所有App的四大组件进行通信，也真够他忙的。如果在一个App中，在AMS层面把剪切板功能给篡改了，那会导致Android系统所有的剪切板功能被篡改——这就是病毒了，如果是这样的话，Android系统早就死翘翘了。所以Android系统不允许我们这么做。
      我们只能在AMS的另一侧，Client端，也就是四大组件这边做篡改，这样即使我们把剪切板功能篡改了，也只影响篡改代码所在的App，在别的App中，剪切板功能还是正常的。
 
关于AMS我们就说这么多，下面介绍四大组件时，会反复提到四大组件和AMS的跨进程通信。
 
（六）Activity 第1讲
      对于做App的开发人员而言，Activity是四大组件中用的最多的，也是最复杂的，我这里只讲Activity的启动和通信原理。还有一些相关的概念，比如说View、Looper、Intent、Resource，我以后另起章节来介绍。
 
      注：我对四大组件的分析，都是基于罗升阳的那本分析Android底层的书，我把其中罗列的大部分代码都删掉了，只保留那些对App开发人员有用的一些代码片段和一些关键类名，并融入了我对四大组件的理解。
 
 
1）首先要搞清，App是怎么启动的。
      在手机屏幕上点击某个App的Icon，假设就是斗鱼App吧，这个App的首页（或引导页）就出现在我们面前了。这个看似简单的操作，背后经历了Activity和AMS的反反复复的通信过程。
      首先要搞清楚，在手机屏幕上点击App的icon快捷图标，此时手机屏幕就是一个Activity，而这个Activity所在的App，业界称之为Launcher。Launcher是手机系统厂商提供的，类似小米华为这样的手机，比拼的就是谁的Launcher绚丽和人性化。
      Launcher这个App，其实和我们做的各类应用类App没有什么不同，我们大家用过华为、小米之类的手机，预装App以及我们下载的各种App，都显示在Launcher上，每个App表现为一个Icon。Icon多了可以分页，可以分组，此外，Launcher也会发起网络请求，调用天气的数据，显示在屏幕上，所谓的人性化界面。
还记得我们在开发一款App时，在Manifest文件中是怎么定义默认启动Activity的么？如下所示：
 

 
而Launcher中为每个App的icon提供了启动这个App所需要的Intent信息，如下所示（比如说斗鱼的包名是）：
action：android.intent.action.MAIN
category: android.intent.category.LAUNCHER
cmp: 斗鱼的包名+ 首页Activity名
 
这些信息是App安装（或Android系统启动）的时候，PackageManagerService从斗鱼的apk包的manifest文件中读取到的。
 
所以点击icon就启动了斗鱼App中的首页。
 
2）启动App哪有那么简单
前面介绍的只是App启动的一个最简单的概述。
仔细看，我们会发现，Launcher和斗鱼是两个不同的App，他们位于不同的进程中，它们之间的通信是通过Binder完成的——这时候AMS出场了。
 
仍然以启动斗鱼App为例子，整体流程是：
Launcher通知AMS，要启动斗鱼App，而且指定要启动斗鱼的哪个页面（也就是首页）。
AMS通知Launcher，好了我知道了，没你什么事了，同时，把要启动的首页记下来。
Launcher当前页面进入Paused状态，然后通知AMS，我睡了，你可以去找斗鱼App了。
AMS检查斗鱼App是否已经启动了。是，则唤起斗鱼App即可。否，就要启动一个新的进程。AMS在新进程中创建一个ActivityThread对象，启动其中的main函数。
斗鱼App启动后，通知AMS，说我启动好了。
AMS翻出之前在第二步存的值，告诉斗鱼App，启动哪个页面。
斗鱼App启动首页，创建Context并与首页Activity关联。然后调用首页Activity的onCreate函数。
 
至此启动流程完成，分成两部分，1-3步，Launcher和AMS相互通信，而后面几步，斗鱼App和AMS相互通信。
 
这会牵扯一堆类进来，列举如下，在接下来的分析中，我们都会遇到：
   Instrumentation
   ActivityThread
   H
   LoadedApk
   AMS
   ActivityManagerNative和ActivityManagerProxy
   ApplicationThread和ApplicationThreadProxy
 
 
第1阶段 Launcher通知AMS
 

 
这是我根据老罗那本书中对Activity的分析，自己手绘的UML图，一共七张，也就是Activity启动所经历的七个阶段。建议各位读者也亲自手绘一遍，从而就加深理解。
 
   第1步、第2步
      从上图中我们看到，点击Launcher上的斗鱼App的icon快捷图标，这时会调用Launcher的startActivitySafely方法，其实还是会调用Activity的startActivity方法，intent中带着要启动斗鱼App所需要的关键信息，如下所示：
      action = “android.intent.action.MAIN”
      category = “android.intent.category.LAUNCHER”
      cmp = “com.douyu.activity.MainActivity”
 
      第3行代码是我猜的，就是斗鱼App在Mainfest文件中指定为首页的那个Activity。这样，我们终于明白，为什么在Mainfest中，给首页指定action和category了。在app的安装过程中，会把这个信息“记录”在Launcher的斗鱼启动快捷图标中。关于App的安装过程，我会在后面的文章详细介绍。
 
      startActivity这个方法，如果我们看它的实现，会发现它调来调去，经过一系列startActivity的重载方法，最后会走到startActivityForResult方法。
 
      
 
      我们知道startActivityForResult需要两个参数，一个是intent，另一个是code，这里code是-1，表示Launcher才不关心斗鱼的App是否启动成功了呢。
      
 
      第3步： startActivityForResult
      Activity内部会保持一个对Instrumentation的引用，但凡是做过App单元测试的同学，对这个类都很熟悉，称之为仪表盘。
      在startActivityForResult方法的实现中，会调用Instrumentation的execStartActivity方法。
 

 
看到这里，我们发现有个mMainThread变量，这是一个ActivityThread类型的变量。
      这个家伙的来头可不小。
ActivityThread，就是主线程，也就是UI线程，它是在App启动时创建的，它代表了App应用程序。
      啥？ActivityThread代表了App应用程序，那Application类岂不是被架空了？其实，Application对我们App开发人员来说也许很重要，但是在Android系统中还真的没那么重要，他就是个上下文。Activity不是有个Context上下文吗？Application就是整个ActivityThread的上下文。
ActivityThread则没有那么简单了。它里面有main函数。
 
      我们知道大部分程序都有main函数，比如java、C#，远了不说，iPhone App用到的Objective-C，也有main函数，那么Android的main函数藏在哪里？就在ActivityThread中，如下所示，代码太多，我只截取了一部分
 

      又有人会问？不是说谁写的程序，谁就要提供main函数，作为入口吗？但Android App却不是这样的。Android App的main函数，在ActivityThread里面，而这个类是Android系统提供的底层类，不是我们提供的。
       所以这就是Andoid有趣的地方。Android App的入口是Mainifest中定义默认启动Activity。这是由Android AMS与四大组件的通信机制决定的。
 
       最近在看吴越版的西游记，就发现这个西天取经为啥用了十几年啊？因为这师徒四个取经路上爱管闲事，所以耽搁了很久。我这篇文章也是如此，经常讲着讲着就跑题了，再这么写下去，不知道要写到啥时候，所以我们一路向西，径直往前走，再遇到奇怪的类，先不要理它。
 
      在回到代码来，这里要传递2个很重要的参数：
   通过ActivityThread的getApplicationThread方法取到一个Binder对象，它的类型为ApplicationThread，它代表着Launcher所在的App进程。
   mToken，这也是个Binder对象，它代表了Launcher这个Activity，这里也通过Instrumentation传给AMS，AMS一查电话簿，就知道是谁向AMS发起请求了。
      
      这两个参数是伏笔，传递给AMS，以后AMS想反过来通知Launcher，就能通过这两个参数，找到Launcher。
 
 
 
       第4步，Instrumentation的execStartActivity方法
       Instrumentation绝对是Adnroid测试团队的最爱，因为它可以帮我们启动Activity。
 
       回到我们的App启动过程来，在Instrumentation的execStartActivity方法中，
 

 
我理解这就是一个透传，Activity把数据借助Instrumentation，传递给ActivityManagerNative，没太多有趣的内容，就不多讲了。
 
      第5步：AMN的getDefault方法
      ActivityManagerNative，简称AMN。这个类后面会反复用到。
      AMN通过getDefault方法，从ServiceManager中取得一个名为activity的对象，然后把它包装成一个ActivityManagerProxy对象（简称AMP），AMP就是AMS的代理对象。
      备注1：ServiceManager是一个容器类。
      备注2:  AMN的getDefault方法返回类型为IActivityManager，而不是AMP。IActivityManager是一个实现了IInterface的接口，里面定义了四大组件所有的生命周期。
      AMN和AMP都实现了IActivityManager接口，AMS继承自AMN（好乱），那么对照着前面AIDL的UML，就不难理解了：
 

 
第6步，AMP的startActivity方法
看到这里，你会发现AMP的startActivity方法，和AIDL的Proxy方法，是一模一样的，写入数据到另一个进程，也就是AMS，然后等待AMS返回结果。
 
至此，第一阶段的工作就做完了。
 
后续流程请参加下一篇文章。
写给Android App开发人员看的Android底层知识（3）
       （七）App启动流程第2篇
 
       书接上文，App启动一共有七个阶段，上篇文章篇幅所限，我们只看了第一阶段，接下来讲剩余的六个阶段，仍然是拿斗鱼App举例子。
 
       简单回顾一下第一阶段的流程，就是Launcher向AMS发送一个跨进程通信，通过AMN/AMP，告诉AMS，我要启动斗鱼App。
 
       画一个图，描述一下启动App所经历的7个阶段：
 

第2阶段 AMS处理Launcher传过来的信息
 

 
这个阶段主要是Binder的Server端在做事情。因为我们是没有机会修改Binder的Server端逻辑的，所以这个阶段看起来非常枯燥，我尽量说的简单些。
首先Binder，也就是AMN/AMP，和AMS通信，肯定每次是做不同的事情，就比如说这次Launcher要启动斗鱼App，那么会发送类型为START_ACTIVITY——TRANSACTION的请求给AMS，同时会告诉AMS要启动哪个Activity。
AMS说，好，我知道了，然后它会干一件很有趣的事情，就是检查斗鱼App中的Manifest文件，是否存在要启动的Activity。如果不存在，就抛出Activity not found的错误，各位做App的同学对这个异常应该再熟悉不过了，经常写了个Activity而忘记在Manifest中声明了，就报这个错，就是因为AMS在这里做检查。不管是新启动一个App的首页，还是在App内部跳转到另一个Activity，都会做这个检查。
但是Launcher还活着啊，所以接下来AMS会通知Launcher，哥们儿没你什么事了，你“停薪留职”吧。那么AMS是通过什么途径告诉Launcher的呢？
 
       前面讲过，Binder的双方进行通信是平等的，谁发消息，谁就是Client，接收的一方就是Server。Client这边会调用Server的代理对象。
       对于从Launcher发来的消息，通过AMS的代理对象AMP，发送给AMS。
 
       那么当AMS想给Launcher发消息，又该怎么办呢？前面不是把Launcher以及它所在的进程给传过来了吗？它在AMS这边保存为一个ActivityRecord对象，这个对象里面有一个ApplicationThreadProxy，单单从名字看就出卖了它，这就是一个Binder代理对象。它的Binder真身，也就是ApplicationThread。
       站在AIDL的角度，来画这张图，是这样的：
 

所以结论是，AMS通过ApplicationThreadProxy发送消息，而App端则是通过ApplicationThread来接收这个消息。
 
      第3阶段 Launcher去休眠，然后通知AMS，我真的已经“停薪留职”了，没有吃空饷
 

ApplicationThread（简称APT），它和ApplicationThreadProxy（简称ATP）的关系，我们在第三阶段已经介绍过了。
      APT接收到来自AMS的消息后，就调用ActivityThread的sendMessage方法，向Launcher的主线程消息队列发送一个PAUSE_ACTIVITY消息。
      前面说过，ActivityThread就是主线程（UI线程）
 
      看到下面的代码是不是很亲切？
 

发送消息是通过一个名为H的Handler类的完成的，这个H类的名字真特么有个性，想记不住都难。
      做App的同学都知道，继承自Handler类的子类，就要实现handleMessage方法，这里是一个switch…case语句，处理各种各样的消息，PAUSE_ACTIVITY消息只是其中一种，由此也能预见到，AMS给Activity发送的所有消息，以及给其它三大组件发送的所有消息，都从H这里经过，为什么要强调这一点呢，既然四大组件都走这条路，那么这里就可以做点手脚，从而做插件化技术，这个我们以后介绍插件化技术的时候会讲到。
 

H对于PAUSE_ACTIVITY消息的处理，如上面的代码，是调用ActivityThread的handlePauseActivity方法。这个方法干两件事：
   ActivityThread里面有一个mActivities集合，保存当前App也就是Launcher中所有打开的Activity，把它找出来，让它休眠。
   通过AMP通知AMS，我真的休眠了。
 
      你可能会找不到H和APT这两个类文件，那是因为它们都是ActivityThread的内嵌类。
 
      至此，Launcher的工作完成了。你可以看到在这个过程中，各个类都起到了什么作用。芸芸众生，粉墨登场：
   APT
   ActivityThread
   H
 
      第4阶段 AMS启动新的进程
      接下来又轮到AMS做事了，你们会发现我不太喜欢讲解AMS的流程，甚至都不画UML图，因为这部分逻辑和App开发人员关系不是很大，我尽量说的简单一些，把流程说清楚就好。
 
      AMS接下来要启动斗鱼App的首页，因为斗鱼App不在后台进程中，所以要启动一个新的进程。这里调用的是Process.start方法，并且指定了ActivityThread的main函数为入口函数。
 

第5阶段 新的进程启动，以ActivityThread的main函数作为入口

启动新进程，其实就是启动一个新的App。
 
      在启动新进程的时候，为这个进程创建ActivityThread对象，这就是我们耳熟能详的主线程（UI线程）。
      创建好UI线程后，立刻进入ActivityThread的main函数，接下来要做2件具有重大意义的事情：
      1）创建一个主线程Looper，也就是MainLooper。看见没，MainLooper就是在这里创建的。
      2）创建Application。记住，Application是在这里生成的。
 
- - - - - - - - - - - - - -华丽的分割线 开始- - - - - - - - - - - - - - -
 
      App开发人员对Application非常熟悉，因为我们可以在其中写代码，进行一些全局的控制，所以我们通常认为Application是掌控全局的，其实Application的地位在App中并没有那么重要，它就是一个Context上下文，仅此而已。
      App中的灵魂是ActivityThread，也就是主线程，只是这个类对于App开发人员是访问不到的——使用反射倒是可以修改这个类的一些行为。
 
- - - - - - - - - - - - - - -华丽的分割线 结束- - - - - - - - - - - - - - -
                                                                                                                                                                                                                              
      创建新App的最后，就是告诉AMS，我启动好了，同时把自己的ActivityThread对象发送给AMS，从此以后，AMS的电话簿中就多了这个新的App的登记信息，AMS以后向这个App发送消息，就通过这个ActivityThread对象。
 
     第6阶段 AMS告诉新App启动哪个Activity
     AMS把传入的ActivityThread对象，转为一个ApplicationThread对象，用于以后和这个App跨进程通信。还记得APT和ATP的关系吗？这就又回到第2阶段的那张关系图了。
 
     还记得第1阶段，Launcher发送给AMS要启动斗鱼App的哪个Activity吗？这个信息被AMS存下来了。
     那么在第6阶段，AMS从过去的记录中翻出来要启动哪个Activity，然后通过ATP告诉App。
 
     第7阶段 启动斗鱼首页Activity
 

      毕其功于一役，尽在第7阶段。这是最后一步。
 
      App，这个Binder的另一端，通过APT接收到AMS的消息，仍然是在H的handleMessage方法的switch语句中处理，只不过，这次消息的类型是LAUNCH_ACTIVITY：
 

 
      ActivityClientRecord是什么？这是AMS传递过来的要启动的Activity。
      还是这里，我们仔细看那个getPackageInfoNoCheck方法，这个方法会提取Apk中的所有资源，然后设置给r的packageInfo属性。这个属性的类型很有名，叫做LoadedApk。各位记住这里，这个地方可以干坏事，也是插件化技术渗入的一个点。
 
      在H的这个分支中，又反过来回调ActivityThread的handleLaunchActivity方法，你要是觉得很绕那就对了。其实我一直觉得，ActivityThread和H合并成一个类也没问题。
 

      重新看一下这个过程，每次都是APT执行ActivityThread的sendMessage方法，在这个方法中，把消息拼装一下，然后扔个H的swicth语句去分析，来决定要执行ActivityThread的那个方法。每次都是这样，习惯就好了。
 
      handleLaunchActivity方法都做哪些事呢？
      1）通过Instrumentation的newActivity方法，创建出来要启动的Activity实例。
      2）为这个Activity创建一个上下文Context对象，并与Activity进行关联。
      3）通过Instrumentation的callActivityOnCreate方法，执行Activity的onCreate方法，从而启动Activity。看到这里是不是很熟悉很亲切？
 
      至此，App启动完毕。这个流程是经过了很多次握手， App和ASM，频繁的向对方发送消息，而发送消息的机制，是建立在Binder的基础之上的。
 
下一篇文章，我们讲Context家族。
写给Android App开发人员看的Android底层知识（4）
（八）App内部的页面跳转
 
      在介绍完App的启动流程后，我们发现，其实就是启动一个App的首页。
 
      接下来我们看App内部页面的跳转。
 
      从ActivityA跳转到ActivityB，其实可以把ActivityA看作是Launcher，那么这个跳转过程，和App的启动过程就很像了。
      有了前面的分析基础，会发现，这个过程不需要重新启动一个新的进程，所以可以省略App启动过程中的一些步骤，流程简化为：
      1）ActivityA向AMS发送一个启动ActivityB的消息。
      2）AMS保存ActivityB的信息，然后通知App，你可以休眠了（onPaused）。
      3）ActivityA进入休眠，然后通知AMS，我休眠了。
      4）AMS发现ActivityB所在的进程就是ActivityA所在的进程，所以不需要重新启动新的进程，所以它就会通知App，启动ActivityB。
      5）App启动ActivityB。
 
      不想看上述文字的，看我画的这个图：
 

 
整体流程我就不多说了，和上一篇文章介绍的App启动流程是基本一致的。
 
      以上的分析，仅限于ActivityA和ActivityB在相同的进程中，如果在Manifest中指定这两个Activity不在同一个进程中，那么就又是另一套流程了，但是整体流程大同小异。
 
 
      （九）Context家族史
      Activity和Service都有Context，这三个类，还有Application，其实是亲戚一家子。
 

 
Activity因为有了一层Theme，所以中间有个ContextThemeWrapper，相当于它是Service和Application的侄子。
 
      ContextWrapper只是一个包装类，没有任何具体的实现，真正的逻辑都在ContextImpl里面。
 
一个应用包含的Context个数：Service个数+Activity个数+1(Application类本身对应一个Context对象)。
 
应用程序中包含多个ContextImpl对象，而其内部变量mPackageInfo指向同一个PackageInfo对象。
 
- - - - - - - - - - - - - 华丽的分割线，以下是例子- - - - - - - - - - - - - - - - - - - -
 
      我们就拿Activity举例子，看看Activity和Context的联系和区别。
 
      我们知道，跳转到一个新的Activity要这么写：
 

 
我们还知道，也可以在Activity中使用getApplicationContext方法获取Context上下文信息，然后使用Context 的startActivity方法，启动一个新的Activity：
 

 
这二者的区别是什么？我们画个图，就看明白了：
 

 
 
      因为Context的startActivity方法，我看了在ContextImpl中的源码实现，仍然是从ActivityThread中取出Instrumentation，然后执行execStartActivity方法，这和使用Activity的startActivity方法的流程是一样的。
 
      还记得我们前面分析的App启动流程么？在第五阶段，创建App进程的时候，先创建的ActivityThread，再创建的Application。Application的生命周期是跟着整个App走的。
      而getApplicationContext得到的Context，就是从ActivityThread中取出来的Application对象，所以这个Context上下文，使用时要当心，容易引起内存泄露。
 

 
 
下一篇文章，我们就要迈进Service的世界了。
写给Android App开发人员看的Android底层知识（5）
     （十）Service
     Service有两套流程，一套是启动流程，另一套是绑定流程。我们做App开发的同学都应该知道。
 
     
     1）在新进程启动Service
       我们先看Service启动过程，假设要启动的Service是在一个新的进程中，分为5个阶段：
       1）App向AMS发送一个启动Service的消息。
       2）AMS检查启动Service的进程是否存在，如果不存在，先把Service信息存下来，然后创建一个新的进程。
       3）新进程启动后，通知AMS说我可以啦。
       4）AMS把刚才保存的Service信息发送给新进程
       5）新进程启动Service
 
     我们仔细看一下这5个阶段：
 
     第1阶段
 
     
 
     和Activity非常像，仍然是通过AMM/AMP把要启动的Service信息发送给AMS。
 
     第2阶段
     AMS检查Service是否在Manifest中声明了，没声明会直接报错。
 
     AMS检查启动Service的进程是否存在，如果不存在，先把Service信息存下来，然后创建一个新的进程。
 
     在AMS中，每个Service，都使用ServiceRecord对象来保存。
 
     第3阶段
     Service所在的新进程启动的过程，就和前面介绍App启动时的过程差不多。
 
     新进程启动后，也会创建新的ActivityThread，然后把ActivityThread对象通过AMP传递给AMS，告诉AMS，新进程启动成功了。
 
     第4阶段
     AMS把传进来的ActivityThread对象改造为ApplicationThreadProxy，也就是ATP，通过ATP，把要启动的Service信息发送给新进程。
 
     第5阶段
 
     
 
     新进程通过ApplicationThread接收到AMS的信息，和前面介绍的启动Activity的最后一步相同，借助于ActivityThread和H，执行Service的onCreate方法。在此期间，为Service创建了Context上下文对象，并与Service相关联。
 
     需要重点关注的是ActivityThread的handleCreateService方法，
 
     
 
     你会发现，这段代码和前面介绍的handleLaunchActivity差不多，都是从PMS中取出包的信息packageInfo，这是一个LoadedApk对象，然后获取它的classloader，反射出来一个类的对象，在这里反射的是Service。
     四大组件的逻辑都是如此，所以我们要做插件化，可以在这里做文章，换成插件的classloader，加载插件中的四大组件。
 
     至此，我们在一个新的进程中启动了一个Service。
 
    2）启动统一进程的Service
     如果是在当前进程启动这个Service，那么上面的步骤就简化为：
       1）App向AMS发送一个启动Service的消息。
       2）AMS例行检查，比如Service是否声明了，把Service在AMS这边注册。AMS发现要启动的Service就是App所在的Service，就通知App启动这个Service。
       3）App启动Service。
 
     我们看到，没有了启动新进程的过程。
 
    3）在同一进程绑定Service
     如果是在当前进程绑定这个Service呢？过程是这样的：
       1）App向AMS发送一个绑定Service的消息。
       2）AMS例行检查，比如Service是否声明了，把Service在AMS这边注册。AMS发现要启动的Service就是App所在的Service，就先通知App启动这个Service，然后再通知App，对Service进行绑定操作。
       3）App收到AMS第1个消息，启动Service，
       4）App收到AMS第2个消息，绑定Service，并把一个Binder对象传给AMS
       5）AMS把接收到的Binder对象，发送给App
       6）App收到Binder对象，就可以使用了。
 
     你也许会问，都在一个进程，App内部直接使用Binder对象不就好了，其实吧，要考虑不在一个进程的场景，代码又不能写两份，两套逻辑，所以就都放在一起了，即使在同一个进程，也要绕着AMS走一圈。
 
    第1阶段：App向AMS发送一个绑定Service的消息。
 
     
 
     第4阶段：处理第2个消息
 
     
     第5阶段和第6阶段：
 
     这一步是要仔细说的，因为AMS把Binder对象传给App，这里没用ATP和APT，而是用到了AIDL来实现，这个AIDL的名字是IServiceConnection。
 
     
 
     ServiceDispatcher的connect方法，最终会调用ServiceConneciont的onServiceConnected方法，这个方法我们就很熟悉了。App开发人员在这个方法中拿到connection，就可以做自己的事情了。
 
      好了，关于Service的底层知识，我们就全都介绍完了。当你再去编写一个Service时，是否感觉对这个组件理解的更透彻了呢？
 
     下一篇我们聊一聊BroadcastReceiver。
写给Android App开发人员看的Android底层知识（6）
（十一）BroadcastReceiver
BroadcastReceiver，也就是广播，简称Receiver。
 
     很多App开发人员表示，从来没用过Receiver。其实吧，对于音乐播放类App，用Service和Receiver还是蛮多的，如果你用过QQ音乐，App退到后台，音乐照样播放不会停止，这就是你写的Service在后台起作用。
     在前台的Activity，点击停止按钮，就会给后台Service发送一个Receiver，通知它停止播放音乐；点击播放按钮，仍然是发送这个Receiver，只是携带的值变了，所以Service收到请求后播放音乐。
     反过来，后台Service播放每播放完一首音乐，接下来准备播放下一首音乐的时候，就会给前台Activity发Receiver，让Activity显示下一首音乐的名称。
所以音乐播放器的原理，就是一个前后台Activity和Service互相发送和接收Receiver的过程。
 
     
 
     Receiver分静态广播和动态广播两种。
     在Manifest中声明的Receiver，是静态广播：
     
     
     
     在程序中手动写注册代码的，是动态广播：
 
     
 
     二者具有相同的功能，只是写法不同。既然如此，我们就可以把所有静态广播，都改为动态广播，这就省的在Manifest文件中声明了，避免了AMS检查。接下来你想到什么？对，Receiver的插件化解决方案，就是这个思路。
     接下来我们看Receiver是怎么和AMS打交道的，分为两部分，一是注册，二是发送广播。
     你只有注册了这个广播，发送这个广播时，才能通知到你，执行onReceive方法。
      
     我们就拿音乐播放器来举例，在Activity注册Receiver，在Service发送广播。Service播放下一首音乐时，会通知Activity修改当前正在播放的音乐名称。
 
     注册过程如下所示：
     1）在Activity中，注册Receiver，并通知AMS。
 
     
     这里Activity使用了Context提供的registerReceiver方法，然后通过AMN/AMP，把一个receiver传给AMS。
     在创建这个Receiver对象的时候，需要为receiver指定IntentFilter，这个filter就是Receiver的身份证，用来描述receiver。
 
     在Context的registerReceiver方法中，它会使用PMS获取到包的信息，也就是LoadedApk对象。
     就是这个LoadedApk对象，它的getReceiverDispatcher方法，将Receiver封装成一个实现了IIntentReceiver接口的Binder对象。
     我们就是将这个Binder对象和filter传递给AMS。
 
     只传递Receiver给AMS是不够的，当发送广播时，AMS不知道该发给谁啊？所以Activity所在的进程还要把自身对象也发送给AMS。
 
     2）AMS收到消息后，就会把上面这些信息，存在一个列表中，这个列表中保存了所有的Receiver。
     注意了，这里忙活半天，都是在注册动态receiver。
     静态receiver什么时候注册到AMS的呢？是在App安装的时候。PMS会解析Manifest中的四大组件信息，把其中的receiver存起来。
 
     动态receiver和静态receiver分别存在AMS不同的变量中，在发送广播的时候，会把两种receiver合并到一起，然后以此发送。其中动态的排在静态的前面，所以动态receiver永远优先于静态receiver收到消息。
 
 
     此外，Android系统每次启动的时候，也会把静态广播接收者注册到AMS。因为Android系统每次启动时，都会重新安装所有的apk，详细流程，我们会在后面PMS的相关章节看到。
 
     - - - - - - - - - - - - - - - 华丽的分界线------------------------
 
    发送广播的流程如下：
     1）在Service中，通过AMM/AMP，发送广播给AMS，广播中携带着Filter。
     2）AMS收到这个广播后，在receiver列表中，根据filter找到对应的receiver，可能是多个，把它们都放到一个广播队列中。最后向AMS的消息队列发送一个消息。
     当消息队列中的这个消息被处理时，AMS就从广播队列中找到合适的receiver，向广播接收者所在的进程发送广播。
     3）receiver所在的进程收到广播，并没有把广播直接发给receiver，而是将广播封装成一个消息，发送到主线程的消息队列中，当这个消息被处理时，才会把这个消息中的广播发送给receiver。
 
     我们下面通过图，仔细看一下这3个阶段：
     第1步，Service发送广播给AMS
 
     
     发送广播，是通过Intent这个参数，携带了Filter，从而告诉AMS，什么样的receiver能接受这个广播。
 
     第2步，AMS接收广播，发送广播。
     接收广播和发送广播是不同步的。AMS每接收到一个广播，就把它扔到广播发送队列中，至于发送是否成功，它就不管了。
     因为receiver分为无序receiver和有序receiver，所以广播发送队列也分为两个，分别发送这两种广播。
 
     AMS发送广播给客户端，这又是一个跨进程通信，还是通过ATP，把消息发给APT。因为要传递Receiver这个对象，所以它也是一个Binder对象，才可以传过去。我们前面说过，在把Receiver注册到AMS的时候，会把Receiver封装为一个IIntentReceiver接口的Binder对象。那么接下来，AMS就是把这个IIntentReceiver接口对象传回来。
 
     第3步，App处理广播
 
     
     这个流程描述如下：
     1）消息从AMS传到客户端，把AMS中的IIntentReceiver接口对象转为InnerReceiver对象，这就是receiver，这是一个AIDL跨进程通信。
     2）然后在ReceiverDispatcher中封装一个Args对象（这是一个Runnable对象，要实现run方法），包括广播接收者所需要的所有信息，交给ActivtyThread来发送
     3）接下来要走的路就是我们所熟悉的了，ActivtyThread把Args消息扔到H这个Hanlder中，向主线程消息队列发送消息。等到执行Args消息的时候，自然是执行Args的run方法。
     4）在Args的run方法中，实例化一个Receiver对象，调用它的onReceiver方法。
     5）最后，在Args的run方法中，随着Receiver的onReceiver方法调用结束，会通过AMN/AMP发送一个消息个AMS，告诉AMS，广播发送成功了。AMS得到通知后，就发送广播给下一个Receiver。
     注意：InnerReceiver是IIntentReceiver的stub，是Binder对象的接收端。
 
 
    广播的种类
     Android广播按发送方式分类有三种：无序广播、有序广播（OrderedBroadcast）和粘性广播（StickyBroadcast）。
 
     1）无序广播是最普通的广播。
     2）有序广播区别于无序广播，就在于它可以指定优先级。
这两种receiver存在AMS不同的变量中，可以认为是两个receiver集合，发送不同类别的广播。
     3）粘性广播是无序广播的一种。
     粘性广播，我们平常见的不多，但我说一个场景你就明白了，那就是电池电量。当电量小于20%的时候，就会提示用户。
     而获取电池的电量信息，就是通过广播来实现的。
     但是一般的广播，发完就完了。我们需要有这样一种广播，发出后，还能一直存在，未来的注册者也能收到这个广播，这种广播就是粘性广播。
 
     由于动态receiver只能在Activity的onCreate()方法调用时才能注册再接收广播，所以当程序没有运行就不能接受到广播；但是静态注册的则不依赖于程序是否处于运行状态。
 
     至此，关于广播的所有概念，就全都介绍完了，就连我都比较惊讶的是，我居然没贴什么代码。希望上述这两千多字，能引导App开发人员进入一个神奇的世界。
 
     下一篇文章，我们去看看ContentProvider。
写给Android App开发人员看的Android底层知识（7）
（十二）ContentProvider
 
（1）ContentProvider是什么？
ContentProvider，简称CP。
做App开发的同学，尤其是电商类App，对CP并不熟悉，对这个概念的最大程度的了解，也仅仅是建立在书本上，它是Android四大组件中的一个。
做系统管理类的App，比如说手机助手这种，有机会频繁使用CP。
而对于应用类App，数据通常存在服务器端，其它应用类App也想使用的时候，一般都是从服务器取数据，所以没机会使用到CP。
 
有时候我们会在自己的App中读取通信录或者短信的数据，这时候就需要用到CP了。通信录或者短信的数据，是以CP的形式提供的，我们在App这边，是使用方。
      对于做应用类App的同学，很少有机会自定义CP供其它App使用。
 
我们快速回顾一下在App中怎么使用CP。
 

 
1）定义CP的App1：
       在App1中定义一个CP的子类MyContentProvider，并在Manifest中声明，为此要在MyContentProvider中实现CP的增删改查四个方法：
 

 

 
2）使用CP的App2：
     在App2访问App1中定义的CP，为此，要使用到ContentResolver，它也提供了增删改查4个方法，用于访问App1中定义的CP：
 

 
首先我们看一下ContentResolver的增删改查这4个方法的底层实现，其实都是和AMS通信，最终调用App1的CP的增删改查4个方法，后面我们会讲到这个流程是怎么样的。
 
      其次，URI是CP的身份证，唯一标识。
      我们在App1中为CP声明URI，也就是authorities的值为baobao，那么在App2中想使用它，就在ContentResolver的增删改查4个方法中指定URI，格式为：
uri = Uri.parse("content://baobao/");
 
      接下来把两个App都进入debug模式，就可以从App2调试进入App1了，比如说，query操作。
 
     （2）CP的本质
      CP的本质是把数据存储在SQLite数据库中。
    
      各种数据源，有各种格式，比如短信、通信录，它们在SQLite中就是不同的数据表，但是对外界的使用者而言，就需要封装成统一的访问方式，比如说对于数据集合而言，必须要提供增删改查四个方法，于是我们在SQLite之上封装了一层，也就是CP。
 
     （3）匿名共享内存（ASM）
CP读取数据使用到了匿名共享内存，英文简称ASM，所以你看上面CP和AMS通信忙的不亦乐乎，其实下面别有一番风景。
      关于ASM的概念，它其实也是个Binder通信，我画个图哦，你们就明白了：
 

 
什么？还没看懂？那我再画一个类的交互关系图：
 

 
这里的CursorWindow就是匿名共享内存。
 
这个流程，简单来说是这样的：
1）Client内部有一个CursorWindow对象，发送请求的时候，把这个CursorWindow类型的对象传过去，这个对象暂时为空。
2）Server收到请求，搜集数据，填充到这个CursorWindow对象。
      3）Client读取内部的这个CursorWindow对象，获取到数据。
 
      由此可见，这个CursorWindow对象，就是匿名共享内存，这是同一块匿名内存。   
举个生活中的例子就是，你定牛奶，在你家门口放个箱子，送牛奶的人每天早上往这个箱子放一袋牛奶，你睡醒了去箱子里取牛奶。这个牛奶箱就是匿名共享内存。
 
 
 
     （4）CP与AMS的通信流程
      接下来我们看一下CP是怎么和AMS通信的。
能坚持看到这里的人，都不容易。我努力多贴图，不贴代码，即使有代码，也是App开发人员能看懂的代码。
还是拿App2想访问App1中定义的CP为例子。我们就看CP的insert方法。
 

 
     上面这5行代码，包括了启动CP和执行CP方法两部分，分水岭在insert方法，insert方法的实现，前半部分仍然是在启动CP，当CP启动后获取到CP的代理对象，后半部分是通过代理对象，调用insert方法。
 
整体的流程如下图所示：
 

 
1）App2发送消息给AMS，想要访问App1中的CP。
2）AMS检查发现，App1中的CP没启动过，为此新开一个进程，启动App1，然后获取到App1启动的CP，把CP的代理对象返回给App2。
      3）App2拿到CP的代理对象，也就是IContentProvider，就调用它的增删改查4个方法了，接下来就是使用ASM来传输数据或者修改数据了，也就是上面提到的CursorWindow这个类，取得数据或者操作结果即可，作为App的开发人员，不需要知道太多底层的详细信息，用不上。
 
至此，关于CP的介绍就结束了。下一篇文章，我们看一下App的安装流程，也就PMS。
写给Android App开发人员看的Android底层知识（8）
（十）PMS及App安装过程
       PMS，全称PackageManagerService，是用来获取Apk包的信息的。
 
       在前面分析四大组件与AMS通信的时候，我们介绍过，AMS总是会使用PMS加载包的信息，将其封装在LoadedApk这个类对象中，然后我们就可以从中取出在manifest声明的四大组件信息了。
 
       （一）
       在下载并安装App的过程，会把Apk存放在data/app目录下。
Apk是一个zip压缩包，在文件头会记录压缩包的大小，所以后续在文件尾巴就算是追加一部小电影，也不会对解压造成影响——木马其实就是这个思路，在可执行文件exe尾巴上挂一个木马病毒，执行exe的同时也会执行这个木马，然后你就中招了。
       我们可以把木马思想运用在Android多渠道打包上。在比较老的Android 4.4版本中，我们会在Apk尾巴上追加几个字节，来标记Apk的渠道。Apk启动的时候，从apk中的尾巴上读取这个渠道值。
       后来Google也发现这个安全漏洞了，在新版本的系统中，就会在Apk安装的时候，检查Apk的实际大小，看这个值与Apk的头部记录的压缩包大小，是否相等，不相等就会报错说安装失败。
      
       （二）
       我们继续说App的安装过程。Android系统使用PMS解析这个Apk中的manifest文件，包括：
   四大组件的信息，比如说，前面讲过的静态Receiver。比如说默认启动的Activity。
   分配用户Id和用户组Id。用户Id是唯一的，因为Android是一个Linux系统。用户组Id指的是各种权限，每个权限都在一个用户组中，比如读写SD卡，比如网络访问，分配了哪些用户组Id，就拥有了哪些权限。
 
       3）在Launcher生成一个icon，icon中保存着默认启动的Activity的信息。
 
       4）App安装过程的最后，是把上面这些信息记录在一个xml文件中，以备下次安装时再次使用。
 
       （三）
       其实，在Android手机系统每次启动的时候，都会使用PMS，把Android系统中的所有Apk都安装一遍，一共4个步骤，如下所示：
 

 
其中的第3步、第4步，和单独安装一个App的步骤是一样的。我们分析一下前两步：
      第1步，因为结束安装的时候，都会把安装信息保存在xml文件中，所以Android系统再次启动时，再次重新安装所有的Apk，就可以直接读取之前保存的xml文件了。
      第2步，从5个目录中读取并安装所有的apk。
 
      最后，回答前面提及的一个问题，为什么App安装时，不把它解压呢？直接从解压文件中读取资源文件比如图片是不是更快呢？其实并不是这样的，这部分逻辑需要到底层C++的代码去寻找，我没有具体看过，只是道听途说问过Lody，他是这么给我解释的：
      每次从apk中读取资源，并不是先解压再找图片资源，而是解析Apk中的Resource.arsc文件，这个文件中存储着资源的所有信息，包括资源在Apk中的地址、大小等等，按图索骥，从这个文件中快速找到相应的资源文件。这是一种很高效的算法。
      不解压Apk的好处，自然是节省空间。