现在安卓系统无论是性能还是体验上其实都不输于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的性能优化牵扯的知识点很多，除了上面讲过的这些常用解决方案，底层原理也值得我们深入探讨，此外还有性能监控还有工具的使用。
一篇文章难以详尽，我根据自己多年的Android开发经验把这些性能优化的底层原理还有各种问题的解决方案等都整理成了PDF文档。
这份笔记免费开源分享，有需要的朋友点个赞，然后点击【此处】进入群共享资源自取，或者直接通过下方代码块找我领取。**
// Wechat number（可复制）：
study5233
项目实战
除了理论部分，这边还给大家整理了一份各大厂的Android性能优化实战案例，里面详细的向大家介绍了互联网巨头的性能优化方案。
PS：本资料包含且不限于腾讯、爱奇艺、字节跳动、百度、京东、支付宝、搜狐、携程、谷歌、网易、高德等，几乎囊括了所有互联网大厂。
《性能优化知识技能手册》 理论总结配合 《大厂性能优化项目实战》 分析一起食用，效果更好哦~
这份笔记免费开源分享，有需要的朋友点个赞，然后点击【此处】进入群共享资源自取，或者直接通过下方代码块找我领取。**
// Wechat number（可复制）：
study5233
视频学习
【Android进阶学习】腾讯/阿里/字节等大厂Android性能优化项目实战大合集（41集全）_哔哩哔哩_bilibili
