Activity启动流程分析

Posted 2022-11-30 轩辕223

广告时间，大家喜欢我的文章，可以关注我的博客http://zwgeek.com

前面说到，希望分析一下Activity的启动流程，整个过程准备分为三篇文章来写
- 程序调用startActivity后发生的操作
- 如果被startActivity的程序是需要启动的程序，程序在最开始初始化时发生的操作。例如在Launcher中启动一个程序。
- 如果被startActivity的程序是已经启动的程序，发生的操作。例如程序自己调用startActivity启动一个自己程序中的Activity

第一篇文章也已经讲完了程序调用startActivity之后发生的事情。

还没有读过的同学可以看这里Activity启动流程分析

这篇文章就来讲第二个部分，一个程序被启动之后发生的事情。第一篇文章中还提到了几个问题，也会在这篇文章中做出解答。

• getApplication() ，getApplicationContext()，getBaseContext()分别有什么区别？
• 单个进程中能存在多个application么？
• 为什么不能使用service或者application作为创建dialog的context参数？

第一篇文章最后讲到了Process.start方法，说到了这个方法会启动一个线程，并且运行ActivityThread的main方法来正式开启一个android程序。所以，很显然，这篇文章就要从ActivityThread的main方法来开始。

首先，来看一下这个Android程序的起点方法，一睹芳容。

这个方法重要的是在Looper prepare之后的部分，Handler跟loop的机制比较简单，可以先百度一下，我后面可能也会写篇文章说一下。简单来说loop就是一个无限循环，通过循环去去查询有没有handler发过来命令，如果有就处理，没有就继续循环。

这样的话，我们就能看出，主进程在做了一个初始化工作之后就把自己放在了一个loop循环中，要跟这个程序打交道，怎么办呢，就是通过获取它的handler，然后发命令，比如现在需要调用onResume方法，通过handler告诉主进程looper要调用onResume，looper就会做相应的处理了。当然这个是关于Android生命周期方法的调用问题，我们也是要单独拉出来讲的，这里就不细说了。

其实这篇文章的重点是这一句话，thread.attach(false)，ActivityThread的初始化操作。来看下这个方法具体做了什么操作。

这个方法看下来还好，也都是配置一些监听器，像ViewRoot监听，内存监听，等等。重要的还是我选中的这一段，首先创建了一个ApplicationThread，然后把这个ApplicationThread交给了RuntimeInit，很多人开发过程中最头痛的就是RuntimeException，其实这里就是异常监控的初始化过程。然后创建了一个ActivityManagerNative，第一篇文章中就提过，ActivityManagerNative在创建的时候就会和ActivityManagerService绑定。接下来程序就可以通过AMN来访问AMS了。可是大家有想过，Client可以通过AMN来访问AMS，但是Server端怎么访问Client端呢，看这句话attachApplication，其实这里就是程序把自己的一个控制器交给了Server端，然后Server端就可以通过这个控制器来操作Client端了。不信我们来看下ApplicationThread的方法。

是不是看到很多控制生命周期的方法，是的，AMS就是通过这个ApplicationThread来控制Client端的。

那么我们来总结一下这里，程序通过AMN来绑定AMS后，自己创建了一个桥梁applicationThread，然后把这个桥梁交给AMS，意思就是说，这是我小弟，以后联系我可以通过他。另一方面，在这个attach中client的各种初始化已经完成了。接下来的工作就通过attachApplication这个方法移交给AMS端了。

那接下来我们来看AMS端的attachApplication方法

AMS端先通过Binder查询到程序的pid，然后调用attachApplicationLocked，继续往下看，这个方法就是AMS在接到“一个新进程启动了”这件事之后做了一些工作，很复杂，但AMS毕竟是老板，多做一些是正常的。

先是用一个ProcessRecord来记录所有和Process有关的信息。

这里有一个generateProvider的操作，但是我感觉应该不是生成程序的ContentProvider，因为此时Manifest文件还没有被解析，这里应该是为Application生成一些系统必要的ContentProvider。至于对不对，后面再验证吧。

后面做了一些配置工作后，调用了这个方法

是的，这个方法才是主线剧情。通过这个方法，AMS将自己初始化的一些成果，告诉了Client端，并将控制权重新交回给Client端。在看bindApplication之前，我们看下AMS后面的工作。

源码的注释写的比较清楚了，判断有没有其他组件在等这个进程启动，如果有，那么这个进程已经启动了，就该通知他们做事了。这不关我们的事，回到正题吧，看看控制权回到Client那边后，又做了什么。不过这里我们也再一次验证了AMS通过ApplicationThread这个类来和Client端打交道。

好，老板做完事情了，工作又回到小弟手中了。什么？你说老板其实什么都没做，你可以去财务领工资了。

但是ApplicationThread毕竟是个桥梁，实际的工作还是得给app的老大ActivityThread来做，所以这个bindApplication方法也是记录了一些AMS传回来的信息之后，又把工作给了ActivityThread。

我们来看下这个bindApplication做了什么，首先记录了一些配置信息

然后在VM中注册APP的信息

这里注释也说了，有两种情况，两个package是共享runtime的。

• 设置了shareUserId
• 设置了ProcessName

在share的情况下是不用再VM中注册的，我的理解是，share的组件并不是一个完整的app，而他所属的原来的app其实已经注册过了。

这里有个问题是，工作是怎么给ActivityThread的呢？看bindApplication的第三部分

ApplicationThread是ActivityThread的内部类，内部类代表什么呢，它其实是持有一个外部类ActivityThread的对象引用的。可以这么说在ApplicationThread中其实是可以调到ActivityThread的所有方法的。那么它为什么要用这种sendMessage，然后通过Handler处理的这种方式呢。我们来想一下Handler的一个作用是什么。切换线程，在任何情况下，不管bindApplication这个方法运行在哪个线程中，只要通过handler这种方式，都可以回到ActivityThread所在的线程，也就是主线程。这就保证了什么呢，保证了Android的所有生命周期方法都是运行在主线程的，也就是我们常说的UI线程。

简单跟下sendMessage

mH是一个H类型的对象，这个H就是ActivityThread内部的Handler

看下这个Handler的handleMessage方法，跟下对BIND_APPLICATION消息的处理。

进到了handleBIndApplication方法，这里就是Application的启动过程了，让我们来仔细看下这个方法处理的步骤

国际惯例，前面也是各种记录，配置，初始化的工作，我们可以完全忽略。

这个地方是一个小的知识点，在3.1以前的版本上，AsyncTask会改变默认的executor，我们看下改变之后的executor是什么样的。

而默认的executor是这样的

所以3.1以前版本的AsyncTask是并行执行任务的，而3.1以后版本反而是顺序执行任务的，当然，这个配置可以通过AsyncTask的参数而改变。

然后我们回到handleBindApplication，后面会继续设置时区，位置，屏幕参数等。

之后创建了一个Context对象，注意，这是我们到目前位置接触到的第一个Context。我们知道在Android中Application，Activity等等其实都是Context的子类，但是他们又是不同的。这里创建的这个context对应的是我们开发过程中的哪个呢，让我们继续往下看。

然后又是一堆配置，其中包括UI线程不能执行网络操作的配置

然后是关于调试的相关配置，开启一个调试端口，其实关于调试也是需要讲很多的，调试本身也是C/S结构的，客户端开一个端口，等着服务端来连接进行调试，这里就是客户端打开端口的操作。

设置了一个默认的HTTP代理

后面一段是创建了一个Instrumentation对象，这里不截图的。之前第一篇文章我们也提到过，跟ActivityStart有关的操作都是由Instrumentation这个类管理的，被我们亲切的称为大管家，其实是为了监视我们的操作。。。

然后，这个方法讲了这么多，前面大家基本可以忽略，到现在才是重点。

这一段，首先创建了一个Application，恩，我们开发过程中遇见的Application就是这里生成的。后面一段是初始化ContentProvider，这个我们后面讲ContentProvider启动过程的时候会看到，不过这里能知道的一个点就是ContentProvider的启动时间是相当早的，在Application的onCreate之前。然后这里的providers确实是之前我们说到的AMS生成的，然后一路传过来的。恩，先不细看了，因为这篇文章主要想说Activity的启动过程。

后面调用了Instrumentation的onCreate方法，是个空方法，可Override，再后面看到吗，通过Instrumentation大管家呼叫了Application的OnCreate方法

至此，我们开发者接触到的Android生命周期中的第一个方法，Application的onCreate被执行了。至于前面生成的Context，我看了一下，传给了Instrumentation成为了Instrumentation中的appContext，但是我并没有找到跟Application对象结合的方法。这个继续往后看吧。

到此为止，这个handleBindApplication方法就结束了，创建了一个appContext，一个Instrumentation，一个Application，并且调用了Application的onCreate。中间还涉及到ContentProvider的初始化操作，我们先忽略。那么Activity在哪里，为什么感觉自己被带偏了。我又一路往前找。终于在AMS的attachApplicationLocked中，我看到了这一步。

bindApplication在执行完我们上面说的那一堆之后，调用了StackSupervisor的attachApplicationLocked，好，我们来看一下。同时，这里的调用顺序也保证了Application的onCreate方法在Activity之前进行。

方法中有一个realStartActivity的方法，名字很形象，前面我们调用过那么多次的startActivity，但是真正的Activity在这里才生成。

这个realStartActivity嘟噜嘟噜的扯了好多，不知道在干吗，但是终于看到了一个熟悉的影子

就这样控制权又回到了ActivityThread

这里先创建了一个ActivityClientRecord，这个就是Client端管理生成的activity对象的包装类，后面生成的Activity类都会被ActivityClientRecord包装一层，然后保存到ActivityThread的mActivities中。

跟Application那边一样，scheduleLaunchActivity最终会被handleLaunchActivity处理，我们略过中间过程，直接看handleLaunchActivity吧。

这个方法触发了Activity的两个生命周期方法，分别是我标出来的onCreate的onResume，然后后面那一段我的理解是Activity被创建出来，并且调用了onResume之后并没有被显示，那么就立刻调用onPause，但其实不是很懂这个地方。让我想想再回来补充吧。

接下来看performLaunchActivity吧

首先更新了ActivityClientRecord的信息，包括ActivityInfo，ComponentName等，我们开发过程中也是经常用到，这些信息都是存在ActivityClientRecord中的。

接下来创建了一个Activity，天哪，我们分析了这么久，终于看到Activity了。创建过程很简单，通过反射new了一个类出来，这个时候的Activity是还没有生命周期的。需要把Activity托管给AMS，才能有生命周期。

接着，我们获取到之前创建的那个Application，为Activity创建了一个Context，然后通过Activity的attach方法把这些绑定起来。

生成Context的方法和之前为Instrumentation生成Context的方法差不多，返回的是一个ContextImpl类型的对象，保存了Activity的上下文。

attach方法将所有的对象包括Instrumentation，Application, ActivityThread等等全部在Activity中保存了一份。

回到performLaunchActivity，attach之后通过Instrumentation大管家调用了Activity的onCreate方法

然后将生成的activity交给ActivityClientRecord，并保存在mActivities中，这就完成了Activity的生成，并托管给系统，之后系统都可以在适当的时候通过token来获取到相应的Activity，并调用其生命周期。

这样performLaunchActivity就结束了，我们返回上一层handleLaunchActivity继续往下看，Activity在生成之后是会立刻调用onResume的。这两个生命周期有什么区别呢， 其实就在于onCreate跟onResume之间执行的这几句话，说实话，在创建的时候区别不大。不同的是onResume未来还会被调用，但是onCreate只有创建的时候才会被调用。

其实到这来一个Activity的启动流程就已经结束了，但是我们顺便来看下handleResumeActivity的工作吧

看这来，从mActivities中根据token获取了ActivityClientRecord，并进一步获得了里面的activity，然后执行了onResume方法，我刚想说，咦，这次调用没有通过大管家哎，然后看了一下performResume方法里面，其实还是通过Instrumentation调用的。

然后，还更新了ActivityClientRecord的相关信息等。

其实到这里onResume已经调用完成了，那么handleResumeActivity后面的这一堆在干什么呢？

通过方法名我们知道，Activity在onResume之后才开始处理显示的逻辑，这里就是通知AMS，Activity onResume已经调用完了，接下来要显示了，那么AMS就会通知WindowManger来显示Activity，这就是另外一件事了，我们在这里就不细细讨论了。

呼~终于写完了，整个流程主线还是很清楚的，AMS和AMN的分工明确。

整个流程总结一下，是下面这种关系

最后还是广告时间，如果喜欢这篇文章，可以关注我的博客http://zwgeek.com