Flutter 项目目录结构设计-一一网

在传统 web 项目中，开发者会对项目中的公共物料做抽离复用，代码片段如：组件、接口、CSS 样式、类型（TypeScript 项目），资源如图片、icon 等。对于公共页面，更倾向于采用公共组件的形式来维护，因为页面是 web 项目中的最高级也是最重的容器，使用公共组件可以减少页面的部署次数、降低调用成本。而对于轻中量级的 Flutter 项目来说，页面是基础容器，扁平化的页面管理方式会随着页面的增多愈加难以维护，因此建议基于项目实际的业务架构进行目录结构设计，提升项目代码的可读性。

以 Apple Music 为例，它是长这样的：

我们从界面设计中可以拆出如下业务模块：

页面入口	页面内容	涉及的页面或模块
探索页	给用户推荐一些个性化的曲库	专辑详情页、歌手详情页、播放页等
排行榜	不同维度统计下的热歌	专辑详情页、歌手详情页、播放页等
搜索页	个性化曲库内搜索	搜索结果页
乐曲库	分类乐曲库	歌单详情页、会员页
设置页	用户设置页，如歌曲偏好等	登录页、用户信息设置页、会员页

四个页面入口相对独立，本身并没有很重的业务逻辑，更多的是展示公共模块的信息。以【探索页】为例，展示用户个性化的专辑、歌手是页面的核心逻辑，登录页是完成该流程的前置条件，专辑模块、歌手模块、播放器模块是实现逻辑的必需物料。再以【设置页】为例，设置页只是不同页面的集合入口和信息的集中展示（这些子页面也可能相互跳转）。

综上，我们可以设计如下业务结构图：

对上图中的四个模块的概念给出如下定义：

模块	模块定义	文件夹缩写
基础模块	基础物料，自身不具备任何逻辑	base
通用模块	自身带有业务逻辑的可复用模块，且保证独立	common
通用页面	可复用的页面，如登录页、搜索页。或通过【多链路】展示的页面	public
业务页面	一级页面，用户不需要进行交互操作即可查看的页面	业务名

目录结构如下：

| 一 images                       // 图片资源
| 一 assets                       // 其他资源，如 icon/svg/音频文件
| 一 test                         // 测试目录
| 一 lib                          // 资源目录
| 一一 config                     // 环境变量等配置
| 一一 router                     // 路由管理
| 一一 common                     // 通用模块
   └── network                   // 网络库
   └── api                       // 接口集合
   └── components                // 组件库
| 一一 public                     // 通用页面
   └── login                     // 登录模块
    └── login_page               // 登录页
     └── login.dart
| 一一 pages                      // 业务页面
   └── Explore
   └── Setting
   └── Trending
     └── trending.dart
     └── Trending_list.dart
     └── Trending_list_search.dart // 同一业务下二级文件命名采用继承的方式，使用’_’连接
   └── Libarary
   └── Search
| 一一 helper                     // 工具文件夹集合
   └── format.dart               // 各类工具函数
复制代码

目录解析：

目录根据业务进行拆分为四个支线，开发者只需要关心当前支线下的业务逻辑；
在上述开发场景下，一旦涉及到公共页面修改，开发者需要进入public文件修改，提高修改的谨慎性；
什么是【多链路】？如果一个页面只有唯一路径可以打开，那么该页面需要放在pages对应业务页面下；如果某页面有大于或等于二条的路径来打开查看，即为多链路，此时需要将该页面移动到public文件夹内；

综上，该目录可以较好地满足一个中型项目的初始化。

文章版权归作者所有，未经允许请勿转载。

THE END

前端