Boost整体架构分析
既然是Flutter开发框架，我们首先要知道的就是通过Boost进行业务开发时，他的整体技术架构是怎么样的。除了闲鱼团队的宣讲文章，我们还需深入到代码内部去了解一些新的概念.
Flutter Boost架构
首先我们一起看一下整个Boost的架构关系。
坦白说，第一次看到这张图的时候，有几个感觉：
- 名词多！
- 名词很多！！
- 名词很多啊！！！
后来看到作者又说了句：
我们想做到把Flutter容器做成浏览器的感觉。填写一个页面地址，然后由容器去管理页面的绘制。
瞬间感觉Boost高度被原地干拔起来了，这是要和V8引擎比肩么😶。
为了让Boost更接地气，我决定把我对源码的理解，重新画一张Low图，让Boost落到地上，避免开发者被整张架构图给"劝退"了。(这里不是吐槽原图，也不代表原图表达有何不当之处)
在整个Boost里面他的核心有两个：
- Native层的引擎复用处理
- Dart侧的多视图栈管理
在我们画的那张图中，隐去了关于路由的几个元素和箭头，同时我们把新的名词换为了原生名词。
下面我再结合Boost里面的一些新名词，理解他们的实际含义和作用。
理解Boost的新概念
现在我们通过几个问答来阐述Boost的中核心内容：
问题1：ContainerManager是工具类还是什么，他的具体代表了什么?
Container Manager是Flutter容器的管理，提供show，remove等Api。它本身也是一个Widget，通过对外暴露State，提供了API操作。这个Widget内部管理了一个Overlay组件，从而实现了多视图栈的管理。
问题2：Container和StatefullWidget，StatelessWidget的区别是什么?
Container就是一个普通的Widget，直接继承了原生Navigator，用于承载页面Widget。可以认为他是用了替换原生的Navigator的。
问题3：Messaging和Coordinator本质是什么？
其实就是对MethoChannel的使用，基本可以认为是一个东西的两种表述。
小结
当我们把Boost架构简化后，可以把目光放到重点上面，其他的枝叶如Flutter View，Route，Channel等，并不是Boost独有的。对Boost的源码分析将在后续章节逐一介绍。
参考