[系统源码]Activity启动流程分析

Activity启动流程分析

Android4.4版本

Activity启动类型与方式

Activitiy启动类型与启动方式：

启动类型：

根Activity：点击Launcher图标启动。

子Activity：根Activity启动后，内部调用startActivity启动子Activity。

启动方式：

显示启动：通过类名启动。
隐式启动：通过组件名启动。

点击Launcher图标触发的应用冷启动流程：

总流程图：

一、startActivity

1.1 类介绍：

Instrumentaion：Activity类的成员变量，用来监控应用程序和系统之间的交互操作。
ActivityManagerProxy：与AMS进行binder call的client端。
ActivityManagerService：由SystemServer启动的，管理四大组件和进程的系统服务。

1.2 流程介绍：
应用程序安装过程中，主要做了两件事：复制apk到指定目录和 AndroidManifest.xml解析。
Launcher会向PMS查询：<action android:name="android.intent.action.MAIN" />和<category android:name="android.intent.category.LAUNCHER" />的Activity，并绑定一个应用图标，点击Launcher对应的应用图标，实际上就是做了一次Activity的隐式启动。而启动信息是保存在Intent中的。

1）点击应用图标onClick触发startActivitySafely。

4）Activity的启动任务交由Instrumentaion通过exeStartActivity来代为执行，以便监控交互的整个过程。

5）应用层执行ActivityManagerNative.getDefault ，通过ServiceManager.getService("activity”) 向kernel binder驱动查询到AMS的binder引用，同时通过asInterface创建ActivityManagerProxy即binder call的client端，proxy通过AMS binder引用与AMS通信。

6）binder call到AMS。

@Override
public final int startActivity(
     IApplicationThread caller,
     String callingPackage,//发起端包名
     Intent intent, //传入的intent信息
     String resolvedType, 
     IBinder resultTo, //token 保证Activity与Window一致性。token与ActivityRecord一一对应，Activity attach时传入，setWindowManager传入，最终由Window的AppToken接收。
     String resultWho, //target 目标activity
     int requestCode,  //startActivityForResult(Intent intent, int requestCode, Bundle options) ,requestCode If >= 0, 会被onActivityResult接收，这里是-1
     int startFlags,  //0
     String profileFile, 
     ParcelFileDescriptor profileFd, 
     Bundle options //startActivityForResult(Intent intent, int requestCode, Bundle options) 
) {
    return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
           resultWho, requestCode,
           startFlags, profileFile, profileFd, options, UserHandle.getCallingUserId());
}

二、Activity信息封装以及堆栈任务调整

2.1 类介绍：

ActivityStackSupervisor：ActivityStack的管理类，同时与AMS、WMS等相关系统服务及时同步信息。
ActivityStack：TaskRecord管理类，不是真正的Activity栈。
TaskRecord：Activity任务栈，四种启动模式。
ActivityRecord：Activity对应的实体对象。

启动模式：

standard(默认)：启动一个新Activity就加入栈顶，不考虑重复。
singleTop ：栈顶复用。
singleTask ：栈内复用，且之上的所有Activity统统出栈。
singleInstance ：独享栈，没有当前activity就创建一个新task来让该activity独享，否则复用。

与Task相关属性：

Intent.FLAG_ACTIVITY_NEW_TASK 创建新的task。
android:taskAffinity = “ packageName “ 亲和性(物以类聚)，同一程序Activity亲和性相同。
android:allowTaskReparenting=“true” Activity 可以移动到与其具有关联的Task中。
android:process = “packageName”设置是否运行在同一程序中。

taskAffinity约束力比较弱，需要Intent.FLAG_ACTIVITY_NEW_TASK 和 android:allowTaskReparenting=“true”作为前置条件。

比如：

同一程序的不同activity放入不同的栈中：taskAffinity 不同 + Intent.FLAG_ACTIVITY_NEW_TASK
不同程序的activity放入同一栈中：taskAffinity相同 + android:allowTaskReparenting=“true”

2.2 流程介绍：

2）AMS.startActivityAsUser 加入UserId信息。

3）ActivityStackSupervisor.startActivityMayWait 选择一个匹配Intent的最合适的目标Activity,并获取对应ActivityInfo。

PMS.resolveIntent: 通过PMS得到被启动Activity的ResolveInfo, queryIntentActivities 通过Component去匹配要被启动的Activity，chooseBestActivity 对多个activity，android:priority(默认是0 , 范围是[-1000, 1000])不同，选优先级高的，android:priority相同弹窗让用户选择。
resolveActivity 由ResolveInfo获取被启动Activity的ActivityInfo。

4）ActivityStackSupervisor.startActivityLocked 将收集到的关于目标启动Activity的信息初始化为ActivityRecord对象。

ActivityRecord r = new ActivityRecord(
        mService, // AMS
        callerApp, //发起端对应的ProcessRecord
        callingUid, //发起端的Uid
        callingPackage, //发起端的包名
        intent,
        resolvedType,
        aInfo, //ActivityInfo 当前activity信息
        mService.mConfiguration,
        resultRecord, 
        resultWho,
        requestCode, componentSpecified, this);

5）ActivityStackSupervisor.startActivityUnCheckedLocked

startActivityUncheckedLocked(
r, //目标Activity
sourceRecord, //源Activity
startFlags,
true,  //doResume = true
options
);

由launchMode和 intent.getFlags 和 taskAffinity 等共同决定目标Activity应该在那个task，以什么形式存在。

6）ActivityStack.resumeTopActivityLocked

判断：

当前有存在的resumed activity，且就是要启动的目标activity，那什么都不用做。
当前没有存在的resumed activity, 直接启动目标activity。
当前有存在的resumed activity，不是要启动的目标activity，那么先让之前的activity走pause流程。

7）ActivityStack.startPausingLocked
这里如果mPausingActivity != null，会有一个500ms的超时消息。

8）ApplicationThreadProxy.schedulePauseActivity
system_server进程通过IApplicationThread与Launcher进程进行binder call通信，执行对当前非目标的其他resumeActivity 执行pause操作。

三、pauseActivity

3.1 流程介绍：

2 - 3）ActivityThread 是一个消息驱动的大looper。

4）handlePauseActivity做两件事：一是通过Instrumentation让目前resume的activity走onPause，二是向AMS 发送binder call通知activityPaused。

四、重回目标Activity resume流程

4.1 流程介绍：

2）ActivityStack.activityPaused : remove PAUSE_TIMEOUT_MSG。

3 - 5)继续之前resumeTopActivity工作。

6）如果启动的Activity对应的进程为空，则走创建进程流程，否则直接走Activity启动流程。

五、进程创建流程

5.1 类介绍：

Process: Framework Java层进程相关操作类，比如杀进程、创建进程、设置进程优先级、设置进程组等。

5.2 流程介绍：

1）AMS通过 Process.start来创建目标Activity对应的进程。

2 - 5）Process.start过程主要是收集创建进程所需参数，包括进程名、pid、uid等信息，打包好通过socket发送给Zygote。

Zygote启动流程：

Zygote通过init进程启动，启动过程主要干了这么几件事：

3）创建虚拟机。

4）注册JNI。

5）registerZygoteSocket()建立socket通道，zygote作为通信的服务端，用于响应客户端请求。

6）preload()预加载系统通用类、资源、openGL以及共享库以及WebView，用于提高app启动效率。

8）fork SystemServer 上层framework系统服务的运行载体。

10）调用runSelectLoop()，随时待命，当接收到请求创建新进程请求时立即唤醒并执行相应工作。

这里process.start最终通过socket向zygote发起创建进进程的请求，同时把相关参数传递过来。

再简单描述下Zygote fork进程的过程：
1）copy-on-write fork
zygote 采用copy-on-write的方式fork进程，从父进程fork一个子进程，刚fork之后，这两个虚拟地址实际上指向的是相同的物理地址（内存页），且把父子共享的页面标记为“只读”，但如果其中任何一个进程要对共享的页面“写操作”，这时内核会复制一个物理页面给这个进程使用，同时修改页表，把原来的只读页面标记为“可写”，留给另外一个进程使用。此时两个虚拟地址指向不同的物理地址（新的物理地址的内容从原物理地址中复制得到）。

2）zygote 复制自己的一份内存拷贝给对应进程，内部包括系统预加载的资源和类也包括虚拟机环境。同时为创建的新进程设置pid，启动进程对应的Binder线程池（16个线程），最后通过反射执行ActivityThread的main方法。

六、ActivityThread初始化以及attach Application

6.1 类介绍：

LoadedApk: APK文件信息封装对象。
PathClassLoader: 加载已被安装的应用路径中.dex 文件。另外要提的是DexClassLoader ：加载指定路径中的.dex 文件。他俩的父类都是BaseDexClassLoader。

6.2 流程介绍：

1 -7)反射执行ActivityThread的main方法, looper消息池转起来，同时binder call到AMS 执行attachApplication，然后AMS binder call回ApplicationThread执行bindApplication。

10 - 18）handleBindApplication : 通过getPackageInfo初始化LoadApk，初始化Instrumentation，通过makeApplication加载主apk, 同时初始化Application类，最后通过Instrumentation执行Application的onCreate回调。

注：时序图默认生成的数字有问题，图中顺序调整下，以上面描述的顺序为准。

七、realStartActivityLocked

AMS执行attachApplicationLocked方法时，其实干了两件事情，一件是binder call回ApplicationThread执行bindApplication。
另一件是走ActivityStackSupervisor.attachApplicationLocked最终执行realStartActivityLocked走Activity在App层的启动流程。

realStartActivityLocked过程非常简单，在ActivityThread中通过消息通信最终执行handleLaunchActivity，通过Instrumentation初始化Activity并走对应的生命周期。

回顾应用启动流程知识点

Binder 通信
Activity 任务栈管理
应用进程创建流程
ActivityThread消息机制
类加载机制

100%原创文章，转载请联系作者。

简书链接：https://www.jianshu.com/u/7f26e9b13731

扫二维码｜关注Stan_Z

微信号｜stan_zht

简书号｜Stan_Z