Activity的Window和WindowManager的创建过程(二)

阅读更多
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 SYSTEM_SERVICE_MAP = new HashMap();
    在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 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;
    }




你可能感兴趣的:(Android,Frameworks)