想让安卓 APP 如丝般顺滑？

随着安卓手机市场占有率的节节攀升，随便在大街上找几个人估计 80% 用的都是安卓手机吧！用安卓手机的人这么多，不知道大家是否曾经感觉到过 APP 卡顿、死机？是否遇到应用程序无响应、闪退？本文就为大家解释一下其中的原因，如何通过帧数来监测 APP 流畅度及解决此问题。

为何 APP 会运行缓慢

学过计算机的人都知道， APP 运行在操作系统上，操作系统依赖于系统的硬件，例如 CPU 、内存等，也就是说 APP 运行也是需要一定的环境的，所以要分析为何 APP 运行缓慢也要从两个方面来考虑：

一、APP 的运行环境

首先硬件配置越高产生 APP 发生运行缓慢问题的时间就会越晚，这个很好理解吧，就是花钱越多用的越舒服（贵手机一般都比便宜手机配置好的哟）。再者，现在人们的手机上，装个 10~20 个 APP 应该是很正常的吧，APP 的每一个页面点击返回键的时候默认都是关闭操作，但这个也可以处理成不关闭。 APP 运营人员为了保持 APP 的活跃度，会有一些推送、消息提醒等功能，这些都是在后台运行的。也就是说即使你的 APP 关闭了，后台依然有 APP 在占用系统资源。这些占用的资源从应用管理列表中可以看见，它们以「进程」和「服务」的方式体现出来了，如下图：

从图中可以看出，APP 即使在后台也会消耗一些资源，试想，如果手机安装的 APP 多了，手机资源剩余的就比较少了，这样 APP 运行慢也就不难理解了。

二、APP 本身的质量问题

APP 是程序员开发出来的， APP 开发者本身对 APP 运行缓慢也负有不可推卸的责任。例如，在 UI 线程做了一些耗时的操作，会导致 UI 卡顿；从网络请求的图片没有做缓存处理，下次仍下载图片导致图片显示慢； API 兼容性处理得不好导致了闪退。。。

我就不自黑了，就写这么多吧！

如何让 APP 流畅运行

知道了原因，就可以各个击破！

首先 APP 运行和硬件环境有关，这个好解决，换一个好点的手机喽，这样说是有些欠妥当但真的能解决问题，平时使用的时候，也要尽量少地安装 APP ，不要以为安装 APP 的成本低就一味地安装，APP 安装的越多在后台运行的程序可能也就越多，最后会过多地占用系统资源。但有时这些因素都不能避免的情况下，我们该怎么办呢？

其实我们还可以采取下面的外科手术式的方法来解决这个问题：

1、使用 XX 清理大师终结不需要的进程，这里的降温其实也就是杀进程。如下图:

2、定期清理垃圾，俗气一下还拿 XX 清理大师来举例子，如下图，点击垃圾清理之后的页面，只需轻轻一点，之后再运行 APP 就会感觉不一样:

3、上述的的方法可以说只能解决一时的问题，治标不治本。据说有些 APP 为了逃避后台进程和服务被杀死，拦截了手机开机、屏幕解锁、网络状态变化、电量变化等事件，拦截了之后一旦发现进程没有开启就会自动把死掉的进程和服务重启。对于消费者来说真是防不胜防！这里介绍一个从系统层面解决的方法，限制后台进程。具体操作是（拿小米手机举例子），设置->其他高级设置->开发者选项->后台进程限制，如下图:

如何检测 APP 流畅度

在安卓 4.1 之前可以说检测非常困难的。例如这个老兄的文章：Android 应用程序 fps meter [帧数显示]的分析。但是 Android 在发布 4.1 JellyBean 版本的同时，推出了「 Project Butter」（黄油计划）,这一计划的目的是让 Android 的操作变得更加流畅迅速、更加可靠稳定。谷歌提供了一个叫做「 GPU 呈现模式分析( Profile GPU rendering ) 」的工具，开启这个功能后，系统就会记录保留每个界面最后 128 帧图像绘制的相关时间信息。如下（打开步骤在开发者选项中找）：

这个时候，通过 adb shell dumpsys gfxinfo com.xxxx.xxx 可以获得很多信息，这里拿手机 QQ 举例子，通过 adb shell dumpsys gfxinfo com.tencent.mobileqq 这个命令就得到的数据如下：

Draw : 表示在 Java 中创建显示列表部分中， OnDraw() 方法占用的时间；

Process ：表示渲染引擎执行显示列表所花的时间， VIEW 越多，时间就越长；

Execute ：表示把一帧数据发送到屏幕上排版显示实际花费的时间，其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。所以这个时间，一般都很短；

PS： View 类包含 Surface （变量名 mSurface ），每个 Surface 通常对应两个 buffer ，一个 front buffer , 一个 back buffer ( 4.1 之后是 3 个，一个前，两个后)。其中，back buffer 就是 canvas 绘图时对应的 bitmap (研究 Android_view_Surface.cpp::lockCanvas )。因此，绘画总是在 back buffer 上，需要更新时，则将 back buffer 和 front buffer 互换。

Draw + Process + Execute = 完整显示一帧，这个时间要小于 16ms 才能保存每秒 60 帧。

这里大致能看见帧数，但是操作起来比较麻烦，也不是很直观。所以，如果有一款不那么麻烦，对开发者友好的流畅度检测工具对开发者来说简直是一个福音，特别是 APP 发布出去之后，APP 在不同的运行环境和在不同的操作环境下的真实体验究竟如何，对开发者价值非常大。

如果你现在正因此而苦恼，那就不要担心啦！兄弟们开足了马力，经过长时间地研究终于可以让你通过 OneAPM MI 产品的 Android SDK 来监测 APP 帧数啦！来试试吧，做开发的兄弟姐妹们！

OneAPM Mobile Insight以真实用户体验为度量标准进行 crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。