Flutter组件化之拆分功能组件

前言

【前文】中我们仿造 Android 组件化的方式，依葫芦画瓢完成了 Flutter 的相关组件化，但是随着 Fultter/Dart 版本升级和编辑器的版本升级，我们发现越来越不好用了，像 Android 一样的一层层树状的依赖结构导致我们无法有效的方法到地层的文件类。

从而导致我们必须要写很多的 export 类，需要我们大量的手动导出供给上层访问，这也太过于麻烦了。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

除此之外我们还有代码访问权限的问题， 每一个业务组件都能访问到全部的服务代码，导致他们拥有完全的代码控制权，在协同开发中并不友好。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

如果需要解决我们就需要把树状的依赖模式改为不超过两层的扇形依赖结构，下面就这个点我们展开探讨。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

一、树形依赖组件化的痛点

树形依赖，就是像 Android 开发客户端一样，一层一层的依赖，最终全部依赖的宿主中：文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

如果在 Flutter 中使用 Android 这样的树形依赖方式，也是可以做到的，我们在前文中已经介绍过相关的改造方式，【像Android一样自行实现组件化】。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

那么为什么又不推荐这么使用呢？主要是又以下的几个痛点。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

1. 超过2层之后的依赖，编辑器不支持，需要手动导入。
2. 模块拆分不够细度，访问权限比较粗放。

之前的文章中我们讲到，在一些老版本的编辑器中，我们的宿主和业务模块是可以相互依赖的，但是在升级 Fultter 版本和新版本 AS 之后，我发现目前已经无法跨组件依赖了，无法正常出现代码提示了。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

并且我们之前的基础服务组件依赖太细，导致我们不需要一些第三方插件的业务组件也会全部依赖到，导致代码访问权限太大，虽然不影响逻辑，但是代码洁癖不爽，也是怕同事访问到了乱改。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

如何解决这些问题，就需要我们使用到扇形的依赖化，就是把功能模块抽取出来按照功能组成对应的模块，我们的业务组件中通过不同的组合依赖对应的功能模块，不需要的组件可以不需要依赖全部的模块。文章源自灵鲨社区-https://www.0s52.com/bcjc/flutterjc/16304.html

最终全部的业务模块组合为全新的宿主App，这员工就可以解决无法导入超过两层依赖的package的问题，从而也能解决代码/库权限访问的问题。

总结就是不超过两层的依赖，接下来我们就详细探讨如何拆分功能组件。

二、扇形依赖功能组件拆分

对于拆分为哪些组件，参考网上的资料和个人的经验之后我的方案是分为数据模块，路由模块，工具模块，控件模块，资源模块，第三方插件与引擎模块，初始化模块。

数据模块：内部包含一些数据业务，数据实体 Entity，数据仓库 Repository，数据模板用例 UserCase，本地数据库 DBHelper，缓存数据 HiveManager 等。

路由模块：监听路由器，自定义路由栈，路由声明周期管理，页面路由路径与路由表等。

工具模块：提供基本的全局工具类如LogUtil,SPUtil,DeviceUitl,RegUtil,ScreenUtil,EncrptUtil 等。

控件模块：基础的控件封装，控件扩展，基础的Dialog和Picker等样式。

资源模块：前文中我们花了大量的笔墨讲解了资源模块的重要性这里不啰嗦，我们在这里定义全局的各种资源，图片，视频，字体等等，注意分好对应组件文件夹哦，方便随时增删改查。

第三方插件与引擎模块：网络请求引擎 Dio ，文件夹管理 DirectoryUtil，气泡弹窗Loading管理，权限管理 Permission ，多媒体与相机管理 CameraPicker，PhotoManager等。

初始化模块：统一处理以上模块需要的初始化和默认配置尽量适用于不同的项目。

那么我们的业务组件想要依赖这些基础模块就可以选择性的引入，最后把想要的业务模块组合在一起就是宿主 App 了。

我们在前文中的业务逻辑不变的情况下，使用这种方案在开发中就会更加的便捷了。