Android 7.0 ActivityManagerService(3) 启动Activity的过程：二
这一篇博客，我们将继续学习Activity的启动流程。
在启动Activity的过程：一中，我们的流程最终分析到AMS通过zygote启动Activity对应的进程，现在我们看看后续的过程如何进行。
关于zygote启动进程的流程，可以参考Android6.0 SystemServer进程。这篇文章中，分析了zygote如何启动SystemServer进程和普通进程。虽然分析的是Android M的代码，但与android N的思路基本一致。
一、ActivityThread的main函数
通过zygote启动进程时，传入的className为android.app.ActivityThread。
因此，当zygote通过反射调用进程的main函数时，ActivityThread的main函数将被启动：
public static void main(String[] args) {
..................
//开始信息采样
SamplingProfilerIntegration.start();
// CloseGuard defaults to true and can be quite spammy. We
// disable it here, but selectively enable it later (via
// StrictMode) on debug builds, but using DropBox, not logs.
//和调试有关
CloseGuard.setEnabled(false);
//得到当前进程的UserEnvironment
Environment.initForCurrentUser();
...............
// Make sure TrustedCertificateStore looks in the right place for CA certificates
// 确保进程能够得到CA证书的路径
final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
TrustedCertificateStore.setDefaultUserDirectory(configDir);
Process.setArgV0("" );
//准备主线程的Looper
Looper.prepareMainLooper();
//创建当前进程的ActivityThread
ActivityThread thread = new ActivityThread();
//调用attach函数
thread.attach(false);
if (sMainThreadHandler == null) {
//保存进程对应的主线程Handler
sMainThreadHandler = thread.getHandler();
}
.........
//进入主线程的消息循环
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
从上述代码可以看出，ActivityThread的main函数最主要工作是：
1、创建出一个Looper，并将主线程加入到消息循环中。
2、创建出ActivityThread，并调用其attach函数。
在介绍AMS的启动过程时，我们就提到了ActivityThread。
当时从代码中，我们知道SystemServer进程，为了融入Android体系，调用createSystemContext函数。
在createSystemContext函数中，SystemServer进程创建了自己的ActivityThread，并调用了attach函数。
通过比对代码容易看出，SystemServer进程作为系统进程，attach参数为true，而普通进程传入的参数为false。
现在，我们重新看看ActivityThread的attach函数，这次侧重于普通进程的部分：
private void attach(boolean system) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
ViewRootImpl.addFirstDrawHandler(new Runnable() {
@Override
public void run() {
//JIT-Just in time
//JIT技术主要是对多次运行的代码进行编译，当再次调用时使用编译之后的机器码，而不是每次都解释，以节约时间
//JIT原理：
//每启动一个应用程序，都会相应地启动一个dalvik虚拟机，启动时会建立JIT线程，一直在后台运行。
//当某段代码被调用时，虚拟机会判断它是否需要编译成机器码，如果需要，就做一个标记。
//JIT线程在后台检测该标记，如果发现标记被设定，就把对应代码编译成机器码，并将其机器码地址及相关信息保存起来
//当进程下次执行到此段代码时，就会直接跳到机器码执行，而不再解释执行，从而提高运行速度
//这里开启JIT，应该是为了提高android绘制的速度
ensureJitEnabled();
}
});
//设置在DDMS中看到的进程名为""
android.ddm.DdmHandleAppName.setAppName("" , UserHandle.myUserId());
//设置RuntimeInit的mApplicationObject参数
RuntimeInit.setApplicationObject(mAppThread.asBinder());
final IActivityManager mgr = ActivityManagerNative.getDefault();
try {
//与AMS通信，调用其attachApplication接口
mgr.attachApplication(mAppThread);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
// Watch for getting close to heap limit.
// 监控GC操作; 当进程内的一些Activity发生变化，同时内存占用量较大时
// 通知AMS释放一些Activity
BinderInternal.addGcWatcher(new Runnable() {
public void run() {
if (!mSomeActivitiesChanged) {
return;
}
Runtime runtime = Runtime.getRuntime();
long dalvikMax = runtime.maxMemory();
long dalvikUsed = runtime.totalMemory() - runtime.freeMemory();
//判断内存占用量是否过大
if (dalvikUsed > ((3*dalvikMax)/4)) {
...........
mSomeActivitiesChanged = false;
try {
//通知AMS释放一些Activity，以缓解内存紧张
mgr.releaseSomeActivities(mAppThread);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
}
});
} else {
.............
}
........
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
在分析Activity启动过程的第一部分时，我们提到过AMS创建一个应用进程后，会设置一个超时时间。
如果超过这个时间，应用进程还没有和AMS交互，AMS就认为该进程创建失败。
因此，应用进程启动后，需要尽快和AMS交互。
上述代码中，attachApplication就是应用进程与AMS交互的接口。
二、AMS的attachApplication函数
我们进入AMS看看attachApplication相关的流程。
public final void attachApplication(IApplicationThread thread) {
synchronized (this) {
int callingPid = Binder.getCallingPid();
final long origId = Binder.clearCallingIdentity();
//进一步调用attachApplicationLocked函数
attachApplicationLocked(thread, callingPid);
Binder.restoreCallingIdentity(origId);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
attachApplicationLocked函数比较长，分段来看一下。
1 Part-I
private final boolean attachApplicationLocked(IApplicationThread thread, int pid) {
ProcessRecord app;
//根据pid查找对应的ProcessRecord对象
if (pid != MY_PID && pid >= 0) {
synchronized (mPidsSelfLocked) {
app = mPidsSelfLocked.get(pid);
}
} else {
app = null;
}
//如果进程由AMS启动，则它在AMS中一定有对应的ProcessRecord
//此处app为null，则表示AMS没有该进程的记录，故需要kill掉此异常进程
if (app == null) {
................
if (pid > 0 && pid != MY_PID) {
//pid大于0且不是系统进程，则直接kill掉
//将调用android_util_Process.cpp中的android_os_Process_sendSignalQuiet函数
//最终通过kill函数杀死进程，kill函数要求pid > 0
Process.killProcessQuiet(pid);
} else {
try {
//pid < 0时，fork进程失败，因此仅上层完成清理工作即可
//调用ApplicationThread的scheduleExit函数
//应用进程将进行一些扫尾工作，例如结束消息循环，然后退出运行
thread.scheduleExit();
} catch (Exception e) {
// Ignore exceptions.
}
}
return false;
}
// If this application record is still attached to a previous
// process, clean it up now.
// 判断pid对应processRecord的IApplicationThread是否为null
// AMS创建ProcessRecord后，在attach之前，正常情况下IApplicationThread应该为null
// 特殊情况下：如果旧应用进程被杀死，底层对应的pid被释放，在通知到达AMS之前（AMS在下面的代码里注册了“讣告”接收对象），
// 用户又启动了一个新的进程，新进程刚好分配到旧进程的pid时
// 此处得到的processRecord可能就是旧进程的，于是app.thread可能不为null，因此需要作判断和处理
if (app.thread != null) {
handleAppDiedLocked(app, true, true);
}
...................
final String processName = app.processName;
try {
//创建一个“讣告”接收对象，注册到应用进程的ApplicationThread中
//当应用进程退出时，该对象的binderDied将被调用，这样AMS就能做相应的处理
//binderDied函数将在另一个线程中被调用，其内部也会调用handleAppDiedLocked函数
AppDeathRecipient adr = new AppDeathRecipient(
app, pid, thread);
thread.asBinder().linkToDeath(adr, 0);
app.deathRecipient = adr;
} catch (RemoteException e) {
app.resetPackageList(mProcessStats);
startProcessLocked(app, "link fail", processName);
return false;
}
设置app的一些变量，例如调度优先级和oom_adj相关的成员
.................
//启动成功，从消息队列中移除PROC_START_TIMEOUT_MSG
mHandler.removeMessages(PROC_START_TIMEOUT_MSG, app);
.................
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
至此，attachApplicationLocked的第一部分介绍完毕。
这部分代码的核心功能比较简单，其实就是：
1、判断进程的有效性，同时注册观察者监听进程的死亡信号。
2、设置pid对应的ProcessRecord对象的一些成员变量，例如和应用进程交互的IApplicationThread对象、进程调度的优先级等。
3、进程注册成功，AMS从消息队列中移除PROC_START_TIMEOUT_MSG。
2 Part-II
现在，我们看看attachApplicationLocked第二部分的代码：
..............
//AMS正常启动后，mProcessesReady就已经变为true了
boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
//generateApplicationProvidersLocked将通过PKMS查询定义在进程中的ContentProvider，并将其保存在AMS的数据结构中
List<ProviderInfo> providers = normalMode ? generateApplicationProvidersLocked(app) : null;
//这里应该是处理：加载ContentProvider时，启动进程的场景
//checkAppInLaunchingProvidersLocked主要将当前启动进程的ProcessRecord，和AMS中mLaunchingProviders的ProcessRecord进行比较
//当判断出该进程是由于启动ContentProvider而被加载的，那么就发送一个延迟消息（10s）
//通过这里可以看出，当由于加载ContentProvider启动进程时，在进程启动后，ContentProvider在10s内要完成发布
if (providers != null && checkAppInLaunchingProvidersLocked(app)) {
Message msg = mHandler.obtainMessage(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG);
msg.obj = app;
mHandler.sendMessageDelayed(msg, CONTENT_PROVIDER_PUBLISH_TIMEOUT);
}
...........
try {
...........
//回调进程ApplicationThread的bindApplication接口
thread.bindApplication(..........);
//更新进程调度策略
updateLruProcessLocked(app, false, null);
..............
} catch () {
............
app.resetPackageList(mProcessStats);
app.unlinkDeathRecipient();
//这里的策略比较激进，当bindApplicaiton失败后，将直接重新启动这个进程
startProcessLocked(app, "bind fail", processName);
return false;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
从代码来看，第二阶段最核心工作就是：
调用进程ApplicationThread的bindApplication函数，接下来我们分析一下该函数。
2.1 ApplicationThread的bindApplication函数
从之前的代码，我们知道应用进程由zygote fork得到，然后调用ActivityThread的main函数，进入到Java世界。
但是截至目前，该进程并没有融入到Android的体系中，因此仅能被称为一个Java进程，甚至连进程名也只是“敷衍”地定义为“pre-initialized”。
我们之前分析AMS启动过程时，介绍了SystemServer的createSystemContext函数。
在该函数中，SystemServer在自己的进程中，创建出Android运行环境，才摇身一变成为了Android进程。
同样，此处的bindApplication函数，就是在新进程中创建并初始化对应的Android运行环境。
现在，我们看看bindApplication函数的主要流程：
//参数较多，无需深究，重要的从代码流程中就能知道含义
public final void bindApplication(.......) {
//按照string-IBinder的方式，保存AMS传递过来的系统service的Binder接口
//这样进程与系统服务通信时，就不需要先通过SystemServer查询了
if (services != null) {
// Setup the service cache in the ServiceManager
ServiceManager.initServiceCache(services);
}
//内部发送H.SET_CORE_SETTINGS消息
//由handleSetCoreSettings进行处理，主要用于保存新的信息
setCoreSettings(coreSettings);
//用AppBindData对象保存参数对应的信息
AppBindData data = new AppBindData();
data.processName = processName;
data.appInfo = appInfo;
data.providers = providers;
..................
//发送消息
sendMessage(H.BIND_APPLICATION, data);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
由以上代码可知，ApplicationThread的接口被AMS调用后，会将参数保存到AppBindData对象中，然后发送消息让ActivityThread的主线程处理。
由此可以看出，对应用进程而言，ApplicationThread只是与AMS通信的接口，实际的工作一般还是会交给ActivityThread来完成。
ActivityThread中处理该消息的实际函数为handleBindApplication，我们看看这个函数的内容。
2.2 handleBindApplication函数
private void handleBindApplication(AppBindData data) {
// Register the UI Thread as a sensitive thread to the runtime.
VMRuntime.registerSensitiveThread();
.................
//初始化性能统计对象
mProfiler = new Profiler();
if (data.initProfilerInfo != null) {
mProfiler.profileFile = data.initProfilerInfo.profileFile;
mProfiler.profileFd = data.initProfilerInfo.profileFd;
mProfiler.samplingInterval = data.initProfilerInfo.samplingInterval;
mProfiler.autoStopProfiler = data.initProfilerInfo.autoStopProfiler;
}
// send up app name; do this *before* waiting for debugger
//重新设置进程名，并修改DDMS中的名称
Process.setArgV0(data.processName);
android.ddm.DdmHandleAppName.setAppName(data.processName,
UserHandle.myUserId());
if (data.persistent) {
// Persistent processes on low-memory devices do not get to
// use hardware accelerated drawing, since this can add too much
// overhead to the process.
//在低内存设备上，禁止常驻进程使用硬件加速
if (!ActivityManager.isHighEndGfx()) {
ThreadedRenderer.disable(false);
}
}
//启动性能统计
if (mProfiler.profileFd != null) {
mProfiler.startProfiling();
}
// If the app is Honeycomb MR1 or earlier, switch its AsyncTask
// implementation to use the pool executor. Normally, we use the
// serialized executor as the default. This has to happen in the
// main thread so the main looper is set right.
//Java并发使用的ThreadExecutor，没有太深入的去了解
//比较浅显的来讲，serialized executor应该是保证一个任务执行完毕后，才去执行下一个任务
//pool executor根据配置的corePoolSize决定初始时，可以并行的数量；
//当同时提交的任务数量，超过corePoolSize时，任务就会加入到队列中
if (data.appInfo.targetSdkVersion <= android.os.Build.VERSION_CODES.HONEYCOMB_MR1) {
AsyncTask.setDefaultExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
}
/*
* Before spawning a new process, reset the time zone to be the system time zone.
* This needs to be done because the system time zone could have changed after the
* the spawning of this process. Without doing this this process would have the incorrect
* system time zone.
*/
TimeZone.setDefault(null);
/*
* Set the LocaleList. This may change once we create the App Context.
*/
LocaleList.setDefault(data.config.getLocales());
//更新资源和兼容性相关的配置
synchronized (mResourcesManager) {
/*
* Update the system configuration since its preloaded and might not
* reflect configuration changes. The configuration object passed
* in AppBindData can be safely assumed to be up to date
*/
mResourcesManager.applyConfigurationToResourcesLocked(data.config, data.compatInfo);
mCurDefaultDisplayDpi = data.config.densityDpi;
// This calls mResourcesManager so keep it within the synchronized block.
applyCompatConfiguration(mCurDefaultDisplayDpi);
}
//根据传递过来的ApplicationInfo创建一个对应的LoadedApk对象
data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
/**
* Switch this process to density compatibility mode if needed.
*/
//如果没有设置屏幕密度，则为Bitmap设置默认的屏幕密度
if ((data.appInfo.flags&ApplicationInfo.FLAG_SUPPORTS_SCREEN_DENSITIES)
== 0) {
mDensityCompatMode = true;
Bitmap.setDefaultDensity(DisplayMetrics.DENSITY_DEFAULT);
}
updateDefaultDensity();
final boolean is24Hr = "24".equals(mCoreSettings.getString(Settings.System.TIME_12_24));
DateFormat.set24HourTimePref(is24Hr);
....................
/**
* For apps targetting Honeycomb or later, we don't allow network usage
* on the main event loop / UI thread. This is what ultimately throws
* {@link NetworkOnMainThreadException}.
*/
//禁止在主线程使用网络操作
if (data.appInfo.targetSdkVersion >= Build.VERSION_CODES.HONEYCOMB) {
StrictMode.enableDeathOnNetwork();
}
/**
* For apps targetting N or later, we don't allow file:// Uri exposure.
* This is what ultimately throws {@link FileUriExposedException}.
*/
//禁止主线程操作文件
if (data.appInfo.targetSdkVersion >= Build.VERSION_CODES.N) {
StrictMode.enableDeathOnFileUriExposure();
}
...............
/**
* Initialize the default http proxy in this process for the reasons we set the time zone.
*/
final IBinder b = ServiceManager.getService(Context.CONNECTIVITY_SERVICE);
if (b != null) {
final IConnectivityManager service = IConnectivityManager.Stub.asInterface(b);
try {
//设置默认的Http proxy
final ProxyInfo proxyInfo = service.getProxyForNetwork(null);
Proxy.setHttpProxySystemProperty(proxyInfo);
} catch (RemoteException e) {
.............
}
}
.........................
//创建出进程读应的Android运行环境
final ContextImpl appContext = ContextImpl.createAppContext(this, data.info);
.........................
// Install the Network Security Config Provider. This must happen before the application
// code is loaded to prevent issues with instances of TLS objects being created before
// the provider is installed.
.................
NetworkSecurityConfigProvider.install(appContext);
.................
if ((data.appInfo.flags&ApplicationInfo.FLAG_LARGE_HEAP) != 0) {
//如果package中声明了FLAG_LARGE_HEAP，则可跳出虚拟机对内存限制
dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
} else {
// Small heap, clamp to the current growth limit and let the heap release
// pages after the growth limit to the non growth limit capacity. b/18387825
dalvik.system.VMRuntime.getRuntime().clampGrowthLimit();
}
// Allow disk access during application and provider setup. This could
// block processing ordered broadcasts, but later processing would
// probably end up doing the same disk access.
final StrictMode.ThreadPolicy savedPolicy = StrictMode.allowThreadDiskWrites();
try {
// If the app is being launched for full backup or restore, bring it up in
// a restricted environment with the base application class.
// 利用LoadedApk的makeApplication函数，通过反射创建出Application
Application app = data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
// don't bring up providers in restricted mode; they may depend on the
// app's custom Application class
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
//加载进程对应Package中携带的ContentProvider
installContentProviders(app, data.providers);
// For process that contains content providers, we want to
// ensure that the JIT is enabled "at some point".
// 通过JIT技术加速
mH.sendEmptyMessageDelayed(H.ENABLE_JIT, 10*1000);
}
}
...................
try {
//调用Application的onCreate函数，完成一些初始化工作
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
.................
}
} finally {
StrictMode.setThreadPolicy(savedPolicy);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
如上文所述，handleBindApplication的目的是让一个Java进程融入到Android体系中。
因此，该函数中的代码主要进行以下工作：
1、按照Android的要求，完成对进程基本参数的设置置，包括设置进程名、时区、资源及兼容性配置；
同时也添加了一些限制，例如主线程不能访问网络等。
2、创建进程对应的ContextImpl、LoadedApk、Application等对象，同时加载Application中的ContentProvider，并初始化Application。
当完成上述工作后，新建的进程终于加入到了Android体系。
3 Part-III
接下来，我们看看AMS中attachApplicationLocked函数的最后一部分内容：
.....................
// Remove this record from the list of starting applications.
// 进程已经启动，从一些列表中移除对应的记录
mPersistentStartingProcesses.remove(app);
...................
mProcessesOnHold.remove(app);
boolean badApp = false;
boolean didSomething = false;
// See if the top visible activity is waiting to run in this process...
if (normalMode) {
try {
//启动Activity
if (mStackSupervisor.attachApplicationLocked(app)) {
didSomething = true;
}
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
badApp = true;
}
}
// Find any services that should be running in this process...
if (!badApp) {
try {
//启动因目标进程还未启动，而处于等待状态的service
didSomething |= mServices.attachApplicationLocked(app, processName);
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown starting services in " + app, e);
badApp = true;
}
}
// Check if a next-broadcast receiver is in this process...
if (!badApp && isPendingBroadcastProcessLocked(pid)) {
try {
//发送因目标进程还未启动，而处于等待状态的Broadcast
didSomething |= sendPendingBroadcastsLocked(app);
} catch (Exception e) {
// If the app died trying to launch the receiver we declare it 'bad'
Slog.wtf(TAG, "Exception thrown dispatching broadcasts in " + app, e);
badApp = true;
}
}
// Check whether the next backup agent is in this process...
if (!badApp && mBackupTarget != null && mBackupTarget.appInfo.uid == app.uid) {
...............
try {
//启动backup Agent
thread.scheduleCreateBackupAgent(mBackupTarget.appInfo,
compatibilityInfoForPackageLocked(mBackupTarget.appInfo),
mBackupTarget.backupMode);
} catch (Exception e) {
Slog.wtf(TAG, "Exception thrown creating backup agent in " + app, e);
badApp = true;
}
}
}
if (badApp) {
//如果以上组件启动出错，则需要杀死进程并移除记录
app.kill("error during init", true);
handleAppDiedLocked(app, false, true);
return false;
}
//如果以上没有启动任何组件，那么didSomething为false
if (!didSomething) {
//调整进程的oom_adj值， oom_adj相当于一种优先级
//如果应用进程没有运行任何组件，那么当内存出现不足时，该进程是最先被系统“杀死”
//反之，进程中运行的组件越多，则越不容易被“杀死”
updateOomAdjLocked();
}
return true;
......
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
这段代码比较好理解，主要功能就是启动新建进程中运行的Activity、Service等组件。
这里我们主要关注一下Activity的启动过程，即下面这段代码：
.............
if (normalMode) {
try {
if (mStackSupervisor.attachApplicationLocked(app)) {
didSomething = true;
}
} catch (Exception e) {
..........
badApp = true;
}
}
...............
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
我们跟进定义于ActivityStackSupervisor中的attachApplicationLocked函数：
boolean attachApplicationLocked(ProcessRecord app) throws RemoteException {
final String processName = app.processName;
boolean didSomething = false;
//ActivityStackSupervisor维护着终端中所有Activity和Task之间的关系
//此处通过轮寻，找出前台栈顶端的待启动Activity
for (int displayNdx = mActivityDisplays.size() - 1; displayNdx >= 0; --displayNdx) {
ArrayList<ActivityStack> stacks = mActivityDisplays.valueAt(displayNdx).mStacks;
for (int stackNdx = stacks.size() - 1; stackNdx >= 0; --stackNdx) {
final ActivityStack stack = stacks.get(stackNdx);
if (!isFocusedStack(stack)) {
continue;
}
ActivityRecord hr = stack.topRunningActivityLocked();
if (hr != null) {
//前台待启动的Activity与当前新建的进程一致时，启动这个Activity
if (hr.app == null && app.uid == hr.info.applicationInfo.uid
&& processName.equals(hr.processName)) {
try {
//realStartActivityLocked进行实际的启动工作
if (realStartActivityLocked(hr, app, true, true)) {
didSomething = true;
}
} catch (RemoteException e) {
.............
}
}
}
}
}
.................
return didSomething;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
通过这段代码，我们终于明白了启动Activity的过程：一中的流程，为什么要花大力气先将待启动的Activity的Task移动到前台，并且要将该Activity移动到栈顶。
毕竟，在创建新进程时，无法将待启动Activity的信息一并传递给新进程（进程刚创建时，并没有加入到Android体系），因此新进程被创建后，无法知道需要创建的Activity。
于是，上面的代码就规定：如果前台栈顶Activity对应的进程信息，与新启动的进程相互吻合时，该进程就需要启动该Activity。
三、realStartActivityLocked函数
接下来，我们看看ActivityStatckSupervisor中的realStartActivityLocked函数：
final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
boolean andResume, boolean checkConfig) throws RemoteException {
if (!allPausedActivitiesComplete()) {
// While there are activities pausing we skipping starting any new activities until
// pauses are complete. NOTE: that we also do this for activities that are starting in
// the paused state because they will first be resumed then paused on the client side.
...........
return false;
}
if (andResume) {
//为显示做准备
r.startFreezingScreenLocked(app, 0);
mWindowManager.setAppVisibility(r.appToken, true);
..........
}
// Have the window manager re-evaluate the orientation of
// the screen based on the new activity order. Note that
// as a result of this, it can call back into the activity
// manager with a new orientation. We don't care about that,
// because the activity is not currently running so we are
// just restarting it anyway.
if (checkConfig) {
Configuration config = mWindowManager.updateOrientationFromAppTokens(
mService.mConfiguration,
r.mayFreezeScreenLocked(app) ? r.appToken : null);
//AMS更新绘制相关的配置信息
mService.updateConfigurationLocked(config, r, false);
}
r.app = app;
app.waitingToKill = null;
r.launchCount++;
...............
//将待启动Activity对应ActivityRecord加入到进程中保存
int idx = app.activities.indexOf(r);
if (idx < 0) {
app.activities.add(r);
}
//更新优先级
mService.updateLruProcessLocked(app, true, null);
mService.updateOomAdjLocked();
...............
final ActivityStack stack = task.stack;
try {
...............
List<ResultInfo> results = null;
List<ReferrerIntent> newIntents = null;
if (andResume) {
results = r.results;
newIntents = r.newIntents;
}
...............
if (andResume) {
app.hasShownUi = true;
app.pendingUiClean = true;
}
app.forceProcessStateUpTo(mService.mTopProcessState);
//通知应用进程启动Activity
app.thread.scheduleLaunchActivity(............);
if ((app.info.privateFlags&ApplicationInfo.PRIVATE_FLAG_CANT_SAVE_STATE) != 0) {
//处理heavy-weight进程的情况
.........
}
} catch (RemoteException e) {
if (r.launchFailed) {
// This is the second time we failed -- finish activity
// and give up.
................
//从代码来看，第二次启动失败，才会将ActivityRecord中的launchFailed置为true
mService.appDiedLocked(app);
stack.requestFinishActivityLocked(r.appToken, Activity.RESULT_CANCELED, null,
"2nd-crash", false);
return false;
}
// This is the first time we failed -- restart process and
// retry.
app.activities.remove(r);
throw e;
}
r.launchFailed = false;
if (andResume) {
// As part of the process of launching, ActivityThread also performs
// a resume.
// Activity进入resumeState后，更新相应的状态
stack.minimalResumeActivityLocked(r);
} else {
................
}
// Launch the new version setup screen if needed. We do this -after-
// launching the initial activity (that is, home), so that it can have
// a chance to initialize itself while in the background, making the
// switch back to it faster and look better.
if (isFocusedStack(stack)) {
//启动系统设置向导对应的Activity，当系统更新或初次使用时需要配置
mService.startSetupActivityLocked();
}
................
return true;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
从上面的代码可以看出，realStartActivityLocked函数主要工作包括：
1、进一步配置ActivityRecord和ProcessRecord；
2、调用scheduleLaunchActivity，通知应用进程启动Activity；
3、在Activity启动后，AMS调用minimalResumeActivityLocked更新相应的状态。
这里我们只需要进一步看看scheduleLaunchActivity和minimalResumeActivityLocked这两个函数的流程。
1、scheduleLaunchActivity
scheduleLaunchActivity定义于ApplicationThread中：
public final void scheduleLaunchActivity(........) {
//更新进程的状态
updateProcessState(procState, false);
ActivityClientRecord r = new ActivityClientRecord();
//保存AMS传递过来的信息
r.token = token;
r.ident = ident;
r.intent = intent;
...........
//更新本地配置
updatePendingConfiguration(curConfig);
//发送消息，即ApplicationThread的工作其实就是与AMS通信
//实际的处理，还是交给进程主线程的代表ActivityThread处理
sendMessage(H.LAUNCH_ACTIVITY, r);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
ActivityThread中的handler处理消息的代码如下：
public void handleMessage(Message msg) {
...............
switch (msg.what) {
case LAUNCH_ACTIVITY: {
..............
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
//利用ApplicationInfo等信息得到对应的LoadedApk，保存到ActivityClientRecord
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
//调用handleLaunchActivity
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY");
..............
} break;
...........
}
.............
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
我们跟进一下handleLaunchActivity：
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
// If we are getting ready to gc after going to the background, well
// we are back active so skip it.
// 如果Activity从前台移动到后台，则有可能准备进行Gc操作
// 现在Activity重新启动，就需要取消Gc操作了
// 对于新建Activity而言，此处无实际动作
unscheduleGcIdler();
mSomeActivitiesChanged = true;
//Activity进行性能统计
if (r.profilerInfo != null) {
mProfiler.setProfiler(r.profilerInfo);
mProfiler.startProfiling();
}
// Make sure we are running with the most recent config.
// 保证Activity以最新的配置启动，即保证Activity符合最新语言、主题、分辨率等的要求
handleConfigurationChanged(null, null);
............
// Initialize before creating the activity
WindowManagerGlobal.initialize();
//1、创建Activity
Activity a = performLaunchActivity(r, customIntent);
if (a != null) {
r.createdConfig = new Configuration(mConfiguration);
............
//2、调用activity的onResume
handleResumeActivity(.......);
if (!r.activity.mFinished && r.startsNotResumed) {
// The activity manager actually wants this one to start out paused, because it
// needs to be visible but isn't in the foreground. We accomplish this by going
// through the normal startup (because activities expect to go through onResume()
// the first time they run, before their window is displayed), and then pausing it.
// 处理可见但非前台的Activity，这种Activity在启动后将进入到pause状态
performPauseActivityIfNeeded(r, reason);
}
...................
} else {
try {
//如果启动错误，则通知AMS
ActivityManagerNative.getDefault()
.finishActivity(r.token, Activity.RESULT_CANCELED, null,
Activity.DONT_FINISH_TASK_WITH_ACTIVITY);
} catch (RemoteException ex) {
...............
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
从上述代码可以看出，handleLaunchActivity的工作主要包括：
1、调用performLaunchActivity创建出Activity；
2、调用handleResumeActivity，完成调用目标Activity的onResume接口等工作；
3、对于可见但非前台的Activity，还需要调用performPauseActivityIfNeeded函数，调用Activity的onPause接口。
我们主要看一下performLaunchActivity和handleResumeActivity函数。
1.1 performLaunchActivity
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
............
Activity activity = null;
try {
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
//反射创建Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
...............
} catch (Exception e) {
...........
}
try {
..............
if (activity != null) {
..........
//设置Activity的主要变量，例如mMainThread、mUiThread等
//mMainThread的类型为ActivityThread；mUiThread的类型为Thread
//二者实际的工作线程是同一个
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);
...........
//进行主题的设置
activity.mStartedActivity = false;
int theme = r.activityInfo.getThemeResource();
if (theme != 0) {
activity.setTheme(theme);
}
//调用Activity的onCreate函数
activity.mCalled = false;
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
.............
r.activity = activity;
r.stopped = true;
if (!r.activity.mFinished) {
//调用Activity的onStart函数
activity.performStart();
r.stopped = false;
}
//调用Activity的onRestoreInstanceState函数
if (!r.activity.mFinished) {
if (r.isPersistable()) {
if (r.state != null || r.persistentState != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
r.persistentState);
}
} else if (r.state != null) {
mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
}
}
//调用Activity的onPostCreate接口
if (!r.activity.mFinished) {
activity.mCalled = false;
if (r.isPersistable()) {
mInstrumentation.callActivityOnPostCreate(activity, r.state,
r.persistentState);
} else {
mInstrumentation.callActivityOnPostCreate(activity, r.state);
}
.............
}
r.paused = true;
//Activity保存到进程中
mActivities.put(r.token, r);
}
} catch (SuperNotCalledException e) {
.........
} catch (Exception e) {
..........
}
return activity;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
performLaunchActivity的功能比较直观，就是利用反射创建出目标Activity，然后设置Activity的内部变量，最后依次调用Activity生命周期中的接口，主要包括onCreate、onStart等。
1.2 handleResumeActivity
接下来，看看handleResumeActivity的工作：
final void handleResumeActivity(.......) {
ActivityClientRecord r = mActivities.get(token);
..............
//主要是调用目标Activity的onResume函数
r = performResumeActivity(token, clearHide, reason);
if (r != null) {
final Activity a = r.activity;
//为绘制做准备工作
..............
if (!r.activity.mFinished && willBeVisible
&& r.activity.mDecor != null && !r.hideForNow) {
//进行绘制相关的工作
.............
}
if (!r.onlyLocalRequest) {
//可以看出ActivityThread用Stack的方式，保存完成onResume的Activity
//r为刚刚完成onResume的新Activity，mNewActivities保存已经完成onResume的Activity
//新的Activity的nextIdle指向旧的
r.nextIdle = mNewActivities;
//然后将新建的Activity保存到mNewActivities中
mNewActivities = r;
...........
//向ActivityThread的MessageQueue中增加一个IdleHandler
Looper.myQueue().addIdleHandler(new Idler());
}
r.onlyLocalRequest = false;
// Tell the activity manager we have resumed.
if (reallyResume) {
try {
//通知AMS Activity进入Resume状态
//AMS会修改对应的存储信息
ActivityManagerNative.getDefault().activityResumed(token);
} catch (RemoteException ex) {
............
}
}
} else {
...........
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
从上面的代码可以看出，handleResumeActivity函数将会调用Activity的onResume接口，并进行绘制相关的操作，
然后向Activity的MessageQueue中增加一个IdleHandler，最终通知AMS更新Activity的状态。
在之前的博客Android7.0 MessageQueue 中，我们提到过当MessagQueue的next函数被调用时，如果队列中没有message需要处理，那么将调用添加到MessageQueue的IdleHandler的queueIdle接口。
handleResumeActivity函数向ActivityThread增加了一个IdleHandler，我们看看它的作用：
private class Idler implements MessageQueue.IdleHandler {
public final boolean queueIdle() {
ActivityClientRecord a = mNewActivities;
..................
if (a != null) {
mNewActivities = null;
IActivityManager am = ActivityManagerNative.getDefault();
ActivityClientRecord prev;
do {
............
if (a.activity != null && !a.activity.mFinished) {
try {
//调用AMS的activityIdle函数
am.activityIdle(a.token, a.createdConfig, stopProfiling);
a.createdConfig = null;
} catch (RemoteException ex) {
..............
}
//do-while循环将处理所有的已经完成onResume的Activity
prev = a;
a = a.nextIdle;
prev.nextIdle = null;
}
}while (a != null);
..........
}
.........
//返回值为false，于是执行一次后，会被移除
return false;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
从上面的代码可以看出，当ActivityThread空闲下来后，将为所有完成onResume的Activity调用AMS的activityIdle函数。
该函数是Activity成功创建并启动流程中的最后一步，我们稍后再分析。
至此，scheduleLaunchActivity函数分析完毕，我们看看realStartActivityLocked函数的下一个关键点minimalResumeActivityLocked。
2、minimalResumeActivityLocked
minimalResumeActivityLocked定义于ActivityStack中。ActivityStack是Activity所在Task中，保存ActivityRecord的数据结构。
我们看看minimalResumeActivityLocked的代码：
void minimalResumeActivityLocked(ActivityRecord r) {
r.state = ActivityState.RESUMED;
.............
mResumedActivity = r;
r.task.touchActiveTime();
//mRecentTasks保存近期被调用的Task
mRecentTasks.addLocked(r.task);
//更新一些状态
completeResumeLocked(r);
//判断AMS当前维护的Activity对应的进程是否可以sleep
//若可以sleep，将调用对应ApplicationThread的scheduleSleeping函数
mStackSupervisor.checkReadyForSleepLocked();
setLaunchTime(r);
............
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
上述代码中主要的工作由completeResumeLocked来完成：
/**
* Once we know that we have asked an application to put an activity in
* the resumed state (either by launching it or explicitly telling it),
* this function updates the rest of our state to match that fact.
*/
private void completeResumeLocked(ActivityRecord next) {
//更新ActivityRecord的变量
next.visible = true;
next.idle = false;
............
if (next.isHomeActivity()) {
//对Home Activity的特殊处理
..........
}
if (next.nowVisible) {
// We won't get a call to reportActivityVisibleLocked() so dismiss lockscreen now.
//如果已经visible将进行通知
mStackSupervisor.reportActivityVisibleLocked(next);
mStackSupervisor.notifyActivityDrawnForKeyguard();
}
// schedule an idle timeout in case the app doesn't do it for us.
//发送一个延迟消息IDLE_TIMEOUT_MSG，延迟时间为10s
//这里就是要求Activity启动后，10s内要调用AMS的activityIdle函数
//不过从代码来看，即使Activity 10s内没有调用activityIdle函数，
//ActivityStackSupervisor也会自己调用activityIdleInternalLocked函数
mStackSupervisor.scheduleIdleTimeoutLocked(next);
mStackSupervisor.reportResumedActivityLocked(next);
......................
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
从这部分代码，可以看出minimalResumeActivityLocked函数整体上就是负责更新一些状态，不用过于在意它的细节。
四、activityIdle函数
现在，我们看一下Activity启动的最后一步，即调用AMS的activityIdle函数：
public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) {
................
synchronized (this) {
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
//主要调用ActivityStackSupervisor的activityIdleInternalLocked函数
ActivityRecord r =
mStackSupervisor.activityIdleInternalLocked(token, false, config);
.................
}
}
..............
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
跟进activityIdleInternalLocked函数：
//ActivityThread在超时时间内，调用activityIdle时，fromTimeout的值为false
//如果超时后，由ActivityStackSupervisor主动调用该函数，fromTimeout的值为true
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
Configuration config) {
................
ActivityRecord r = ActivityRecord.forTokenLocked(token);
if (r != null) {
....................
mHandler.removeMessages(IDLE_TIMEOUT_MSG, r);
....................
if (fromTimeout) {
//超时时，将通知Activity完成启动
reportActivityLaunchedLocked(fromTimeout, r, -1, -1);
}
if (config != null) {
r.configuration = config;
}
r.idle = true;
................
}
//当所有Resumed Activity都处于空闲状态时
if (allResumedActivitiesIdle()) {
if (r != null) {
mService.scheduleAppGcsLocked();
}
//mLaunchingActivity是一个WakeLock，用于防止在操作Activity的过程中休眠
//由于该WakeLock不能长时间使用，因此系统设置了一个超时消息LAUNCH_TIMEOUT_MSG
//处理该消息时，将释放该WakeLock
//此处，当所有Activity均空闲时，说明事件处理完毕，此时需要释放该WakeLock
if (mLaunchingActivity.isHeld()) {
mHandler.removeMessages(LAUNCH_TIMEOUT_MSG);
...............
mLaunchingActivity.release();
}
ensureActivitiesVisibleLocked(null, 0, !PRESERVE_WINDOWS);
}
// Atomically retrieve all of the other things to do.
//processStoppingActivitiesLocked返回那些因本次Activity启动而被暂停(paused)的Activity
final ArrayList<ActivityRecord> stops = processStoppingActivitiesLocked(true);
NS = stops != null ? stops.size() : 0;
if ((NF = mFinishingActivities.size()) > 0) {
//finishes保存等待结束的Activity
finishes = new ArrayList<>(mFinishingActivities);
mFinishingActivities.clear();
}
.................
// Stop any activities that are scheduled to do so but have been
// waiting for the next one to start.
for (int i = 0; i < NS; i++) {
r = stops.get(i);
final ActivityStack stack = r.task.stack;
if (stack != null) {
if (r.finishing) {
//如果被暂停的Activity已经处于了finishing状态，则通知它们执行Destroy操作，即Activity的onDestroy函数将被调用
stack.finishCurrentActivityLocked(r, ActivityStack.FINISH_IMMEDIATELY, false);
} else {
//否则通知它们执行stop操作，即Activity的onStop将被调用
stack.stopActivityLocked(r);
}
}
}
// Finish any activities that are scheduled to do so but have been
// waiting for the next one to start.
// 处理等待结束的Activity，从代码来看最终也是调用其onDestroy接口
for (int i = 0; i < NF; i++) {
r = finishes.get(i);
final ActivityStack stack = r.task.stack;
if (stack != null) {
activityRemoved |= stack.destroyActivityLocked(r, true, "finish-idle");
}
}
................
//AMS清理没有任何组建的无用进程
mService.trimApplications();
if (activityRemoved) {
//如果等待结束的Activity被处理，保证前台栈顶Activity处于Resumed状态
resumeFocusedStackTopActivityLocked();
}
return r;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
至此，启动Activity最后一部分的主要工作介绍完毕。
从代码来看，这一部分最主要的工作是：
进行一些扫尾工作，即根据后台Activity是否处于finishing状态，分别调用其onStop和onDestroy接口。
同时，AMS也会清理一些无实际工作的进程。
最后需要补充的是：
我们利用am start -W启动Activity时，需要等待返回结果，详细代码可以参考启动Activity的过程：一。
在ActivityStarter的startActivityMayWait函数中：
final int startActivityMayWait(.........) {
.............
//outResult != null，说明启动命令发送成功
if (outResult != null) {
outResult.result = res;
if (res == ActivityManager.START_SUCCESS) {
mSupervisor.mWaitingActivityLaunched.add(outResult);
do {
try {
//等待Task移动到前台
mService.wait();
} catch (InterruptedException e) {
}
} while (outResult.result != START_TASK_TO_FRONT
&& !outResult.timeout && outResult.who == null);
if (outResult.result == START_TASK_TO_FRONT) {
res = START_TASK_TO_FRONT;
}
}
if (res == START_TASK_TO_FRONT) {
ActivityRecord r = stack.topRunningActivityLocked();
if (r.nowVisible && r.state == RESUMED) {
outResult.timeout = false;
outResult.who = new ComponentName(r.info.packageName, r.info.name);
outResult.totalTime = 0;
outResult.thisTime = 0;
} else {
outResult.thisTime = SystemClock.uptimeMillis();
mSupervisor.mWaitingActivityVisible.add(outResult);
do {
try {
//等待Activity可见
mService.wait();
} catch (InterruptedException e) {
}
} while (!outResult.timeout && outResult.who == null);
}
}
}
..................
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
上面代码中，startActivityMayWait等待的信号均由ActivityStackSupervisor触发。
在启动Activity的过程：一中简单提到过，在startActivityLocked函数的最后，调用了postStartActivityUncheckedProcessing函数进行通知：
void postStartActivityUncheckedProcessing(......) {
.............
// We're waiting for an activity launch to finish, but that activity simply
// brought another activity to front. Let startActivityMayWait() know about
// this, so it waits for the new activity to become visible instead.
if (result == START_TASK_TO_FRONT && !mSupervisor.mWaitingActivityLaunched.isEmpty()) {
mSupervisor.reportTaskToFrontNoLaunch(mStartActivity);
}
............
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
我们看ActivityStackSupervisor的reportTaskToFrontNoLaunch函数：
void reportTaskToFrontNoLaunch(ActivityRecord r) {
boolean changed = false;
for (int i = mWaitingActivityLaunched.size() - 1; i >= 0; i--) {
WaitResult w = mWaitingActivityLaunched.remove(i);
//who表示componentName，Activity未可见前为null
if (w.who == null) {
changed = true;
// Set result to START_TASK_TO_FRONT so that startActivityMayWait() knows that
// the starting activity ends up moving another activity to front, and it should
// wait for this new activity to become visible instead.
// Do not modify other fields.
w.result = START_TASK_TO_FRONT;
}
}
if (changed) {
//notifyAll通知ActivityStarter待启动Activity对应的Task移动到了前台
mService.notifyAll();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
同样，当Activity可见时，WindowManagerService将回调ActivityRecord中的windowsVisible函数：
public void windowsVisible() {
synchronized (mService) {
ActivityRecord r = tokenToActivityRecordLocked(this);
if (r != null) {
r.windowsVisibleLocked();
}
}
}
void windowsVisibleLocked() {
mStackSupervisor.reportActivityVisibleLocked(this);
...........
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
跟进一下ActivityStackSupervisor的reportActivityVisibleLocked函数：
void reportActivityVisibleLocked(ActivityRecord r) {
sendWaitingVisibleReportLocked(r);
}
void sendWaitingVisibleReportLocked(ActivityRecord r) {
boolean changed = false;
for (int i = mWaitingActivityVisible.size()-1; i >= 0; i--) {
WaitResult w = mWaitingActivityVisible.get(i);
if (w.who == null) {
changed = true;
w.timeout = false;
if (r != null) {
//构造出ComponentName等信息
w.who = new ComponentName(r.info.packageName, r.info.name);
}
w.totalTime = SystemClock.uptimeMillis() - w.thisTime;
w.thisTime = w.totalTime;
}
}
if (changed) {
//notifyAll通知ActivityStarter待启动Activity可见
mService.notifyAll();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
五、总结
大图地址
至此，AMS启动Activity的后一部分基本介绍完毕。
这一部分的代码整体流程如上图所示，我们省略一些细节，例如绘制等。
从整个逻辑来看，这部分流程比较清晰，主要思想如下：
1、启动进程，创建自己的ActivityThread和ApplicationThread。
2、进程与AMS通信，其实就是完成一个注册过程（将ApplicationThread作为Binder通信接口交给AMS保存），AMS毕竟要统一管理系统中所有的应用进程。
3、AMS通知进程创建自己的Android运行环境，加入到Android体系。
4、AMS通知进程可以启动进程中的组件了，注意四大组件的顺序以此是ContentProvider、Activity、Service、BroadcastReceiver（参考上述代码，可以容易看出这个结论，本文我们仅分析了Activity的启动过程）。
5、Activity启动完成后，通知AMS更新相关的状态，并进行一些扫尾工作。
整体而言，所有的实际工作都是由进程自己完成的，AMS仅起到一个管理的作用。