EROFS 和 方舟 辩证的看 —— 方舟

接上篇

方舟 = 诺亚方舟 ？

如果是那就说明HW对它的期望值是很高的。

作为一个编译器，而且在各种编译器百家争鸣人时代，能给予这样的期待，那一定会是非比寻常的。

现在就坐等它开源了。

先看看官宣方舟编译器的四大技术亮点：

1、是一种多语言联合优化编译器，消除了跨语言调用的开销
2、程序运行时无需依赖虚拟机，减少资源占用，并且建立了高效的内存回收机制
3、可针对不同应用灵活编译优化，翻译出性能更佳的机器指令
4、开发者学习和使用成本低，打包时即编译

说实话光看这4点，道理是这么个道理，但总觉有些意外。我的意外不是说“没想到还能这么干”的意外，而是“就这样？！”的意外。
为什么这么说呢？

第4点就没什么好说的了，相对一艘大船来说，这就是一个锚而已，无非就是集成到开发环境中；再复杂一点就是结合第3点“针对不同应用灵活编译优化”。而不需要开发者做太复杂的配置。

那第3点我不是太理解了，除了优化时间和空间，还能有什么选项？不同的应用场景用不同 GC？或是可以指定不同的运算精度？如果是这样，个人觉得是把问题搞复杂了。

那关于第1，2点，技术上没什么好说的，本人的 OpenCV for Golang 就做到了，但实话说，用奇技淫巧来做个小项目玩玩没什么，但用于整个 Android 这个工作量就有些大了，而且还要处理很复杂的依赖关系。

现在没有源码，不知道它到底是怎样实现的。还是很期待它早点开源。

可能有人会觉得我是不是太矛盾了，刚还好象很不以为然的样子，现在又说期待。其实这并不矛盾，虽然从方向上面看起来没什么新意，但从具体实现上不代表没有啊。更何况它的命名就能让人充满期待。

Android 的优化空间还很大

其实 Java 和 设计模式 根本目的都是为了提高开发者的效率。从辩证的思维看，有得必有失，那提高了开发效率，失去的就是运行效率。Java 虚拟机导致运行效率低，很多人是有所了解的。那为什么说 设计模式 会导致运行效率低呢？ 比如工厂模式，代理模式等，简单理解的话大部份的模式都需要一个或多个“中间人”，你真的相信“没有中间商赚差价“吗？就算没“差价”转个手也得要时间吧！
还有就是java很多常用的类本身就有很大的优化空间，虽然已经用NATIVE，FASTNATIVE 做了一些优化。但毕竟 Android 的使用场景有所不同，还是有进一些点能起到明显的优化效果，我曾对 Android 7.1 做过优化实验，对运行效率提升有很明显的效果。

即使是效率很高的C/C++，也是有优化空间的。可以参考llvm在ir上的优化。

总之提高运行效率确实是有很多事可做的，还是等方舟开源再说吧。