View中的draw和onDraw,dispatchDraw的区别
2015-09-16 20:02
274 查看
Android的view组件显示主要经过mesure, layout和draw这三个过程。在mesure阶段里调用mesure(int widthSpec, int heightSpec)方法,这个方法是final不能被重写,在这个过程里会调用onMesure(int widthSpec,
int heightSpec)方法。当组件设置好大小后,调用final layout(int l, int t, int r, int b)方法进行布局,在这个过程里会调用onLayout(boolean changed, int l, int t, int r, int b)方法,所以处理组件的布局通常要重写onMesure和onLayout这两个方法。
View组件的绘制会调用draw(Canvas canvas)方法,这个方法在源代码里看不到在哪里调用...draw过程中主要是先画Drawable背景,对drawable调用setBounds()然后是draw(Canvas
c)方法.有点注意的是背景drawable的实际大小会影响view组件的大小,drawable的实际大小通过getIntrinsicWidth()和getIntrinsicHeight()获取,当背景比较大时view组件大小等于背景drawable的大小,不过俺没有在源代码里找到布局时调用过 getIntrinsicWidth()和getIntrinsicHeight()方法...
画完背景后,draw过程会调用onDraw(Canvas canvas)方法,然后就是dispatchDraw(Canvas
canvas)方法, dispatchDraw()主要是分发给子组件进行绘制,我们通常定制组件的时候重写的是onDraw()方法。值得注意的是ViewGroup容器组件的绘制,当它没有背景时直接调用的是dispatchDraw()方法, 而绕过了draw()方法,当它有背景的时候就调用draw()方法,而draw()方法里包含了dispatchDraw()方法的调用。因此要在ViewGroup上绘制东西的时候往往重写的是dispatchDraw()方法而不是onDraw()方法,或者自定制一个Drawable,重写它的draw(Canvas
c)和getIntrinsicWidth().
Android性能优化之一:ViewStub
http://www.cnblogs.com/lwbqqyumidi/p/4047108.html
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()。
相关部分代码如下:
复制代码
1 public void showEmptyView() {
2 listview.setVisibility(View.GONE);
3 if (noDataView == null) {
4 ViewStub noDataViewStub = (ViewStub) view.findViewById(R.id.no_data_viewstub);
5 noDataView = noDataViewStub.inflate();
6 } else {
7 noDataView.setVisibility(View.VISIBLE);
8 }
9 }
10
11 public void showListView(){
12 listview.setVisibility(View.VISIBLE);
13 if(noDataView != null){
14 noDataView.setVisibility(View.GONE);
15 }
16 }
复制代码
特别需要注意的是对ViewStub是否已经inflate的判断。
在Listview Item中,有时候可能遇到如下场景:在不同的列表页item的布局一部分不同,但相对于整个item布局来说又不是很多,此时最常见的有如下两种处理:
1.对不同的部分都写出来,放到一个item文件中,然后逻辑分别处理不同部分的显示与否(View.VISIBLE和View.GONE);
2.对这两种不同的item整个部分都分别区分开,完全写成两个item文件,然后结合listView显示不同布局分别做逻辑处理(通过getItemType()等方式)。
以上两种处理方式其实都可以,第一种方式逻辑清晰,非常灵活,只是在一定程度上增加了内存和资源消耗。第二种方式是的布局文件有重复(虽然相同部分可以通过include,但是逻辑上还是有重复的),包括逻辑上处理的代码实质上的重复。一般对于有较大不同的item布局推荐采用此种方式。
有时候结合需求,可以在第一种方式的基础上,结合ViewStub“占位符”可以比较好的完成此类需求。也相当于是两种方式的一种折中形式,但同时兼顾了内存和资源消耗以及不同的布局逻辑控件。
int heightSpec)方法。当组件设置好大小后,调用final layout(int l, int t, int r, int b)方法进行布局,在这个过程里会调用onLayout(boolean changed, int l, int t, int r, int b)方法,所以处理组件的布局通常要重写onMesure和onLayout这两个方法。
View组件的绘制会调用draw(Canvas canvas)方法,这个方法在源代码里看不到在哪里调用...draw过程中主要是先画Drawable背景,对drawable调用setBounds()然后是draw(Canvas
c)方法.有点注意的是背景drawable的实际大小会影响view组件的大小,drawable的实际大小通过getIntrinsicWidth()和getIntrinsicHeight()获取,当背景比较大时view组件大小等于背景drawable的大小,不过俺没有在源代码里找到布局时调用过 getIntrinsicWidth()和getIntrinsicHeight()方法...
画完背景后,draw过程会调用onDraw(Canvas canvas)方法,然后就是dispatchDraw(Canvas
canvas)方法, dispatchDraw()主要是分发给子组件进行绘制,我们通常定制组件的时候重写的是onDraw()方法。值得注意的是ViewGroup容器组件的绘制,当它没有背景时直接调用的是dispatchDraw()方法, 而绕过了draw()方法,当它有背景的时候就调用draw()方法,而draw()方法里包含了dispatchDraw()方法的调用。因此要在ViewGroup上绘制东西的时候往往重写的是dispatchDraw()方法而不是onDraw()方法,或者自定制一个Drawable,重写它的draw(Canvas
c)和getIntrinsicWidth().
Android性能优化之一:ViewStub
http://www.cnblogs.com/lwbqqyumidi/p/4047108.html
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()。
相关部分代码如下:
复制代码
1 public void showEmptyView() {
2 listview.setVisibility(View.GONE);
3 if (noDataView == null) {
4 ViewStub noDataViewStub = (ViewStub) view.findViewById(R.id.no_data_viewstub);
5 noDataView = noDataViewStub.inflate();
6 } else {
7 noDataView.setVisibility(View.VISIBLE);
8 }
9 }
10
11 public void showListView(){
12 listview.setVisibility(View.VISIBLE);
13 if(noDataView != null){
14 noDataView.setVisibility(View.GONE);
15 }
16 }
复制代码
特别需要注意的是对ViewStub是否已经inflate的判断。
在Listview Item中,有时候可能遇到如下场景:在不同的列表页item的布局一部分不同,但相对于整个item布局来说又不是很多,此时最常见的有如下两种处理:
1.对不同的部分都写出来,放到一个item文件中,然后逻辑分别处理不同部分的显示与否(View.VISIBLE和View.GONE);
2.对这两种不同的item整个部分都分别区分开,完全写成两个item文件,然后结合listView显示不同布局分别做逻辑处理(通过getItemType()等方式)。
以上两种处理方式其实都可以,第一种方式逻辑清晰,非常灵活,只是在一定程度上增加了内存和资源消耗。第二种方式是的布局文件有重复(虽然相同部分可以通过include,但是逻辑上还是有重复的),包括逻辑上处理的代码实质上的重复。一般对于有较大不同的item布局推荐采用此种方式。
有时候结合需求,可以在第一种方式的基础上,结合ViewStub“占位符”可以比较好的完成此类需求。也相当于是两种方式的一种折中形式,但同时兼顾了内存和资源消耗以及不同的布局逻辑控件。
相关文章推荐
- 弹框
- TCP 的那些事儿(下)
- 前端性能优化(六)
- 2015区域赛长春网络赛 Elven Postman
- 三元运算符
- Machine learning (1)线性回归
- Hadoop QuickStart VM
- C#中var关键字
- opencv-mat
- 九. 200创业教训万元获得--“神刻”这是忽悠?
- TCP 的那些事儿(上)
- autofs rhel7
- HDOJ 3065 病毒侵袭持续中
- 副本集指南(二)
- MyBatis学习总结(一)
- STL—— queue 单向队列
- Java对象序列化
- 黑马程序员——7K面试
- java SE复习笔记11
- 四:redis的sets类型 - 相关操作(有序和无序集合)