背景
现在安卓系统无论是性能还是体验上其实都不输于iOS，只是因为手机厂商多而杂，他们会改源码，自定义系统，最后又过一遍不同开发水平工程师的手，导致很多手机即使在机器上面的跑分非常高，里面的APP运行也有卡顿现象。
而且这种卡顿会随着产品的更新迭代，功能的越发复杂，UI页面的越发丰富，变得更加严重。
但是，产品功能的更新需求，新功能的开发和UI的丰富都是用户的需求，是不可逆的趋势。在这样的情况下，优秀的性能优化人才一直是几大头部互联网公司高价竞聘的对象。
性能优化的目的
- 流畅（解决：卡顿）
- 稳定（解决：内存溢出、崩溃）
- 低耗损（解决：耗电快、流量大、网络慢）
- 小安装包（解决：APK过大）
性能优化的方向
- 布局优化
- 绘制优化
- 网络优化
- APK优化
- 内存优化
- 卡顿优化
- 耗电优化
- ListView/RecycleView及Bitmap/图片优化
- 数据库SQLite优化
- 启动优化
- 数据结构优化
- 稳定性优化
性能优化方案
布局优化
本质：减少View的层级，提高测量、布局和绘制的速度。
常用方案：
- 优先选择LinearLayout布局可以减少View的层级（注意相同组件可能RelativeLayout绘制时间长）；
- 使用 < include > 标签抽取常用的布局组件中的共同部分（便于复用）；
- 用 < ViewStub > 标签加载不常用的布局，延迟加载（需要的时候在activity中加载出来）；
- 用 < Merge > 标签减少布局的嵌套层次
绘制优化
本质：View的onDraw方法要避免执行大量的操作
常用方案：
onDraw中不要创建新的局部对象（避免产生大量的临时对象占用过多内存）；
onDraw方法中不要做耗时的任务（尽量降低onDraw方法中的复杂度）
网络优化
本质：减少流量消耗、电量消耗、用户等待时间，提高用户体验。
常用方案：
- 尽量减少网络请求，能够合并的就尽量合并
- 避免DNS解析，根据域名查询可能会耗费上百毫秒的时间，也可能存在DNS劫持的风险。可以根据业务需求采用增加动态更新IP的方式，或者在IP方式访问失败时- 切换到域名访问方式。
- 大量数据的加载采用分页的方式
- 网络数据传输采用GZIP压缩
- 加入网络数据的缓存，避免频繁请求网络
- 上传图片时，在必要的时候压缩图片
APK优化
本质：减少安装包体积。
常用方案：
- 减少应用中不必要的资源文件，比如图片，在不影响APP效果的情况下尽量压缩图片，有一定的效果
- 在使用了SO库的时候优先保留v7版本的SO库，删掉其他版本的SO库。
- res资源优化
- 代码优化
- lib资源优化
- assets资源优化
- 代码混淆
- 插件化
- 7z极限压缩
PS：详细具体的操作实现实现原理，后文另外有专门的分析。
内存优化
本质：避免内存泄漏、扩大内存。
常用方案（从不同方向讨论）：
扩大内存：
- 一个是在清单文件中的Application下添加largeHeap="true"这个属性，另一个就是同一个应用开启多个进程来扩大一个应用的总内存空间。
- 第二种方法其实就很常见了，比方说我使用过个推的SDK，个推的Service其实就是处在另外一个单独的进程中。
内存泄漏（多方向讨论）：
静态变量导致的内存泄漏
办法：将内部类设为静态内部类或独立出来；使用context.getApplicationContext()。
单例模式导致的内存泄漏
方案：传参context.getApplicationContext()。
属性动画导致的内存泄漏
方案：在Activity.onDestroy()中调用Animator.cancel()停止动画。
Handler导致的内存泄漏
方案：使用静态内部类+WeakReference弱引用；当外部类结束生命周期时清空消息队列。
线程导致的内存泄漏
方案：将AsyncTask和Runnable设为静态内部类或独立出来；在线程内部采用弱引用保存Context引用。
资源未关闭导致的内存泄漏
方案：在Activity销毁的时候要及时关闭或者注销。例如：
① BraodcastReceiver：调用unregisterReceiver()注销；
②Cursor，Stream、File：调用close()关闭；
③Bitmap：调用recycle()释放内存（2.3版本后无需手动）。
Adapter导致的内存泄漏
方案：在构造Adapter时使用缓存的convertView。
WebView导致的内存泄漏
方案：其实避免WebView导致内存泄漏的最好方法就是让WebView所在的Activity处于另一个进程中，当这个Activity结束时杀死当前WebView所处的进程即可，我记得阿里钉钉的WebView就是另外开启的一个进程，应该也是采用这种方法避免内存泄漏。
集合类泄漏
方案：在onDestry时回收不需要的集合。
PS：为什么会导致泄漏，以及泄漏的具体情况，更多原理，后文另外有专门的分析整理。
卡顿优化
本质：优化UI、提高启动跳转还有响应的速度。
常用方案：
- 不在主线程进行网络访问/大文件的IO操作
- 绘制UI尽量减少绘制UI层次；减少不必要的view嵌套，可以用Hierarchy Viewer工具来检测，后面会详细讲；
- 当布局是用的FrameLayout，可以把它改成merge，可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout)
- 提高显示速度,使用ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。
- 在view层级相同的情况下，尽量使用 LinerLayout而不是RelativeLayout；因为RelativeLayout在测量的时候会测量二次，而LinerLayout测量一次，可以看下它们的源码；
- 删除控件中无用的属性;
- 布局复用.比如listView 布局复用
- 尽量避免过度绘制（overdraw）,比如：背景经常容易造成过度绘制。由于我们布局设置了背景，同时用到的MaterialDesign的主题会默认给一个背景。这时应该把主题添加的背景去掉；还有移除
- XML 中非必须的背景
- 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。也是避免过度绘制．
- 启动优化,启动速度的监控，发现影响启动速度的问题所在，优化启动逻辑，提高应用的启动速度。比如闪屏页面，合理优化布局，加载逻辑优化，数据准备.
- 合理的刷新机制，尽量减少刷新次数，尽量避免后台有高的 CPU 线程运行，缩小刷新区域。
耗电优化
本质：减少电量消耗。
常用方案：
- 合理的使用wake_lock锁，wake_lock锁主要是相对系统的休眠(这里就是为了省电，才做休)而言的，意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题，比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了wake_lock锁。
- 使用jobScheduler2，集中处理一些网络请求，有些不用很及时的处理可以放在充电的时候处理，比如，图片的处理，APP下载更新等等；
- 计算优化，避开浮点运算等。
- 数据在网络上传输时，尽量压缩数据后再传输，建议用FlatBuffer序列化技术，这个比json效率高很多倍，不了解FlatBuffer，建议找资料学习一下。
现如今，国内移动互联网红利期已过，Android 开发也从最初的一人难求，到后来的一个岗位百人竞投，僧多粥少的情况直接导致整个行业对求职者的要求越来越高，Android 开发越来越规范，间接导致项目对质量要求的提升。启动优化、内存优化、App 崩溃监控等性能调优也逐渐成了人手必备的技能。
