有没有感觉你用的 Android 手机很卡？貌似手机配置都已经挺不错的了，四核、八核、≥2GB RAM 这样的配置居然还会发生动画掉帧、点击某个按钮或图标出现停顿一会儿之类的情况？高通、MTK、英伟达之类的芯片制造商不是整天宣称什么制程、架构如何先进，什么一秒钟多少万多少亿次浮点运算，怎么还整天被用户说很卡很不爽？
关于 Android 系统存在卡顿和不流畅的问题，似乎是个千古谜案——即便到现在也还有很多 Android 用户坚持说他们新买的旗舰已如丝般柔滑，却真正在流畅的细微处比 iOS 差了一截。不过从古到今，试图解释 Android 卡顿的观点就有千百种，据说即便是采访 Android 内部开发工程师，他们也说这是个说不清道不明的问题。这次我们就从相关 Android 卡顿的几个主流说法谈起，尝试从相对浅显的角度来理解这一问题。
都是 Dalvik VM 虚拟机惹的祸？
按照普通人对虚拟机的理解，就是平常一直在用 Windows 操作系统，想装个 Mac OS 玩玩又没钱买苹果电脑咋办？——装个虚拟机。从这个角度来理解，不管是出于玩机还是开发、或考虑兼容性的问题，用过虚拟机的同学就知道，这东西的效率和原生安装方式不在一个层面，不管是从驱动、资源利用等各角度来看都是如此。
Android 的系统框架上，在最底层的 Linux 内核之上就跑了个虚拟机，在 Android 4.4 之前，这个虚拟机叫 Dalvik VM。绝大部分 Android 应用就运转在 Dalvik VM 虚拟机之上——很多人，甚至是程序员认为，Android 系统之所以不流畅和卡顿，罪魁祸首就是此虚拟机，想想我们平常应用层面虚拟机的运行效率就知道了，再牛逼的硬件也抵不住软件这么坑啊。
早年的 Android 系统能有如此奇葩的框架和执行思路并不是因为 Andy Rubin 真的很二。Android 选择这条路的原因是看中互联网上浩瀚的 Java 资源—— Java 应用可以运行在 Android 这种 Linux 内核的系统上正是拜虚拟机所赐，对于一个当时的新生系统而言，想要尽早构建起应用生态，这是个捷径——也是 Android 现在拥有这么多应用资源的关键所在。
不过另有一个帮派的程序员表示，这个层面的虚拟机和我们平常自己在电脑上装的虚拟机根本不是一回事，它的执行效率并没有人们想象的不堪，实际使用中和直接调用底层基础函数也没差多少。
（NDK 的也可是让 Android 应用不用跑在虚拟机上）
我们从谷歌后来的行动看到，情况好像没有这么简单。早在 Android 2.3 时期，谷歌就意识到 Dalvik 并非长久之计，就为 Android 引入了 NDK ——这是个真正的开发包，使用 C/C++ 语言也可以为 Android 开发应用，以这种方式开发的应用不会跑在虚拟机上。彼时的程序员认为，这是 Android 从应用层真正开始具备与 iOS 相抗衡实力的开始，但这种梦想很快就被打破，一方面是让开发者放弃 Java 全面转向 C/C++ 并不现实，而且后两者开发难度甚高，涉及内存操作甚至与设备驱动程序对话，对于 Android 这种机器种类繁多的系统而言，开发者采用 NDK 很不现实（类似《极品飞车》这种大型 3D 游戏运行代码理应采用 C++，所以这类游戏针对 Android 手机的不同处理器甚至还有不同的版本）。
所以在Android 4.4时期，谷歌为之引入了一种新的 ART 虚拟机，用以替代 Dalvik。ART 的特点是相比 Dalvik 更为高效：Dalvik 虚拟机在每次运行应用时会将之编译为二进制机器代码，ART 的改进之一就在于在应用安装的时候就将二进制代码编译完成（所以每个应用安装所占空间会更大），这叫预编译模式，而不是等到每次运行应用才编译。
理论上听来，ART 似乎的确较 Dalvik 效率更高些，谷歌自己说 ART 对比 Dalvik 速度平均提升幅度达到 80%，不过各位已经在用 Android 4.4 甚至 5.0 的小伙伴有这种体会吗？或许今后随着 Android 生态以及系统自身的完善，ART 可以表现出更大的优势，起码现在我们没怎么看出来它对系统流畅性体验改善有多大贡献。
另外，在系统框架层面，除了探讨虚拟机可能是拖垮 Android 流畅性的元凶之一这种说法，还有人也会谈到 Linux 这类宏内核在驱动方面的先天不足，这些或许都是阻碍 Android 有丝般流畅的要素，但是否还有其他原因呢？
硬件加速弱爆了
显示系统图形界面的时候，如果画图的工作都交给 CPU 完成，这效率是可想而知的，犹如你让一位精通数学的同学画图，多少他倒是能画，只是能不能画好很成问题。如果 GPU，也就是专门的画图工作者能够协助这个过程，情况自是大不相同。虽说系统流畅性是个相当大的话题，但硬件加速是否做得好就成为其中的重要因素。
完善如上所述的这个过程，几乎是贯穿 Android 2.x 早期，到最新的 Android 5.1，甚至此后很长一段时间内，谷歌需要努力的方向。针对系统图片、网页等 2D 图形绘制，Android 所用的是谷歌早在 2005 年就收购的 Skia（那时 Android 都还没出生，Chrome 也采用 Skia 作为 2D 图形引擎）。
Skia 原始版本的图形光栅处理完全基于 CPU 和软件运算，也就是说早期 Android 的 2D 图形绘制对 GPU 的利用率存在严重不足，相较 iOS 和 Windows Phone 这种在硬件加速领域有着很久积累的系统完全不是一个水平。
在 Android 的系统设置 – 调试选项中，有个 ” 强制进行 GPU 渲染 ” 选项，开启这个选项以后会发现某些应用的运行的确更流畅了，但有些则出现了更糟糕的使用体验。在 Android 2.3 时代，国外科技博客 DorothyBrowse 特别强制开启这种 Skia GPU 加速，尝试进行 Webkit 渲染（Chrome 的渲染引擎）测试，结果发现相较 CPU 自己画图，所谓的 GPU 加速居然出现了反效果，可知当时的 Skia GPU 加速在 Android 平台有多么不成熟。
在 Android 3.0 之前，这套系统都没有真正行之有效的图形加速方案（即便从初版开始，Android 就在努力融合硬件加速），Android 3.0 才实现窗口相对完整的硬件加速绘制。实际上，即便是到 Android 4.1，谷歌大肆宣传的黄油计划，过渡动画帧率达到 60fps，通过预判和缓冲来提升效率，其 GPU 加速支持也并不完整。谷歌自己的官方文档中就提到，并不是所有 2D 图像操作的 API 都已经支持硬件加速。
不过总的说来，Android 的 GPU 加速是朝着逐步完善的方向发展的，最新版相较过去已经有了很大程度的提升，从系统级应用和各类操作这些年来流畅度的明确提升就能感觉得到，即便这种提升在 iOS 和 Windows Phone 面前还是显得有些无力。可是来到第三方应用，这个问题又变得非常复杂。
第三方应用质量很悲剧
在宣称如 ” 丝般顺滑 “、甚至 ” 赶超 iOS” 的 Android 4.1 问世以后，不说和 iOS 比实际如何，其系统级应用倒真的流畅了很多，可是第三方应用死性未改，该怎么卡还是怎么卡。这就是个相当复杂的问题了。
其一，在 Android 一步步向前的步伐中，API Level 越高，GPU 硬件加速也的确愈加完善，比如 Android 5.1 所用 API Level 22。所谓的 API Level，标识的是 Android 平台框架的 API 版本。这个 API 可以理解为 Android 所跑虚拟机针对应用开发而支持的功能，随着版本号的变化，这些 ” 功能 ” 在发生着升级或转变。对 Android 的系统应用而言，采用最新的 API 是理所当然的，流畅性也保持在最佳状态。
但对第三方应用来说，采用最新的 API，就意味着对旧版本系统的抛弃。比如微信应用更新，如果很任性地用上 API Level 22，那么最新版的微信将只支持 Android 5.1，人类可以忍受吗？所以微信迄今为止还在采用 API Level 9，微博则为 API Level 14。这种 API 的迭代，也是苹果为何高度追求系统一致性的重要原因。想想 Android 系统的碎片化问题，第三方应用要变得更高效，好像是个根本无法完成的任务。
这还只是第三方应用开发的一环。其二，Android 应用开发者的 ” 随性 ” 让 Android 应用的效率更加悲惨。比如说谷歌在应用开发的指导原则中提到，如果应用不够流畅，应该看看是否存在 ” 过度渲染（OverDraw）” 的问题，就是布局重叠、重复绘制。
要检查这个问题，有兴趣的同学可以一起来做这个实验。在 Android 系统设置的开发者选项中，选择 ” 显示 GPU 过度绘制 “，此时整个界面变得花花绿绿一片。这些色块所表达的是，无色透明状态为最佳，蓝色表示很好，绿色为不错，浅红色表示较差，深红色为过度绘制问题严重。类似 Instagram 等应用的情况似乎挺好，而某博和 Facebook 过度渲染的问题就很严重。这只是 Android 应用开发中的一个例子，如此这般罔顾开发原则的状况那是数也数不清的。在 Android 相对开放的应用世界中，这种情况是不会有警察去抓的，显然 iOS 全程把关 App Store 就不会这么悲剧。
其三，在天朝这样一个奇特的国度，开放的系统无疑为许多应用开发商提供了大好机会。很多应用当安装到你手机中，其行为习惯可能是你完全不知道了，而且可能实情会更令你震惊，这就是下面一个话题了。
内存居然还不够用？
装越多 APP 手机越卡，相关 Android 装越多应用，手机越卡的解释非常多样，甚至包括对于固态存储原理的解释。或许这些都是原因所在，不过更关键的原因是这样的：Android 系统中有个叫做 Receiver（接收器？）的东西，负责传递系统接收到的变化，就像是神经系统。比如说按下 Power 键锁屏，长按关机，或者长按相机按键启动相机应用，或者插入耳机，都是在 Receiver 接收到以后通知相应 apk，后由程序给出响应。
应用本身就可以跟系统注册任何形式的 Receiver，其较大的用处之一是通知系统启动某个程序。比如 YouTube 的 Receiver 在开机时、系统语言切换后、系统账户改变后这三种情况下自动启动 YouTube 应用本身——这是个比较常见的 Receiver。而国内的诸多 ” 异士 ” 是如何写 Receiver 的呢？
某些著名视频站 APP 在下面这些情况下都会启动，包含开机时、网络状况改变时（2G、3G 与 WiFi 间切换）、安装其它 App 时、卸载其它 APP 时、用户唤醒机器时 … 对于用户而言，无论你怎么杀进程清内存，只要这些操作被触发，Receiver 就会启动相应程序，话说连个 WiFi、下个新应用都要启动该应用，哪有透明度可言，真是独有社会主义特色。
此类国产 APP 相当多见，常见 Receiver 动作还有：耳机拔出或插入时、文件下载完成后、WiFi 扫描 SSID 完成后，都启动程序，是不是感觉灰常神奇？它们的宗旨就是永远不会被你杀死，什么一键杀进程，分分钟给你活过来，除非彻底卸载它们，或禁用相应 Reciever。在这种情况下，Android 系统对于内存容量的要求自然是非一般的。
所谓的内存回收机制此刻都已不值一提，何以 iPhone 1GB 内存流畅运行至今，而 Android 现如今已是 4GB 时代；这也是很多 Android 优化文章告诉用户，如果某应用一周不用就卸载的核心所在，环境使然。你听说过 iOS 优化让用户卸应用的吗？
碎片化问题让 Android 千疮百孔
可以说，除了 Android 本身的顽疾之外，导致上述绝大部分问题的根源就是 Android 的碎片化，无论是 Android 自身开放的态度让各种高配、低配的手机都在使用，还是手机制造商对 Android 进行的二次开发。要将硬件加速做好、规范第三方应用质量，在 Android 开放的理念下是几近不可能完成的任务，且谷歌自己都难以收拾局面。
Android 的开放和碎片化带来的问题还远不止上面这些，一个典型的例子是 iOS 和 Windows Phone 都具备了特别出色的信息推送机制，比如说 QQ、微信接收消息，在 iOS 和 Windows Phone 中，应用本身不需要常驻后台，通过每台手机和推送服务器保持唯一连接，就能收到推送通知，无论对性能和功耗的节省都具备了极大的意义。
Android 系统当然也具备了消息推送的可行性，但由于碎片化问题，以及国内因为某种原因不得不去掉谷歌服务的现状，令 Android 不同应用采用五花八门的推送机制。许多 Android 应用获取消息的方式是轮询（而非推送），即应用主动地与服务器连接并查询是否有新消息，可想而知它对系统和网络资源的消耗。
关乎 Android 系统本身，则除了文首提到的虚拟机机制，还有许多相当微妙的问题形成它与 iOS 之间的流畅性差异，比如 Android 对多任务的支持更类似于桌面系统，本身就只有靠堆砌硬件才能满足这种多任务的需求，当然 iOS 的多任务也已经不像很多人理解的那样，是多年前的 ” 假后台 ” 了，它针对第三方应用开放的多任务 API 正越来越多。
总之，Android 的卡顿和不流畅是个极其复杂、庞大的问题，上面所提的这些也只是挖掘了其中的一部分。就 Android 系统的发展轨迹来看，从初代问世至今，其发展史都可以看做是谷歌在系统流畅性问题上所做的一次次努力，流畅性改善甚至是 Android 前行的一条线索，所以谷歌也才毫不吝啬地一次次地宣传，我们的系统更流畅了，不管相较竞争对手有多大差距和多少不可控性，现在的 Android 也已经比过去流畅了很多，虽然未来还有很长的路要走。