众所周知，Android 是基于 Java 语言的，iOS 是基于 Obejctive-C。表现在手机和应用程序运行机制上，Java 的代码实际上需要两次“转换”才能最终以用户可看的程序跑起来，一次发生在开发者发布安装包前，使用开发者自己机器的 CPU，另一次在用户启动 APP 前，使用手机的 CPU。而基于 Objective-C 的代码只需要一次这种“转换”，在开发者发布安装包前，所以只占用开发者机器的 CPU 时间。
我们假设同样代码量的程序，需要同样多的 CPU 时间，进行从代码到最终能跑的“转换”。那么把这种工作全部放在了开发者的机器上进行的 iOS 显然就更具优势，因为用户在打开 APP 之前不需要再浪费时间进行“转换”，这部分时间由开发者“忍受”了。而 Android 程序启动相对较慢就是因为第二次“转化”需要在打开程序时进行引起的。这两种机制是历史的产物，总体上不能说谁好谁坏，只有适用范围的问题。考虑到手机属于体验要求比较高的设备，显然 iOS 这种机制更合适。所以这两种机制带来的后果就是，iOS 总是比 Android 快，而且是天生的。
现在 ART 的出现代表了什么？代表了 Android 在启动程序时将像 iOS 一样，无须进行第二次“转换”工作了。ART 把第二次“转换”所要使用的时间放在“程序安装时”进行，而不再是“程序启动时”进行。这样做虽然安装程序时要慢一点，但是在使用时就会明显快起来。按我的浅薄理解，就是把以前每次启动程序都要做的工作改成“一次性”的工作，放在用户不那么在乎的安装时完成。这从长期来看也降低了总体的“转换”时间。
试想一个程序，安装后你使用了 N 次。按原先 Dalvik 的方法（术语叫 Just-in-time compilation），N 次启动就需要进行 N 次这样的“转换”。但是按照 ART 的方法（术语叫 Ahead-of-time compilation），不管这个程序你使用几次，都只发生一次“转换”。这也解释了为什么使用 ART 会降低 CPU 的使用频率，进而降低电量的使用。
当然，ART 也会带来其他的负面影响。其一是增加程序安装所需的时间，只是目前还不知道具体会是多少。考虑到其他技术因素，这个时长的增加可能比我为了讲解方便所举的“第二次转换”所需的时长要长一点，但是肯定不会长到无法忍受的地步。据我查到的资料，这个变化对小程序几乎可以忽略不计，受影响的应该是以游戏为主的程序，因为他们本身代码量就更大。不过这跟你获得的收益也是成正比的，因为 ART 可以让你在打开游戏时省更多的时间。如果将来都是“后台安装”的话，对用户体验更是微乎其微，你去看几个新闻这时间就过去了。
第二个缺点是会使安装后的文件占用更多的空间，据称是 10%-20% 的增长。不过不要紧，这个增长指的是对“代码”部分文件的增加，比如一个 100M 的游戏，可能代码只有 20M，剩下 80M 是图片和音乐等文件，所以即便增加 20% 的安装所需空间，也只不过多了 4M 而已，在动辄 16G，32G，甚至 128G 容量的智能手机面前，影响更是微乎其微。
据我了解，ART 这个项目其实在 2 年前就已经开始了，只不过之前一直不受关注，只有零星的报道，毕竟“计划不等于现实”嘛。可是现在 Android 4.4 版本以“开发者预览”的形式将其呈现出来，目的就是让手机厂商、应用开发者等进行测试，从而帮助该项目进行改进。从我得到的信息来看，ART 的稳定性并不差，完全可以胜任日常使用。
这也是为什么我会说，Android 4.4 的 ART 选项决定了 Android 5.0 系统重大改变——彻底从Dalvik转换到ART。iOS 开发人员和其用户所引以为傲的流畅体验已经不再是一个值得炫耀的东西，因为这种体验随着登陆 Android 平台变得“大众化”，再加上 Android 市场占有率的巨大优势、Google Play 商店的崛起，iOS 设备还能靠什么支撑自己的高价策略？
我们假设同样代码量的程序，需要同样多的 CPU 时间，进行从代码到最终能跑的“转换”。那么把这种工作全部放在了开发者的机器上进行的 iOS 显然就更具优势，因为用户在打开 APP 之前不需要再浪费时间进行“转换”，这部分时间由开发者“忍受”了。而 Android 程序启动相对较慢就是因为第二次“转化”需要在打开程序时进行引起的。这两种机制是历史的产物，总体上不能说谁好谁坏，只有适用范围的问题。考虑到手机属于体验要求比较高的设备，显然 iOS 这种机制更合适。所以这两种机制带来的后果就是，iOS 总是比 Android 快，而且是天生的。
现在 ART 的出现代表了什么？代表了 Android 在启动程序时将像 iOS 一样，无须进行第二次“转换”工作了。ART 把第二次“转换”所要使用的时间放在“程序安装时”进行，而不再是“程序启动时”进行。这样做虽然安装程序时要慢一点，但是在使用时就会明显快起来。按我的浅薄理解，就是把以前每次启动程序都要做的工作改成“一次性”的工作，放在用户不那么在乎的安装时完成。这从长期来看也降低了总体的“转换”时间。
试想一个程序，安装后你使用了 N 次。按原先 Dalvik 的方法（术语叫 Just-in-time compilation），N 次启动就需要进行 N 次这样的“转换”。但是按照 ART 的方法（术语叫 Ahead-of-time compilation），不管这个程序你使用几次，都只发生一次“转换”。这也解释了为什么使用 ART 会降低 CPU 的使用频率，进而降低电量的使用。
当然，ART 也会带来其他的负面影响。其一是增加程序安装所需的时间，只是目前还不知道具体会是多少。考虑到其他技术因素，这个时长的增加可能比我为了讲解方便所举的“第二次转换”所需的时长要长一点，但是肯定不会长到无法忍受的地步。据我查到的资料，这个变化对小程序几乎可以忽略不计，受影响的应该是以游戏为主的程序，因为他们本身代码量就更大。不过这跟你获得的收益也是成正比的，因为 ART 可以让你在打开游戏时省更多的时间。如果将来都是“后台安装”的话，对用户体验更是微乎其微，你去看几个新闻这时间就过去了。
第二个缺点是会使安装后的文件占用更多的空间，据称是 10%-20% 的增长。不过不要紧，这个增长指的是对“代码”部分文件的增加，比如一个 100M 的游戏，可能代码只有 20M，剩下 80M 是图片和音乐等文件，所以即便增加 20% 的安装所需空间，也只不过多了 4M 而已，在动辄 16G，32G，甚至 128G 容量的智能手机面前，影响更是微乎其微。
据我了解，ART 这个项目其实在 2 年前就已经开始了，只不过之前一直不受关注，只有零星的报道，毕竟“计划不等于现实”嘛。可是现在 Android 4.4 版本以“开发者预览”的形式将其呈现出来，目的就是让手机厂商、应用开发者等进行测试，从而帮助该项目进行改进。从我得到的信息来看，ART 的稳定性并不差，完全可以胜任日常使用。
这也是为什么我会说，Android 4.4 的 ART 选项决定了 Android 5.0 系统重大改变——彻底从Dalvik转换到ART。iOS 开发人员和其用户所引以为傲的流畅体验已经不再是一个值得炫耀的东西，因为这种体验随着登陆 Android 平台变得“大众化”，再加上 Android 市场占有率的巨大优势、Google Play 商店的崛起，iOS 设备还能靠什么支撑自己的高价策略？
