小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。

Flutter小技巧目录
【Flutter小技巧01】--- TextField文本垂直居中
【Flutter小技巧02】Flutter环境变量配置
【Flutter小技巧03】-- 常见报错记录

前言：开发中，架构设计的好坏和后续开发和迭代有很大的关系，好的架构可以万变应不变，不好的架构往往会寸步难行，下面是我自己的架构设计和看法，如有不对，请指教。

一、开发模式

目前Flutter开发模式一般是两种：

1、统一管理模式：适用于创建Flutter工程来管理多端（ios、android、web、desktop,等）

2、三端分离模式：适用于在原来的项目中引用flutter模块，让flutter模块编译后产物集成在原生(ios、android、web、desktop等)项目中。

二、架构总览

主要有：业务层、基础层、Service层、DB层、组件层、扩展层

业务层：每个模块下面如果还有很多内容，不相关的内容，可再次划分成小模块，大类模块划分，大类模块在细化小类模块。（宗旨：模块划分清晰，模块之前减少关联，尽量低耦合）后期业务模块相近的，单独抽出来，实现业务模块化插件。各自业务各自维护。

基础层：后期根据业务量和项目使用Flutter的频率，抽出来，插件化。可以分多个插件化(基础组件，网络，工具类等)，有可能一些项目不需要所有基础层的内容。减少关联（网络、日志、权限、工具类、配置/常量、主题、国际化...）

Service层：接口请求，请求后处理好处理，控制层/视图层直接使用，业务请求解耦，每个业务一个API,只负责业务的接口请求，方便后期和业务模块一起打包模块化. 服务层和业务层关联,也就是说有服务层必然有对应的业务层

DB层：sp、sqlite 数据缓存等

组件层：基础组件，后期插件化，项目中尽可能的不适用基础的系统组件，使用二次封装的二次，等插件化的时候，导入插件即可，需要大量替换。提供足够多的可选属性，开发中积累

扩展层：扩展层，根据项目的业务是否使用扩展的内容。增删。后期可独立模块插件化。尽量低低低耦合。注：扩展层(每个独立模块,属于业务中的扩展)

三、架构详细说明图：

最后：往往选择合适的、符合业务长期扩展迭代的即可。架构就是为了方便业务、可扩展、灵活性高等。不一定是按部就班的。

记录自己的小技巧，下次好改进。