系统填充布局是一个巨大的开销，过多的布局嵌套和VIEW对应用的性能有很大的影响。为了应用的运行流畅和响应快速，我们应该尽可能的使布局简单和避免因为较小的UI改变而重新填充布局的情况。

1.冗余的布局是冗余的

    如果有关Frame中间嵌套了一个Linearlayout，它们都被设置成了MATCH_PARENT，这样做就是冗余的，只是增加了填充布局的时间而已。所以我们在布局中添加子布局时，应该注意查找冗余布局。

    因为布局是可以被任意嵌套的，所以容易造成复杂，多层的布局，这是不提倡的，我们应尽量保持布局的简单。虽然没有强制规定，但是布局嵌套最好不要超过10层。

                 

            

 

 

    在这个例子中，如果FrameLayout被加入到了其他布局中的话就会成为冗余布局，影响性能，更好的选择是，使用merge标签代替FrameLayout，merge的特点就是当它被嵌套的其他的布局中时，这个节点会被删除，然后直接将merge中的VIEW加入到父类布局中去。

  merge标签和include标签一起使用，可以构建更加灵活，简单，可复用的布局。include标签的作用就是将一个布局加入到另一个布局中去。例如：

              

 

 2.避免过多的使用VIEW

    现实中，一个应用一般会包含很多的VIEW，但并不是每一个VIEW都能有得到，有的VIEW可能很少会被用到，这就造成了很大的资源浪费，一定程度上影响应用的流畅程度。

如果当VIEW需要时才加载就会减少因为加载过多VIEW造成的资源浪费。

    ViewStub就能实现这样的功能，ViewStub中的VIEW只有被显示的调用inflate或者被设置为可见时才会显示，这样就能保证，不需要这些VIEW的时候就不加载它们。

              <ViewStub

              android:id="@+id/stub_import"

              android:inflatedId="@+id/panel_import"

              android:layout="@layout/progress_overlay"

              android:layout_width="fill_parent"

              android:layout_height="wrap_content"

              android:layout_gravity="bottom" />

在这个ViewStub的属性中，id为了便于以后设置为可见和inflate，inflateID重写了它所包含的布局文件的根节点的ID，layout就是他所包含的布局文件，在ViewStub中，所有的

layout_*属性都将会被应用于它所包含的布局文件的顶级节点中。

   上边说到，当你需要加载ViewStub中的VIEW时，需要显示的调用inflate或者设置它为可见，这里两种方式也有不同之处：    

         ((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);

         // or

        View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();

   当设置为可见时，也会触发infalte方法。

  但是如果显示的调用inflate方法，infalte方法能返回ViewStub中的跟VIEW，并且会删除掉ViewStub，因为此时ViewStub中的VIEW已经加载，ViewStub已经失去了意义，所有没必要保留一个没必要的引用。

    ViewStub是一个很高效的标签，与其手动的inflate View并在运行时添加到View层次上，不如简单的使用ViewStub。ViewStub唯一的缺点是不支持Merge标签。