什么是组件化/渠道化
在App开发和架构规划时, 考虑如何去管理代码复用, 解耦
如何将功用进行
分治，将大问题分化成多个独立的小问题。
组件化和渠道化就是App开发中最盛行的分治手段。
本节不仅适用于Flutter架构规划,也相同适用于Android/iOS等一切软件开发
组件化
组件化又名模块化, 将一个大型App依照关注点分离拆分红多个独立的组件或模块。
每个独立的组件都是一个独自的系统，能够独自保护、晋级甚至直接替换，也能够依靠于别的组件，
只需组件功用不发生变化，就不会影响其他组件和APP的整体功用。
组件化的中心思想是将独立的功用进行拆分。
组件可所以一个软件包（Package）、页面、UI控件，甚至可能是封装了一些函数的模块。
组件代码如何安排, 需求遵从如下基本准则
单一责任
每个组件仅供给一个功用，有自己固定的责任和明晰的鸿沟, 这样才干良性开展。
一个反例是Common或Util组件：“这段代码放哪儿好像都不合适，那就放Common（Util）吧”。定义不明确、归属鸿沟不明晰的代码, 终究变成了垃圾堆。
再遇到不知道该放哪儿的代码时，就需求从头思考组件的规划和责任了。
接口安稳准则(开闭准则)
- 接口应该具有高复用度并保持安稳。要做到这一点，在组件封装时做好
功用笼统和接口规划 - 一切可能发生变化的因子都在组件内部做好
适配，不要露出给它的调用方。
安稳性准则
不要让安稳的组件依靠不安稳的组件。
比方组件1依靠了组件5，假如组件1很安稳，可是组件5常常变化，那么组件1也就会变得不安稳了，需求常常适配。
假如组件5里确实有组件1不可或缺的代码，咱们能够考虑把这段代码拆出来独自做成一个新的组件，或是直接在组件1中复制一份依靠的代码。
减少依靠
组件尽量减少对其他底层组件的依靠。比方，直接复制依靠的代码到组件中, 删掉依靠组件。
组件化具体实施步骤
-
剥离与事务无关的根底功用，比方网络恳求、组件中间件、第三方库封装、UI组件等，将它们封装为
根底库。 -
依照
事务维度，比方首页、详情页、搜索页等，去拆分独立的模块了。拆分的粒度能够
先粗后细，只需能将大体区分明晰的事务组件进行拆分，后续就能够通过分布迭代、局部微调，终究完结整个事务项目的组件化。 -
依照上面的4个准则，修正各个组件的依靠，以及最小化对外的接口。
组件循环依靠
假如组件之间的依靠联系比较复杂，就会在出现功用耦合现象。
一旦这些组件的内部完结和外部接口发生变化，整个App就会堕入不安稳的状态，即所谓牵一发而动全身。
渠道化
渠道化是组件化的晋级，即在组件化的根底上，对它们供给的功用进行分类，一致分层区分，增加依靠管理的概念。
咱们依照四象限剖析法，把App的组件依照事务和UI分化为4个维度，来剖析组件能够分为哪几类。
- 具备UI特点的独立事务模块；
- 不具备UI特点的根底事务功用；
- 不具备事务特点的UI控件
- 不具备事务特点的根底功用
渠道化分层
组件之间既保持了独立性，一起也具有必定的弹性，在不越界的状况下依照功用区分各司其职。
渠道化关注的是组件之间联系的合理性，遵从单向依靠准则。
-
单向依靠准则，指的是组件依靠的顺序从上到下依靠，不要出现基层模块依靠上层模块这样循环依靠的现象, 避免复杂的耦合。
-
除了不允许出现基层组件依靠上层组件的状况，跨层组件和同层组件之间的依靠联系也应当严格控制。
基层组件怎样调用上层组件
增加中间层，比方Event Bus、Provider或Router，以中间层转发的方式完结信息同步。
比方，坐落第4层的网络引擎中，会针对特定的过错码跳转到坐落第1层的一致过错页，这时咱们就能够利用Router供给的命名路由跳转，在不感知过错页的完结状况下来完结。
又比方，坐落第2层的账号组件中，会在用户登入登出时自动刷新坐落第1层的首页和我的页面，这时咱们就能够利用Event Bus来触发账号切换事情，在不需求获取页面实例的状况下告诉它们更新界面。
Flutter系统分层
除了上面介绍的事务和UI四象限法则之外，也能够使用其他的区分策略，只需整体结构层次明晰明确，不存在难以确定归属的组件就能够了。
比方，Flutter就采用Embedder（操作系统适配层）、Engine（渲染引擎及Dart VM层）和Framework（UI SDK层）整体三层的区分。Flutter框架每一层的组件定义都有着明确的鸿沟，其向上供给的功用和向下依靠的能力也非常明确。
