本文从源码角度详细剖析了Android APK的启动过程，包括ActivityThread的main()函数、Binder线程的创建、Activity的创建以及与AMS的交互。重点介绍了Activity的启动流程，从startActivity到Activity的onCreate()、onResume()，揭示了界面绘制的过程，涉及到ViewRootImpl、DecorView和WindowManager的角色。整个过程展示了Android系统的Binder机制和消息处理流程。
APK程序的运行过程
首先，ActivityThread从main()函数中开始执行，调用prepareMainLooper()为UI线程创建一个消息队列(MessageQueue)。
public static void main(String[] args) {
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
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);
Environment.initForCurrentUser();
// Set the reporter for event logging in libcore
EventLogger.setReporter(new EventLoggingReporter());
AndroidKeyStoreProvider.install();
// Make sure TrustedCertificateStore looks in the right place for CA certificates
final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
TrustedCertificateStore.setDefaultUserDirectory(configDir);
Process.setArgV0("<pre-initialized>");
Looper.prepareMainLooper();
ActivityThread thread = new ActivityThread();
//我们在这里发现这个方法 我们看下源码
thread.attach(false);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
if (false) {
Looper.myLooper().setMessageLogging(new
LogPrinter(Log.DEBUG, "ActivityThread"));
}
// End of event ActivityThreadMain.
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
}attach的源码 它便会创建一个Binder线程（具体是指ApplicationThread，Binder的服务端，用于接收系统服务AMS发送来的事件），该Binder线程通过Handler将Message发送给主线程，具体过程可查看 startService流程分析 这里不细说，具体可以了解了解binder机制
private void attach(boolean system) {
sCurrentActivityThread = this;
mSystemThread = system;
if (!system) {
ViewRootImpl.addFirstDrawHandler(new Runnable() {
@Override
public void run() {
ensureJitEnabled();
}
});
android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
UserHandle.myUserId());
RuntimeInit.setApplicationObject(mAppThread.asBinder());
final IActivityManager mgr = ActivityManagerNative.getDefault();
try {
mgr.attachApplication(mAppThread);
} catch (RemoteException ex) {
// Ignore
}
// Watch for getting close to heap limit.
BinderInternal.addGcWatcher(new Runnable() {
@Override 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)) {
if (DEBUG_MEMORY_TRIM) Slog.d(TAG, "Dalvik max=" + (dalvikMax/1024)
+ " total=" + (runtime.totalMemory()/1024)
+ " used=" + (dalvikUsed/1024));
mSomeActivitiesChanged = false;
try {
mgr.releaseSomeActivities(mAppThread);
} catch (RemoteException e) {
}
}
}
});
} else {
// Don't set application object here -- if the system crashes,
// we can't display an alert, we just want to die die die.
android.ddm.DdmHandleAppName.setAppName("system_process",
UserHandle.myUserId());
try {
mInstrumentation = new Instrumentation();
ContextImpl context = ContextImpl.createAppContext(
this, getSystemContext().mPackageInfo);
mInitialApplication = context.mPackageInfo.makeApplication(true, null);
mInitialApplication.onCreate();
} catch (Exception e) {
throw new RuntimeException(
"Unable to instantiate Application():" + e.toString(), e);
}
}
// add dropbox logging to libcore
DropBox.setReporter(new DropBoxReporter());
ViewRootImpl.addConfigCallback(new ComponentCallbacks2() {
@Override
public void onConfigurationChanged(Configuration newConfig) {
synchronized (mResourcesManager) {
// We need to apply this change to the resources
// immediately, because upon returning the view
// hierarchy will be informed about it.
if (mResourcesManager.applyConfigurationToResourcesLocked(newConfig, null)) {
// This actually changed the resources! Tell
// everyone about it.
if (mPendingConfiguration == null ||
mPendingConfiguration.isOtherSeqNewer(newConfig)) {
mPendingConfiguration = newConfig;
sendMessage(H.CONFIGURATION_CHANGED, newConfig);
}
}
}
}
@Override
public void onLowMemory() {
}
@Override
public void onTrimMemory(int level) {
}
});
}里面发现一个特别重要的类
ViewRootImpl可能大家对它不是很陌生，乍以为他是一个view，熟悉后发现他其实是一个继承于handler的类，这个类是作为native层和view层系统或者说fromwork层通信的桥梁，我们的setcontentview中调用的n多方法，就是在它的消息川底下开始绘制和布局view的 这个ViewRootImpl我们留下去凡汐他，继续回归正题看
然后创建一个ActivityThread对象，在ActivityThread的初始化代码中会创建一个H（Handler）对象和一个ApplicationThread（Binder）对象。其中Binder负责接收远程AmS的IPC调用，接收到调用后，则通过Handler把消息发送到消息队列，UI主线程会异步地从消息队列中取出消息并执行相应操作，比如start、stop、pause等。
我们来看源码
public final class ActivityThread {
...
final ApplicationThread mAppThread = new ApplicationThread();
final Looper mLooper = Looper.myLooper();
final H mH = new H();
...
接着UI主线程调用Looper.loop()方法进入消息循环体，进入后就会不断地从消息队列中读取并处理消息。
当ActivityThread接收到AmS发送start某个Activity后，就会创建指定的Activity对象。那我们来看看startAvtitity到底干了些什么事
经过几层调用后发现 源码都在Activity.java这个类 都是几个不同参的startactivit互相调用，他们最后都会调用到这里
@Override
public void startActivity(Intent intent) {
this.startActivity(intent, null);
}
@Override
public void startActivity(Intent intent, @Nullable Bundle options) {
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);
}
}那么我们来看这个-1的作用 先来看看startActrivityForResult的源码
public void startActivityForResult(Intent intent, int requestCode, @Nullable Bundle options) {
if (mParent == null) {
Instrumentation.ActivityResult ar =
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
//...此处省略一万行代码2333这里面一个重要的方法就是
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
我们来看看他到底搞什么幺蛾子
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, String target,
Intent intent, int requestCode, Bundle options) {
IApplicationThread whoThread = (IApplicationThread) contextThread;
if (mActivityMonitors != null) {
synchronized (mSync) {
final int N = mActivityMonitors.size();
for (int i=0; i<N; i++) {
final ActivityMonitor am = mActivityMonitors.get(i);
if (am.match(who, null, intent)) {
am.mHits++;
if (am.isBlocking()) {
return requestCode >= 0 ? am.getResult() : null;
}
break;
}
}
}
}
try {
intent.migrateExtraStreamToClipData();
intent.prepareToLeaveProcess();
//重点在这里 ahhhh 那么这个ActivityManagerNative.getDefault()是个什么鬼，我们在下面说
int result = ActivityManagerNative.getDefault()
.startActivity(whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target, requestCode, 0, null, options);
checkStartActivityResult(result, intent);
} catch (RemoteException e) {
throw new RuntimeException("Failure from system", e);
}
return null;
}public abstract class ActivityManagerNative extends Binder implements IActivityManager
{
/**
* Cast a Binder object into an activity manager interface, generating
* a proxy if needed.
*/
static public IActivityManager asInterface(IBinder obj) {
if (obj == null) {
return null;
}
IActivityManager in =
(IActivityManager)obj.queryLocalInterface(descriptor);
if (in != null) {
return in;
}
return new ActivityManagerProxy(obj);
}
/**
* Retrieve the system's default/global activity manager.
*/
static public IActivityManager getDefault() {
return gDefault.get();
}
我们发现getdefault会返回一个IActivityManager对象
其实这个返回的是ActivityManagerProxy的实例，
它只是一个代理类，这个代理类实际上代理的是
IBinder b = ServiceManager.getService("activity")这个Service。
public interface IActivityManager extends IInterface {
public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
String resolvedType, IBinder resultTo, String resultWho, int requestCode, int flags,
ProfilerInfo profilerInfo, Bundle options) throws RemoteException;注册的系统服务 我们发现实现的这个IInterface会回调一个IBinder类型的变量，说明系统内部通信实际上也是使用的binder机制 那么初始化或者说注册这个AMS后要怎么呢 我们来看看看看大概流程，到最后instrumention ->new activity()初始化activity，初始化conteximpl 通过activity的attache方法回调onCreate（） oncreate方法调用setContentView addView和初始化decorView和各种ViewGroup和View同时activityThread handleResumeActivity 调用acytivity的onresume使用profomeMersure和profomeDraw完成界面绘制；
大概绘制流程是这样 我们在下篇博客讲
Activity又会创建PhoneWindow类→DecorView类→创建相应的View或者ViewGroup。创建完成后，Activity需要把创建好的界面显示到屏幕上，于是调用WindowManager类，后者于是创建一个ViewRoot对象，该对象实际上创建了ViewRoot类和W类，创建ViewRoot对象后，WindowManager再调用WmS提供的远程接口完成添加一个窗口并显示到屏幕上。
接下来，用户开始在程序界面上操作。KeyQ线程不断把用户消息存储到QueueEvent队列中，InputDispatcherThread线程逐个取出消息，然后调用WmS中的相应函数处理该消息。当WmS发现该消息属于客户端某个窗口时，就会调用相应窗口的W接口。
W类是一个Binder，负责接收WmS的IPC调用，并把调用消息传递给ViewRoot，ViewRoot再把消息传递给UI主线程ActivityThread，ActivityThread解析该消息并做相应的处理。在客户端程序中，首先处理消息的是DecorView，如果DecorView不想处理某个消息，则可以将该消息传递给其内部包含的子View或者ViewGroup，如果还没有处理，则传递给PhoneWindow，最后再传递给Activity。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
