背景

现在安卓系统无论是性能还是体验上其实都不输于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 崩溃监控等性能调优也逐渐成了人手必备的技能。

学习资源和路线

我这里就分享一份由大佬亲自收录整理的性能优化学习笔记，另外还有Android学习PDF+架构视频+面试文档+Android开发面试专题资料，高级进阶架构资料和视频。

总结

这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理，帮助大家在未来取得一份不错的答卷。 希望能帮助大家在技术的道路上更进一步。当然，你也可以拿去查漏补缺，提升自身的竞争力。真心希望可以帮助到大家，Android路漫漫，共勉！

由于文章篇幅有限，文档资料内容较多，本可以提供链接下载，但无奈容易被和谐，所以全部存档，需要这些文档这里的朋友，可以私信我，希望能够共同进步，共勉！