Android性能优化系列――Understanding Overdraw
“无言的悲伤”通过精心收集，向本站投稿了7篇Android性能优化系列――Understanding Overdraw，下面是小编帮大家整理后的Android性能优化系列――Understanding Overdraw，希望对大家有所帮助。
篇1：Android性能优化系列――Understanding Overdraw
过度绘制（Overdraw）是指在一帧的时间内像素被绘制了多次；
理论上一个像素每次只绘制一次是最优的，但是由于层叠的布局导致一些像素会被多次绘制，而每次绘制都会对应到CPU的一组绘图命令和GPU的一些操作，所以对重叠不可见元素的重复绘制会产生额外的计算，需要尽量减少Overdraw的发生，
Android系统提供了测量Overdraw的选项，在开发者选项－调试GPU过度绘制（Show GPU Overdraw），打开选项就可以看到当前页面Overdraw的状态。
根据overdraw的次数会显示不同的颜色来区分
transparent = no overdraw blue = 1 layer green = 2 layers light-red = 3 layers dark red = you’re doing it wrong优化方法
总的原则就是：尽量避免重叠不可见元素的绘制
去除不需要的背景资源
在theme中添加android:windowbackground=“null”； 在Activity中设置getWindow.setBackgroundDrawable(null)这个方法要在setContentView()之后，因为getWindow().setBackground(Drawable)会讲这里的Drawable设置到DecorView的background，默认是0xff000000，而setContentView才会第一次初始化phoneWindow的DecorView；
分段设置背景
有时候为了方便会先给Layout设置一个整体的背景，再给子View设置背景，这里也会造成重叠，如果子View宽度mach_parent，可以看到完全覆盖了Layout的一部分，这里就可以通过分别设置背景来减少重绘，
View onDraw()方法
自定义View绘制时避免重叠部分的绘制，可以使用
canvas.clipRect(); // 裁剪canvascanvas.quickReject(); // 判断矩形区域是否相交
其他绘制优化建议
在onDraw函数里尽量避免分配内存、创建对象，会导致频繁的垃圾回收降低性能；在初始化、或者动画间隙做这些事情 减少invalidate的调用 尽可能保持layout的扁平化，尽可能少调用requestLayout()，requestLayout会导致系统遍历整个View树重新去measure和layout，如果layout嵌套复杂，这里也会产生性能问题 如果布局复杂，可以考虑自定义ViewGroup来特殊处理
Reference
Android Performance Patterns: Understanding Overdraw
Android Performance Patterns: Invalidations, Layouts, and Performance
篇2：Android编码规范及性能优化
最近看到新人的android代码实在问题太多，一些基本的地方都有问题，于是重新培训了下代码规范，希望后面能慢慢好起来，
一、Android编码规范
1.java代码中不出现中文，最多注释中可以出现中文
2.局部变量命名、静态成员变量命名只能包含字母，单词首字母出第一个外，都为大写，其他字母都为小写
3.常量命名只能包含字母和_，字母全部大写，单词之间用_隔开
4.layout中的id命名命名模式为：view缩写_模块名称_view的逻辑名称view的缩写详情如下LayoutView：lvRelativeView:rvTextView:tvImageView:ivImageButton:imButton:btn
5.activity中的view变量命名命名模式为：逻辑名称+view缩写建议：如果layout文件很复杂，建议将layout分成多个模块，每个模块定义一个moduleViewHolder，其成员变量包含所属view
6.strings.xml中的id命名命名模式：activity名称_功能模块名称_逻辑名称/activity名称_逻辑名称/common_逻辑名称strings.xml中，使用activity名称注释，将文件内容区分开来7.drawable中的图片命名命名模式：activity名称_逻辑名称/common_逻辑名称
7.styles.xml：将layout中不断重现的style提炼出通用的style通用组件，放到styles.xml中；
8.使用layer-list和selector
9.图片尽量分拆成多个可重用的图片
10.服务端可以实现的，就不要放在客户端
11.引用第三方库要慎重，避免应用大容量的第三方库，导致客户端包非常大
12.处理应用全局异常和错误，将错误以邮件的形式发送给服务端
13.图片的.9处理
14.使用静态变量方式实现界面间共享要慎重
15.Log(系统名称 模块名称 接口名称，详细描述)
16.单元测试（逻辑测试、界面测试）
17.不要重用父类的handler，对应一个类的handler也不应该让其子类用到，否则会导致message.what冲突
18.activity中在一个View.OnClickListener中处理所有的逻辑
19.strings.xml中使用%1$s实现字符串的通配
20.如果多个Activity中包含共同的UI处理，那么可以提炼一个CommonActivity，把通用部分叫由它来处理，其他activity只要继承它即可
21.使用button+activitgroup实现tab效果时，使用Button.setSelected(true)，确保按钮处于选择状态，并使activitygroup的当前activity与该button对应
22.如果所开发的为通用组件，为避免冲突，将drawable/layout/menu/values目录下的文件名增加前缀
23.数据一定要效验，例如字符型转数字型，如果转换失败一定要有缺省值；服务端响应数据是否有效判断；
二、Android性能优化
1.http用gzip压缩，设置连接超时时间和响应超时时间 http请求按照业务需求，分为是否可以缓存和不可缓存，那么在无网络的环境中，仍然通过缓存的httpresponse浏览部分数据，实现离线阅读，
2.listview 性能优化 1).复用convertView在getItemView中，判断convertView是否为空，如果不为空，可复用。如果couvertview中的view需要添加listerner，代码一定要在if(convertView==null){}之外。2).异步加载图片item中如果包含有webimage，那么最好异步加载3).快速滑动时不显示图片当快速滑动列表时（SCROLL_STATE_FLING），item中的图片或获取需要消耗资源的view，可以不显示出来；而处于其他两种状态（SCROLL_STATE_IDLE 和SCROLL_STATE_TOUCH_SCROLL），则将那些view显示出来。
3.使用线程池，分为核心线程池和普通线程池，下载图片等耗时任务放置在普通线程池，避免耗时任务阻塞线程池后，导致所有异步任务都必须等待。
4.异步任务，分为核心任务和普通任务，只有核心任务中出现的系统级错误才会报错，异步任务的ui操作需要判断原activity是否处于激活状态。
5.尽量避免static成员变量引用资源耗费过多的实例,比如Context。
6.使用WeakReference代替强引用，弱引用可以让您保持对对象的引用，同时允许GC在必要时释放对象，回收内存。对于那些创建便宜但耗费大量内存的对象，即希望保持该对象，又要在应用程序需要时使用，同时希望GC必要时回收时，可以考虑使用弱引用。
7.超级大胖子Bitmap及时的销毁(Activity的onDestroy时，将bitmap回收)设置一定的采样率巧妙的运用软引用drawable对应resid的资源，bitmap对应其他资源。
8.保证Cursor 占用的内存被及时的释放掉，而不是等待GC来处理。并且 Android明显是倾向于编程者手动的将Cursor close掉。
9.线程也是造成内存泄露的一个重要的源头。线程产生内存泄露的主要原因在于线程生命周期的不可控。
10.如果ImageView的图片是来自网络，进行异步加载。
11.应用开发中自定义View的时候，交互部分，千万不要写成线程不断刷新界面显示，而是根据TouchListener事件主动触发界面的更新。
三、AndroidUI优化
1.layout组件化，尽量使用merge及include复用
2.使用styles，复用样式定义
3.软键盘的弹出控制，不要让其覆盖输入框
4.数字、字母和汉字混排占位问题：将数字和字母全角化。由于现在大多数情况下我们的输入都是半角，所以 字母和数字的占位无法确定，但是一旦全角化之后，数字、字母的占位就和一个汉字的占位相同了，这样就可以避免由于占位导致的排版问题
5.英文文档排版：textview自动换行时要保持单词的完整性，解决方案是计算字符串长度，然后手动设定每一行显示多少个字母并加上‘n‘
6.复杂布局使用RelativeLayout
7.自适应屏幕，使用dp替代pix
8.使用android:layout_weight或者TableLayout制作等分布局
9.使用animation-list制作动画效果
篇3：Android：使用SparseArray代替HashMap优化性能
之前看到一篇关于adapter的文章用到了SparseArray，所以在这里写写关于SparseArray的用法，
SparseArray是官方针对安卓所写的容器，与HashMap类似，不过性能比HashMap好。
SparseArray实现了Cloneable接口，还可以调用clone方法。
首先看看SparseArray的用法：
构造：
SparseArray的构造与我们用惯的HashMap，ArrayList一样也是new出一个实例然后使用。
SparseArray
SparseArray
也可以在构造的时候就指定大小:
SparseArray
添加元素：
用惯ArraList和HashMap的我们知道要往容器里面添加元素可以分别调用add和put方法。 SparseArray也一样，可以调用put(int key,E value); 相信有读者一经发现上面构造SparseArray的时候已经发现，构造的时候只指定一个泛型，而不像HashMap那样构造的时候要指定两个泛型类型：new HashMap
SparseArray
public void append(int key, E value)SparseArray储存数据是使用二分法储存，说储存的数据是根据键的大小，从小到大排列。
取值：
既然可以添加那么自然可以取出来：
public E get(int key) ;
根据键取值。 除此之外还有一个方法可以取值：
public E get(int key, E valueIfKeyNotFound) ;
可以看到多了一个参数，从第二个参数的名字可以猜到，当找不到该键的值得时候默认使用第二个参数的值。
除了按键取值之外还可以按顺序取键，按顺序取值： 查看第几个位置的值：
public int keyAt(int index)
查看第几个位置的键：
public E valueAt(int index)
如果所查的键或值没有的话会返回负数。
删除：
delete(int key) remove(int key) delete与remove的效果是一样的这里不多说 除此之外还有： removeAt(int index) //按顺序删除
clear() 全部清空
改：
public void setValueAt(int index, E value) public void put(int key, E value)
setValueAt可以将index位置上的值改成value 而put方法前面说过，如果说put进去的键已经存在那么就会覆盖，达到修改的效果。如果put进去的键还没有的话就增加。
说完基本的增删改查再扯一下其它：
既然官方推荐使用SparseArray，那么在编码过程中遇到键为int形式的则尽量使用SparseArray代替map。
篇4：Android性能检测工具――traceview
一、标注测试的代码区域
如果我们想要测试gridView设置适配器这段代码，该怎么做呢？很简单，用两行代码夹住它~
原始的代码：
mPhotoWall.setAdapter(mAdapter);
标注为测试的代码：
Debug.startMethodTracing(“my_trace_file”);
mPhotoWall.setAdapter(mAdapter);
Debug.stopMethodTracing();
这样我们就表明了，我们的测试是从setAdapter前开始，到它之后结束的，这里有个文件名，my_trace_file，这是我们测试后，得到测试报告的名字，一会再说。
PS：记得要加上权限：
二、查看测试报告
运行程序后，我们会在sdcard文件夹下找到我们的测试报告文件
如果我们想要查看的话，可以通过命令行，把它移动到d盘
adb pull /sdcard/my_trace_file.trace d:/
接着调用
adb pull /sdcard/my_trace_file.trace d:/
即可打开测试报告的图形界面：
三、表头中各个参数的意义
nl Cpu Time%：方法在运行期间被调用的时间占总时间的百分比，
Incl Cpu Time：方法执行的总时间（包括调用子函数所消耗的时间）：调用该方法每次所需要消耗的时间*执行次数。
Excl Cpu Time%：方法自身所消耗的时间（不包括调用其他方法所消耗的时间）占总时间的百分比。
Excl Cpu Time：方法自身所消耗的时间。
Incl Real Time%：方法真正执行的时间占总时间的百分比。
Incl Real Time：方法真正被执行的时间。
Excl Real Time%：方法真正被执行的时间占总时间的百分比
Excl Real Time：方法真正被执行的所消耗的时间
Calls+RecurCalls/Total：方法被调用的次数+重复调用的次数
Cpu Time/Call：方法每次被执行的时间
Real Time/Call：方法真实被执行的时间
PS：一般在activity的onCreate()中添加Debug.startMethodTracing(“Test”), 在onStop()中来调用Debug.stopMethodTracing()。这样当我们切换到其它activity或者点击home键的时候onStop()就会被调用，我们也就可以得到完整的trace file。
篇5：android性能测试systrace
一：简介
systrace 是 Android4.1 引入的一套用于做性能分析的工具，
基于 Linux 内核的 ftrace 机制（用于跟踪 Linux 内核的函数调用），
可以输出各个线程当前的函数调用状态。
它可帮助开发者收集 Android 关键子系统（如 surfaceflinger、
WindowManagerService 等 Framework 部分关键模块、服务）
的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能
二：内核配置
Kernel hacking---->Tracers
<?www.2cto.com/kf/ware/vc/“ target=”_blank“ class=”keylink“>vcD4KPHA+PHN0cm9uZz7I/aO6IGluaXQucmMgxeTWwzwvc3Ryb25nPjxicj4KzO280yBtb3VudCBkZWJ1Z2ZzIG5vbmUgL3N5cy9rZXJuZWwvZGVidWcvPC9wPgo8cD48YnI+CjwvcD4KPHA+PC9wPgo8c3Ryb25nPsvEo7rKudPDPC9zdHJvbmc+Cru3vrOjumFuZHJvaWQgNC4zPGJyPgphZGIgway908nosbijqM34wucvVVNCo6kKPGJyPgrA/aO6PGJyPgpjZCBleHRlcm5hbC9jaHJvbWl1bS10cmFjZSAvL7TLtKbTw7XEysdhbmRyb2lk1LTC69bQtcRzeXN0cmFjZaOs0rK/ydLU08NTREvW0LXECjxicj4KcHl0aG9uIHN5c3RyYWNlLnB5IC1iIDMyNzY4IC10IDE1IGdmeCBpbnB1dCB2aWV3IHdlYnZpZXcgd20gYW0gXAphdWRpbyB2aWRlbyBjYW1lcmEgaGFsIHJlcyBkYWx2aWsgc2NoZWQgZnJlcSBpZGxlPGJyPgo8YnI+Ci1iIDo8YnI+Cta4tqggdHJhY2UgtcQgYnVmILOktsgKPGJyPgotdDo8YnI+Cta4tqi8x8K8tcTKsbzko6y1pc67w+sKPGJyPgpnZnggaW5wdXQgdmlldyB3ZWJ2aWV3ILXIOjxicj4K1ri2qNKqvMfCvLXExNrI3brNIGZyYW1ld29ya3MvbmF0aXZlL2NtZHMvYXRyYWNlL2F0cmFjZS5jcHDA78PmtcQga19jYXRlZ29yaWVzIMr91+mxo7PW0rvWwgo8YnI+Cgo8YnI+CjxzdHJvbmc+zuWjur3hufs8L3N0cm9uZz4KveG5+8rks/a1vSBleHRlcm5hbC9jaHJvbWl1bS10cmFjZS90cmFjZS5odG1sPGJyPgrKudPDuci46OSvwMDG97Tyv6o8YnI+CjxpbWcgc3JjPQ==”www.2cto.com/uploadfile/Collfiles/1121/201411210858494.jpg“ alt=”\“>
附：参数说明
篇6：由浅入深讲解android开发中listview的性能优化
ListView是一种可以显示一系列项目并能进行滚动显示的View，在每行里，既可以是简单的文本，也可以是复杂的结构。一般情况下，你都需要保证ListView运行得很好（即：渲染更快，滚动流畅）。在接下来的内容里，我将就ListView的使用，向大家提供几种解决不同性能问题的解决方案。
如果你想使用ListView，你就不得不使用ListAdapter来显示内容。SDK中，已经有了几种简单实现的Adapter：
· ArrayAdapter
· SimpleAdapter （显示Maps列表）
· SimpleCursorAdapter（显示通过Cursor从DB中获取的信息）
这些实现对于显示简单的列表来说，非常棒！一旦你的列表比较复杂，你就不得不书写自己的ListAdapter实现。在多数情况下，直接从ArrayAdapter扩展就能很好地处理一组对象。此时，你需要处理的工作只是告诉系统如何处理列表中的对象。通过重写getView(int, View, ViewGroup)方法即可达到。
在这里，举一个你需要自定义ListAdapter的例子：显示一组图片，图片的旁边有文字挨着。
图片需要实时从internet上下载下来。让我们先创建一个Class来代表列表中的项目：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29public class ImageAndText { private String imageUrl; private String text; public ImageAndText(String imageUrl, String text) {this.imageUrl = imageUrl; this.text = text; } public String getImageUrl() { return imageUrl; } public String getText() { returntext; } }现在，我们要实现一个ListAdapter，来显示ImageAndText列表。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71public class ImageAndTextListAdapter extends ArrayAdapter这些View都是从“image_and_text_row.xml”XML文件中inflate的：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31”1.0“ encoding=”utf-8“?>”schemas.android.com/apk/res/android“android:orientation=”horizontal“ android:layout_width=”fill_parent“android:layout_height=”wrap_content“>
这个ListAdapter实现正如你所期望的那样，能在ListView中加载ImageAndText，
但是，它唯一可用的场合是那些拥有很少项目、无需滚动即可看到全部的列表。如果ImageAndText列表内容很多的时候，你会看到，滚动起来不是那么的平滑（事实上，远远不是）。
性能改善
上面例子最大的瓶颈是图片需要从internet上下载。因为我们的代码都在UI线程中执行，所以，每当一张图片从网络上下载时，UI就会变得停滞。如果你用3G网络代替WiFi的话，性能情况会变得更糟。
为了避免这种情况，我们想让图片的下载处于单独的线程里，这样就不会过多地占用UI线程。为了达到这一目的，我们可能需要使用为这种情况特意设计的AsyncTask。实际情况中，你将注意到AsyncTask被限制在10个以内。这个数量是在Android SDK中硬编码的，所以我们无法改变。这对我们来说是一个制限事项，因为常常有超过10个图片同时在下载。
AsyncImageLoader
一个变通的做法是手动的为每个图片创建一个线程。另外，我们还应该使用Handler来将下载的图片invoke到UI线程。我们这样做的原因是我们只能在UI线程中修改UI。我创建了一个AsyncImageLoader类，利用线程和Handler来负责图片的下载。此外，它还缓存了图片，防止单个图片被下载多次。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81public class AsyncImageLoader { private HashMap篇7：web服务器性能优化
web服务器性能优化
作为一种资源的组织和表达机制，Web已成为Internet最主要的信息传送媒介。因此Web的性能已经成为判断一个网站成功与否的一个重要评估标准。而Web服务器则是决定Web性能的重要环节。
Web服务器性能就是指一个Web服务器响应用户请求的能力。为了提高Web服务器的性能人们进行了诸多尝试，已经取得了可喜的成果。本文通过对前人研究结果的分析，提出了在具体应用环境中优化Web服务器的方法和策略。
Web服务器概述
Web系统在现在网络中广泛使用，而Web服务器则是Web系统的一个重要组成部分。完整的Web结构应包括:HTTP协议，Web服务器，通用网关接口CGI、Web应用程序接口、Web浏览器。
Web服务器是指驻留在因特网上某种类型计算机的程序。它是在网络中信息提供者基干HTTP的为实现信息发布、资料查询、数据处理等诸多应用搭建基本平台的服务器，其主要功能是提供网上信息浏览服务。当Web浏览器(客户端)连到服务器并请求文件时，服务器将处理该请求并将文件发送到该浏览器上，附带的信息会告诉浏览器如何查看该文件(即文件类型)。
Web服务器在web页面处理中大致可分为三个步骤:第一步，web浏览器向一个特定的服务器发出Web页面请求;第二步，Web服务器接收到 web页面请求后，寻找所请求的web页面，并将所请求的Web页面传送给Web浏览器;第三步，Web服务器接收到所请求的web页面，并将它显示出来。
web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。在Web上，常见的大多数表单核搜索引擎上都是用的是CGI脚本。
影响web应用服务器性能的因素
Web服务器的性能就是指一个Web服务器响应用户请求的能力，服务器的性能对于一个Web系统来说至关重要。为了提高Web服务器的性能人们进行了许多尝试，也采用了许多技术和方法，但是这些技术和方法往往缺乏适用性。
通过对前人的研究分析可以发现，在web服务器的优化方而存在这种问题的原因主要有两个:一方面是服务器性能评测造成的，一方面是选用优化方案时考虑不全面造成的。
现行的服务器性能评测工具在对Web服务器进行评测时，其实是由一台或几台计算机模拟客户机，与被测的Web服务器进行通信，它们其实组成的只是一个局域网的环境，这与真正的广域网的环境有一定的差别。
另外，评测工具在选择网络负载时，虽然已经尽可能的接近真实负载，但是与持续的高频率负载要求仍有差距;再者，在性能测试指标的选择与分析上也不够合理，造成了分析结果不够公正、可靠。而在选用优化Web服务器的方法时，往往只是考虑Web服务器这一个方面，很少结合具体的应用环境。所以就造成了评测结果不够科学，应用环境考虑不够全面，Web服务器性能优化缺乏针对性。因此在具体的应用环境下优化Web服务器的'性能需要另外考虑以下两个主要因素:网络特性和Web负载特点。
网络特性是指web服务器所在网络情况，是广域网还是局域网，是高速网络(传输速率在1OOMb/s以上的网络就叫做高速网络)还是低速网络，在不同的网络中相关的传输数据的类型、网络相应时间、吞吐量，利用率等网络特性不尽相同，所以要加以区分，具体情况具体分析。
而在Web负载特点方面，由于在对Web服务器进行评测时，一个非常关键的因素就是Web负载的选择。评测工具虽然有多种，但是它们都在选择负载上做足了功课。关于Web负载特点的研究主要目的就在于对Web服务器性能进行评测时，可以根据这些特点，选择模拟最真实的Web负载的评测工具以便获得最贴近事实的Web服务器性能评测数据，以便更好的对其进行分析和得出优化方案。
【Android性能优化系列――Understanding Overdraw】相关文章：
7.android ORM框架的性能简单测试(androrm vs ormlite)
8.android Actionbar 上的 MenuItem 的 使用细节和优化
10.android全屏显示
文档为doc格式
