Android流畅度优化
流畅度对于任何产品来说其重要性不言而喻，相对于iPhone，Android手机的一个诟病就是卡…为了在后续的开发中避免卡顿问题，细读了腾讯TMQ专行测试团队出品的《移动App性能评测与优化》，本文内容是阅读此书的笔记。
评判流畅度的标准
FPS
FPS:Frames per second，计算方法(来自当我们讨论流畅度的时候，我们究竟在说什么？)
FPS = (v2 - v1) / (t2 - t1);
即每秒绘制次数。FPS并不能很好地反应一个App的卡顿程度，因为它不适用于绝大多数非连续绘制的应用。(有时候App是静态页面，并没有绘制，所以可能很流畅，但是FPS却很低)
流畅度(SM)
SM的计算方法(来自当我们讨论流畅度的时候，我们究竟在说什么？)：
SM = (60* totalSeconds - totalSkippedFrames) / totalSeconds;
它反映的是丢帧的数量(60 - SM)，可以很好的弥补 FPS 无法准确刻画非连续绘制的应用显示性能的缺陷。
卡顿的原因
导致应用卡顿的原因有很多，UI布局不合理的布局问题，Lint代码分析中建议修改的代码问题，App逻辑中存在的逻辑问题，IO操作不合理的IO问题。
UI布局问题
- 过度绘制(去除多余的背景)
- 没有用的父布局(可用merge标签解决)
- 布局层次过深(使用线性布局导致，可用RelativeLayout代替LinearLayout)
- 不常用的UI被设置为GONE(使用ViewStup代替)
Lint分析代码问题
- DrawAllocation：避免在绘制或者解析布局(draw/layout)时分配对象，比如在onDraw()中实例化Paint对象。
- Wakelock：手机不能进入休眠状态，导致手机一直保持高耗电状态。
- Recycle：某些资源，比如TypedArrays、V嗯咯cityTrackers，用完之后应该被回收，但是忘记回收。
- ObsoleteLayoutParam：Layout中无用的参数。
- UseCompoundDrawables：可优化的布局，包含一个ImageView和一个TextView的线性布局可悲CompoundDrawable的TextView代替。
- HandlerLeak：Handler的使用不当导致内存泄漏。
- UseSparseArrays：尽量使用Android的SparseArray代替HashMap。
- UseValueOf：需要常量时不应该直接new，应该用ValueOf转换。比如需要整数42的对象，不要直接new Integer(42)，应该使用Integer.valueOf(42)，这样可以省内存。
- DisableBaselineAlignment：如果LinearLayout被用于嵌套的layout空间计算，它的android:baselineAligned属性应该被设置成false，以加速layout计算。
- InefficientWeight：当线性布局里面只有一个控件，并且使用了weight的时候，最好把width和height设置为0，这样可以省略布局的measure过程。
- FloatMath：使用FloatMap代替Math。
- nestedWeights：避免嵌套weight，那将拖累执行效率。
- UnuseResources/UnusedIds：未被适应的资源会使程序变大，并且编译速度降低。
- Overdraw：如果RootView指定一个背景Drawable，会先用Theme的背景绘制一遍，然后才用指定的背景，可以设置theme的backgroud为null来解决
- UselessLeaf/UselessParent：View或者View的父亲没有用，应该把它移除，避免加深布局的层次。
- UnusedNamespace：有些布局没有必要使用namespace，会影响代码执行效率。
App逻辑问题
- 主线程的耗时操作
- 执行主线程时，其它线程抢占CPU
IO层问题
- UI线程中频繁读写磁盘
- 读写内容重复
流畅度优化经验
布局原则
- 尽量多使用RelativeLayout代替LinearLayout。
- 布局层次一样时，使用LinearLayout代替RelativeLayout，因为LinearLayout性能要高一些。
- 将可复用的组件抽取出来并通过include标签使用。
- 动态地inflation view性能要比setVisiblity性能要好，使用VIewStup是最好的选择。
- 使用merge标签减少布局的嵌套层次。
- 去除多余的背景颜色，减少过度绘制。
- 使用Compound Drawables（包含图片的TextView）
- 嵌套使用包含layout_weight属性的LinearLayout会在绘制时花费昂贵的系统资源，因为每个子组件都需要被测量两次。在使用ListView和GridView的时候这个问题尤为重要，因为子组件会被重复创建，所以要尽量避免使用layout_weight。
ListView优化
- 复用convertView。
- 异步加载图片。
- 快速滑动时不显示图片。
- item要尽可能减少控件和布局的层次。ListView的背景色与cacheColorHint设置为相同颜色，可以提高滑动时的渲染性能。
- getView方法中不能做复杂的逻辑计算，特别是数据库访问和网络访问操作。
UI线程优化
- 不要阻塞UI线程：占用CPU较多的数据库操作尽可能在独立线程进行，如果频繁创建线程，考虑使用线程池。
- 不要在UI线程之外操作UI
卡顿优化的分析工具
GPU过度绘制+Trace for OpenGL -> 解决过度绘制
Hierarchy Viewer -> 查找UI布局不合理的地方
Traceview，Systrace -> 代码逻辑分析
StrictMode -> IO问题，UI线程中的IO操作，内存泄漏
关于流畅度问题的思考
卡顿的根本原因应该只有两个，一是CPU处理不过来(UI线程)，二是GPU绘制处理不过来。从CPU的方向考虑，线程抢占，内存不足(内存泄漏等)过高导致频繁GC，UI布局问题导致mesure、layout耗时过多，UI线程中的耗时操作等；而绘制处理不过来，应该是过度绘制导致的。
