欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~
本文由WeTest质量开放平台团队发表于云+社区专栏
一款app除了要有令人惊叹的功能和令人发指交互之外，在性能上也应该追求丝滑的要求，这样才能更好地提高用户体验。
以下是本人在工作中对经历过的性能优化的一些总结，依据故事的发展路线，将其分为了5个部分，分别是：常见的性能问题；产生性能问题的一些可能原因；解决性能问题的套路；代码建议及潜在性能问题排查项。
1.png
如看不清大图，下文会有拆解
一 首先，我们先了解一下都有哪些性能问题
2.png
1、内存泄露。
通俗来讲，内存泄露不仅仅会造成应用内存占用过大，还会导致应用卡顿，造成不好的用户体验，至于，为什么一个“小小的”内存泄露会造成应用卡顿，我不得不拿这幅图来说说话了。
3.png
没错，这就是Android开发童鞋需要了解的Generational Heap Memory模型，这里我们只关心当对象在Young Generation中存活了一段时间之后，如果没被干掉，那么会被移动到Old Generation中，同理，最后会移动到Permanent Generation中。那么用脚想一想就知道，如果内存泄露了，那么，抱歉，你那块内存随时间推移自然而然将进入Permanent Generation中，然鹅，内存不是白菜，想要多少就有多少，这里，因为沙盒机制的原因，分配给你应用的内存当然是有那么一个极限值的，你不能逾越（有人笑了，不是有large heap么，当然我也笑了，我并没有看到这货被宗师android玩家青睐过），好了，你那块造成泄露内存的对象占着茅坑不拉屎，剩下来可以供其他对象发挥的内存空间就少了；打个比方，舞台小了，演员要登台表演，没有多余空间，他就只能等待其他演员下来他才能表演啊，这等待的时间，是没法连续表演的，所以就卡了嘛。
2、频繁GC
呵呵，频繁GC会造成卡顿，想必你经过上面的洗礼，已经知道了为什么，不错，当然也是因为“舞台空间不足，新的演员上台表演需要先让表演完的下来”。那么造成这种现象的原因是什么呢？
a、内存泄露，好的，你懂了，不用讲了，这个必须有可能会造成。
b、大量对象短时间被创建，又在短时间内“需要”被释放，注意这里的需要，其实是不得不，为什么，同样是因为“舞台空间不够了”，举个例子，在onDraw中new 对象，因为onDraw大约16ms会执行一次（wait，你能否确定一下，什么是大约16ms，对不起，不能，掉帧了就不是，哪怕掉那么一点点）。脑补一下，每秒中创建大约60个对象，嗯，骚年，你以为Young Generation是白菜么，想拿多少就拿多少，对不起，这里是限量的，这里用完了，在来申请，我就得去回收一些回来，我回收总得耗时间吧，耗时间，好吧，onDraw 等着等着就错过了下一个16ms的执行了，如是，用户看起来就卡了。
3、耗电问题
km上有一个问题很尖锐，说是微视看小视频看一会手机就会发烫，所以，用户一直就很关注耗电问题，不过不好意思，我们的app至今还没有遇到过严重的耗电问题，虽然没有遇到比较严重的耗电问题，不代表就不需要去了解这样的问题的解决办法，我总结有：
a、没有什么特别重要的信息，比如，钱到账，电话来了，100元实打实无门槛代金券方法，等等，请不要打扰用户，不要频繁唤醒用户，否则，结果只能是卸载，或者关闭一切通知。
b、适当的做本地缓存，避免频繁请求网络数据，这里，说起来容易，做起来并非三刀两斧就能搞定，要配合良好的缓存策略，区分哪些是一段时间不会变更的，哪些是绝对不能缓存的很重要。
c、对某些执行时间较长的同步操作在用户充电且有wifi的时候在做，除非用户强制同步..等等，就不扯太多，因为后面还有很多内容。
4、OOM问题
呵呵，这个问题，想必经过前面1、2的洗礼，你应该已经明白这个什么原因导致的，你可以想想一下"舞台上将要上的一个演员是一个巨大胖子，即便不表演的演员都下来了，他还是挤不上去，怎么办，演砸了，还能怎么办，直接崩溃，散场！"造成这个问题的原因，可能有，（呵呵，保险起见，只能说可能，分析的时候可以从这里出发）
a、内存泄露了，想必你会心一笑。
b、大量不可见的对象占据内存，这个其实，很常见，只是大家可能一直不太关心罢了，比如，请求接口返回了列表有100项数据，每项数据比如有100个字段，其中你用户展示数据的只有10几个而已，但是，你解析的时候，剩下的99个不知不觉吃了你的内存，当，有个胖子要内存时，呵呵，嗝屁了。
c、还有一种很常见的场景是一个页面多图的场景，明明每个图只需要加载一个100_100的，你却使用原始尺寸（1080_1980）or更大，而且你一下子还加载个几十张，扛得住么？所以了解一下inSampleSize，或者，如果图片归你们上传管理，你可以借助万象优图，他为你做了剪切好不同尺寸的图片，这样省得你在客户端做图片缩放了。
二 以上了解了一些性能问题，这里，简单的串一串导致这些性能问题的原因
4.png
1、人为在ui线程中做了轻微的耗时操作，导致ui线程卡顿
嗯，很多小伙伴不以为然，以为在onCreate中读一下pref算什么，解析下json数据算得了什么，可实际情况是并不是这样的，正确的做法是，将这些操作使用异步封装起来，小伙伴可以了解一下rxjava，现在最新版本已经是rxjava2了，如果不清楚使用方式，可以Google一下。
2、layout过于复杂，无法在16ms完成渲染
这个很多小伙伴深有体会了，这里简单的了解下，我们先简单的把渲染大概分为"layout","measure""draw"这么几个阶段，当然你不要以为实际情况也是如此，好，层级复杂，layout,measure可能就用到了不该用的时间，自然而然，留给draw的时间就可能不够了，自然而然就悲剧了。那么以前给出的很多建议是，使用RelativeLayout替换LinearLayout,说是可以减少布局层次，然鹅，现在请不要在建议别人使用RelativeLayout，因为ConstraintLayout才是一个更高性能的消灭布局层级的神器。ConstraintLayout 基于Cassowary算法，而Cassowary算法的优势是在于解决线性方程时有极高的效率，事实证明，线性方程组是非常适合用于定义用户界面元素的参数。由于人们对图形的敏感度非常高，所以UI的渲染速度显得非常重要。因此在2016年，iOS和Android都基于Cassowary算法来研发了属于自己的布局系统，这里是ConstraintLayout与传统布局RelativeLayout，LinearLayout实现时的性能对比，不过这里是老外的测试数据，原文可以参考这里。demo中也提供了测试的方法，感兴趣的小伙伴可以尝试一下咯。
5.png
测量/布局（单位：毫秒，100 帧的平均值）
3、同一时间执行的动画过多，导致CPU或者GPU负载过重
这里主要是因为动画一般会频繁变更view的属性，导致displayList失效，而需要重新创建一个新的displayList，如果动画过多，这个开销可想而知