android 插件化之Activity生命周期之一

------本文转载自  Android插件化原理解析——Activity生命周期管理 这一系列的文章实在是写的好!

1, 概述

在Java平台要做到动态运行模块、热插拔可以使用ClassLoader技术进行动态类加载，比如广泛使用的OSGi技术。

在Android上当然也可以使用动态加载技术，但是仅仅把类加载进来就足够了吗？

Activity，Service等组件是有生命周期的，它们统一由系统服务AMS管理；

使用ClassLoader可以从插件中创建Activity对象，但是，一个没有生命周期的Activity对象有什么用？

所以在Android系统上，仅仅完成动态类加载是不够的；我们需要想办法把我们加载进来的Activity等组件交给系统管理，

让AMS赋予组件生命周期；这样才算是一个有血有肉的完善的插件化方案。

接下来的系列文章会讲述 DroidPlugin对于Android四大组件的处理方式，

我们且看它如何采用Hook技术坑蒙拐骗把系统玩弄于股掌之中，最终赋予Activity，Service等组件生命周期，

完成借尸还魂的。首先，我们来看看DroidPlugin对于Activity组件的处理方式。

阅读本文之前，可以先clone一份understand-plugin-framework，参考此项目的binder-hook 模块。本编文章的源码基于android 6.0.

2, Activity启动过程

完整的Activity启动流程请参看---Activity启动流程源码解析

启动Activity非常简单，一个startActivity就完事了；那么在这个简单调用的背后发生了什么呢？

Read the fucking source code！关于Activity的启动过程，也不是三言两语能解释清楚的，

如果按照源码一步一步走下来，插件化系列文章就不用写了；所以这里我就给出一个大致流程，只列出关键的调用点。

2.1 AndroidManifest.xml的限制

启动Activity确实非常简单，但是Android却有一个限制：必须在AndroidManifest.xml中显示声明使用的Activity；

这个硬性要求很大程度上限制了插件系统的发挥：假设我们需要启动一个插件的Activity，

插件使用的Activity是无法预知的，这样肯定也不会在Manifest文件中声明；如果插件新添加一个Activity，

主程序的AndroidManifest.xml就需要更新；既然双方都需要修改升级，何必要使用插件呢？

这已经违背了动态加载的初衷：不修改插件框架而动态扩展功能。

能不能想办法绕过这个限制呢？

束手无策啊，怎么办？借刀杀人偷梁换柱无中生有以逸待劳乘火打劫瞒天过海…等等！偷梁换柱瞒天过海？貌似可以一试。

我们可以耍个障眼法：既然AndroidManifest文件中必须声明，那么我就声明一个（或者有限个）替身Activity好了，

当需要启动插件的某个Activity的时候，先让系统以为启动的是AndroidManifest中声明的那个替身，暂时骗过系统；

然后到合适的时候又替换回我们需要启动的真正的Activity；所谓瞒天过海，莫过如此！

现在有了方案了，但是该如何做呢？兵书又说，知己知彼百战不殆！如果连Activity的启动过程都不熟悉，怎么完成这个瞒天过海的过程？

2.2 startActivity

首先是Activity类的startActivity方法：

public void startActivity(Intent intent) {    startActivity(intent, null);}

跟着这个方法一步一步跟踪，会发现它最后在startActivityForResult里面调用了

Instrument对象的execStartActivity方法；接着在这个函数里面调用了ActivityManagerNative类的startActivity方法；

这个过程在前文已经反复举例讲解了，我们知道接下来会通过Binder IPC到AMS所在进程调用

AMS的startActivity方法；Android系统的组件生命周期管理就是在AMS里面完成的，那么在AMS里面到底做了什么呢？

ActivityManagerService的startActivity方法如下：

public final int startActivity(IApplicationThread caller, String callingPackage,        Intent intent, String resolvedType, IBinder resultTo,        String resultWho, int requestCode, int startFlags,        String profileFile, ParcelFileDescriptor profileFd, Bundle options) {    return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,            resultWho, requestCode,            startFlags, profileFile, profileFd, options, UserHandle.getCallingUserId());}

很简单，直接调用了startActivityAsUser这个方法；接着是ActivityStackSupervisor类的startActivityMayWait方法。

这个ActivityStackSupervisor类到底是个啥？如果仔细查阅，低版本的Android源码上是没有这个类的；

后来AMS的代码进行了部分重构，关于Activity栈管理的部分单独提取出来成为了ActivityStackSupervisor类；好了，继续看代码。

startActivityMayWait这个方法前面对参数进行了一系列处理，我们需要知道的是，在这个方法内部对传进来的Intent进行了解析，

并尝试从中取出关于启动Activity的信息。

然后这个方法调用了startActivityLocked方法；在startActivityLocked方法内部进行了一系列重要的检查：

比如权限检查，Activity的exported属性检查等等；我们上文所述的，启动没有在Manifestfest中显示声明的Activity抛异常也是这里发生的：

if (err == ActivityManager.START_SUCCESS && aInfo == null) {    // We couldn't find the specific class specified in the Intent.    // Also the end of the line.    err = ActivityManager.START_CLASS_NOT_FOUND;}

这里返回ActivityManager.START_CLASS_NOT_FOUND之后，在Instrument的execStartActivity返回之后会检查这个值，然后抛出异常：

case ActivityManager.START_CLASS_NOT_FOUND:    if (intent instanceof Intent && ((Intent)intent).getComponent() != null)        throw new ActivityNotFoundException(                "Unable to find explicit activity class "                + ((Intent)intent).getComponent().toShortString()                + "; have you declared this activity in your AndroidManifest.xml?");

源码看到这里，我们已经确认了『必须在AndroidManifest.xml中显示声明使用的Activity』的原因；

然而这个校检过程发生在AMS所在的进程system_server，我们没有办法篡改，只能另寻他路。

OK，我们继续跟踪源码；在startActivityLocked之后处理的都是Activity任务栈相关内容。

最终到达了ActivityStackSupervisor的realStartActivityLocked方法；人如其名，这个方法开始了真正的“启动Activity”：

它调用了ApplicationThread的scheduleLaunchActivity方法，开始了真正的Activity对象创建以及启动过程。

这个ApplicationThread是什么，是一个线程吗？与ActivityThread有什么区别和联系？

不要被名字迷惑了，这个ApplicationThread实际上是一个Binder对象，

是App所在的进程与AMS所在进程system_server通信的桥梁；在Activity启动的过程中，App进程会频繁地与AMS进程进行通信：

1,App进程会委托AMS进程完成Activity生命周期的管理以及任务栈的管理；这个通信过程AMS是Server端，

  App进程通过持有AMS的client代理ActivityManagerNative完成通信过程；

2,AMS进程完成生命周期管理以及任务栈管理后，会把控制权交给App进程，让App进程完成Activity类对象的创建，

   以及生命周期回调；这个通信过程也是通过Binder完成的，App所在server端的Binder对象存在于

  ActivityThread的内部类ApplicationThread；AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信。

  App进程内部的ApplicationThreadserver端内部有自己的Binder线程池，它与App主线程的通信通过Handler完成，

  这个Handler存在于ActivityThread类，它的名字很简单就叫H，这一点我们接下来就会讲到。

现在我们明白了这个ApplicationThread到底是个什么东西，接上文继续跟踪Activity的启动过程；

我们查看ApplicationThread的scheduleLaunchActivity方法，这个方法很简单，就是包装了参数最终使用Handler发了一个消息。

正如刚刚所说，ApplicationThread所在的Binder服务端使用Handler与主线程进行通信，

这里的scheduleLaunchActivity方法直接把启动Activity的任务通过一个消息转发给了主线程；我们查看Handler类对于这个消息的处理：

Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");ActivityClientRecord r = (ActivityClientRecord)msg.obj;r.packageInfo = getPackageInfoNoCheck(        r.activityInfo.applicationInfo, r.compatInfo);handleLaunchActivity(r, null);Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);

可以看到，这里直接调用了ActivityThread的handleLaunchActivity方法，在这个方法内部有一句非常重要：

Activity a = performLaunchActivity(r, customIntent);

绕了这么多弯，我们的Activity终于被创建出来了！继续跟踪这个performLaunchActivity方法看看发生了什么；

由于这个方法较长，我就不贴代码了，读者可以自行查阅；要指出的是，这个方法做了两件很重要的事情：

1,使用ClassLoader加载并通过反射创建Activity对象

java.lang.ClassLoader cl = r.packageInfo.getClassLoader();activity = mInstrumentation.newActivity(        cl, component.getClassName(), r.intent);StrictMode.incrementExpectedActivityCount(activity.getClass());r.intent.setExtrasClassLoader(cl);

2,如果Application还没有创建，那么创建Application对象并回调相应的生命周期方法；

Application app = r.packageInfo.makeApplication(false, mInstrumentation);// ... 省略if (r.isPersistable()) {    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);} else {    mInstrumentation.callActivityOnCreate(activity, r.state);}

Activity的启动过程到这里就结束了，可能读者还是觉得迷惑：不就是调用了一系列方法吗？

具体做了什么还是不太清楚，而且为什么Android要这么设计？

方法调用链再长也木有关系，有两点需要明白：

1,平时我们所说的Application被创建了，onCreate方法被调用了，我们或许并没有意识到我们所说的

Application,Activity除了代表Android应用层通常所代表的“组件”之外，它们其实都是普通的Java对象，

也是需要被构造函数构造出来的对象的；在这个过程中，我们明白了这些对象到底是如何被创建的。

2,为什么需要一直与AMS进行通信？哪些操作是在AMS中进行的？其实AMS正如名字所说，管理所有的“活动”，

整个系统的Activity堆栈，Activity生命周期回调都是由AMS所在的系统进程system_server帮开发者完成的；

Android的Framework层帮忙完成了诸如生命周期管理等繁琐复杂的过程，简化了应用层的开发。