启动流程为什么要了解
不了解 ，平时开发好像也没啥问题啊。其实不然，解决这些问题后，你会对Android系统有更深层次的理解，也会学习到系统源码优秀的设计。并且对解决一些高级问题和深入的性能优化问题有很大帮助，是技术进阶的必要阶段。这就需要我们通过阅读源码来梳理这些问题，但另一方面，系统源码是很庞大繁杂的，我们需要带着问题抓住主流程，不能陷入代码细节——这是阅读系统源码以及其他第三方库源码的正确姿势。
1， 系统开机到启动Launcher应用桌面的流程
手机开机会启动系统boolt,
会创建zogote进程-->JVM-->启动systm_server-->会启动系统AMS 、WMS、PMS、广播、WIFI、电量等服务
//系统源码
public final class SystemServer {
/**
* The main entry point from zygote.
*/
public static void main(String[] args) {
new SystemServer().run();
}
private void run() {
// Start services.
//这里启动了几个重要的服务
startBootstrapServices();
startCoreServices();
startOtherServices();
}
//这里启动了 AMS、PMS
private void startBootstrapServices() {
//启动了SystemServiceManager
traceBeginAndSlog("StartInstaller");
Installer installer = mSystemServiceManager.startService(Installer.class);
traceEnd();
//启动了StartActivityManager AMS
// Activity manager runs the show.
traceBeginAndSlog("StartActivityManager");
mActivityManagerService = mSystemServiceManager.startService(
ActivityManagerService.LifIApplicationThreadIApplicationThreadecycle.class).getService();
mActivityManagerService.setSystemServiceManager(mSystemServiceManager);
mActivityManagerService.setInstaller(installer);
traceEnd();
//启动了PackageManagerService PMS
// Start the package manager.
traceBeginAndSlog("StartPackageManagerService");
mPackageManagerService = PackageManagerService.main(mSystemContext, installer,
mFactoryTestMode != FactoryTest.FACTORY_TEST_OFF, mOnlyCore);
mFirstBoot = mPackageManagerService.isFirstBoot();
mPackageManager = mSystemContext.getPackageManager();
traceEnd();
traceBeginAndSlog("StartUserManagerService");
mSystemServiceManager.startService(UserManagerService.LifeCycle.class);
traceEnd();
}
2，Launcher点击应用桌面app启动流程，根Activity的启动—应用进程启动
我们知道，想要启动一个应用程序（App），需要点击手机桌面的应用图标。Android系统的桌面叫做Launcher，有以下作用：
作为Android系统的启动器，用于启动应用程序。
作为Android系统的桌面，用于显示和管理应用程序的快捷图标和其他桌面组件。
Launcher本身也是一个应用程序，它在启动过程中会请求PackageManageService（系统的包管理服务）返回系统中已经安装的app的信息，并将其用快捷图标展示在桌面屏幕上，用户可以点击图标启动app。例如华为手机的Launcher就是 “华为桌面” 这个系统app。
当点击app图标后，Launcher会在桌面activity（此activity就叫Launcher）内调用startActivitySafely方法，startActivitySafely方法会调用startActivity方法。
应用桌面是一个LauncherActicity页面,里面有点击事件
分析源码
Intent intent = new Intent(this, TestActivity.class);
this.startActivity(intent);
//下面我们就来对Activity的工作流程进行梳理，达到对Activity整体流程的掌握。从startActivity方法开始，会走到
@Override
public void startActivity(Intent intent, @Nullable Bundle options) {
if (mIntent != null && mIntent.hasExtra(AutofillManager.EXTRA_RESTORE_SESSION_TOKEN)
&& mIntent.hasExtra(AutofillManager.EXTRA_RESTORE_CROSS_ACTIVITY)) {
if (TextUtils.equals(getPackageName(),
intent.resolveActivity(getPackageManager()).getPackageName())) {
// Apply Autofill restore mechanism on the started activity by startActivity()
final IBinder token =
mIntent.getIBinderExtra(AutofillManager.EXTRA_RESTORE_SESSION_TOKEN);
// Remove restore ability from current activity
mIntent.removeExtra(AutofillManager.EXTRA_RESTORE_SESSION_TOKEN);
mIntent.removeExtra(AutofillManager.EXTRA_RESTORE_CROSS_ACTIVITY);
// Put restore token
intent.putExtra(AutofillManager.EXTRA_RESTORE_SESSION_TOKEN, token);
intent.putExtra(AutofillManager.EXTRA_RESTORE_CROSS_ACTIVITY, true);
}
}
if (options != null) {
startActivityForResult(intent, -1, options);
} else {
// Note we want to go through this call for compatibility with
// applications that may have overridden the method.
startActivityForResult(intent, -1);
}
}
startActivityForResult方法：
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
if (mParent == null) {
options = transferSpringboardActivityOptions(options);
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
if (ar != null) {
mMainThread.sendActivityResult(
mToken, mEmbeddedID, requestCode, ar.getResultCode(),
ar.getResultData());
}
if (requestCode >= 0) {
mStartedActivity = true;
}
cancelInputsAndStartExitTransition(options);
} else {
...
}
}
看到里面调用了mInstrumentation.execStartActivity方法，其中一个参数mMainThread.getApplicationThread()，它的类型是ApplicationThread，ApplicationThread是ActivityThread的内部类，继承IApplicationThread.Stub，也是个Binder对象，在Activity工作流程中有重要作用。而Instrumentation具有跟踪application及activity生命周期的功能，用于android 应用测试框架中代码检测。接着看下mInstrumentation.execStartActivity方法：
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
IApplicationThread whoThread = (IApplicationThread) contextThread;
Uri referrer = target != null ? target.onProvideReferrer() : null;
if (referrer != null) {
intent.putExtra(Intent.EXTRA_REFERRER, referrer);
}
...
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess(who);
int result = ActivityTaskManager.getService()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}
这里看到Activity的启动又交给了ActivityTaskManager.getService()，这是啥？跟进去看看：
//ActivityTaskManager
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
return IActivityTaskManager.Stub.asInterface(b);
}
};
看到IBinder这个标志，这里你应该明白了：这里是获取一个跨进程的服务。获取的什么服务呢？是ActivityTaskManagerService（ATMS），它继承于IActivityTaskManager.Stub，是个Binder对象，并且是通过单例提供服务的。 ATMS是用于管理Activity及其容器（任务、堆栈、显示等）的系统服务，运行在系统服务进程（system_server）之中。
值得说明的是，ATMS是在Android10中新增的，分担了之前ActivityManagerService（AMS）的一部分功能（activity task相关）。
在Android10 之前 ，这个地方获取的是服务是AMS。查看Android10的AMS，你会发现startActivity方法内也是调用了ATMS的startActivity方法。所以在理解上，ATMS就隶属于AMS。
接着看，ActivityTaskManager.getService().startActivity有个返回值result，且调用了checkStartActivityResult(result, intent)：
public static void checkStartActivityResult(int res, Object intent) {
if (!ActivityManager.isStartResultFatalError(res)) {
return;
}
switch (res) {
case ActivityManager.START_INTENT_NOT_RESOLVED:
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?");
throw new ActivityNotFoundException(
"No Activity found to handle " + intent);
case ActivityManager.START_PERMISSION_DENIED:
throw new SecurityException("Not allowed to start activity "
+ intent);
...
case ActivityManager.START_CANCELED:
throw new AndroidRuntimeException("Activity could not be started for "
+ intent);
default:
throw new AndroidRuntimeException("Unknown error code "
+ res + " when starting " + intent);
}
}
Activity的管理——AMS
好了，到这里，Activity的启动就跨进程（IPC）的转移到系统进程提供的服务ATMS中了，接着看ATMS的startActivity
@Override
public final int startActivity(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions,
UserHandle.getCallingUserId());
}
@Override
public int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId) {
return startActivityAsUser(caller, callingPackage, intent, resolvedType, resultTo,
resultWho, requestCode, startFlags, profilerInfo, bOptions, userId,
true /*validateIncomingUser*/);
}
int startActivityAsUser(IApplicationThread caller, String callingPackage,
Intent intent, String resolvedType, IBinder resultTo, String resultWho, int requestCode,
int startFlags, ProfilerInfo profilerInfo, Bundle bOptions, int userId,
boolean validateIncomingUser) {
enforceNotIsolatedCaller("startActivityAsUser");
userId = getActivityStartController().checkTargetUser(userId, validateIncomingUser,
Binder.getCallingPid(), Binder.getCallingUid(), "startActivityAsUser");
// TODO: Switch to user app stacks here.
return getActivityStartController().obtainStarter(intent, "startActivityAsUser")
.setCaller(caller)
.setCallingPackage(callingPackage)
.setResolvedType(resolvedType)
.setResultTo(resultTo)
.setResultWho(resultWho)
.setRequestCode(requestCode)
.setStartFlags(startFlags)
.setProfilerInfo(profilerInfo)
.setActivityOptions(bOptions)
.setMayWait(userId)
.execute();
}
跟到startActivityAsUser中，通过getActivityStartController().obtainStarter方法获取ActivityStarter实例 然后调用一系列方法，最后的execute()方法是开始启动activity：
int execute() {
try {
// TODO(b/64750076): Look into passing request directly to these methods to allow
// for transactional diffs and preprocessing.
if (mRequest.mayWait) {
return startActivityMayWait(mRequest.caller, mRequest.callingUid,
mRequest.callingPackage, mRequest.realCallingPid, mRequest.realCallingUid,
mRequest.intent, mRequest.resolvedType,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.startFlags,
mRequest.profilerInfo, mRequest.waitResult, mRequest.globalConfig,
mRequest.activityOptions, mRequest.ignoreTargetSecurity, mRequest.userId,
mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup,
mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart);
} else {
return startActivity(mRequest.caller, mRequest.intent, mRequest.ephemeralIntent,
mRequest.resolvedType, mRequest.activityInfo, mRequest.resolveInfo,
mRequest.voiceSession, mRequest.voiceInteractor, mRequest.resultTo,
mRequest.resultWho, mRequest.requestCode, mRequest.callingPid,
mRequest.callingUid, mRequest.callingPackage, mRequest.realCallingPid,
mRequest.realCallingUid, mRequest.startFlags, mRequest.activityOptions,
mRequest.ignoreTargetSecurity, mRequest.componentSpecified,
mRequest.outActivity, mRequest.inTask, mRequest.reason,
mRequest.allowPendingRemoteAnimationRegistryLookup,
mRequest.originatingPendingIntent, mRequest.allowBackgroundActivityStart);
}
} finally {
onExecutionComplete();
}
}
分了两种情况，不过 不论startActivityMayWait还是startActivity最终都是走到下面这个startActivity方法：
private int startActivity(final ActivityRecord r, ActivityRecord sourceRecord,
IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask,
ActivityRecord[] outActivity, boolean restrictedBgActivity) {
int result = START_CANCELED;
final ActivityStack startedActivityStack;
try {
mService.mWindowManager.deferSurfaceLayout();
result = startActivityUnchecked(r, sourceRecord, voiceSession, voiceInteractor,
startFlags, doResume, options, inTask, outActivity, restrictedBgActivity);
} finally {
final ActivityStack currentStack = r.getActivityStack();
startedActivityStack = currentStack != null ? currentStack : mTargetStack;
...
}
postStartActivityProcessing(r, result, startedActivityStack);
return result;
}
里面有调用了startActivityUnchecked方法，之后调用RootActivityContainer的resumeFocusedStacksTopActivities方法。RootActivityContainer是Android10新增的类，分担了之前ActivityStackSupervisor的部分功能。接着跳转到ActivityStack的resumeTopActivityUncheckedLocked方法：
//ActivityStack
boolean resumeTopActivityUncheckedLocked(ActivityRecord prev, ActivityOptions options) {
if (mInResumeTopActivity) {
// Don't even start recursing.
return false;
}
boolean result = false;
try {
mInResumeTopActivity = true;
result = resumeTopActivityInnerLocked(prev, options);
final ActivityRecord next = topRunningActivityLocked(true /* focusableOnly */);
if (next == null || !next.canTurnScreenOn()) {
checkReadyForSleep();
}
} finally {
mInResumeTopActivity = false;
}
return result;
}
跟进resumeTopActivityInnerLocked方法：
private boolean resumeTopActivityInnerLocked(ActivityRecord prev, ActivityOptions options) {
...
boolean pausing = getDisplay().pauseBackStacks(userLeaving, next, false);
if (mResumedActivity != null) {
if (DEBUG_STATES) Slog.d(TAG_STATES,
"resumeTopActivityLocked: Pausing " + mResumedActivity);
// 暂停上一个Activity
pausing |= startPausingLocked(userLeaving, false, next, false);
}
...
//这里next.attachedToProcess()，只有启动了的Activity才会返回true
if (next.attachedToProcess()) {
...
try {
final ClientTransaction transaction =
ClientTransaction.obtain(next.app.getThread(), next.appToken);
...
//启动了的Activity就发送ResumeActivityItem事务给客户端了，后面会讲到
transaction.setLifecycleStateRequest(
ResumeActivityItem.obtain(next.app.getReportedProcState(),
getDisplay().mDisplayContent.isNextTransitionForward()));
mService.getLifecycleManager().scheduleTransaction(transaction);
....
} catch (Exception e) {
....
mStackSupervisor.startSpecificActivityLocked(next, true, false);
return true;
}
....
} else {
....
if (SHOW_APP_STARTING_PREVIEW) {
//这里就是 冷启动时 出现白屏 的原因了：取根activity的主题背景 展示StartingWindow
next.showStartingWindow(null , false ,false);
}
// 继续当前Activity，普通activity的正常启动 关注这里即可
mStackSupervisor.startSpecificActivityLocked(next, true, true);
}
return true;
}
先对上一个Activity执行pause操作，再执行当前创建操作，代码最终进入到了ActivityStackSupervisor.startSpecificActivityLocked方法中。这里有个点注意下，启动activity前调用了next.showStartingWindow方法来展示一个window，这就是冷启动时 出现白屏 的原因了。我们继续看ActivityStackSupervisor.startSpecificActivityLocked方法：
void startSpecificActivityLocked(ActivityRecord r, boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
final WindowProcessController wpc =
mService.getProcessController(r.processName, r.info.applicationInfo.uid);
boolean knownToBeDead = false;
if (wpc != null && wpc.hasThread()) {
try {
realStartActivityLocked(r, wpc, andResume, checkConfig);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting activity "
+ r.intent.getComponent().flattenToShortString(), e);
}
knownToBeDead = true;
}
...
try {
if (Trace.isTagEnabled(TRACE_TAG_ACTIVITY_MANAGER)) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "dispatchingStartProcess:"
+ r.processName);
}
// 上面的wpc != null && wpc.hasThread()不满足的话，说明没有进程，就会取创建进程
final Message msg = PooledLambda.obtainMessage(
ActivityManagerInternal::startProcess, mService.mAmInternal, r.processName,
r.info.applicationInfo, knownToBeDead, "activity", r.intent.getComponent());
mService.mH.sendMessage(msg);
} finally {
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
}
逻辑很清晰：有应用进程就启动activity（普通activity），没有就去创建进程（然后再启动根activity）。
应用进程存在的判断条件是：wpc != null && wpc.hasThread()，看下WindowProcessController的hasThread方法：
// The actual proc... may be null only if 'persistent' is true (in which case we are in the
// process of launching the app)
private IApplicationThread mThread;
boolean hasThread() {
return mThread != null;
}
前面已有说明，IApplicationThread是ApplicationThread在客户端（app）在服务端（系统进程）的代理，这里判断 IApplicationThread不为空 就代表进程已存在，为啥这么判断呢？这里先猜测，进程创建后，一定会有给IApplicationThread赋值的操作，这样就符合这个逻辑了。我们继续看，瞅瞅进程是如何创建的，以及创建后是否有给IApplicationThread赋值的操作。
使用ActivityTaskManagerService的mH（继承handler）发送了一个消息，消息中第一个参数是ActivityManagerInternal::startProcess，ActivityManagerInternal的实现是AMS的内部类LocalService，LocalService的startProcess方法调用了AMS的startProcessLocked方法，那么我们就看看AMS 的startProcessLocked方法，这里应该就是创建进程了
final ProcessRecord startProcessLocked(String processName,
ApplicationInfo info, boolean knownToBeDead, int intentFlags,
HostingRecord hostingRecord, boolean allowWhileBooting,
boolean isolated, boolean keepIfLarge) {
return mProcessList.startProcessLocked(processName, info, knownToBeDead, intentFlags,
hostingRecord, allowWhileBooting, isolated, 0 /* isolatedUid */, keepIfLarge,
null /* ABI override */, null /* entryPoint */, null /* entryPointArgs */,
null /* crashHandler */);
}
这里调用了ProcessList.startProcessLocked方法，内部又多次调用了startProcessLocked不同的重载方法，最后走到startProcess方法：
private Process.ProcessStartResult startProcess(HostingRecord hostingRecord, String entryPoint,
ProcessRecord app, int uid, int[] gids, int runtimeFlags, int mountExternal,
String seInfo, String requiredAbi, String instructionSet, String invokeWith,
long startTime) {
try {
...
startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, runtimeFlags, mountExternal,
app.info.targetSdkVersion, seInfo, requiredAbi, instructionSet,
app.info.dataDir, invokeWith, app.info.packageName,
new String[] {PROC_START_SEQ_IDENT + app.startSeq});
}
checkSlow(startTime, "startProcess: returned from zygote!");
return startResult;
} finally {
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
}
}
调用了Process.start方法，跟进看下：
public static ProcessStartResult start(@NonNull final String processClass,
@Nullable final String niceName,
int uid, int gid, @Nullable int[] gids,
int runtimeFlags,
int mountExternal,
int targetSdkVersion,
@Nullable String seInfo,
@NonNull String abi,
@Nullable String instructionSet,
@Nullable String appDataDir,
@Nullable String invokeWith,
@Nullable String packageName,
@Nullable String[] zygoteArgs) {
return ZYGOTE_PROCESS.start(processClass, niceName, uid, gid, gids,
runtimeFlags, mountExternal, targetSdkVersion, seInfo,
abi, instructionSet, appDataDir, invokeWith, packageName,
/*useUsapPool=*/ true, zygoteArgs);
}
ZYGOTE_PROCESS是用于保持与Zygote进程的通信状态，发送socket请求与Zygote进程通信。Zygote进程是进程孵化器，用于创建进程。ZYGOTE_PROCESS的start就不再跟进去了，关于这块知识可以参考《Android进阶解密》第二章、第三章。我们只需要知道其内部：
Zygote通过fork创建了一个进程
在新建的进程中创建Binder线程池（此进程就支持了Binder IPC）
最终是通过反射获取到了ActivityThread类并执行了main方法
3.2 根Activity的启动
在之前文章 [Handler：Android消息机制–中介绍主线程的消息机制时就介绍过ActivityThread的main方法，主要就是开启了主线程的消息循环。
final H mH = new H();
public static void main(String[] args) {
...
//1、准备主线程的Looper
Looper.prepareMainLooper();
long startSeq = 0;
if (args != null) {
for (int i = args.length - 1; i >= 0; --i) {
if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
startSeq = Long.parseLong(
args[i].substring(PROC_START_SEQ_IDENT.length()));
}
}
}
//这里实例化ActivityThread，也就实例化了上面的mH，就是handler。
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
//获取handler
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
...
//主线程looper开启
Looper.loop();
//因为主线程的Looper是不能退出的，退出就无法接受事件了。一旦意外退出，会抛出异常
throw new RuntimeException("Main thread loop unexpectedly exited");
}
在这理，我们关注 这两这行代码：
ActivityThread thread = new ActivityThread();
thread.attach(false, startSeq);
创建ActivityThread实例，同时会创建ApplicationThread实例，ApplicationThread实例是ActivityThread实例的属性。然后调用了attach方法：
private void attach(boolean system, long startSeq) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
UserHandle.myUserId());
RuntimeInit.setApplicationObject(mAppThread.asBinder());
final IActivityManager mgr = ActivityManager.getService();
try {
//把ApplicationThread实例关联到AMS中
mgr.attachApplication(mAppThread, startSeq);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
...
}
...
}
前面提到过这里mgr就是AMS在客户端的代理，所以mgr的attachApplication方法，就是IPC的走到AMS的attachApplication方法了：
public final void attachApplication(IApplicationThread thread, long startSeq) {
synchronized (this) {
int callingPid = Binder.getCallingPid();
final int callingUid = Binder.getCallingUid();
final long origId = Binder.clearCallingIdentity();
attachApplicationLocked(thread, callingPid, callingUid, startSeq);
Binder.restoreCallingIdentity(origId);
}
}
attachApplicationLocked方法很长，这里保留重要的几点：
private final boolean attachApplicationLocked(IApplicationThread thread,
int pid, int callingUid, long startSeq) {
...
//1、IPC操作，创建绑定Application
thread.bindApplication(processName, appInfo, providers, null, profilerInfo,
null, null, null, testMode,
mBinderTransactionTrackingEnabled, enableTrackAllocation,
isRestrictedBackupMode || !normalMode, app.isPersistent(),
new Configuration(app.getWindowProcessController().getConfiguration()),
app.compat, getCommonServicesLocked(app.isolated),
mCoreSettingsObserver.getCoreSettingsLocked(),
buildSerial, autofillOptions, contentCaptureOptions);
...
// 2、赋值IApplicationThread
app.makeActive(thread, mProcessStats);
...
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
//3、通过ATMS启动 根activity
didSomething = mAtmInternal.attachApplication(app.getWindowProcessController());
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
...
}
AMS的attachApplicationLocked方法主要三件事：
调用IApplicationThread的bindApplication方法，IPC操作，创建绑定Application；
通过makeActive方法赋值IApplicationThread，即验证了上面的猜测（创建进程后赋值）；
通过ATMS启动 根activity
先看makeActive方法：
public void makeActive(IApplicationThread _thread, ProcessStatsService tracker) {
...
thread = _thread;
mWindowProcessController.setThread(thread);
}
看到使用mWindowProcessController.setThread(thread)确实完成了IApplicationThread的赋值。这样就可以依据IApplicationThread是否为空判断进程是否存在了。
再看创建绑定Application的过程：IApplicationThread的bindApplication方法实现是客户端的ApplicationThread的bindApplication方法，它又使用H转移到了ActivityThread的handleBindApplication方法（从Binder线程池转移到主线程），看下handleBindApplication方法：
private void handleBindApplication(AppBindData data) {
...
final LoadedApk pi = getPackageInfo(instrApp, data.compatInfo,
appContext.getClassLoader(), false, true, false);
final ContextImpl instrContext = ContextImpl.createAppContext(this, pi,
appContext.getOpPackageName());
try {
//创建Instrumentation
final ClassLoader cl = instrContext.getClassLoader();
mInstrumentation = (Instrumentation)
cl.loadClass(data.instrumentationName.getClassName()).newInstance();
}
...
final ComponentName component = new ComponentName(ii.packageName, ii.name);
mInstrumentation.init(this, instrContext, appContext, component,
data.instrumentationWatcher, data.instrumentationUiAutomationConnection);
...
//创建Application
app = data.info.makeApplication(data.restrictedBackupMode, null);
...
mInitialApplication = app;
try {
mInstrumentation.onCreate(data.instrumentationArgs);
}
...
try {
//内部调用Application的onCreate方法
mInstrumentation.callApplicationOnCreate(app);
}
...
}
主要就是创建Application，并且调用生命周期onCreate方法。你会发现在前面介绍的ActivityThread的performLaunchActivity方法中，也有同样的操作，只不过会先判断Application是否已存在。也就是说，正常情况下Application的初始化是在handleBindApplication方法中的，并且是创建进程后调用的。performLaunchActivity中只是做了一个检测，异常情况Application不存在时才会创建。
这里注意一点，创建Application后，内部会attach方法，attach内部会调用attachBaseContext方法，attachBaseContext方法是我们能接触到的一个方法，接着才是onCreate方法。
再来看 根activity 的启动，回到上面AMS的attachApplicationLocked方法，调用了mAtmInternal.attachApplication方法，mAtmInternal是ActivityTaskManagerInternal实例，具体实现是在ActivityTaskManagerService的内部类LocalService，去看看：
//ActivityTaskManagerService#LocalService
public boolean attachApplication(WindowProcessController wpc) throws RemoteException {
synchronized (mGlobalLockWithoutBoost) {
return mRootActivityContainer.attachApplication(wpc);
}
}
mRootActivityContainer是RootActivityContainer实例，看下它的attachApplication方法：
boolean attachApplication(WindowProcessController app) throws RemoteException {
final String processName = app.mName;
boolean didSomething = false;
for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
final ActivityDisplay display = mActivityDisplays.get(displayNdx);
final ActivityStack stack = display.getFocusedStack();
if (stack != null) {
stack.getAllRunningVisibleActivitiesLocked(mTmpActivityList);
final ActivityRecord top = stack.topRunningActivityLocked();
final int size = mTmpActivityList.size();
for (int i = 0; i < size; i++) {
final ActivityRecord activity = mTmpActivityList.get(i);
if (activity.app == null && app.mUid == activity.info.applicationInfo.uid
&& processName.equals(activity.processName)) {
try {
//这个方法很重要就是调用
if (mStackSupervisor.realStartActivityLocked(activity, app,
top == activity /* andResume */, true /* checkConfig */)) {
didSomething = true;
}
}
...
}
}
}
}
if (!didSomething) {
ensureActivitiesVisible(null, 0, false /* preserve_windows */);
}
return didSomething;
}
遍历activity栈，此时理论上应该只有一个根activity，然后调用mStackSupervisor.realStartActivityLocked方法，看到这里我们知道了，这里就开始走上面分析过的流程了，即使用ClientTransaction会跨进程交给客户端
realStartActivityLocked方法：
boolean realStartActivityLocked(ActivityRecord r, WindowProcessController proc,
boolean andResume, boolean checkConfig) throws RemoteException {
...
// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(
proc.getThread(), r.appToken);
final DisplayContent dc = r.getDisplay().mDisplayContent;
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
System.identityHashCode(r), r.info,
// TODO: Have this take the merged configuration instead of separate global
// and override configs.
mergedConfiguration.getGlobalConfiguration(),
mergedConfiguration.getOverrideConfiguration(), r.compat,
r.launchedFromPackage, task.voiceInteractor, proc.getReportedProcState(),
r.icicle, r.persistentState, results, newIntents,
dc.isNextTransitionForward(), proc.createProfilerInfoIfNeeded(),
r.assistToken));
// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
lifecycleItem = ResumeActivityItem.obtain(dc.isNextTransitionForward());
} else {
lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);
// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);
...
return true;
}
中间有段代码如上，通过 ClientTransaction.obtain( proc.getThread(), r.appToken)获取了clientTransaction，其中参数proc.getThread()是IApplicationThread，就是前面提到的ApplicationThread在系统进程的代理。
ClientTransaction是包含一系列的待客户端处理的事务的容器，客户端接收后取出事务并执行。
接着看，使用clientTransaction.addCallback添加了LaunchActivityItem实例：
//都是用来发送到客户端的
private List<ClientTransactionItem> mActivityCallbacks;
public void addCallback(ClientTransactionItem activityCallback) {
if (mActivityCallbacks == null) {
mActivityCallbacks = new ArrayList<>();
}
mActivityCallbacks.add(activityCallback);
}
看下LaunchActivityItem实例的获取：
/** Obtain an instance initialized with provided params. */
public static LaunchActivityItem obtain(Intent intent, int ident, ActivityInfo info,
Configuration curConfig, Configuration overrideConfig, CompatibilityInfo compatInfo,
String referrer, IVoiceInteractor voiceInteractor, int procState, Bundle state,
PersistableBundle persistentState, List<ResultInfo> pendingResults,
List<ReferrerIntent> pendingNewIntents, boolean isForward, ProfilerInfo profilerInfo,
IBinder assistToken) {
LaunchActivityItem instance = ObjectPool.obtain(LaunchActivityItem.class);
if (instance == null) {
instance = new LaunchActivityItem();
}
setValues(instance, intent, ident, info, curConfig, overrideConfig, compatInfo, referrer,
voiceInteractor, procState, state, persistentState, pendingResults,
pendingNewIntents, isForward, profilerInfo, assistToken);
return instance;
}
new了一个LaunchActivityItem然后设置各种值。我们从名字就能看出，它就是用来启动activity的。它是怎么发挥作用的呢？接着看：
回到realStartActivityLocked方法，接着调用了
mService.getLifecycleManager().scheduleTransaction(clientTransaction)，mService是ActivityTaskManagerService，getLifecycleManager()方法获取的是ClientLifecycleManager实例，它的scheduleTransaction方法如下：
void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
final IApplicationThread client = transaction.getClient();
transaction.schedule();
if (!(client instanceof Binder)) {
transaction.recycle();
}
}
很简单，就是调用IApplicationThread的scheduleTransaction方法。由于IApplicationThread是ApplicationThread在系统进程的代理，所以真正执行的地方就是 客户端的ApplicationThread中了。也就是说，Activity启动的操作又跨进程的还给了客户端。
好了，到这里我们稍稍梳理下：启动Activity的操作从客户端 跨进程 转移到 ATMS，ATMS通过ActivityStarter、ActivityStack、ActivityStackSupervisor 对 Activity任务、activity栈、Activity记录 管理后，又用过跨进程把正在启动过程又转移到了客户端。
2.3 线程切换及消息处理——mH
接着上面的分析，我们找到ApplicationThread的scheduleTransaction方法：
@Override
public void scheduleTransaction(ClientTransaction transaction) throws RemoteException {
ActivityThread.this.scheduleTransaction(transaction);
}
那就再看ActivityThread的scheduleTransaction方法，实际在其父类ClientTransactionHandler中：
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
使用sendMessage发送消息，参数是ActivityThread.H.EXECUTE_TRANSACTION和transaction，接着看
void sendMessage(int what, Object obj) {
sendMessage(what, obj, 0, 0, false);
}
private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
if (DEBUG_MESSAGES) {
Slog.v(TAG,
"SCHEDULE " + what + " " + mH.codeToString(what) + ": " + arg1 + " / " + obj);
}
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
if (async) {
msg.setAsynchronous(true);
}
mH.sendMessage(msg);
}
最后调用了mH.sendMessage(msg)，mH是个啥？我们看看：
//ActivityThread
final H mH = new H();
class H extends Handler {
public static final int BIND_APPLICATION = 110;
@UnsupportedAppUsage
public static final int EXIT_APPLICATION = 111;
@UnsupportedAppUsage
public static final int RECEIVER = 113;
@UnsupportedAppUsage
public static final int CREATE_SERVICE = 114;
@UnsupportedAppUsage
public static final int SERVICE_ARGS = 115;
...
public static final int EXECUTE_TRANSACTION = 159;
public static final int RELAUNCH_ACTIVITY = 160;
...
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case BIND_APPLICATION:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
AppBindData data = (AppBindData)msg.obj;
handleBindApplication(data);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
case EXIT_APPLICATION:
if (mInitialApplication != null) {
mInitialApplication.onTerminate();
}
Looper.myLooper().quit();
break;
case RECEIVER:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "broadcastReceiveComp");
handleReceiver((ReceiverData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
case CREATE_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, ("serviceCreate: " + String.valueOf(msg.obj)));
handleCreateService((CreateServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
case BIND_SERVICE:
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "serviceBind");
handleBindService((BindServiceData)msg.obj);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
break;
...
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
if (isSystem()) {
// Client transactions inside system process are recycled on the client side
// instead of ClientLifecycleManager to avoid being cleared before this
// message is handled.
transaction.recycle();
}
break;
case RELAUNCH_ACTIVITY:
handleRelaunchActivityLocally((IBinder) msg.obj);
break;
...
}
Object obj = msg.obj;
if (obj instanceof SomeArgs) {
((SomeArgs) obj).recycle();
}
if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
}
}
mH是在创建ActivityThread实例时赋值的，是自定义Handler子类H的实例，也就是在ActivityThread的main方法中，并且初始化是已经主线程已经有了mainLooper，所以，使用这个mH来sendMessage就把消息发送到了主线程。
那么是从哪个线程发送的呢？那就要看看ApplicationThread的scheduleTransaction方法是执行在哪个线程了。根据IPC知识，我们知道，服务器的Binder方法运行在Binder的线程池中，也就是说系统进行跨进程调用ApplicationThread的scheduleTransaction就是执行在Binder的线程池中的了。
到这里，消息就在主线程处理了，那么是怎么处理Activity的启动的呢？接着看。我们找到ActivityThread.H.EXECUTE_TRANSACTION这个消息的处理，就在handleMessage方法的倒数第三个case（就在上面代码）：取出ClientTransaction实例，调用TransactionExecutor的execute方法，那就看看：
public void execute(ClientTransaction transaction) {
if (DEBUG_RESOLVER) Slog.d(TAG, tId(transaction) + "Start resolving transaction");
final IBinder token = transaction.getActivityToken();
...
executeCallbacks(transaction);
executeLifecycleState(transaction);
...
}
继续跟进executeCallbacks方法：
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
if (callbacks == null || callbacks.isEmpty()) {
// No callbacks to execute, return early.
return;
}
if (DEBUG_RESOLVER) Slog.d(TAG, tId(transaction) + "Resolving callbacks in transaction");
final IBinder token = transaction.getActivityToken();
ActivityClientRecord r = mTransactionHandler.getActivityClient(token);
// In case when post-execution state of the last callback matches the final state requested
// for the activity in this transaction, we won't do the last transition here and do it when
// moving to final state instead (because it may contain additional parameters from server).
final ActivityLifecycleItem finalStateRequest = transaction.getLifecycleStateRequest();
final int finalState = finalStateRequest != null ? finalStateRequest.getTargetState()
: UNDEFINED;
// Index of the last callback that requests some post-execution state.
final int lastCallbackRequestingState = lastCallbackRequestingState(transaction);
final int size = callbacks.size();
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
...
item.execute(mTransactionHandler, token, mPendingActions);
item.postExecute(mTransactionHandler, token, mPendingActions);
...
}
}
遍历callbacks，调用ClientTransactionItem的execute方法，而我们这里要关注的是ClientTransactionItem的子类LaunchActivityItem，看下它的execute方法：
public void execute(ClientTransactionHandler client, IBinder token,
PendingTransactionActions pendingActions) {
Trace.traceBegin(TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
ActivityClientRecord r = new ActivityClientRecord(token, mIntent, mIdent, mInfo,
mOverrideConfig, mCompatInfo, mReferrer, mVoiceInteractor, mState, mPersistentState,
mPendingResults, mPendingNewIntents, mIsForward,
mProfilerInfo, client, mAssistToken);
client.handleLaunchActivity(r, pendingActions, null /* customIntent */);
Trace.traceEnd(TRACE_TAG_ACTIVITY_MANAGER);
}
里面调用了client.handleLaunchActivity方法，client是ClientTransactionHandler的实例，是在TransactionExecutor构造方法传入的，TransactionExecutor创建是在ActivityThread中：
//ActivityThread
private final TransactionExecutor mTransactionExecutor = new TransactionExecutor(this);
所以，client.handleLaunchActivity方法就是ActivityThread的handleLaunchActivity方法。
好了，到这里 ApplicationThread把启动Activity的操作，通过mH切到了主线程，走到了ActivityThread的handleLaunchActivity方法。
2.4 Activity启动核心实现——初始化及生命周期
ActivityThread 类中的方法
public Activity handleLaunchActivity(ActivityClientRecord r,
PendingTransactionActions pendingActions, Intent customIntent) {
...
final Activity a = performLaunchActivity(r, customIntent);
...
return a;
}
继续跟performLaunchActivity方法，这里就是activity 启动的核心实现了
/** activity 启动的核心实现. */
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//1、从ActivityClientRecord获取待启动的Activity的组件信息
ActivityInfo aInfo = r.activityInfo;
if (r.packageInfo == null) {
r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
Context.CONTEXT_INCLUDE_CODE);
}
ComponentName component = r.intent.getComponent();
if (component == null) {
component = r.intent.resolveActivity(
mInitialApplication.getPackageManager());
r.intent.setComponent(component);
}
if (r.activityInfo.targetActivity != null) {
component = new ComponentName(r.activityInfo.packageName,
r.activityInfo.targetActivity);
}
//创建ContextImpl对象
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
//2、创建activity实例
java.lang.ClassLoader cl = appContext.getClassLoader();
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);
r.intent.prepareToEnterProcess();
if (r.state != null) {
r.state.setClassLoader(cl);
}
} catch (Exception e) {
..
}
try {
//3、创建Application对象（如果没有的话）
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
...
if (activity != null) {
CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
Configuration config = new Configuration(mCompatConfiguration);
if (r.overrideConfig != null) {
config.updateFrom(r.overrideConfig);
}
Window window = null;
if (r.mPendingRemoveWindow != null && r.mPreserveWindow) {
window = r.mPendingRemoveWindow;
r.mPendingRemoveWindow = null;
r.mPendingRemoveWindowManager = null;
}
appContext.setOuterContext(activity);
//4、attach方法为activity关联上下文环境
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
if (customIntent != null) {
activity.mIntent = customIntent;
}
r.lastNonConfigurationInstances = null;
checkAndBlockForNetworkAccess();
activity.mStartedActivity = false;
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
activity.mCalled = false;
//5、调用生命周期onCreate
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
if (!activity.mCalled) {
throw new SuperNotCalledException(
"Activity " + r.intent.getComponent().toShortString() +
" did not call through to super.onCreate()");
}
r.activity = activity;
}
r.setState(ON_CREATE);
synchronized (mResourcesManager) {
mActivities.put(r.token, r);
}
}
...
return activity;
}
performLaunchActivity主要完成以下事情：
从ActivityClientRecord获取待启动的Activity的组件信息
通过mInstrumentation.newActivity方法使用类加载器创建activity实例
通过LoadedApk的makeApplication方法创建Application对象，内部也是通过mInstrumentation使用类加载器，创建后就调用了instrumentation.callApplicationOnCreate方法，也就是Application的onCreate方法。
创建ContextImpl对象并通过activity.attach方法对重要数据初始化，关联了Context的具体实现ContextImpl，attach方法内部还完成了window创建，这样Window接收到外部事件后就能传递给Activity了。
调用Activity的onCreate方法，是通过 mInstrumentation.callActivityOnCreate方法完成。
我们发现，根activity的启动前 需要创建应用进程，然后走到ActivityThread的main方法，开启主线程循环，初始化并绑定Application、赋值IApplicationThread，最后真正的启动过程和普通Activity是一致的。
上面的流程图 补充 根activity的逻辑，完整关系如下：
image.png
总结
关于 普通Activity 启动的流程的讲解，我们分成了几个阶段：启动的发起、AMS的管理、线程切换、启动核心实现，知道了启动过程经历了两次IPC，客户端到AMS、AMS到客户端，以及Activity创建和生命周期的执行。 然后又在此基础上 补充的根activity的启动：先创建应用进程，再绑定Application，最后真正启动跟Activity。
本篇内容涉及大量知识点，结合 IPC、Handler、Window等相关知识，这样可以对Android系统有更加完整的认识。
