给产品经理讲技术｜程序猿到底做了啥？（一）

【相关推荐】

给产品经理讲技术｜什么是代码混淆

给产品经理讲技术 | 撩妹技术三部曲之”框架“

给产品经理讲技术丨没线，并不可怕？

给产品经理讲技术丨提需求的正确姿势是什么

给产品经理讲技术丨产品后悔药来了，讲讲热补丁技术

在一个软件产品的迭代中，有一些非产品类的需求也是程序猿不得不做的工作，比如之前讲过的「代码重构」和今天要讲的「性能优化」。

「优化」在汉语中的愿意为「采取一定措施使变得优秀」，在计算机领域，则一般是指在完成同样的功能前提下，消耗更低的资源（包括时间、内存、电量等），对应到具体的产品形态上，则是动画更流畅，操作更顺滑，占用的存储空间更小等这些用户可以实实在在体验到的特性。对性能的持续优化，是一个追求卓越的产品所必不可少的。

然而，当程序猿对你说「昨天主要在做这里的优化」时，你知道他昨天到底做了什么又是如何做的吗？

1)启动速度优化

启动速度的快慢作为用户对你的第一印象，这是个必须重视的问题。我们将启动定义成从用户「打开」应用程序到「可操作」这个过程。每个应用程序都需要一个启动过程，这个过程中，应用程序需要准备好必须的资源并对功能模块初始化（其实还是准备资源啦）。

而在冷启动的过程中，这些资源都需要从外部存储器（磁盘、SD卡等）中加载，例如读取图片、文件、用户账户信息等。随着功能的扩展，功能依附的资源、数据越来越多，如果将所有的资源都一股脑的放在启动阶段加载，启动过程将会不断的被延长。

然而，在启动时，或者启动后的一段时间内，并不会用到所有的数据。将数据按照「必须的」、「可延时加载的」和「不需要主动加载的」进行分类，其中「必须的」资源会阻塞用户的操作，例如闪屏的初始化，首屏内容的数据准备等；「可延时加载的资源」则可以等到UI可操作后，「异步」的在线程中执行，控制的好的话，用户基本上不会感知到这个过程的存在。

一些非关键路径功能所需的资源，则可以延后到功能被真正使用时再进行初始化，不需要在启动过程中自动初始化。这样处理后，启动速度就会变的可控。启动速度优化的关键点，就是准确的区分出这三类资源，并尽量的压缩「必须」资源的数量，以及降低「可延时加载的」资源对UI操作的影响。

2）操作和动画卡顿的优化

在《庖丁解牛：来比比谁家的app更卡》中果果有讲到如何评价一个Android应用的「卡顿」程度，也提到了 。在解决「过度绘制」问题之前，程序猿首先要定位到哪个控件被错误的设置了背景。通过代码去查的话，过程会很「苦逼」，好在谷歌给「苦逼」的程序猿带来一个名叫Hierarchy Viewer的工具，让程序猿能在「苦逼」的道路上走的稍微不那么「苦逼」。

上图中每个灰色的方框都代表一个UI控件，横向的连线表示控件的父子关系，也就是UI的层级，越往右层级越深，而最左边的一个灰色方框你可以把它当做你手机的屏幕。用鼠标点击对应的灰色方框，Hierarchy Viewer会将当前方框对应的控件和其子控件的内容展示出来，这样，程序猿就可以快速的定位到哪一个控件被不科学的设置了背景资源。找到它，干掉它！

除了「过度绘制」外，过深的UI层级也会影响操作的流畅性。原因是系统的绘制和排版指令，都是通过控件树的根节点向叶子节点传递的，对应Hierarchy Viewer显示的内容就是从左到右依次传递，很显然，UI层级越深，指令传递的过程就越长，当用户的操作触发排版和重绘时，就会消耗更多的时间，进而造成「卡顿」。Hierarchy Viewer也是检查应用程序UI层级很好的工具，比如上图上那些只包含一个子控件的父控件，一般情况下都是可以合并的。

关于「性能优化」，都是一些「技术向」的概念，大家先消化一下，后续再讲讲关于内存、电量和流量的优化。另外，文中如有没说清楚或者有异议的地方欢迎留言讨论。

欢迎添加微信公众号：给产品经理讲技术

关键字：产品经理, 性能, 程序员, 软件产品

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！