全面理解-Flutter（万字长文，【性能优化实战】

从目前行业的产品，以及社区生态来说，React Native 整体还是胜出 Flutter 一筹。毕竟早出来几年，市场占有率和行业积累还是在的。但是长远来看，技术发展也有它的必然规律，Flutter 的技术理念已经领先了 React Native，作为大公司、或者大前端团队的技术储备和技术选型，科技公司要想在未来在行业有一席之地，使用 Flutter 这样的技术，必然也会是一个趋势。至于开发者对于技术本身，应该也会对 Flutter 保有浓厚的兴趣吧，毕竟技术永远都会向前发展，无论是谁，不进步一样会被淘汰。因此，作为技术开发人员首先保持的就是一颗好奇的心，进而持续成长。

当然，未来可能成功的框架不一定就是 Flutter，但是它设计理念和设计思路是一脉相承的，类 Flutter 框架一样也会出现。 就像 React 出来了，Vue 也会跟着出来了。有的团队使用 Vue，有的团队使用 React。但是，您会发现它们越来越像了。使用 Vue 的也没必要说使用 React 的同学水平不好，不存在的！理念很重要，有一句话说的很有意思，叫 ~ 思路决定出路！

2、Flutter 技术架构

1）拥有了 RN，为什么又会出现 Flutter

在谈及 Flutter 之前，我们还是要先简单回顾一下，客户端的上一次技术革新 —— ReactNative（此后简称 RN）。相信非常多的团队都有去落地实践 RN 的机会，很多 APP 的首屏渲染方案都是用 RN 技术栈进行的。我们自己的产品 企鹅辅导 和 腾讯课堂 内的应用也是一样。

这里简单回顾一下，在有客户端开发的场景下，为什么又出现了 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 的通信，页面的事件监听，复杂动画的渲