Android 大前端进化史

简单介绍一下大前端的进化史。科普文。大约，可能，差不多会单个写写吧。

原生项目：

APP 调用系统中的控件，系统中的控件分发事件，渲染。
结果：由于系统不同，每个系统都需要一套代码调用系统控件。

大前端初代目

webview ：不能打，但是很能吹
初代目代表：PhoneGap, Apache Cordova, Ionic
由 H5+JS 通过 webview（仍然是系统的控件）实现页面渲染。

结果：兼容性，流畅性，加载速度，都是瓶颈。而且，不能直接调用原生特有服务（拍照啥的，只有安卓手机有，web没有的），还是需要原生程序员写功能，通过桥接由 JS 调用。

大前端二代目

RN ： 能打，不过太年轻
创建飞雷神之术，解决 webview 的性能问题，由 JS -> RN ©->Native 执行渲染。

飞雷神之术原理：由于 native 可以调用 C ，C可以调用 JS，那么没有什么是增加一个中间层不能解决的，加个 C层，做个 JS 控件 到 Native 控件的映射，再做个三端通信机制就好了。再优化一下渲染，创建一个 DOM 树，计算 different ，只渲染 different 提高效率，一般的小喽啰足以应付，RN 以此成名。

JS代码和原生代码本身都是很快的，瓶颈经常发生在当我们视图从一边转向另一边时。未来构建高质量的应用程序时，我们必须将使用桥接的次数控制到最小。可以预见，在比较复杂的页面滑动时，different 算法，DOM 树的刷新，都是累赘，所以 RN 的列表滑动性能仍然是个问题。并且，显而易见，原生特有服务依然需要原生程序员编写。不过摇一摇的热重载不需要重新打包安装，还是应该给个好评。对了 react 的响应式思想，还是应该学学的，精准而又优雅。

大前端三代目

Flutter ：贼能打，就是长得丑(界面酷炫流畅的一逼,代码丑的一逼)
三代目吸取二代目经验，将控件库变成框架的一部分，放到 APP 中，APP 中的控件直接调用 canvas渲染，完全不用系统的控件，这样，就在渲染层达到了跨平台，摒弃了桥接的思想。由于不用系统的控件，所以，集成框架后，包会比较大 （啥也不写就7M），不过这是问题么？还支持热重载，由于文件的加载机制，还可以热更新。简直是大前端的希望啊。
一个好好的面包上，站了一只苍蝇，是比较令人发狂的。Flutter 使用 Dart 语言，Dart是用预编译的方式编译多个平台的原生代码，这允许Flutter直接与平台通信，而不需要通过执行上下文切换的JavaScript桥接器。由于控件是框架的一部分，所以所有的控件，都需要重新学习，看着 API 一点一点敲，是比较闹心的。