闲鱼 Flutter 实践与思考( 三 ) _Flutter

第三个阶段是 Flutter 大规模的推广的问题，真正意义上让团队每个同学都可以开发 Flutter 的代码。
而这一过程中，主要的挑战在于如何让没有经验的同学在短时间内可以写出高水平的 Flutter 代码并解决代码隔离问题。这部分我们通过对 Redux 的标准进行扩展，前后经历了三个版本的迭代讨论，最终在保持 Redux 核心三原则的基础上，扩展出了 Component 机制来解决组件复用以及代码隔离的问题，这个在多人协同的复杂业务上是非常重要的。我们也将其开源并命名为 Fish-Redux ，欢迎大家使用。
Flutter 的变化与展望改进与优化闲鱼在混合架构的演进的过程中，与 Flutter 相关的改动主要有两部分，第一部分是针对于引擎本身的 Bug 进行的修复工作，随着 Flutter 的日益完善，这部分目前对大家的参考意义不太大。
而另一部分则是关于性能的优化与改进。有两个比较典型的例子：
1、第一个是混合开发的开始阶段，如果每次都创建新的 FlutterView 进行渲染，会造成内存的严重消耗，但如果全局只使用一个 FlutterView 又会造成 Native 和 Flutter 页面栈管理复杂。基于这个问题我们研发出 Flutter_Boost 的方案，既保证了全局只有一个 Engine 实例共享，又通过该框架屏蔽了 Native 和 Flutter 页面栈管理复杂的问题。
2、另一个是针对图片和视频在 Flutter 页面上渲染的优化。主要的策略是通过改造 Flutter Engine 将绘制部分的 API 做扩展，允许 Flutter Engine 接受 TextureID 的直接传递，保证 Flutter 页面在使用外接纹理绘制的过程中整个调用链路足够短，使用的内存足够少。这个方案当然也有缺陷，就是需要改 Engine ，通过去年的优化，我们已经找到了类似缩短链路又不改引擎的方案，后续也会分享给大家。
后续规划后续团队的 Flutter 发展规划大体有几个方面：

目前需要基于闲鱼现有的技术体系，为集团赋能。我们正在跟淘宝架构团队进行横向的联通，通过贡献我们现有能力的方式，推进 AliFlutter 的落地，以帮助集团更多的团队。当然闲鱼主要是输出技术方案，中台本身还是由其他团队来支持和负责。
闲鱼也有自己的主线，我们希望推进技术栈的归一，保证端和云的编程模型可以进行归一。举个例子，未来的业务团队一个人就可以从端到云进行开发，这对于构建柔性的技术组织有巨大好处，这种类型的组织极大的减少了技术栈之间的协同，对企业成本和效率有明显提升。
我们也有非常多贴近业务的技术方案在进行尝试中。比如动态模版框架和轻量级游戏引擎，未来可能会产生一些机会和变化。

我们目前团队的架构师， Fish-Redux 的作者吉丰将于今年的 GMTC 上给大家分享详细的架构设计和应用场景，欢迎大家参加。
您觉得 Flutter 在未来的发展趋势如何？跨平台开发会出现大一统的局面吗？从目前的方案上来看， Flutter 是行业内跨平台方案解决的较为彻底的一个，且背后有 Google 支持。大量的头部公司都有团队在持续投入和研究，因此我认为作为一种跨平台的解决方案，未来 Flutter 有机会成为主流的开发方式之一，另外由于它是跨终端的解决方案，未来在 PC 端和 IoT 设备端也会有一定的机会。
但 Flutter 一定不是唯一的方案，而且不可能完全代替 Native 开发。从成本和效率来说，若 Flutter 后续将生态完善起来，对于绝大部分小前台的 App 或需要多个终端进行投放的 App 来说将会是一个不错的选择，这也是大厂在推进 Flutter 上都比较积极的原因。对于大厂来讲，百花齐放是非常有必要的，大厂 all in 某一种技术是非常危险的选择。
而对于跨平台开发来说，行业内一直都在不断推陈出新，所以我觉得不太可能出现大一统局面。另外，跨平台开发框架其实是非常多的，除了 Flutter ， Weex 和 ReactNative ，我们去看 Qt ，去看 Cocos2d-x 包括浏览器技术都是跨平台技术。技术选型跟团队架构师定义的当前问题、团队同学的知识结构、上下游的技术架构都有一定的关系，没有最好的技术，只有相应场景下具有优势的技术。