最近在看維術的Android插件化原理解析萄喳，需要補充一些Framework層的知識，首先來研究Activity的啟動過程猾愿。
Activity的啟動從Activity類中startActivity方法(先看Actiivty中的充择，后面再看Context中的，本質是一樣的)開始匪蟀。跟著這個方法一步一步跟蹤，會發(fā)現(xiàn)它最后在startActivityForResult里面調用了Instrument對象的execStartActivity方法宰僧；
Instrumentation類中的execStartActivity方法材彪，源碼如下：
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
IApplicationThread whoThread = (IApplicationThread) contextThread;
......
......
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess();
int result = ActivityManagerNative.getDefault()
.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) {
}
return null;
}
發(fā)現(xiàn)最終調用的是ActivityManagerNative類中的startActivity方法。ActivityManagerNative指的是Binder本地對象琴儿，這個類是抽象類段化，它的實現(xiàn)是ActivityManagerService；因此對于AMS的最終操作都會進入ActivityManagerService這個真正實現(xiàn)造成，接著調用startActivityAsUser方法显熏，最終調用ActivityStackSupervisor類中的startActivityMayWait方法，ActivityStackSupervisor這個類低版本沒有晒屎，在startActivityMayWait中調用startActivityLocked之后處理的都是Activity任務棧相關內容喘蟆，這一系列ActivityStack和ActivityStackSupervisor糾纏不清的調用看下圖就明白了；
ActivityStack類中的resumeTopActivityLocked方法中調用ActivityStack中的resumeTopActivityInnerLocked鼓鲁，然后在改方法中調用ActivityStackSupervisor類中的startSpecificActivityLocked方法:
void startSpecificActivityLocked(ActivityRecord r,
boolean andResume, boolean checkConfig) {
// Is this activity's application already running?
ProcessRecord app = mService.getProcessRecordLocked(r.processName,
r.info.applicationInfo.uid, true);
r.task.stack.setLaunchTime(r);
//如果App已經(jīng)運行了蕴轨，直接創(chuàng)建Activity
if (app != null && app.thread != null) {
try {
if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
|| !"android".equals(r.info.packageName)) {
// Don't add this if it is a platform component that is marked
// to run in multiple processes, because this is actually
// part of the framework so doesn't make sense to track as a
// separate apk in the process.
app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode,
mService.mProcessStats);
}
//真正啟動Activity
realStartActivityLocked(r, app, andResume, checkConfig);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Exception when starting activity "
+ r.intent.getComponent().flattenToShortString(), e);
}
// If a dead object exception was thrown -- fall through to
// restart the application.
}
//如果App還沒有運行，創(chuàng)建ActivityThread的進程骇吭，然后創(chuàng)建Activity
mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
"activity", r.intent.getComponent(), false, false, true);
//走到這里會先創(chuàng)建ActivityThread的進程橙弱，在ActivityThread的main方法中調用attach方法，
//接著調用AMS的attachApplication方法，接著調用AMS的attachApplicationLocked棘脐，
//接著調用ActivityStackSupervisor的attachApplicationLocked斜筐，
//接著調用realStartActivityLocked方法創(chuàng)建Activity
}
接著在改方法中調用realStartActivityLocked，人如其名蛀缝，這個方法開始了真正的“啟動Activity”：它調用了ApplicationThread的scheduleLaunchActivity方法顷链，開始了真正的Activity對象創(chuàng)建以及啟動過程。
ApplicationThread是ActivityThread中定義的內部類内斯，繼承ApplicationThreadNative(ApplicationThreadNative extends Binder implements IApplicationThread )蕴潦，ApplicationThread實際上是一個Binder對象，是App所在的進程與AMS所在進程system_server通信的橋梁俘闯。
這里的scheduleLaunchActivity方法直接把啟動Activity的任務通過一個消息轉發(fā)給了主線程潭苞；我們查看Handler類對于這個消息的處理：
case LAUNCH_ACTIVITY: {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null);
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
可以看到，這里直接調用了ActivityThread的handleLaunchActivity方法真朗，在這個方法內部有一句非常重要：
Activity a = performLaunchActivity(r, customIntent);
繞了這么多彎此疹，我們的Activity終于被創(chuàng)建出來了！這個方法做了兩件很重要的事情：
使用ClassLoader加載并通過反射創(chuàng)建Activity對象：
java.lang.ClassLoader cl = r.packageInfo.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);
}
如果Application還沒有創(chuàng)建遮婶，那么創(chuàng)建Application對象并回調相應的生命周期方法蝗碎；
Application app = r.packageInfo.makeApplication(false, mInstrumentation);
Activity的啟動過程到這里就結束了，這里調用了一系列方法旗扑，大多數(shù)方法我也不知道是干嘛的蹦骑，留待以后研究，畢竟代碼邏輯還是很復雜的臀防。
