page1
我们开始分析一下Activity的Window和WindowManager的创建过程, 在Activity的attach函数中, 不仅会创建Context, 还会创建Window和WindowsManager对象.因此我们就从Activity的attach函数开始分析:
1 final void attach(Context context, ActivityThread aThread,
2 Instrumentation instr, IBinder token, int ident,
3 Application application, Intent intent, ActivityInfo info,
4 CharSequence title, Activity parent, String id,
5 NonConfigurationInstances lastNonConfigurationInstances,
6 Configuration config) {
7 attachBaseContext(context);
8
9 mFragments.attachActivity(this, mContainer, null);
10
11 mWindow = PolicyManager.makeNewWindow(this);
12 mWindow.setCallback(this);
13 mWindow.getLayoutInflater().setPrivateFactory(this);
14 if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {
15 mWindow.setSoftInputMode(info.softInputMode);
16 }
17 if (info.uiOptions != 0) {
18 mWindow.setUiOptions(info.uiOptions);
19 }
20 mUiThread = Thread.currentThread();
21
22 mMainThread = aThread;
23 mInstrumentation = instr;
24 mToken = token;
25 mIdent = ident;
26 mApplication = application;
27 mIntent = intent;
28 mComponent = intent.getComponent();
29 mActivityInfo = info;
30 mTitle = title;
31 mParent = parent;
32 mEmbeddedID = id;
33 mLastNonConfigurationInstances = lastNonConfigurationInstances;
34
35 mWindow.setWindowManager(
36 (WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
37 mToken, mComponent.flattenToString(),
38 (info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
39 if (mParent != null) {
40 mWindow.setContainer(mParent.getWindow());
41 }
42 mWindowManager = mWindow.getWindowManager();
43 mCurrentConfig = config;
44 }
第11行(Activity->attach)会调用PolicyManager的makeNewWindow函数来为这个Activity创建一个Window, 关于PolicyManager的makeNewWindow函数的详细分析可以参考page2文件.
private Window mWindow;
第12行(Activity->attach)会将mWindow的callback设置成当前activity, 这样mWindow就能将一些事件交给acticity去执行
第13-19行(Activity->attach)会设置Window的一些属性, 我们先不关心.
第35-38行(Activity->attach)会调用Window的setWindowManager函数, setWindowManager函数详细分析可以参考page6文件.
第39-41行(Activity->attach)会判断该Activity的mParent是否不为空, 如果不为空则会为Window的setContainer来设置成mParent的Window. 关于setContainer函数的详细分析可以参考page11文件.
第42行(Activity->attach)会调用Window的getWindowManager来得到WindowManager, 这样每一个Activity实例都会拿着一个WindowManager对象了.
page2
PolicyManager的makeNewWindow函数的定义如下:
public static Window makeNewWindow(Context context) {
return sPolicy.makeNewWindow(context);
}
PolicyManager的makeNewWindow函数只是简单地调用静态成员变量sPolicy的makeNewWindow函数, sPolicy的定义和初始化如下:
private static final String POLICY_IMPL_CLASS_NAME =
"com.android.internal.policy.impl.Policy";
private static final IPolicy sPolicy;
static {
// Pull in the actual implementation of the policy at run-time
try {
Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME);
sPolicy = (IPolicy)policyClass.newInstance();
} catch (ClassNotFoundException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be loaded", ex);
} catch (InstantiationException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);
} catch (IllegalAccessException ex) {
throw new RuntimeException(
POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);
}
}
可以看到sPolicy其实是加载的com.android.internal.policy.impl.Policy类, 为什么要动态的加载类呢? 为什么不直接初始化一个Policy类呢? 这难道就是策略模式???????
因此我们看一下com.android.internal.policy.impl.Policy的makeNewWindow函数的实现:
public Window makeNewWindow(Context context) {
return new PhoneWindow(context);
}
只是new了一个PhoneWindow, 并返回．关于PhoneWindow的构造过程可以参考page3文件.
page3
在这里我们看一下PolicyManager的创建过程, 我们先来看一下PolicyManager类的继承体系:
public class PhoneWindow extends Window implements MenuBuilder.Callback
public abstract class Window
PhoneWindow的构造函数如下:
1 public PhoneWindow(Context context) {
2 super(context);
3 mLayoutInflater = LayoutInflater.from(context);
4 }
第2行(PhoneWindow->PhoneWindow)会调用父类的构造函数, Window类的构造函数如下:
public Window(Context context) {
mContext = context;
}
Window类的构造函数除了初始化mContext之外, 什么也没干. 这样就说明, Window会拿着一个Context实例.
第3行(PhoneWindow->PhoneWindow)会调用LayoutInflater的from函数来获得一个LayoutInflater对象并初始化成员变量mLayoutInflater. 关于LayoutInflater的from函数的详细分析可以参考page4文件.
page4
这里我们分析一下LayoutInflater的创建过程, 也就是LayoutInflater的from函数的调用过程:
1 public static LayoutInflater from(Context context) {
2 LayoutInflater LayoutInflater =
3 (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
4 if (LayoutInflater == null) {
5 throw new AssertionError("LayoutInflater not found.");
6 }
7 return LayoutInflater;
8 }
第2-3行(LayoutInflater->from)会调用Context的getSystemService来得到一个LAYOUT_INFLATER_SERVICE服务, 哦!!!解析layout是作为一个服务存在的啊, 那就是Binder喽!
这里Context其实是个Activity对象, 因此这里其实会调用Activity的getSystemService函数, Activity的getSystemService函数的定义如下:
1 public Object getSystemService(String name) {
2 if (getBaseContext() == null) {
3 throw new IllegalStateException(
4 "System services not available to Activities before onCreate()");
5 }
6
7 if (WINDOW_SERVICE.equals(name)) {
8 return mWindowManager;
9 } else if (SEARCH_SERVICE.equals(name)) {
10 ensureSearchManager();
11 return mSearchManager;
12 }
13 return super.getSystemService(name);
14 }
第13行(Activity->getSystemService)会调用父类ContextThemeWrapper类的getSystemService函数, ContextThemeWrapper类的getSystemService函数的定义如下:
1 @Override public Object getSystemService(String name) {
2 if (LAYOUT_INFLATER_SERVICE.equals(name)) {
3 if (mInflater == null) {
4 mInflater = LayoutInflater.from(mBase).cloneInContext(this);
5 }
6 return mInflater;
7 }
8 return mBase.getSystemService(name);
9 }
第2-7行(ContextThemeWrapper->getSystemService)又会调用LayoutInflater.from(mBase), 我靠, 这不死循环了么? 注意啊, 这是mBase, mBase其实是个ContextImpl类型的, 因此这里会调用ContextImpl的
getSystemService函数, 关于ContextImpl的getSystemService函数的详细分析可以参考page5文件.