page5
在这篇文章中, 我们分析一下ContextImpl的getSystemService函数,
1 public Object getSystemService(String name) {
2 ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);
3 return fetcher == null ? null : fetcher.getService(this);
4 }
第2行(ContextImpl->getSystemService)SYSTEM_SERVICE_MAP的定义如下:
private static final HashMap<String, ServiceFetcher> SYSTEM_SERVICE_MAP = new HashMap<String, ServiceFetcher>();
在ContextImpl加载过程中, 会初始化SYSTEM_SERVICE_MAP, 我们这里只关心LAYOUT_INFLATER_SERVICE服务, 相关代码如下:
static {
............
registerService(LAYOUT_INFLATER_SERVICE, new ServiceFetcher() {
public Object createService(ContextImpl ctx) {
return PolicyManager.makeNewLayoutInflater(ctx.getOuterContext());
}});
............
}
ContextImpl类的registerService函数的定义如下:
1 private static int sNextPerContextServiceCacheIndex = 0;
2 private static void registerService(String serviceName, ServiceFetcher fetcher) {
3 if (!(fetcher instanceof StaticServiceFetcher)) {
4 fetcher.mContextCacheIndex = sNextPerContextServiceCacheIndex++;
5 }
6 SYSTEM_SERVICE_MAP.put(serviceName, fetcher);
7 }
registerService函数很好理解吧.
我们回到getSystemService的第3行(ContextImpl->getSystemService), 这里会调用ServiceFetcher的getService函数, ServiceFetcher是ContextImpl的一个内部类, ServiceFetcher的getService函数定义如下:
1 public Object getService(ContextImpl ctx) {
2 ArrayList<Object> cache = ctx.mServiceCache;
3 Object service;
4 synchronized (cache) {
5 if (cache.size() == 0) {
6 // Initialize the cache vector on first access.
7 // At this point sNextPerContextServiceCacheIndex
8 // is the number of potential services that are
9 // cached per-Context.
10 for (int i = 0; i < sNextPerContextServiceCacheIndex; i++) {
11 cache.add(null);
12 }
13 } else {
14 service = cache.get(mContextCacheIndex);
15 if (service != null) {
16 return service;
17 }
18 }
19 service = createService(ctx);
20 cache.set(mContextCacheIndex, service);
21 return service;
22 }
23 }
第5-18行(ServiceFetcher->getService)会尝试在cache里取.
第19行(ServiceFetcher->getService)会调用createService函数, 来创建一个Service.
其实这里调用的是这句
return PolicyManager.makeNewLayoutInflater(ctx.getOuterContext());
我靠, 来看一看PolicyManager的makeNewLayoutInflater函数的实现吧:
public static LayoutInflater makeNewLayoutInflater(Context context) {
return sPolicy.makeNewLayoutInflater(context);
}
还记得这逻辑么?这会导致com.android.internal.policy.impl.Policy的makeNewLayoutInflater函数的调用, 定义如下:
public LayoutInflater makeNewLayoutInflater(Context context) {
return new PhoneLayoutInflater(context);
}
FUCK, 绕了这么大一圈, 最后还是会new一个PhoneLayoutInflater对象, 因此, 我们就知道了Window所拥有的其实是个PhoneLayoutInflater对象.
第20行(ServiceFetcher->getService)会将刚创建的Service设置到cache中去.
page6
在这篇文章里, 我们分析一下Window的setWindowManager函数的实现, 在这个函数里会为该Window创建一个WindowManager.
Window的setWindowManager函数的定义如下:
1 public void setWindowManager(WindowManager wm, IBinder appToken, String appName,
2 boolean hardwareAccelerated) {
3 mAppToken = appToken;
4 mAppName = appName;
5 mHardwareAccelerated = hardwareAccelerated
6 || SystemProperties.getBoolean(PROPERTY_HARDWARE_UI, false);
7 if (wm == null) {
8 wm = (WindowManager)mContext.getSystemService(Context.WINDOW_SERVICE);
9 }
10 mWindowManager = ((WindowManagerImpl)wm).createLocalWindowManager(this);
11 }
第3行(Window->setWindowManager)会保存activity的token
第4行(Window->setWindowManager)会保存appName
第5-6行(Window->setWindowManager)判断是否需要硬件加速, 判断是否的条件是否用户显示启动该选项或者系统支持
第7-9行(Window->setWindowManager)会通过mContext来获得WINDOW_SERVICE服务, 详细分析可以参考page7文件.
第10行(Window->setWindowManager)会调用WindowManagerImpl的createLocalWindowManager函数来得到一个WindowManagerImpl对象, 并用该对象初始化成员变量mWindowManager.createLocalWindowManager函数的定义如下:
public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
return new WindowManagerImpl(mDisplay, parentWindow);
}
createLocalWindowManager函数只不过又创建了一个WindowManagerImpl对象, 只不过该对象有parentWindow而已.
page7
这里我们分析一下ContextImpl的WINDOW_SERVICE服务的获取过程, 而这是通过调用getSystemService函数来得到的,
getSystemService函数的实现逻辑其实我们已经分析过了, 其实最后会执行到这里:
1 registerService(WINDOW_SERVICE, new ServiceFetcher() {
2 public Object getService(ContextImpl ctx) {
3 Display display = ctx.mDisplay;
4 if (display == null) {
5 DisplayManager dm = (DisplayManager)ctx.getOuterContext().getSystemService(
6 Context.DISPLAY_SERVICE);
7 display = dm.getDisplay(Display.DEFAULT_DISPLAY);
8 }
9 return new WindowManagerImpl(display);
10 }});
是不是很熟悉.
第5-6行(ContextImpl->registerService)又通过调用getSystemService函数来获得DISPLAY_SERVICE服务, 别说了, 看下面的代码:
registerService(DISPLAY_SERVICE, new ServiceFetcher() {
@Override
public Object createService(ContextImpl ctx) {
return new DisplayManager(ctx.getOuterContext());
}});
会new一个DisplayManager, 关于DisplayManager的构造过程可以参考page8文件.
第7行(ContextImpl->registerService)会调用DisplayManager的getDisplay函数, 关于getDisplay函数的详细分析可以参考page9文件.
第9行(ContextImpl->registerService)会用刚刚得到的Display对象new一个WindowManagerImpl, 并返回. WindowManagerImpl函数的构造函数如下所示:
public WindowManagerImpl(Display display) {
this(display, null);
}
private WindowManagerImpl(Display display, Window parentWindow) {
mDisplay = display;
mParentWindow = parentWindow;
}
page8
这里我们看一下DisplayManager的构造过程, DisplayManager的构造函数如下:
1 public DisplayManager(Context context) {
2 mContext = context;
3 mGlobal = DisplayManagerGlobal.getInstance();
4 }
第2行(DisplayManager->DisplayManager)会保存Context
第3行(DisplayManager->DisplayManager)会调用DisplayManagerGlobal.getInstance()函数来获得DisplayManagerGlobal实例, DisplayManagerGlobal的getInstance函数的定义如下:
1 public static DisplayManagerGlobal getInstance() {
2 synchronized (DisplayManagerGlobal.class) {
3 if (sInstance == null) {
4 IBinder b = ServiceManager.getService(Context.DISPLAY_SERVICE);
5 if (b != null) {
6 sInstance = new DisplayManagerGlobal(IDisplayManager.Stub.asInterface(b));
7 }
8 }
9 return sInstance;
10 }
11 }
从getInstance函数的定义可以知道, getInstance主要逻辑就是通过ServiceManager得到DISPLAY_SERVICE服务, 这是Binder相关的. 获得DISPLAY_SERVICE服务之后会用这个服务来创建一个DisplayManagerGlobal对象,
DisplayManagerGlobal的构造函数的定义如下:
private DisplayManagerGlobal(IDisplayManager dm) {
mDm = dm;
}
Activity的Window和WindowManager的创建过程(二)
猜你喜欢
转载自zzu-007.iteye.com/blog/2382853
今日推荐
周排行