想让安卓 APP 如丝般顺滑？

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

为什么 APP 会运行缓慢

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

1、APP 的运行环境

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

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

2、APP 自己的质量问题

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

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

如何让 APP 流畅运行

知道了缘由，就能够各个击破！

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

其实咱们还能够采起下面的外科手术式的方法来解决这个问题：

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

二、按期清理垃圾，俗气一下还拿 XX 清理大师来举例子，以下图，点击垃圾清理以后的页面，只需轻轻一点，以后再运行 APP 就会感受不同:

三、 上述的的方法能够说只能解决一时的问题，治标不治本。听说有些 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 官方技术博客。