1.1　移动端软件发展历程

2008年7月，苹果公司推出第一代手机iPhone 3G，同年9月谷歌正式发布了Android 1.0系统，标志着正式步入移动端（特指Android和iOS，下同）发展期，移动端的发展历史，按照开发者的经历大致可以分为4个阶段：原生阶段、Hybird阶段、RN阶段、Flutter阶段。

原生阶段：我们使用原生语言（Android使用Java或Kotlin，iOS使用Objective-C或Swift）开发应用，对同样的功能需要写Android和iOS两个版本，开发和维护成本都很高，同时动态化能力非常弱，紧急问题的修复和添加新功能都需要到相应平台发版，尤其是iOS审核的周期非常长。从开发者的角度出发，是否有一种方案可以开发一套代码能在多个平台运行且能够动态发版，而无须再经过平台的审核？基于这个需求，HTML5兴起，移动端发展步入了Hybird阶段。

Hybird阶段：通过WebView容器加载HTML5网页进行渲染，通过JavaScript Bridge调用一部分系统能力，同步更新服务器上的HTML5网页。我们还实现了动态更新，一切看似美好。可是Hybird阶段仅仅持续了很短的时间，因为我们发现这种方案存在致命的缺陷——性能。大家都在想有没有一种既能跨平台，性能又高的方案呢？于是移动端发展步入了RN阶段。

RN阶段：RN是React Native的简称，当然这个阶段不只有React Native，还有Weex等跨平台方案，它们的原理大同小异，都是使用JavaScript开发，但是绘制交给原生平台，通过JavaScript VM的解析桥接原生控件进行绘制，这样性能得到了极大提升。但是随着开发的进行，我们又发现了新的问题——桥的成本太高，当频繁地跨桥调用时就会出现性能问题，比如ListView的滑动，React Native早期的ListView控件存在极大的性能问题。除了性能问题，维护成本也很高，由于React Native要桥接到原生控件，但Android和iOS控件的差异导致React Native无法统一API，有的属性iOS支持，Android不支持，有的Android支持，iOS不支持，这就导致经常需要开发Android和iOS两套插件，另外还需要维护React Native端，RN架构（尤其是版本升级）维护成本比Android和iOS还要高，所以综合下来成本比原来还高，这个阶段的跨平台就失去了意义。Flutter在这个时候就应运而生了。

Flutter阶段：Flutter吸收了前面的经验，既没有使用WebView，也没有使用原生控件进行绘制，而是自己实现了一套高性能渲染引擎来绘制UI，这个引擎就是大名鼎鼎的Skia，Skia是一个2D绘图引擎库，Chrome和Android都采用Skia作为引擎。Flutter完美地解决了跨平台代码复用和性能问题，大家都在感叹：似乎UI迎来了终极解决方案。