在看ActivityThread
源码的时候,看到有博客提到它承担着整个应用的运转以及生命周期。于是很好奇想一探究竟,跟着跟着大概就把应用启动过程过程了解了一下。这篇文章主要是介绍ActivityThread
中有关于应用启动过程以及Activity
启动部分。有关Binder的机制或者其他部分内容太多了,以后专门看看。
Activity有且只有一个ActivityThread
对象,他是每一个应用程序所在进程的主线程,。先看看主入口方法main
,整个应用的loop死循环是从这边启动的。贴上代码:
public static void main(String[] args) {
...
ActivityThread thread = new ActivityThread();
thread.attach(false);
...
Looper.loop();
throw new RuntimeException("Main thread loop unexpectedly exited");
}
第一部分是ActivityThread
对象执行attach方法。这个是本文要分析的部分,就是他来启动应用。
第二部分是启动Looper,这个是整个应用程序的心脏。下一篇文章将分析。
OK!先跟进attach方法看下。贴上代码:
private void attach(boolean system) {
if (!system) {
final IActivityManager mgr = ActivityManagerNative.getDefault();
try {
mgr.attachApplication(mAppThread);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
} else {
...
}
...
}
传入system
值为false,那么这里会进入判断为true的代码块里面。其中attachApplication
是启动Application的方法,也是作为本文分析流程的入口。
1、ActivityThread
把mAppThread
对象传给AMS
上面介绍到了attachApplication
方法,那么接下来看下mAppThread
怎么传给AMS的。贴上时序图:
可以看到Activity通过ActivityManagerProxy
代理来和AMS通信的。
那么先看下ActivityManagerNative.getDefault()
是怎么获取对象的。先进入ActivityManagerNative
的getDefault
方法,贴上代码:
/**
* Retrieve the system's default/global activity manager.
*/
static public IActivityManager getDefault() {
return gDefault.get();
}
注意到是gDefault
对象的方法,跟进去:
private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
protected IActivityManager create() {
IBinder b = ServiceManager.getService("activity");
if (false) {
Log.v("ActivityManager", "default service binder = " + b);
}
IActivityManager am = asInterface(b);
if (false) {
Log.v("ActivityManager", "default service = " + am);
}
return am;
}
};
public abstract class Singleton<T> {
private T mInstance;
protected abstract T create();
public final T get() {
synchronized (this) {
if (mInstance == null) {
mInstance = create();
}
return mInstance;
}
}
}
首先Singleton是一个获取单例对象的方法。首次调用get()方法就会执行create(),那么回到gDefault
对象的create()方法看看。
首先是ServiceManager.getService("activity")
。跟进ServiceManager
类源码看一下:
private static IServiceManager getIServiceManager() {
if (sServiceManager != null) {
return sServiceManager;
} // Find the service manager
sServiceManager = ServiceManagerNative.asInterface(BinderInternal.getContextObject());
return sServiceManager;
}
/**
* Returns a reference to a service with the given name.
*
* @param name the name of the service to get
* @return a reference to the service, or <code>null</code> if the service doesn't exist
*/
public static IBinder getService(String name) {
try {
IBinder service = sCache.get(name);
if (service != null) {
return service;
} else {
return getIServiceManager().getService(name);
}
} catch (RemoteException e) {
Log.e(TAG, "error in getService", e);
}
return null;
}
先看下getIServiceManager()
方法,他返回的sServiceManager
对象(ServiceManagerService
的代理)。ServiceManagerService
不是真实存在的,而是存在于C++层的一个单独的进程。
那么getService
就是通过代理获取String为activity
的服务的IBinder
对象,其实也就是AMS的IBinder
对象。
现在回到gDefault
方法中。看下asInterface(b)
方法,其中b也就是上面从ServiceManagerService
获取的IBinder
对象。
现在看下asInterface
方法,贴上代码:
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);
}
queryLocalInterface
方法用于检查obj是否位于本地进程,很明显前面获取AMS的IBinder
对象位于另一个进程。那么asInterface
返回的就是new出来的ActivityManagerProxy
对象了。
到这一步返回到上面的getDefault()
方法,可以知道他实际上返回的是AMS的ActivityManagerProxy
代理对象。也就是说attach方法中的mgr对象其实也就是AMS的代理了。
那么看下attach方法中的mgr.attachApplication(mAppThread)
,也就是通过代理把mAppThread
参数传给了AMS。
那到底是传什么东西呢?
看看ActivityManagerProxy
源码:
class ActivityManagerProxy implements IActivityManager
{
...
public void attachApplication(IApplicationThread app) throws RemoteException
{
Parcel data = Parcel.obtain();
Parcel reply = Parcel.o