Android布局优化之ViewStub控件
viewstub是android布局优化中一个很不错的标签/控件，直接继承自view。虽然android开发人员基本上都听说过，但是真正用的可能不多。
viewstub可以理解成一个非常轻量级的view，与其他的控件一样，有着自己的属性及特定的方法。当viewstub使用在布局文件中时，当程序inflate布局文件时，viewstub本身也会被解析，且占据内存控件，但是与其他控件相比，主要区别体现在以下几点：
1.当布局文件inflate时，viewstub控件虽然也占据内存，但是相相比于其他控件，viewstub所占内存很小；
2.布局文件inflate时，viewstub主要是作为一个“占位符”的性质，放置于view tree中，且viewstub本身是不可见的。viewstub中有一个layout属性，指向viewstub本身可能被替换掉的布局文件，在一定时机时，通过viewstub.inflate()完成此过程；
3.viewstub本身是不可见的，对viewstub setvisibility(..)与其他控件不一样，viewstub的setvisibility 成view.visible或invisible如果是首次使用，都会自动inflate其指向的布局文件，并替换viewstub本身，再次使用则是相当于对其指向的布局文件设置可见性。
这里需要注意的是：
1.viewstub之所以常称之为“延迟化加载”，是因为在教多数情况下，程序无需显示viewstub所指向的布局文件，只有在特定的某些较少条件下，此时viewstub所指向的布局文件才需要被inflate，且此布局文件直接将当前viewstub替换掉，具体是通过viewstub.infalte()或viewstub.setvisibility(view.visible)来完成；
2.正确把握住viewstub的应用场景非常重要，正如如1中所描述需求场景下，使用viewstub可以优化布局；
3.对viewstub的inflate操作只能进行一次，因为inflate的时候是将其指向的布局文件解析inflate并替换掉当前viewstub本身（由此体现出了viewstub“占位符”性质），一旦替换后，此时原来的布局文件中就没有viewstub控件了，因此，如果多次对viewstub进行infalte，会出现错误信息：viewstub must have a non-null viewgroup viewparent。
4.3中所讲到的viewstub指向的布局文件解析inflate并替换掉当前viewstub本身，并不是完全意义上的替换（与include标签还不太一样），替换时，布局文件的layout params是以viewstub为准，其他布局属性是以布局文件自身为准。
下面看一下简单的需求场景：在listview显示列表数据时，可能会出现服务端一条数据都没有的情况，此时显示一个emptyview，提示用户暂无数据。此时考虑到实际应用中emptyview显示出来的机会相当小，因此，可以在布局文件中使用viewstub站位，然后确实没有数据时才viewstub.infalte()。
相关部分代码如下：
public void showemptyview() {
listview.setvisibility(view.gone);
if (nodataview == null) {
viewstub nodataviewstub = (viewstub) view.findviewbyid(r.id.no_data_viewstub);
nodataview = nodataviewstub.inflate();
} else {
nodataview.setvisibility(view.visible);
}
}
public void showlistview(){
listview.setvisibility(view.visible);
if(nodataview != null){
nodataview.setvisibility(view.gone);
}
}
特别需要注意的是对viewstub是否已经inflate的判断。
在listview item中，有时候可能遇到如下场景：在不同的列表页item的布局一部分不同，但相对于整个item布局来说又不是很多，此时最常见的有如下两种处理：
1.对不同的部分都写出来，放到一个item文件中，然后逻辑分别处理不同部分的显示与否（view.visible和view.gone）；
2.对这两种不同的item整个部分都分别区分开，完全写成两个item文件，然后结合listview显示不同布局分别做逻辑处理（通过getitemtype()等方式）。
以上两种处理方式其实都可以，第一种方式逻辑清晰，非常灵活，只是在一定程度上增加了内存和资源消耗。第二种方式是的布局文件有重复（虽然相同部分可以通过include，但是逻辑上还是有重复的），包括逻辑上处理的代码实质上的重复。一般对于有较大不同的item布局推荐采用此种方式。
有时候结合需求，可以在第一种方式的基础上，结合viewstub“占位符”可以比较好的完成此类需求。也相当于是两种方式的一种折中形式，但同时兼顾了内存和资源消耗以及不同的布局逻辑控件。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。