小常识，大应战！本文正在参与“程序员必备小常识”创造活动。

本文已参与「掘力星计划」，赢取创造大礼包，应战创造鼓励金。

前言：开发中，架构规划的好坏和后续开发和迭代有很大的关系，好的架构能够万变应不变，不好的架构往往会寸步难行，下面是我自己的架构规划和观点，如有不对，请指教。

一、开发形式

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

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

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

二、架构总览

主要有：事务层、根底层、Service层、DB层、组件层、扩展层

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

根底层：后期根据事务量和项目运用Flutter的频率，抽出来，插件化。能够分多个插件化(根底组件，网络，东西类等)，有或许一些项目不需求一切根底层的内容。削减相关（网络、日志、权限、东西类、装备/常量、主题、国际化…）

Service层：接口恳求，恳求后处理好处理，控制层/视图层直接运用，事务恳求解耦，每个事务一个API,只负责事务的接口恳求，便利后期和事务模块一同打包模块化. 服务层和事务层相关,也便是说有服务层必定有对应的事务层

DB层：sp、sqlite 数据缓存等

组件层：根底组件，后期插件化，项目中尽或许的不适用根底的系统组件，运用二次封装的二次，等插件化的时分，导入插件即可，需求很多替换。供给足够多的可选属性，开发中积累

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

三、架构详细说明图：

最终：往往选择合适的、契合事务长时间扩展迭代的即可。架构便是为了便利事务、可扩展、灵活性高等。不一定是墨守成规的。

记载自己的小技巧，下次好改善。