微博极速版根本就没有经过编译，不知道一帮人测什么呢....
菊花那个编译器大概就是重新实现了ART
分为runtime?和编译器两部分
编译器将java?编译成机器码runtime?负责处理GC?以及java?动态特性，由于类加载之前已经编译完成，所以这个runtime?比ART?少了解释器和JIT/AOT?编译器，以及IR?生成优化器。
性能方面
据内部人士透露实际性能并不比dex2oat everything?完的ART?强，毕竟ART?几十项编译优化不是开玩笑的。大嘴比较的应该是刚安装的app，毕竟刚安装的时候基本上是解释执行。但是内存和耗电应该会有一点优势，毕竟菊花编译器得工作不是在手机上完成的，runtime?也被极大的简化。再谈一下ART?的性能，首先现在ART?的时间性能并不差，AOT + JIT +?解释器的运行模式也是google?这么多年的结果，8.0?之后的模版解释器经过大量优化性能已经不差。optimizing?编译后端优化后的代码甚至比原生code?优秀。ART?与原生代码差距在于内存占用以及java?动态特性带来的消耗。当然还有混合模式时，方法跳转执行模式切换时栈复制的消耗。
菊花编译器的不足之处
首先是违背了java?得一处编译处处运行的初衷，显然这种“优化”只能在含有对应runtime?的机器上生效。对应app?的进程应该在zygote_fangzhou?上被孵化出来。其次前面说了，性能并不会有明显优势。据透露，目前只支持system server，为啥呢，我个人不负责任的猜测runtime?并没有保留解析Dex?的逻辑，编译器可能是直接从java?编成机器码，而普通app?大量充斥着动态加载dex?等操作，自然不能完美兼容。
那为什么做这款编译器？
和Flutter?类似，华为准备建设自己的app?生态补充上一点，和Fuchsia?类似，这套编译器和runtime?很可能也用于华为新系统，到时候方便快速拉拢开发者。
那为什么大嘴会说流畅性大大提升？
很简单，ui?上的优化空间比语言层面大的多得多
另外媒体疯狂测试的“微博极速版”经我解包分析并没有任何优化痕迹，暂时媒体还激动的太早了。
总的来说，华为能做出一套性能不俗的java?编译器和runtime?还是有点东西的。
