真正的跨平台运行

跨平台运行应该不完全等同于跨平台开发，

真正的跨平台开发语言应该是C，

事实的跨平台编译器应该是LLVM或GCC，

跨平台的层次问题，恐怕又是个大话题暂不论。

跨平台运行的主流实现源于Java应该没有争议，

.NET也是一个流派，

当时跨的主要是Windows和类Unix，

现今，面对瘦身如此严重的Android和iOS，

JVM和CLR实在是太重型了。

另一个角度看，就是解决Runtime的跨平台的问题，

回头看，最早搞Plugin/Micro-Runtime成事的人家，

应该就是Flash了，在IE和FireFox里面生存了这么多年，

无数次解决Plugin是多余的东西争议之后，依旧生存下来，

最强对手Java的Applet也要以JavaFX的身份重生。

剖开AVM（FlashRuntime），无论是帧模型，还是弹性跑道模型，

全局事件总线和其基础上的数据绑定机制，

再有饱受争议的Flex框架，

积极的一塌糊涂的GC策略，

几乎都是在极端低性能运行环境，

但是却计算重载条件下逼出来的解决办法，

程序运行起来，卡而不死、慢而不死，

这就是当年为什么只有Flash能搞定流畅动画的原因，

换在移动设备上就是拼的UI效率/帧数了。

这种经验不是Java和.NET有钱就能积累出来的，

Java的UI依旧一塌糊涂，抛出JavaFX救场，

.NET用XAML做WPF确实不错，

瘦身的SilverLight看似很好，Mono也能帮上忙，

两者依旧各种前凸后撅，放不进ARM的小身材

或者缺胳膊少腿，难等大雅之堂。

同样，AVM的完备Runtime结构，

也不是iOS的Object-C朝夕能够建立出来，

Apple根上是个造设备和卖MP3的，

软件基础是乔老爷子被赶出Apple那几年的积累，

iOS抱着ARC不用GC也是没有办法事情。

如果iOS真的有了AVM一样的功能的Runtime，

如果JVM和.NET与AVM一样的小和高效了，

大家就都需要更高的计算能力来承载了，

那时，如果已经有了足够的计算能力，

AdobeAir还会显得慢吗？