LocalActivityManager的内部机制详解

LocalActivityManager的内部机制

LocalActivityManager内部机制的核心在于，它使用了主线程对象mActivityThread来装载指定的Activity。注意，这里是装载，而不是启动，这点很重要。

 

所谓的启动，一般是指会创建一个进程(如果所在应用进程还不存在)运行该Activity，而装载仅仅是指把该Activity作为一个普通类进行加载，并创建一个该类的对象而已，而该类的任何函数都没有被运行。

 

LocalActivityManager提供了一个重要方法startActivity()，该方法正是利用主线程mActivityThread去装载指定的Activity，其执行过程如图10-25所示。

 

 

 
 

图10-25  LocalActivityManager类中startActivity()的执行流程

 

Manager对象必须已经被初始化，初始化的工作是在dispatchCreate()方法中首先被完成的，而这又是在 ActivityGroup类中的onCreate()中被调用的。也就是说，LocalActivityManager的 startActivity()方法必须在所在的Activity的onCreate()方法执行完毕后被调用。

 

判断目标Activity是否包含在该Manager中。Manager中使用两个列表变量保存已经装载过的Activity对象，分别是 mActivities和mActivityArray。前者是一个HashMap类型，每一个LocalActivityRecord按照一个字符串对 应；后者是一个ArrayList列表。

 

判断装载的Activity对象是否有正处于resume状态的，如果有，则要先暂停，事实上可以完全不用暂停，暂停仅仅是Manager希望完全 按照Activity对象本身的执行顺序调用它，从而使得看上去更像是一个标准的子Activity启动方式。而暂停则是通过调用 moveToState()完成的。

 

如果目标Activity已经被装载到了当前Manager中，下面就需要判断是直接使用该Activity的当前窗口呢，还是需要先销毁该 Activity，并重新调用其onCreate()？注意，这里所说的销毁仅仅是指把Activity变成"销毁"的状态而已，并不是说销毁该 Activity对象。而判断的规则有点类似于AmS中根据Activity的flag执行不同的操作，其中包括是否先调用目标Activity的 onNewIntent()，还包括是否是CLEAR_TOP模式。一般作为TabActivity的嵌入式Activity都不会是CLEAR_TOP 模式，否则，如果多个Tab页使用同一个Activity对象将导致所显示的内容完全相同。

 

调用moveToState()改变指定Activity到resume状态。

 

返回Activity所对应的Window窗口。

 

从以上步骤可以看出，装载Activity对象的过程对AmS来讲是完全不可见的，因为这是装载而不是启动，因此看似TabActvity同时运行 了多个Activity，而实际上仅仅是运行了ActivityGroup一个Activity。那些嵌入的Activity仅仅是贡献了自己所包含的 Window窗口而已，TabActivity正是把这些Window窗口的DecorView作为tabcontent的子视图而已。

 

下面对moveToState(LocalActivityRecord r, int desireState)函数的过程进行说明，参数r代表目标Activity对象，desireState代表期望把目标Activity改变成哪种状态。

 

moveToState()函数内部首先判断r.curState是否是RESTORED或者DESTROY状态，如果是则直接返回。因为 RESTORED代表刚刚创建了目标Activity对象，还没有执行onCreate()方法，所以不能改变状态；DESTROY代表已经销毁，也不能 改变状态。

 

接着，判断r.curState是否是INITIALIZE状态，这种情况只有在第一次调用startActivity()装载目标 Activity对象时才会执行到，其内部主要包括调用startActivityNow()和performResumeActivity()将目标 Activity改变到STARTED或者RESUMED状态。

 

由于Activity当前状态不同，要想达到不同的期望状态自然需要经过不同的步骤。moveToState()函数内部正是使用switch语句 先判断当前处于什么状态，然后再在case里面使用if…else语句判断期望的状态，最后再调用不同的函数。其状态和调用关系如表10-8所示，该表中 调用的函数名称使用了简写，比如performRestartActivity简写为Restart。

 

表10-8  Activity在不同状态中转换时需执行的操作

 

目标状态 当前状态	CREATED	STARTED	RESUMED
CREATED		Restart ();	Restart(); Resume();
STARTED	Stop();		Resume();
RESUMED	Pause(); Stop();	Pause();

从以上的步骤可以看出，startActivity()的内部执行逻辑有点像AmS中根据当前Activity状态调用不同方法。这两者就像《西游 记》中的小雷音寺和大雷音寺，两者的本质区别在于LocalActivityManager仅仅是为了获取Activity对应的Window对象，中间 的状态切换仅仅是为了保证Activity本身的执行过程，从而保证Window对象的视图内容有一个正确的呈现。

 

ActivityGroup内部的Activity生命期控制

 

前面分析了LocalActivityManager内部的执行原理，接下来分析一个有意思的问题："在TabActivity的多个Tab页切换时，内嵌的Activity对象会在onPause()和onResume()之间切换吗？"

 

从上面的分析可知，Manager装载Activity的目的仅仅是为了获取其所包含的Window对象，而一旦获取后，则似乎不需要再纠缠于 Activity本身的生命期状态变换操作。其实笔者也是这么认为的，可以尝试屏蔽以下代码，该段代码的作用是在装载下一个Activity之前先暂停当 前的Activity对象。

 

 

 

屏蔽后，运行结果丝毫不受影响，原因很简单，这里做暂停的目的仅仅为了保持Activity原有的生命期过程，从而可以保持原有Activity释 放相关资源的行为。比如当Activity A以启动的方式运行时，如果另一个Activity B要启动，则会先暂停A。在一般的程序设计中，暂停会回调onPause()操作，如果该Activity使用了大量的内存或者其他资源，在 onPause()函数中程序员可能会尝试释放这些资源以提高系统效率，这就是为什么在LocalActivityManager中也保持了这种流程的原 因。当然，如果你不释放，也不会发生什么逻辑错误。

 

而在以上代码的moveToState()操作中调用了mActivityThread的onPause()或者onStop()操作，这就是为什 么在Tab页切换时，对应的Activity也会执行onPause()或者onStop()的原因。这完全与AmS无关，因此不要因为这个而产生 TabActivity同时运行了两个Activity（TabActivity本身和嵌入的Activity）的错觉。

 

另外还有一个有意思的问题，请思考下面的操作过程。

 

打开一个TabActivity，比如"联系人"程序，在上面的四个Tab页上都点一次，然后再按"Home"键回到桌面，然后再从联系人图标中进入该程序。请思考此时TabActivity内嵌的Activity会发生生命期状态改变吗？

 

首先TabActivity当然会从stop状态转变为start状态，并先后调用onStart()和onPause()。因为它是一个标准的 Activity，TabActivity的父类是ActivityGroup，而在该类中，相应的onXXX()方法内部都增加了 mLocalActivityManager.dispatchXXX()代码，比如：

 

 

而在LocalActivityManager中，dispatchXXX()则会把相应的 action再dispatch到所包含的所有嵌入式Activity对象中。所以，以上问题的答案是内嵌的Activity生命期会从stop状态转换 到resume状态。仔细查看ActivityGroup的onXXX()函数发现，唯独没有onStart()方法，其原因是在 LocalActivityManager的moveToState()方法中可以直接把子Activity的状态从stop改变到resume，所以， 此处可以省略对onStart()的重载。