Android性能优化，大致可从如下两个方向进行分析

一、绘制优化

a.UI绘制
问题：应用启动慢，滑动或者点击卡顿
解决方案
1，从布局视图角度分析
I，使用HierarchyViewer工具检查是否需要优化布局。
1）使用标签重用视图
2）使用标签合并不需要或者是重复的节点。目的减少节点数量
3）层次过深考虑使用自定义View。目的减少节点数量
4）ViewSub延迟加载。当前不渲染
总体目标是为了减少当前需要渲染的视图数量，
减少总体measure、layout测量跟布局的时间（浅浅绿色）（红色、浅蓝色、蓝色、黄色会减少）
减少总体onDraw的时间（蓝色）
减少准备绘制图片的时间(浅蓝色)
减少执行的命令（红色）
减少GPU的任务（黄色）
如果是单个视图绘制的时间过多需要逐个分析，需要使用TraceView工具
II，使用GPU过度绘制检查是否有过度绘制。
消除多余的背景资源。减少绘画层数
可以使用Canver.ClipRect跟Canver.QuickReject函数指定绘画区域。不去绘画重复区域
优化布局来减少节点数量
总体目的是为了减少对单区域的绘制次数
2，从函数调用角度分析
1），通过TraceView/AS->CPU Profile工具检查是否有函数耗时太长。单次耗时过长，频繁调用导致耗时太长
通过观察火焰图
2），onMeasure、onLayout、onDraw函数是否执行时间过长。
如果函数逻辑调用没有问题需要看看是否能从布局视图的角度去优化
3），检查短时间内动画执行的次数过多
3，从CPU资源角度分析
子线程过多，主线程调度延迟。由于主线程获取不到CPU资源，可将子线程优先级设置为后台线程

通过systrace工具检查丢帧

b.应用启动
先对比查看应用启动时间 adb shell am start -W package/xxxActivity
解决方案：可通过systrace查看是哪个线程/进程阻塞了应用的启动
加快应用启动的方法：
1，延迟加载主题：先将主题设为设为透明，等到onCreate函数中再通过setTheme加载主题
2，延迟加载View
3，推迟任务
4，布局优化
5，只初始化必须的

二、内存优化

a、先dumpsys meminfo package 查看内存占用情况，暂时用不到的应用先不启动加载
分析方式
1，AS->Memory Profile/ES->Heap工具观察内存是否一直增长。如果是，可能发生了泄漏
2，dumpsys meminfo 观察几个重要的数据(Activities、ViewRootImpl、Views)的数量是否在Activity退出进入时有规律的增加减少，如果不是可能发生了泄漏
3，MAT来具体分析泄漏位置
1)，多抓几张内存快照过滤之后做对比，看看对象数量的增减情况
2)，定位之后通过GC ROOT分析它们的引用树
常见内存泄漏情形
1)，Handler引发的泄漏
2)，单例引发的泄漏
3)，间接引用引发的泄漏
非静态内部类创建静态实例造成的内存泄漏
4)，线程造成的内存泄漏
5)，资源使用完未关闭
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。
6)，集合的数据引发的泄漏
解决方案
1，数据优化：使用缓存LruCache。保存到本地
2，使用高性能容器SparseArray和ArrayMap代替HashMap

b，线程池优化：使用线程池

c，Bitmap优化：
1，降低采样率：BitmapFactory.Options 参数inSampleSize的使用，先把 options.inJustDecodeBounds设为true，只是去读取图片的大小
2，复用内存：
1，BitmapFactory.Options 参数iinBitmap跟SoftReference的结合。Android4.4
3，要选择合适的图片规格：ARGB_4444、ARGB_8888、RGB_565
4，不实用的调用recycle()释放

d，View优化：
1，不在onDraw中创建对象，不做耗时操作
2，View复用。ListView、resycview复用View

e，关闭不必要的Service、BroadcastReceiver

f，OOM
1，大数据使用分页加载
2，图片需要降低采样率

g，内存抖动
1，避免在调用频繁的函数中创建对象