腾讯官方文档，Flutter全方位深入探索，kotlin语法像Delphi

这里简单回顾一下，在有客户端开发的场景下，为什么又出现了 RN ？

RN 的价值简单来讲就是—— 可接受的页面性能 + 高效开发 + 热更新。

• 更新：传统的 APP 上架之后，出现了业务 BUG，用户只能去更新 APP，进行 BUG 修复。客户端实现热更新修复 BUG，有多难，可以问问 IOS 的开发同学。大概率猜测，手 Q 和微信，应该还是有方案可以热更新的。但是对很多小厂商这确实是非常艰难的事情。因此，得益于强大的动态化能力 RN 的价值也就完美的体现出来了。

• 高效：一个 APP 发布上线，Android 和 IOS 同时需要开发两个应用，而 RN 只需要一套代码，就可以运行在双平台上，节省很大的人力成本。并且很多业务线有很强的业务运营诉求，可能会存在很短时间内的多次改版和发布的情况出现，客户端开发的人力瓶颈和发布周期的限制，已经很难满足这样的业务场景了。尤其在一些有损发布的情况下，赶着时间点，带着 BUG 上线的场景，在后续进行增量的修复，再这样的情况下，传统客户端的表现，简直就是灾难性的。

• 性能：RN 具有优于 H5 的性能体验。毕竟是通过客户端进行的页面渲染，速度上比 WebView 渲染还是要快不少的。这个在 Weex、Hippy、Plato 上都有所体现，虽然低于 Native 的性能，但是在可接受范围。PS：这里的表达，不是描述客户端开发不好。只是单纯从业务角度上看待问题，而把合适的技术放在合适的位置是非常重要的，这也是架构师核心价值之一

回顾了以上三点，我们发现 RN 的出现，有它的必然性。那么回到主题，RN 已经这么优秀了，为什么还要有 Flutter 的存在，有一次向 Ab 哥请教技术成长的时候，Ab 哥提到了很有意思的一个观点，就是您对一项技术了解的深入程度，取决于是否能认清这项技术的局限。 就像人一样，他（她）有多少优点，就会存在多少缺点。没发现，不等于不存在，因为一定存在。因此，顺着这个思路，我们简单的看一下 RN 的问题。

首先，看维护成本，虽然 RN 是一套代码多端运行。但还是需要 IOS 和 Android 开发帮助我们去一个一个的绘制组件，尤其遇到特殊诉求的时候，还要 case by case 的处理，并且随着 IOS 和 Android 系统本身的迭代和升级，以及框架自身发展的历史包袱，我们可能还需要处理很多与原生系统之间的平台差异，修复各种奇奇怪怪的 BUG，这对业务来说是很大的负担。

其次，对性能诉求，无论是产品还是开发同学，对于用户体验的追求，永远都不会停止。RN 存在诸多性能的短板，因此，才会有 Weex 这样的产品出现，去定制化的解决业务场景下的问题。JS 和 Native 的通信，页面的事件监听，复杂动画的渲染和交换成本，都是很大的性能挑战。

最后，在存在更强的业务诉求的时候，人们就不得不去寻找更好的方式去实现。非常存感激的看待谷歌这家公司，都是定位于商业公司，但实际上对世界的影响力上面，公司与公司之间差距还是非常大的。这个课题范围太大，以后有机会可以深度讨论一下。

您看到了上面的描述，为了解决上面这些问题 —— 自绘引擎时代出现了，以 Flutter 为代表的技术方案会应运而生，相信一定不会只有 Flutter 一项跨平台技术出现的，历史总是惊人的相似。其实想到自绘引擎，我最先想到的是那些游戏引擎。那现在又为什么给出 自绘引擎 这样的一个概念呢？H5 是依赖于浏览器渲染，RN 依赖于