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

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

// 将button作为一个窗体加入到WMS中

private void installFloatingWindow() {

    // ① 获取一个WindowManager实例

    finalWindowManager wm =

                    (WindowManager)getSystemService(Context.WINDOW_SERVICE);

    // ② 新建一个button控件

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

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

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

   LayoutParams lp = createLayoutParams();

    // ④ 通过WindowManager.addView()方法将button作为一个窗体加入到系统中

   wm.addView(btn, lp);

   btn.setOnClickListener(new View.OnClickListener() {

       @Override

       public void onClick(View v) {

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

           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显示在屏幕上时包括了标题栏、菜单button等控件，可是在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。