Android原生、ReactNative、Flutter三者在设计上不同的理念
1.UI显示流程
1.原生:通过layout布局决定UI效果，其中样式文件和界面元素卸载不居中，更新的功能也在代码中。
这种写法 性能很高效，但是开发者使用起来很死板，通过文件的方式强行将代码与布局分离。
2.RN:React独创了Virtual DOM机制。Virtual DOM是一个存在于内存中的JavaScript对象，它与DOM是一一对应的关系，也就是说只要有Virtual DOM，我们就能渲染出DOM。当界面发生变化时，得益于高效的DOM Diff算法，我们能够知道Virtual DOM的变化，从而高效的改动DOM，避免了重新绘制DOM，通过DOM映射成原生控件显示在屏幕上。
React是一个专注于UI部分框架，做UI架构很厉害，性能相比原生会有些损耗，但是相对于html还是高出了很多。
3.Flutter: 基于dart描述的UI效果，直接通过SKia图像处理引擎渲染到界面上。没有虚拟DOM，也没有原生映射，性能对于原生还会高一些。
性能高，而且可以热重载，设计架构也是google出产，但是目前不稳定，支持的生态有效
2.状态更新机制
1.原生:几乎全靠开发者双手完成状态更新，比如TextView发生改变，需要findById然后setText，虽然目前有MVVM等非常优秀的设计模式，但这并不是一种完美的状态机制，只不过让你的状态少了些。真正的状态机制是指 数据状态有周期，有传递特性，也能因为数据改变从而影响UI，在Android中是没有这这种设计机制的。
2.RN:万物皆组件，界面、按钮、Text等都是组件，有组件就有状态，有状态就会发生相互传递，数据发生改变会实时影响UI。
3.Flutter: 所有组件分为两类： 有状态的和无状态的。由于不是基于DOM展开，有状态的组件性能开销会大，因为需要底层进行实时监听。其他的和RN的设计理念一样，只是底层细节不一样（Flutter的展示和绘制都是在NDK中实现的）
3.编译流程
1.原生:Java文件编译成Class,然后被dex工具编译成dex，最终打包成APK文件，随后通过adb命令安装到手机中。如果Java文件发生变化，上述流程需要重新来一边，再安装到手机中，才能看到最终的效果。 原生不支持热重载技术，最根本还是在于class的编译机制与懒加载机制。
2.RN:.js文件通过adb推送到apk中，通过执行程序中的消息队列，利用diff算法检测到UI差异，通知DOM树进行更新，重新渲染。通过相同的class加载不同的react文件，达到实时刷新界面的目的。
3.Flutter: .dart文件通过adb推送到apk中，通过Skia图像处理引擎，引擎直接加载Dart描述的UI，然后重新渲染。
ReactNative 生命周期
getDefaultProps:在组件创建之前，会先调用getDefaultProps(),全局调用一次。
componentWillMount:准备加载组件，调用一次，这个函数调用时机是在组件创建并初始化了状态之后，在第一次绘制render()之前，可以在这里做一些业务初始化操作。（相当于onMeasure）
componentDidMount: 这个函数调用的时候，其虚拟DOM已经构建完成，你可以在这个函数开始获取其中的元素或者子组件了（相当于onLayout）
componentWillReceiveProps 接受父组件新的属性（props）
shouldComponentUpdate 当组件接收到新的属性和状态改变的话，都会触发这个函数
componentWillUpdate 如果组件状态或者属性改变，并且shouldComponentUpdate = true 会触发这个函数
