Flutter组件化之拆分功能组件

前言

从而导致我们必须要写很多的 export 类，需要我们大量的手动导出供给上层访问，这也太过于麻烦了。

除此之外我们还有代码访问权限的问题， 每一个业务组件都能访问到全部的服务代码，导致他们拥有完全的代码控制权，在协同开发中并不友好。

如果需要解决我们就需要把树状的依赖模式改为不超过两层的扇形依赖结构，下面就这个点我们展开探讨。

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

树形依赖，就是像 Android 开发客户端一样，一层一层的依赖，最终全部依赖的宿主中：

那么为什么又不推荐这么使用呢？主要是又以下的几个痛点。

1. 超过2层之后的依赖，编辑器不支持，需要手动导入。

2. 模块拆分不够细度，访问权限比较粗放。

之前的文章中我们讲到，在一些老版本的编辑器中，我们的宿主和业务模块是可以相互依赖的，但是在升级 Fultter 版本和新版本 AS 之后，我发现目前已经无法跨组件依赖了，无法正常出现代码提示了。

并且我们之前的基础服务组件依赖太细，导致我们不需要一些第三方插件的业务组件也会全部依赖到，导致代码访问权限太大，虽然不影响逻辑，但是代码洁癖不爽，也是怕同事访问到了乱改。

如何解决这些问题，就需要我们使用到扇形的依赖化，就是把功能模块抽取出来按照功能组成对应的模块，我们的业务组件中通过不同的组合依赖对应的功能模块，不需要的组件可以不需要依赖全部的模块。

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

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

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

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

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

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

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

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

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

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

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

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

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

大家有兴趣可以查看对应的源码，在文章尾部有链接。

总结

本文我们对仿 Android 组件话的树状依赖结构进行了改造，变为了更加符合 Fultter 开发的扇形依赖结构，并且对功能模块做出了大致拆分。

主要的代码定义在前文中已经讲过，本篇没有重复讲这一块，主要讲的是拆分功能模块，大家可以作为参考从而实现自己项目的业务拆分，不必要照着我的来，这里也只是给出参考。

对于组件化的一些疑问，这里再次重申。Fultter 不是一定要组件化的，很多应用其实是原生的应用只是加上了少量的Flutter插件而已，你没有必要非要上组件化。

相当多的 Flutter 小型应用，其实页面不多也没有多少业务组件吗，其实没有必要上组件化，我比较是推荐一些大型 Flutter 为主的应用才会应用到组件化。

最重要的是源码奉上，请各位高工大佬指点 【传送门】。

那么当我们完成了对应的组件化改造之后是不是就完美了呢，我们接下来开发还有没有其他的痛点了呢？又该如何解决呢？

嘿嘿，这里留一个悬念吧，期待一下，后面会出哦。

那么本期内容就到这里，一人计短，多人计长，闭门造车思路难免会走弯，文章难免有错误，如果你有其他的更多的更好的实现方式，也希望大家能评论区指出和交流。

如有讲的不到位或错漏的地方，如我的文章有错别字，不通顺的，或者代码、注释、有错漏的地方，同学们都可以指出修正。

如果感觉本文对你有一点点的启发，还望你能点赞支持一下,你的支持是我最大的动力啦！

Ok,这一期就此完结。