Android原生、ReactNative、Flutter对比
首先从三者不同的设计理念对比，主要有三部分UI显示流程、状态更新机制、编译流程
UI显示流程
-
Android原生
通过layout布局决定,界面和样式写在布局文件中（xml）页面更新及功能写在代码中
总结：性能高效，通过文件的方式强行将代码与布局分开，操作死板
-
ReactNative
React独创了Virtual DOM机制 Virtual DOM是一个存在于内存中的 Javascript对象 它与DOM是一一对应的关系,也就是说只要有Virtual DOM,我们就能渲染出DOM。当界面发生变化时,得益于高效的DOM Diff算法,我们能够知道Virtual DOM的变化,从而高效的改动DOM,避免了重新绘制DOM,通过DOM映射（反射）成原生控件显示在屏幕上
总结：React是一个专注于UI部分框架，但毕竟会存在DOM与原生控件的映射,难免性能会有些损耗,但是相对于html还是高出很多
-
Flutter
基于dart描述的UI效果，直接通过Skia图像处理引擎渲染到界面上。没有虚拟DOM，也没有原生映射,性能对于原生还会高一些。
总结：性能虽高，热加载技术，框架是Google出的，但目前生态有限
状态更新机制
-
Android原生
Android几乎全靠开发者双手完成状态更新,比如 Textview发生改变需要 findByld然后 setText虽然目前有MVVM非常优秀的设计模式,但这并不是一种完美的状态机制,只不过代码少些了
备注：真正的状态机制是只数据状态有周期,有传递特性,也能因为数据改変了影响影响UI。在Android中是没有这种设计机制的
-
ReactNative
万物皆组件,界面,按钮,Text都是组件,有组件就有状态,有状态就会发生相互传递，数据发生改变实时影响UI
-
Flutter
所有组件分为两类有状态的无状态的。由于不是基于DOM展开,有状态的组件性能会开销大,因为需要底层进行实时监听。其他的都和Reactnative设计理念一样,只不过底层细节不一致
编译流程
- Android编译流程
Java文件编译成Class,然后被dex工具编译成dex最终打包成APK文件,随后通过adb命令安装到手机中Java文件发生変化,上述流程需要重新来一遍,安装到手机中,才能看到最终效果
总结:原生不支持热重载技术最根源还是在于class的编译机制与懒加载机
- ReactNative编译流程
总结:通过相同的class加载不同的js文件达到实时刷新界面的目的,可局部刷新
- Flutter编译流程
总结：编译流程里进行adb推送差异文件的
