以一个标准的 Flutter 工程为例，由于每个用户的电脑内的环境都不一样，那么在你关注这个工程本身的同时还需要关注用户本地的环境配置。我们不可能永远知道业务团队同学在使用什么样的配置，每次处理问题都进行沟通的话，就会在无形之中多出了太多的成本。Flutter 把环境直接配置在了项目内部，通过 FlutterW 安装的项目，它的内部除了代码资源外，还会有一个依赖配置表，里面会将此项目的一些信息，诸如基础的依赖、SDK 版本、打包工具等，都描述清楚，然后根据这个配置表来自动拉取相应的资源从而形成一个沙盒环境，在这个环境内进行独立开发。
自动化工程能力
第二个是自动化工程能力。如上图，当业务团队需要反馈问题的时候，FlutterW 会收集更多信息提交给我们团队，我们基础技术部收到信息后会将问题还原并提出解决方案，这时候我们可以将解决方案部署到 FlutterW 的云端服务器，FlutterW 会自动更新这些方案从而为业务团队解决问题。通过 FlutterW 这个媒介，我们可以尽量地拿到用户信息并将解决方案实时部署。
以上两个是 FlutterW 最核心的两个能力，简单总结来说就是：
-
标准化工程环境，保证项目成员环境?致，问题可回溯。
-
?动化工程方案能力，协助排查问题、解决问题，实施?案。
-
提供低成本体验 Flutter 能力，降低 Flutter 的推广难度。
-
配合研发流程打包发布 Flutter 产物。
容器化工程方案背景
这里的容器化工程方案更多的是指 API 的容器化。Flutter 是一个跨平台语言，跨平台框架，身为一名开发者听起来实在是很美好——做一个 App 就可以各个端去跑。但当开发者真正着手开发一个跨平台应用的时候，就会发现需要了解的实在是太多了：Dart 是不可避免的，还有 Java、OC、平台相关语言… 因为我们终究还是要依赖平台的能力，这样要求还是比较高的。正因为一般的开发很难兼顾好各个平台，所以我们很多业务开发会同时配置一个 iOS 和一个 Android，当平台出现问题时分别跟进，但这样很浪费人力。那有没有办法让我们的业务只关注在 Dart 上呢？不用再去管这些所谓的平台能力呢？显然是可以的。
多端、多业务交叉部署
我们引入了一层标准化的 API，用来规范化各个平台提供的所有能力。平台实现这样一套标准能力后，Dart 业务的开发方就不需要再烦心于各个平台的问题，面向这一层 API 进行编程就可以了。也正是引入这一层，使我们可以达到真正的多端、多业务交叉部署。
Flutter 作为一个渲染框架，自身就保证了运行环境的渲染能力的统一，而容器化 API 又保证了各个平台、各个端的基础能力的统一，有了渲染能力和基础能力的统一，业务方就可以真真正正的用一套代码跑在各个端上了。
业务隔离部署
这其实是对于开发者的开发体验的一个优化。既然是面向 API 编程，那么就不需要关注最终运行在哪里了。对于开发来说，在开发时运行一个 H5 版本岂不是更方便、更轻巧？最起码不用再连接一部手机。在实际交付的时候，再打包成产物，交付到实际的设备上。
体系
–
那么容器化 API 是一个什么样的体系呢？
如上图，整个容器化 API 最重要的部分是上方的红色部分，我们需要固定 API 层并将其标准化，所以它有一个独立的 API 版本管理。但仅仅提供一层 API 也是不够的，以字节跳动为例，公司内部的 App 特别多，每一个应用都要重复实现这些接口的实现并不科学，所以我们为它提供了一套默认实现——而且这个方案可以支持他们随便移出这些实现，修改成自己的实现或者做一些其他的扩展。
经历了这么多的考量，最终得出了这个容器化 API 方案的最终产品，大概总结下来就是：
-
容器化标准化了各端的基础能?；
-
分离开发关注点，降低开发难度；
-
业务开发、部署环境可分离，可以?向 Web 端提供更快更好的开发体验，最终部署在 Native 获得更好的?户使?体验。
ByteRedux 状态管理方案背景
Flutter 是一种典型的响应式 UI 框架，这种框架的特点就是 ui = f(state)，重要是状态而不是 UI。只要我们能管理好一个应用的状态，那我们整个应用的页面或者行为就始终受控。但 Flutter 这种框架，它状态分散在各个组件当中，各个页面之间要互动、流转，从而导致这个操作十分烦琐，很难维护。
选择
–
所以我们要尝试研究之前前端的一些经验，目前业界的主流就是 Redux，那它有什么优势呢？
如上图，左侧的图更像我们平时的一些应用开发，各个元素间相互调用，各个对象间也经过各种循环来调用，一旦项目相对庞大，就会没有人敢随便动这个项目，项目就会逐渐失去可维护性。反观 Redux，它提供了一个角色，把所有的状态收归在其内部，除了参与元素外，主要是对 UI 的监听，监听那些状态有着什么样的改变。同时，我们也更容易知道它内部会发生哪些变化。
简单看一下 Redux 的原理，上文提到的管理角色叫做 Store，Store 内持有了整个应用的所有 State，同时它也持有着所有的 Reducer——用来更新这些状态的。正因为数据和更新方法都在控制范围内，整个应用就拥有较高的可控性。
大致流程就是：我们的页面元素 View 发送一个事件通知 Store，在 Store 内部会根据这个事件进行处理并遍历所有的 Reducer，哪一个 Reducer 对这个事件感兴趣就会更新的状态，同时 View 元素就会自动改变。重点在于这是一个单向的数据流和单一数据源。
缺陷
–
当我们真正使用 Redux 的时候，就发现 Redux 有一些不足之处：
-
入门成本偏高，但维护成本显著降低
-
全局只有?个 Store 是个大问题
-
牵一发动全身，全局计算导致性能问题
-
无法多人协作开发
- 状态是静态定义的
-
数据结构复杂化
-
状态缺乏生命周期
由此，我们也尝试比较了一下目前市面上其他的状态管理方案：
可以看得出来，各个解决方案都有其优缺点，但结合我们自身应用的规模化考虑还是觉得 Redux 这种强管理、数据状态可控的模式更适合我们。
方案介绍
那么之前的问题关键在于哪里呢？
-
关键问题：Store“超重”，Store 需要负责具体 UI 互动细节，又要负责管理全局状态两个角色；
-
核心思路：引入更高?级的概念取代 Store 成为单?数据源，管理全局。
回想我们的状态本身，状态分布于页面上，而且状态之间往往会有一些归属关系，例如有的页面在登陆后才会存在，有的信息在登陆后才会有。由此我们选择了一个树状结构，也就是我们的自研方案——ByteRedux。
高性能、低成本学习
我们引入了一个 StoreTree 来承担这个单一数据源这个角色，引入这个角色以后有什么好处呢？第一个就是高性能、低学习成本。为了避免引入开发时候的误区，我们选择了让 Store 来代理这棵树让 Store 和单一数据源完成整个交互。
举一个例子，我们的 UI 发送一个 Action 到这个最左边的 Store 的时候，这个 Store 不会直接在内部处理而是转发到根节点，从而投派给 StoreTree 这个角色，让 StoreTree 管理这个 Action，帮你去寻址到你想发送的 Store，这时它内部才会进行计算并更新内部的状态。这个过程对于我们普通开发者来说，和原本的 Redux 用法基本上没区别，并不需要额外的学习成本。高性能又是怎么理解呢？如下图，这个 UI 元素能影响到的仅有它的目标 Store，其余四个节点的状态完全不会受干预，也不会导致其他无关的界面的任何的 ReBuilt。
支持模块化开发
要支持多元开发和模块化开发，有一个问题必须要重视。如上图所示，模块 A 在宿主应用内的运行时，根结点会继续寻找合适的挂载节点，然后加入之前的应用的单一数据源——StoreTree 里面，并让自己开始运行。那么在模块开发时该如何运行呢？
我们的 Store 根结点会自己生成一个根节点，从而保证生成单一数据源的这个对象在一个小模块内依然可以正常运行。但仅仅保证可以运行还是不够的，开发者做模块开发时，总会依赖一些外部的属性。例如，很多情况下要依赖登录信息和用户状态等，我们的根结点可以 Match 一些外部的状态，从而加速我们的整个开发流程。
复?已有社区资源
ByteRedux 作为我们自研的框架，如何复用社区已有资源也很重要。整个方案的核心就是维护 StoreTree，具体到每一个 StoreTree 是否需要自己实现则不是关键问题。但如果我们可以通过一个转换器用上社区中所有的轮子肯定是最好的，所以最终我们通过一个转换器实现了对社区已有资源的复用。
架构
–
ByteRedux 的架构需要关注的只有中间的部分，图中的 ByteRunner 就负责刚才的模块化开发，包括判断节点是否需要、如何寻找已有的单一数据源、如何创建单一数据源等，同时它也是支持 Mork 数据的关键。
关于 ByteRedux 的优点总结下来就是：
-
具备 Redux 的所有优势（强管控、可预测、测试友好）；
-
高性能；
-
支持模块化开发、运行；
-
学习成本低；
-
复用已有社区资源；
-
支持全局、局部?播等新特性。
总结与展望