有没有感觉你用的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这种在硬件加速领域有着很久积累的系统完全不是一个水平。