为什么关注性能

数据显示：

  • 应用首次工作出错以后， 79% 的用户只会再重试一两次。
  • 当应用载入时间超过 3 秒时， 25% 的用户会放弃使用该应用。
  • 31% 的用户会将糟糕的体验转告他人。

由这些数据可以看出，性能在用户体验1方面有很大的影响，也直接影响了C端应用的质量。

性能指标

具体可以从以下几个方面来分析性能：

内存

内存是影响用户直接交互体验的重要因素，它直接影响到 app 的使用流畅度。移动设备的内存资源非常有限，为每个APP进程分配的私有内存也是有限制。一方面要合理的申请内存使用，以免导致频繁的GC影响性能和大对象申请发生内存溢出；另一方面，要及时释放内存，以免发生内存泄漏。可以从内存峰值、内存均值、内存抖动、内存泄漏这几个方面进行考量。

CPU

与内存类似，CPU的占用影响了 app 的发热和卡顿，可以通过 CPU 峰值、CPU 均值这两个方面进行考量。

电量消耗

没有用户喜欢使用高耗电的 app，所以电量消耗在高性能方面也值得关注。

启动时间

app 启动的整个过程，可以分解成下面几个步骤：

  1. 用户在点击App Icon
  2. 系统为 app 创建进程，显示启动窗口
  3. app 在进程中创建自己的组件

img

图中可以看出，系统的进程分配以及一些窗口切换的动画效果等，都是跟系统相关的，无法优化。而可以优化的是 application 的创建过程。

启动可以分为冷启动和热启动，冷启动是指当应用启动时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用。而热启动是指当应用已经被打开， 但是被按下返回键、home 键等按键回到桌面或者是其他程序的时候，再重新打开该app时， 这个方式叫做热启动（后台已经存在该应用进程）。冷启动时间较长，可能会出现长时间的白屏，所以现在很多应用采取添加闪屏的方式来优化用户体验。

另外，启动优化也包括了页面的启动时间的考量，也就是页面的渲染时间，可以使用工具来监听这部分时间。

响应速度

每个应用都应该快速地响应用户交互。一旦启动应用，用户总是希望它可以尽可能快地工作，一切必要的处理都应该在尽可能短的时间内完成。比如在照片应用中，用户通常希望看到调整亮度或对比度等简单效果的实时预览效果。 因此，相应的处理需要在几毫秒内完成。

UI性能

人类大脑与眼睛对一个画面的连贯性感知是有一个界限的，比如电影帧率通常为 24fps，手机领域 （尤其是动画过渡）也需要感知屏幕操作的连贯性，Android/iOS 把达到这种流畅的帧率规定为 60fps。引起 UI 卡顿的常见原因有如下几种：

  1. 主线程做了阻塞 UI 的耗时操作；
  2. 同一时刻动画执行多次导致 GPU 和 CPU 过度绘制；
  3. View 过度绘制导致 GPU 和 CPU 过度绘制；
  4. 频繁地进行布局绘制、文本计算等操作导致 View 需要重新渲染；
  5. 频繁的对象创建和销毁；
  6. 过度复杂的业务逻辑，耗时函数。

可以对UI 重绘、滚动帧率、页面 ANR（Application Not Responding）等方面进行评测。

网络环境

网络性能是一个 app 看不见的体验，国内网络环境错综复杂，要面对各种流量劫持和各种不稳定因素，所以，对于网络接口性能，也值得关注。例如复杂网络环境、接口往返时间、接口数据异常、CDN、服务器异常等方面，都是需要考虑的。需要考虑不同带宽和不同稳定情况的网络环境下 app 的响应。

用户行为

收集用户行为路径，包括操作路径和页面停留时长等。通过对用户行为路径的分析，可以针对用户访问量大的内容进行集中优化，有助于提高优化效率。

性能分析

通过测量各种指标来分析应用的方式有两种：采样和埋点。

采样

采样（或基于探测点的性能分析）是指以一定的周期间隔采集状态，通常需要借助工具。由于不会干扰应用的执行，采样可以很好地提供应用的全景图。采样的不足之处在于它不能返回 100% 精确的细节，如果采样的频率是 10 毫秒，那么就无法得知在探测点之间的 9.999 毫秒内发生了什么。

埋点

通过修改代码，记录细节信息的埋点能够提供比采样更加精确的结果。既可以在关键部分主动埋点，也可以在性能分析或处理用户反馈时有针对性地埋点，以便解决问题。因为埋点需要注入额外代码，所以它一定会影响应用的性能，对内存或速度 （或同时对二者）造成损害。

参考博客：