注意 在Android中，一个UI元素被称为一个视图（View），然而，笔者认为控件才是UI元素的更贴切的名字。因为UI元素不仅仅是为了向用户显示一些内容，更重要的是它们响应用户的输入并进行相应的工作。本书后续部分将以控件来称呼UI元素(View)。

另外，本章的目的并不是介绍如何使用各种Android控件，而是介绍Android控件系统的工作原理。本章要求读者至少应了解使用Android控件的基本知识。

// 将按钮作为一个窗口添加到WMS中

private void installFloatingWindow() {

    // ① 获取一个WindowManager实例

    finalWindowManager wm =

                    (WindowManager)getSystemService(Context.WINDOW_SERVICE);

    // ② 新建一个按钮控件

    finalButton btn = new Button(this.getBaseContext());

   btn.setText("Click me to dismiss!");

    // ③ 生成一个WindowManager.LayoutParams，用以描述窗口的类型与位置信息

   LayoutParams lp = createLayoutParams();

    // ④ 通过WindowManager.addView()方法将按钮作为一个窗口添加到系统中

   wm.addView(btn, lp);

   btn.setOnClickListener(new View.OnClickListener() {

       @Override

       public void onClick(View v) {

            // ⑤当用户点击按钮时，将按钮从系统中删除

           wm.removeView(btn);

           stopSelf();

        }

    });

}

    privateLayoutParams createLayoutParams() {

       LayoutParams lp = new WindowManager.LayoutParams();

       lp.type = LayoutParams.TYPE_PHONE;

       lp.gravity = Gravity.CENTER;

       lp.width = LayoutParams.WRAP_CONTENT;

       lp.height = LayoutParams.WRAP_CONTENT;

       lp.flags = LayoutParams.FLAG_NOT_FOCUSABLE

               | LayoutParams.FLAG_NOT_TOUCH_MODAL;

       return lp;

    }

public Object getSystemService(String name) {

    // 获取WINDOW_SERVICE所对应的ServiceFetcher

   ServiceFetcher fetcher = SYSTEM_SERVICE_MAP.get(name);

    // 调用fetcher.getService()获取一个实例

    returnfetcher == null ? null : fetcher.getService(this);

}

registerService(WINDOW_SERVICE, newServiceFetcher() {

           public Object getService(ContextImpl ctx) {

               // ① 获取Context中所保存的Display对象

               Display display = ctx.mDisplay;

               /* ② 倘若Context中没有保存任何Display对象，则通过DisplayManager获取系统

                  主屏幕所对应的Display对象 */

               if (display == null) {

                   DisplayManager dm =

                            (DisplayManager)ctx.getOuterContext().getSystemService(

                                                                   Context.DISPLAY_SERVICE);

                   display = dm.getDisplay(Display.DEFAULT_DISPLAY);

               }

               // ③ 使用Display对象作为构造函数创建一个WindowManagerImpl对象并返回

               return new WindowManagerImpl(display);

           }});

    publicWindowManagerImpl(Display display) {

       this(display, null);

    }

    privateWindowManagerImpl(Display display, Window parentWindow) {

       mDisplay = display;

       mParentWindow = parentWindow;

    }

说明 WindowManagerImpl的构造函数引入了一个Window类型的参数parentWindow。Window类是什么呢？以Activity为例，一个Activity显示在屏幕上时包含了标题栏、菜单按钮等控件，但是在setContentView()时并没有在layout中放置它们。这是因为Window类预先为我们准备好了这一切，它们被称之为窗口装饰。除了产生窗口装饰之外，Window类还保存了窗口相关的一些重要信息。例如窗口ID（IWindow.asBinder()的返回值）以及窗口所属Activity的ID(即AppToken)。在6.6.1 介将会对这个类做详细的介绍。

    publicvoid addView(View view, ViewGroup.LayoutParams params) {

       mGlobal.addView(view, params, mDisplay, mParentWindow);

    }

    privatefinal WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();

    publicvoid addView(View view, ViewGroup.LayoutParams params,

            Display display, Window parentWindow){

        ......// 参数检查

       final WindowManager.LayoutParams wparams =(WindowManager.LayoutParams)params;

        /* ① 如果当前窗口需要被添加为另一个窗口的附属窗口（子窗口），则需要让父窗口视自己的情况

            对当前窗口的布局参数(LayoutParams)进行一些修改 */

        if(parentWindow != null) {

           parentWindow.adjustLayoutParamsForSubWindow(wparams);

        }

       ViewRootImpl root;

        ViewpanelParentView = null;

       synchronized (mLock) {

            ......

           // WindowManager不允许同一个View被添加两次

           int index = findViewLocked(view, false);

           if (index >= 0) { throw new IllegalStateException("......");}

           // ② 创建一个ViewRootImpl对象并保存在root变量中

           root = new ViewRootImpl(view.getContext(), display);

           view.setLayoutParams(wparams);

           /* ③ 将作为窗口的控件、布局参数以及新建的ViewRootImpl以相同的索引值保存在三个

              数组中。到这步为止，我们可以认为完成了窗口信息的添加工作 */

           mViews[index] = view;

            mRoots[index] = root;

           mParams[index] = wparams;

        }

        try{

           /* ④ 将作为窗口的控件设置给ViewRootImpl。这个动作将导致ViewRootImpl向WMS

               添加新的窗口、申请Surface以及托管控件在Surface上的重绘动作。这才是真正意义上

                完成了窗口的添加操作*/

           root.setView(view, wparams, panelParentView);

        }catch (RuntimeException e) { ...... }

    }

注意 笔者并不认同将这个三元组分别存储在三个数组中的设计。如果创建一个WindowRecord类来统一保存这个三元组将可以省去很多麻烦。

另外，mViews、mParams以及mRoots这三个数组的容量是随着当前进程中的窗口数量的变化而变化的。因此在addView()以及随后的removeView()中都伴随着数组的新建、拷贝等操作。鉴于一个进程所添加的窗口数量不会太多，而且也不会很频繁，所以这些时间开销是可以接受的。不过笔者仍然认为相对于数组，ArrayList或CopyOnWriteArrayList是更好的选择。

    publicvoid updateViewLayout(View view, ViewGroup.LayoutParams params) {

        ......// 参数检查

       final WindowManager.LayoutParams wparams =(WindowManager.LayoutParams)params;

        // 将布局参数保存到控件中

       view.setLayoutParams(wparams);

       synchronized (mLock) {

           // 获取窗口在三个数组中的索引

           int index = findViewLocked(view, true);

           ViewRootImpl root = mRoots[index];

            // 更新布局参数到数组中

           mParams[index] = wparams;

           // 调用ViewRootImpl的setLayoutParams()使得新的布局参数生效

           root.setLayoutParams(wparams, false);

        }

    }

说明 在实际的应用开发过程中，有时会在logcat的输出中遇到有关WindowLeaked的异常输出。WindowLeaked异常发生与WindowManagerGlobal中，其原因是Activity在destroy之前没有销毁其附属窗口，如对话框、弹出菜单等。

public ViewRootImpl(Context context, Displaydisplay) {

    /* ① 从WindowManagerGlobal中获取一个IWindowSession的实例。它是ViewRootImpl和

      WMS进行通信的代理 */

    mWindowSession= WindowManagerGlobal.getWindowSession(context.getMainLooper());

    // ②保存参数display，在后面setView()调用中将会把窗口添加到这个Display上

    mDisplay= display;

   CompatibilityInfoHolder cih = display.getCompatibilityInfo();

   mCompatibilityInfo = cih != null ? cih : new CompatibilityInfoHolder();

    /* ③ 保存当前线程到mThread。这个赋值操作体现了创建ViewRootImpl的线程如何成为UI主线程。

      在ViewRootImpl处理来自控件树的请求时（如请求重新布局，请求重绘，改变焦点等），会检

      查发起请求的thread与这个mThread是否相同。倘若不同则会拒绝这个请求并抛出一个异常*/

    mThread= Thread.currentThread();

    ......

    /* ④ mDirty用于收集窗口中的无效区域。所谓无效区域是指由于数据或状态发生改变时而需要进行重绘

      的区域。举例说明，当应用程序修改了一个TextView的文字时，TextView会将自己的区域标记为无效

      区域，并通过invalidate()方法将这块区域收集到这里的mDirty中。当下次绘制时，TextView便

      可以将新的文字绘制在这块区域上 */

    mDirty =new Rect();

   mTempRect = new Rect();

    mVisRect= new Rect();

    /* ⑤ mWinFrame，描述了当前窗口的位置和尺寸。与WMS中WindowState.mFrame保持着一致 */

   mWinFrame = new Rect();

    /* ⑥ 创建一个W类型的实例，W是IWindow.Stub的子类。即它将在WMS中作为新窗口的ID，以及接

      收来自WMS的回调*/

    mWindow= new W(this);

    ......

    /* ⑦ 创建mAttachInfo。mAttachInfo是控件系统中很重要的对象。它存储了此当前控件树所以贴附

      的窗口的各种有用的信息，并且会派发给控件树中的每一个控件。这些控件会将这个对象保存在自己的

     mAttachInfo变量中。mAttachInfo中所保存的信息有WindowSession，窗口的实例（即mWindow），

      ViewRootImpl实例，窗口所属的Display，窗口的Surface以及窗口在屏幕上的位置等等。所以，当

      要需在一个View中查询与当前窗口相关的信息时，非常值得在mAttachInfo中搜索一下 */

   mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display,this, mHandler, this);

    /* ⑧ 创建FallbackEventHandler。这个类如同PhoneWindowManger一样定义在android.policy

      包中，其实现为PhoneFallbackEventHandler。FallbackEventHandler是一个处理未经任何人

      消费的输入事件的场所。在6.5.4节中将会介绍它 */

   mFallbackEventHandler =PolicyManager.makeNewFallbackEventHandler(context);

    ......

    /* ⑨ 创建一个依附于当前线程，即主线程的Choreographer，用于通过VSYNC特性安排重绘行为 */

    mChoreographer= Choreographer.getInstance();

    ......

}

说明 mHandler与mThread两个成员都是为了单线程模型而存在的。Android的UI操作不是线程安全的，而且很多操作也是建立在单线程的假设之上（如scheduleTraversals()）。采用单线程模型的目的是降低系统的复杂度，并且降低锁的开销。

public void setView(View view,WindowManager.LayoutParams attrs, View panelParentView) {

   synchronized (this) {

        if (mView == null) {

           // ① mView保存了控件树的根

           mView = view;

           ......

           // ②mWindowAttributes保存了窗口所对应的LayoutParams

           mWindowAttributes.copyFrom(attrs);

            ......

           /* 在添加窗口之前，先通过requestLayout()方法在主线程上安排一次“遍历”。所谓

             “遍历”是指ViewRootImpl中的核心方法performTraversals()。这个方法实现了对

              控件树进行测量、布局、向WMS申请修改窗口属性以及重绘的所有工作。由于此“遍历”

              操作对于初次遍历做了一些特殊处理，而来自WMS通过mWindow发生的回调会导致一些属性

              发生变化，如窗口的尺寸、Insets以及窗口焦点等，从而有可能使得初次“遍历”的现场遭

              到破坏。因此，需要在添加窗口之前，先发送一个“遍历”消息到主线程。

               在主线程中向主线程的Handler发送消息如果使用得当，可以产生很精妙的效果。例如本例

              中可以实现如下的执行顺序：添加窗口->初次遍历->处理来自WMS的回调 */

           requestLayout();

           /*③ 初始化mInputChannel。参考第五章，InputChannel是窗口接受来自InputDispatcher

             的输入事件的管道。 注意，仅当窗口的属性inputFeatures不含有

             INPUT_FEATURE_NO_INPUT_CHANNEL时才会创建InputChannel，否则mInputChannel

             为空，从而导致此窗口无法接受任何输入事件 */

           if ((mWindowAttributes.inputFeatures

                   & WindowManager.LayoutParams.INPUT_FEATURE_NO_INPUT_CHANNEL) == 0) {

               mInputChannel = new InputChannel();

           }

           try {

               ......

               /* 将窗口添加到WMS中。完成这个操作之后，mWindow已经被添加到指定的Display中去

                 而且mInputChannel（如果不为空）已经准备好接受事件了。只是由于这个窗口没有进行

                 过relayout()，因此它还没有有效的Surface可以进行绘制 */

               res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,

                        getHostVisibility(), mDisplay.getDisplayId(),

                       mAttachInfo.mContentInsets, mInputChannel);

           } catch (RemoteException e) {......} finally { ...... }

           ......

           if (res < WindowManagerGlobal.ADD_OKAY) {

               // 错误处理。窗口添加失败的原因通常是权限问题，重复添加，或者tokeen无效

           }

           ......

            /*④ 如果mInputChannel不为空，则创建mInputEventReceiver，用于接受输入事件。

             注意第二个参数传递的是Looper.myLooper()，即mInputEventReceiver将在主线程上

             触发输入事件的读取与onInputEvent()。这是应用程序可以在onTouch()等事件响应中

             直接进行UI操作等根本原因。

            */

           if (mInputChannel != null) {

               ......

               mInputEventReceiver = new WindowInputEventReceiver(mInputChannel,

                           Looper.myLooper());

           }

          /* ViewRootImpl将作为参数view的parent。所以，ViewRootImpl可以从控件树中任何一个

            控件开始，通过回溯getParent()的方法得到 */

           view.assignParent(this);

            ......

        }

    }

}

说明 很多文章都倾向于将performTraversals()的工作划分为测量、布局与绘制三个阶段。然而笔者认为如此划分隐藏了WMS在这个过程中的地位，并且没能体现出控件树对窗口尺寸的期望、WMS对窗口尺寸做最终的确定，最后以WMS给出的结果为准再次进行测量的协商过程。而这个协商过程充分体现了ViewRootImpl作为WMS与控件树的中间人的角色。

private void performTraversals() {

    // 将mView保存在局部变量host中，以此提高对mView的访问效率

    finalView host = mView;

    ......

    // 声明本阶段的主角，这两个变量将是mView的SPEC_SIZE分量的候选

    intdesiredWindowWidth;

    intdesiredWindowHeight;

    .......

    Rectframe = mWinFrame; // 如上一节所述，mWinFrame表示了窗口的最新尺寸

    if(mFirst) {

        /*mFirst表示了这是第一次遍历，此时窗口刚刚被添加到WMS，此时窗口尚未进行relayout，因此

          mWinFrame中没有存储有效地窗口尺寸 */

        if(lp.type == WindowManager.LayoutParams.TYPE_STATUS_BAR_PANEL) {

            ......// 为状态栏设置desiredWindowWidth/Height，其取值是屏幕尺寸

        }else {

            //① 第一次“遍历”的测量，采用了应用可以使用的最大尺寸作为SPEC_SIZE的候选

           DisplayMetrics packageMetrics =

               mView.getContext().getResources().getDisplayMetrics();

           desiredWindowWidth = packageMetrics.widthPixels;

           desiredWindowHeight = packageMetrics.heightPixels;

        }

        /* 由于这是第一次进行“遍历”，控件树即将第一次被显示在窗口上，因此接下来的代码填充了

         mAttachInfo中的一些字段，然后通过mView发起了dispatchAttachedToWindow()的调用

          之后每一个位于控件树中的控件都会回调onAttachedToWindow() */

        ......

    } else {

        // ② 在非第一次遍历的情况下，会采用窗口的最新尺寸作为SPEC_SIZE的候选

       desiredWindowWidth = frame.width();

       desiredWindowHeight = frame.height();

        /* 如果窗口的最新尺寸与ViewRootImpl中的现有尺寸不同，说明WMS侧单方面改变了窗口的尺寸

          这将产生如下三个结果 */

        if(desiredWindowWidth != mWidth || desiredWindowHeight != mHeight) {

            // 需要进行完整的重绘以适应新的窗口尺寸

           mFullRedrawNeeded = true;

           // 需要对控件树进行重新布局

           mLayoutRequested = true;

           /* 控件树有可能拒绝接受新的窗口尺寸，比如在随后的预测量中给出了不同于窗口尺寸的测量结果

             产生这种情况时，就需要在窗口布局阶段尝试设置新的窗口尺寸 */

           windowSizeMayChange = true;

        }

    }

    ......

    /* 执行位于RunQueue中的回调。RunQueue是ViewRootImpl的一个静态成员，即是说它是进程唯一

      的，并且可以在进程的任何位置访问RunQueue。在进行多线程任务时，开发者可以通过调用View.post()

      或View.postDelayed()方法将一个Runnable对象发送到主线程执行。这两个方法的原理是将

      Runnable对象发送到ViewRootImpl的mHandler去。当控件已经加入到控件树时，可以通过

     AttachInfo轻易获取这个Handler。而当控件没有位于控件树中时，则没有mAttachInfo可用，此时

      执行View.post()/PostDelay()方法，Runnable将会被添加到这个RunQueue队列中。

      在这里，ViewRootImpl将会把RunQueue中的Runnable发送到mHandler中，进而得到执行。所以

      无论控件是否显示在控件树中，View.post()/postDelay()方法都是可用的，除非当前进程中没有任何

      处于活动状态的ViewRootImpl */

   getRunQueue().executeActions(attachInfo.mHandler);

    booleanlayoutRequested = mLayoutRequested && !mStopped;

    /* 仅当layoutRequested为true时才进行预测量。

     layoutRequested为true表示在进行“遍历”之前requestLayout()方法被调用过。

     requestLayout()方法用于要求ViewRootImpl进行一次“遍历”并对控件树重新进行测量与布局 */

    if(layoutRequested) {

       final Resources res = mView.getContext().getResources();

        if(mFirst) {

            ......// 确定控件树是否需要进入TouchMode，本章将在6.5.1节介绍 TouchMode

        }else {

            /*检查WMS是否单方面改变了ContentInsets与VisibleInsets。注意对二者的处理的差异，

             ContentInsets描述了控件在布局时必须预留的空间，这样会影响控件树的布局，因此将

             insetsChanged标记为true，以此作为是否进行控件布局的条件之一。而VisibleInsets则

             描述了被遮挡的空间，ViewRootImpl在进行绘制时，需要调整绘制位置以保证关键控件或区域，

             如正在进行输入的TextView等不被遮挡，这样VisibleInsets的变化并不会导致重新布局，

             所以这里仅仅是将VisibleInsets保存到mAttachInfo中，以便绘制时使用 */

           if (!mPendingContentInsets.equals(mAttachInfo.mContentInsets)) {

               insetsChanged = true;

           }

           if (!mPendingVisibleInsets.equals(mAttachInfo.mVisibleInsets)) {

               mAttachInfo.mVisibleInsets.set(mPendingVisibleInsets);

           }

            /*当窗口的width或height被指定为WRAP_CONTENT时，表示这是一个悬浮窗口。

             此时会对desiredWindowWidth/Height进行调整。在前面的代码中，这两个值被设置

             被设置为窗口的当前尺寸。而根据MeasureSpec的要求，测量结果不得大于SPEC_SIZE。

             然而，如果这个悬浮窗口需要更大的尺寸以完整显示其内容时，例如为AlertDialog设置了

             一个更长的消息内容，如此取值将导致无法得到足够大的测量结果，从而导致内容无法完整显示。

             因此，对于此等类型的窗口，ViewRootImpl会调整desiredWindowWidth/Height为此应用

             可以使用的最大尺寸 */

           if (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT

                   || lp.height == ViewGroup.LayoutParams.WRAP_CONTENT) {

               // 悬浮窗口的尺寸取决于测量结果。因此有可能需要向WMS申请改变窗口的尺寸。

               windowSizeMayChange = true;

               if (lp.type == WindowManager.LayoutParams.TYPE_STATUS_BAR_PANEL) {

                   //

               } else {

                   // ③ 设置悬浮窗口SPEC_SIZE的候选为应用可以使用的最大尺寸

                   DisplayMetrics packageMetrics = res.getDisplayMetrics();

                   desiredWindowWidth = packageMetrics.widthPixels;

                   desiredWindowHeight = packageMetrics.heightPixels;

               }

           }

        }

        // ④ 进行预测量。通过measureHierarchy()方法以desiredWindowWidth/Height进行测量

        windowSizeMayChange |=measureHierarchy(host, lp, res,

               desiredWindowWidth, desiredWindowHeight);

    }

    // 其他阶段的处理

    ......

｝

private boolean measureHierarchy(final View host,final WindowManager.LayoutParams lp,

       final Resources res, final int desiredWindowWidth,

        final int desiredWindowHeight) {

    intchildWidthMeasureSpec; // 合成后的用于描述宽度的MeasureSpec

    intchildHeightMeasureSpec; // 合成后的用于描述高度的MeasureSpec

    booleanwindowSizeMayChange = false; // 表示测量结果是否可能导致窗口的尺寸发生变化

    booleangoodMeasure = false; // goodMeasure表示了测量是否能满足控件树充分显示内容的要求

    // 测量协商仅发生在LayoutParams.width被指定为WRAP_CONTENT的情况下

    if(lp.width == ViewGroup.LayoutParams.WRAP_CONTENT) {

        /* ① 第一次协商。measureHierarchy()使用它最期望的宽度限制进行测量。这一宽度限制定义为

         一个系统资源。可以在frameworks/base/core/res/res/values/config.xml找到它的定义 */

       res.getValue(com.android.internal.R.dimen.config_prefDialogWidth,mTmpValue, true);

        intbaseSize = 0;

        // 宽度限制被存放在baseSize中

        if(mTmpValue.type == TypedValue.TYPE_DIMENSION) {

           baseSize = (int)mTmpValue.getDimension(packageMetrics);

        }

        if(baseSize != 0 && desiredWindowWidth > baseSize) {

           // 使用getRootMeasureSpec()函数组合SPEC_MODE与SPEC_SIZE为一个MeasureSpec

           childWidthMeasureSpec = getRootMeasureSpec(baseSize, lp.width);

            childHeightMeasureSpec =

                           getRootMeasureSpec(desiredWindowHeight,lp.height);

            //②第一次测量。由performMeasure()方法完成

           performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

           /* 控件树的测量结果可以通过mView的getmeasuredWidthAndState()方法获取。如果

             控件树对这个测量结果不满意，则会在返回值中添加MEASURED_STATE_TOO_SMALL位 */

           if ((host.getMeasuredWidthAndState()&View.MEASURED_STATE_TOO_SMALL)

                                                ==0) {

               goodMeasure = true; // 控件树对测量结果满意，测量完成

           } else {

               // ③ 第二次协商。上次测量结果表明控件树认为measureHierarchy()给予的宽度太小，

                 在此适当地放宽对宽度的限制，使用最大宽度与期望宽度的中间值作为宽度限制 */

               baseSize = (baseSize+desiredWindowWidth)/2;

               childWidthMeasureSpec = getRootMeasureSpec(baseSize, lp.width);

               // ④ 第二次测量

               performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

               // 再次检查控件树是否满足此次测量

               if ((host.getMeasuredWidthAndState()&View.MEASURED_STATE_TOO_SMALL)

                                                                                == 0) {

                   goodMeasure = true; // 控件树对测量结果满意，测量完成

               }

            }

        }

    }

    if(!goodMeasure) {

        /* ⑤ 最终测量。当控件树对上述两次协商的结果都不满意时，measureHierarchy()放弃所有限制

          做最终测量。这一次将不再检查控件树是否满意了，因为即便其不满意，measurehierarchy()也没

          有更多的空间供其使用了 */

       childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth,lp.width);

       childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight,lp.height);

       performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

        /* 最后，如果测量结果与ViewRootImpl中当前的窗口尺寸不一致，则表明随后可能有必要进行窗口

          尺寸的调整 */

        if(mWidth != host.getMeasuredWidth() || mHeight != host.getMeasuredHeight())

        {

           windowSizeMayChange = true;

        }

    }

    // 返回窗口尺寸是否可能需要发生变化

    returnwindowSizeMayChange;

}

public final void measure(int widthMeasureSpec,int heightMeasureSpec) {

    /* 仅当给予的MeasureSpec发生变化，或要求强制重新布局时，才会进行测量。

      所谓强制重新布局，是指当控件树中的一个子控件的内容发生变化时，需要进行重新的测量和布局的情况

      在这种情况下，这个子控件的父控件（以及其父控件的父控件）所提供的MeasureSpec必定与上次测量

      时的值相同，因而导致从ViewRootImpl到这个控件的路径上的父控件的measure()方法无法得到执行

      进而导致子控件无法重新测量其尺寸或布局。因此，当子控件因内容发生变化时，从子控件沿着控件树回溯

      到ViewRootImpl，并依次调用沿途父控件的requestLayout()方法，在这个方法中，会在

     mPrivateFlags中加入标记PFLAG_FORCE_LAYOUT，从而使得这些父控件的measure()方法得以顺利

      执行，进而这个子控件有机会进行重新测量与布局。这便是强制重新布局的意义 */

    if ((mPrivateFlags& PFLAG_FORCE_LAYOUT) == PFLAG_FORCE_LAYOUT ||

           widthMeasureSpec != mOldWidthMeasureSpec ||

           heightMeasureSpec != mOldHeightMeasureSpec) {

        /* ① 准备工作。从mPrivateFlags中将PFLAG_MEASURED_DIMENSION_SET标记去除。

         PFLAG_MEASURED_DIMENSION_SET标记用于检查控件在onMeasure()方法中是否通过

         调用setMeasuredDimension()将测量结果存储下来 */

       mPrivateFlags &= ~PFLAG_MEASURED_DIMENSION_SET;

       ......

        /* ② 对本控件进行测量 每个View子类都需要重载这个方法以便正确地对自身进行测量。

          View类的onMeasure()方法仅仅根据背景Drawable或style中设置的最小尺寸作为

          测量结果*/

       onMeasure(widthMeasureSpec, heightMeasureSpec);

        /* ③ 检查onMeasure()的实现是否调用了setMeasuredDimension()

         setMeasuredDimension()会将PFLAG_MEASURED_DIMENSION_SET标记重新加入

         mPrivateFlags中。之所以做这样的检查，是由于onMeasure()的实现可能由开发者完成，

          而在Android看来，开发者是不可信的 */

        if((mPrivateFlags & PFLAG_MEASURED_DIMENSION_SET)

                                     !=PFLAG_MEASURED_DIMENSION_SET) {

           throw new IllegalStateException(......);

        }

       // ④ 将PFLAG_LAYOUT_REQUIRED标记加入mPrivateFlags。这一操作会对随后的布局操作放行

       mPrivateFlags |= PFLAG_LAYOUT_REQUIRED;

    }

    // 记录父控件给予的MeasureSpec，用以检查之后的测量操作是否有必要进行

   mOldWidthMeasureSpec = widthMeasureSpec;

   mOldHeightMeasureSpec = heightMeasureSpec;

}

protected final void setMeasuredDimension(intmeasuredWidth, int measuredHeight) {

    /* ① 测量结果被分别保存在成员变量mMeasuredWidth与mMeasuredHeight中

   mMeasuredWidth = measuredWidth;

    mMeasuredHeight = measuredHeight;

    // ② 向mPrivateFlags中添加PFALG_MEASURED_DIMENSION_SET，以此证明onMeasure()保存了测量结果

   mPrivateFlags |= PFLAG_MEASURED_DIMENSION_SET;

}

private void performTraversals() {

    ......// 测量控件树的代码

    /* 标记mLayoutRequested为false。因此在此之后的代码中，倘若控件树中任何一个控件执行了

     requestLayout()，都会重新进行一次“遍历” */

    if (layoutRequested) {

        mLayoutRequested = false;

    }

    // 确定窗口是否确实需要进行尺寸的改变

    booleanwindowShouldResize = layoutRequested && windowSizeMayChange

       && ((mWidth != host.getMeasuredWidth() || mHeight !=host.getMeasuredHeight())

           || (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT &&

                   frame.width() < desiredWindowWidth && frame.width() !=mWidth)

           || (lp.height == ViewGroup.LayoutParams.WRAP_CONTENT &&

                   frame.height() < desiredWindowHeight && frame.height() !=mHeight));

}

注意ViewRootImpl对是否需要调整窗口尺寸的判断是非常小心的。第4章介绍WMS的布局子系统时曾经介绍过，调整窗口尺寸所必须调用的performLayoutAndPlaceSurfacesLocked()函数会导致WMS对系统中的所有窗口新型重新布局，而且会引发至少一个动画帧渲染，其计算开销相当之大。因此ViewRootImpl仅在必要时才会惊动WMS。