Android 应用开发性能优化完全分析-北京尚学堂.docVIP

Android 应用开发性能优化完全分析 1 背景 其实有点不想写这篇文章的，但是又想写，有些矛盾。不想写的原因是随便上网一搜一堆关于性能的建议，感觉大家你一总结、我一总结的都说到了很多优化注意事项，但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用，啥啥啥该咋用等，却很少有较为系统的进行真正性能案例分析的，大多数都是嘴上喊喊或者死记住规则而已（当然了，这话我自己听着都有些刺耳，实在不好意思，其实关于性能优化的优质博文网上也还是有很多的，譬如Google官方都已经推出了优化专题，我这里只是总结下自的感悟而已，若有得罪欢迎拍砖，我愿挨打，因为我之前工作的一半时间都是负责性能优化）。 当然了，本文不会就此编辑这么一次，因为技术在发展，工具在强大（写着写着Android Studio 1.4版本都推送了），自己的经验也在增加，所以本文自然不会覆盖所有性能优化及分析；解决的办法就是该文章会长期维护更新，同时在评论区欢迎你关于性能优化点子的探讨。 Android应用的性能问题其实可以划分为几个大的模块的，而且都具有相对不错的优化调试技巧，下面我们就会依据一个项目常规开发的大类型来进行一些分析讲解。 PS：之前呆过一家初创医疗互联网公司，别提性能优化了，老板立完新项目后一个月就要求见到上线成品，这种压迫下谈何性能优化，纯属扯蛋，所以不到三个月时间我主动选择撤了，这种现象后来我一打听发现在很多初创公司都很严重，都想速成却忽略了体验。 PPPS：本文只是达到抛砖引玉的作用，很多东西细究下去都是值得深入研究的，再加上性能优化本来就是一个需要综合考量的任务，不是说会了本文哪一点就能做性能分析了，需要面面俱到才可高效定位问题原因。 2 应用UI性能问题分析 UI可谓是一个应用的脸，所以每一款应用在开发阶段我们的交互、视觉、动画工程师都拼命的想让它变得自然大方美丽，可是现实总是不尽人意，动画和交互总会觉得开发做出来的应用用上去感觉不自然，没有达到他们心目中的自然流畅细节；这种情况之下就更别提发布给终端用户使用了，用户要是能够感觉出来，少则影响心情，多则卸载应用；所以一个应用的UI显示性能问题就不得不被开发人员重视。 2-1 应用UI卡顿原理 人类大脑与眼睛对一个画面的连贯性感知其实是有一个界限的，譬如我们看电影会觉得画面很自然连贯（帧率为24fps），用手机当然也需要感知屏幕操作的连贯性（尤其是动画过度），所以Android索性就把达到这种流畅的帧率规定为60fps。 有了上面的背景，我们开发App的帧率性能目标就是保持在60fps，也就是说我们在进行App性能优化时心中要有如下准则： 换算关系：60帧/秒-----------16ms/帧； 准则：尽量保证每次在16ms内处理完所有的CPU与GPU计算、绘制、渲染等操作，否则会造成丢帧卡顿问题。 从上面可以看出来，所谓的卡顿其实是可以量化的，每次是否能够成功渲染是非常重要的问题，16ms能否完整的做完一次操作直接决定了卡顿性能问题。 当然了，针对Android系统的设计我们还需要知道另一个常识；虚拟机在执行GC垃圾回收操作时所有线程（包括UI线程）都需要暂停，当GC垃圾回收完成之后所有线程才能够继续执行（这个细节下面小节会有详细介绍）。也就是说当在16ms内进行渲染等操作时如果刚好遇上大量GC操作则会导致渲染时间明显不足，也就从而导致了丢帧卡顿问题。 有了上面这两个简单的理论基础之后我们下面就会探讨一些UI卡顿的原因分析及解决方案。 2-2 应用UI卡顿常见原因 我们在使用App时会发现有些界面启动卡顿、动画不流畅、列表等滑动时也会卡顿，究其原因，很多都是丢帧导致的；通过上面卡顿原理的简单说明我们从应用开发的角度往回推理可以得出常见卡顿原因，如下： 人为在UI线程中做轻微耗时操作，导致UI线程卡顿； 布局Layout过于复杂，无法在16ms内完成渲染； 同一时间动画执行的次数过多，导致CPU或GPU负载过重； view过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重； View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染； 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作； 冗余资源及逻辑等导致加载和执行缓慢； 臭名昭著的ANR； 可以看见，上面这些导致卡顿的原因都是我们平时开发中非常常见的。有些人可能会觉得自己的应用用着还蛮OK的，其实那是因为你没进行一些瞬时测试和压力测试，一旦在这种环境下运行你的App你就会发现很多性能问题。 2-3 应用UI卡顿分析解决方法 分析UI卡顿我们一般都借助工具，通过工具一般都可以直观的分析出问题原因，从而反推寻求优化方案，具体如下细说各种强