本文会从底层原理、优化思路、实际场景的优化策略、核心技术实现、优化成果等方面，为大家深度讲解淘特 Flutter 流式场景优化，欢迎交流与指正。

由于Flutter的跨平台应用特性，可以提高人效之余，还能保证在iOS和Android平台实现方案的统一性，避免了后续因需求业务扩展由于实现方案不同带来的限制。目前京东到家19个活动落地页已经全部替换为Flutter实现，与此同时也带来了包体积的不断膨胀，其中iOS和Android双端Flutter业务模块包占比都高达20%。苹果官方尽管已经将包体积放宽至200M，考虑到用户在更新和下载的时候的多种场景，我们针对于包的大小限制仍旧以100M为衡量标准，所以Flutter业务模块的瘦身对于到家app来说仍旧是至关重要的。因此我们进行了Flutter包动态下发探索。

本文介绍了Flutter for Web的发展现状，并且从编译、部署、运行和渲染等几个方面进行了介绍和原理分析。

在移动端，经常会存在局部视图切换的场景，比如图1所示的场景， 页面的左边部分支持切换到下一个页面并且下一个页面可以返回到上一个页面。在Android中，可以使用Fragment实现图中所示的效果, iOS中可以使用UINavigationController实现类似的效果。那么在Flutter中，应该怎么实现这种局部页面切换呢？

在Flutter中，页面切换是通过Navigator实现的， 那么能否考虑将Navigator用于局部页面切换呢？答案是肯定的。本文将重点介绍使用Navigator进行局部页面切换，以及在使用的过程中碰到的一些问题和解决方案。由于业务中目前使用的Flutter版本为v1.12.13，所以本文也会基于这个版本进行分析。

贝壳在iPad和安卓平板（这两种后续统称为PAD）上面进行了多款产品的开发；为了提高开发效率，实现一套UI跨端展示，贝壳使用Flutter进行了大量实践。

在手机上屏幕比较小，一般一个页面就是一个完整的Flutter页面，这种场景使用一个FlutterActivity容器进行加载就可以了。然而在PAD上，屏幕比较大，交互更加的丰富；由于业务上大量的用到了地图和一些H5页面，会出现同屏Native和Flutter混合的情况，会使用到FlutterFragment和Fragment在同屏切换的场景；因此我们不得不采用Native+Flutter的混合方案，FlutterEngine作为Native和Flutter桥连的容器在这中间扮演着重要的角色。

这期间贝壳PAD经历了单FlutterEngine到多FlutterEngine再到Flutter2.0的FlutterEngineGroup这一系列的容器改变，下面会详细的介绍FlutterEngine在PAD上的演变过程。

前面大家了解了Web和Native端的路由管理，这篇文章出场的是大前端领域备受开发者喜欢的新秀Flutter。

Flutter作为一款跨平台UI框架，借鉴了React（Web开发框架）的响应式的UI框架设计思想等。在Flutter中，一切皆是Widget（组件），其中StatefulWidget（有状态的组件）和React中的组件类似，可以通过数据变化去手动更新视图，Flutter路由管理实现的核心组件Navigator就是这样的一个StatefulWidget。

本文主要记录了如何一步步学习了解Flutter视图绘制原理，然后应用到性能监控和性能优化的实践。

闲鱼近期实现了端上直播间的 Flutter 技术重构，验证和拓展了 Flutter 在音视频领域的业务边界。因为直播丰富的玩法和可变的交互，通常我们会在直播间页面覆盖一层互动层，用于处理和展示业务互动行为。这一互动层，通常是由 H5/Weex 等技术来实现的，以满足动态性和业务投放的需求。因为其背后有着一整套配套的解决方案和能力，显然在 Flutter 场景下，复用或移植成熟的 Native 能力是比较好的解决方案，PlatformView 是最适合用于实现该组件的技术，这也是我们采用的方案。

如果熟悉React的话，你在使用Flutter的时候肯定会充满即视感，其实这一点也不奇怪，实际上Flutter官方就提到在设计Flutter时受到了React的影响。对于熟悉React的前端开发人员来说，从与React对比开始入门想必是相对来说比较轻松的一个方式。

Flutter与React，两者都作为一个声明式UI框架，都遵循UI = f(state)的理念，加之Flutter本身就参考了React，所以两者有大量相似的地方。下面我们从编写一个经典前端入门应用Todo List开始我们的Flutter之路。

去年，闲鱼图片库在大规模的应用下取得了不错的成绩，但也遇到了一些问题和诉求，需要进一步的演进，以适应更多的业务场景与最新的 flutter 特性。比如，因为完全抛弃了原生的 ImageCache，在与原生图片混用的场景下，会让一些低频的图片反而占用了缓存；比如，我们在模拟器上无法展示图片；比如我们在相册中，需要在图片库之外再搭建图片通道。

这次，我们巧妙地将外接纹理与 FFi 方案组合，以更贴近原生的设计，解决了一系列业务痛点。没错，Power 系列将新增一员，我们将新的图片库命名为 「PowerImage」！

随着各种多端技术的蓬勃发展，如今的移动端和前端早已不再拘泥于自身的边界，而是不断延伸、扩展和融合，逐步向着真正的大前端技术迈进。跨端技术也从早期的Cordova/PhoneGap、纯H5页面发展到如今的ReactNative（以下简称RN）、Weex、小程序、Flutter群雄并存的局面。各种技术栈各有优劣和特点，技术选型需视团队自身情况而定，没有绝对好坏之分。然而在实际开发中，并不是只选用一种技术栈，那么研究多种技术栈融合和嵌套使用的就有了迫切的必要性。

本文我们从实际业务场景出发，初步实践了在RN里面嵌套flutter view、在native里面嵌套flutter view，探索其可行性，并回顾这个过程中遇到的一些问题和解决方案。

本文旨在尽量避开具体的代码细节，从思想上去介绍flutter的各种技术实现，让已经在从事flutter开发的同学有更多的收获，同时对flutter感兴趣的观望者也能更好的了解这门技术。

最近这两年，移动端各种跨平台的开发方案如雨后春笋般涌现，一方面是随着移动互联网的普及和快速发展，移动终端设备的软硬件、操作系统、开发工具链等日趋成熟；另一方面，传统 PC 端的技术、资源也在逐步迁移到移动端上来，大家都想造轮子“一统天下”。

还在为Flutter GPU后台Crash而苦恼吗，快进来看看吧！

keframe是贝壳的一个关于Flutter流畅度优化的开源组件。主要功能是通过分帧渲染来优化由构建导致的卡顿，例如页面切换或者复杂列表快速滚动的场景。

国际化是指在设计软件时，将软件与特定语言及地区脱钩的过程。当软件被移植到不同的语言地区时，软件本身不用做内部工程上的改变或修正。

本地化则是指当移植软件时，加上与特定区域设置有关的资讯和翻译文件的过程。国际化和本地化之间的区别虽然微妙，但却很重要。国际化意味着产品有适用于任何地方的潜力；本地化则是为了更适合于特定地方的使用，而另外增添的特色。用一项产品来说，国际化只需做一次，但本地化则要针对不同的区域各做一次。这两者之间是互补的，并且两者结合起来才能让一个系统适用于各地。