项目架构

Provider+MVVM

目录结构

├── all_pages 存放所有的逻辑页面
│   ├── example 样例
│   │   ├── example_model.dart mode
│   │   ├── example_page.dart  page
│   │   ├── example_view_model.dart viewMode
│   │   ├── model 如果页面需要model的不只一个，建一个model 文件夹
│   │   └── view 如果页面需要的view的不只一个，建一个View 文件夹
├── ext 存放扩展
├── global 
│   ├── cache 内存缓存
│   ├── config 配置
│   ├── event 事件
│   ├── net 网络请求
│   ├── route 路由
│   └── theme 主题
│   └── model model
├── helper 对第三方库的封装
├── l10n 国际化
├── lib  自定义的的库或者下载的第三方库
│   ├── module
│   └── mvvm
├── manager 数据封装和管理
├── service 封装的服务
├── tools 不包含本项目逻辑的工具类
├── utils 包含本项目业务逻辑的工具类
├── view  包含本项目业务逻辑的的封装组件，这里
└── widget 包含本项目业务逻辑的的组建

运行

准备

• 更新库：flutter pub get
• 国际化：flutter gen-l10n
• 运行

使用命令

• flutter run --debug/release ---dart-define=B_ENV=debug/verify/local/pred/prer/release
• eg:flutter run --debug --dart-define=B_ENV=debug 就可以运行开发环境
• eg:flutter run --debug --dart-define=B_ENV=verify 就可以运行测试环境

android studio 配置如下

• --dart-define=B_ENV=debug
• 
• 

打包

准备

project_path=$(cd `dirname $0`; pwd)
cd $project_path
cd ..
git pull
flutter clean
flutter pub get
flutter gen-l10n
cd ios
pod install

android

• 给测试打测试环境的包，用Debug 编译模式
  • flutter build appbundle --release --flavor test
• 给测试打灰度环境的包，用Pre 编译模式
  • flutter build appbundle --release --flavor pre
• 给测试打生产环境的包，用Release 编译模式
  • flutter build appbundle --release --flavor pro

iOS

IOS Xcode

• 给测试打测试环境的包，用Verify 编译模式
• 给测试打灰度环境的包，用Pre 编译模式
• 给测试打生产环境的包，用Release 编译模式

fastlane

• 上传到TestFlight fastlane upload_release
• 上传到蒲公英 fastlane upload_pgy e:Verify (Verify PreR Release Loc 可以配置不同的环境)

命名规范

• 项目工程名用下划线_命名
• 文件夹用下划线_命名
• 图片命名下划线_命名 并且加上_img 后缀，方便后面写工具来排重和删除多余的文件
• 类用大驼峰
• 方法，变量用小驼峰
• 图片命名下划线_命名
• 不同的类或者文件都需要加上对应的后缀
  • Page eg:user_info_page.dart UserInfoPage
  • Model eg:user_info_model.dart UserInfoModel
  • ViewModel eg:user_info_view_model.dart UserInfoViewModel
  • Utils eg:user_info_utils.dart userInfoUtils
  • Tools eg:user_info_tools.dart UserInfoTools
  • Helper eg:user_info_helper.dart UserInfoHelper
  • …

代码规范

• 目前遵守flutter_lints的规范

git管理

• 命名统一使用下划线_

代码提交

• fix:dec 修复bug
• feat:dec 开发一个新功能
• optimize:dec 优化了
• delete:dec 删除了
• doc:dec 添加了文档或者注释

分支管理

• master 审核成功，并且已经上架，线上正在使用的版本
• release 开发完成，准备上架的版本
• dev 能够正常运行并且下一个迭代要上线版本
• feature_1.2.0_dec 正在开发的版本
• 开发一个新功能 git checkout -b feat_dec
• 开发完成合并到dev
• 测试阶段，从dev 打包，小bug 可以直接在dev上修改，大bug 需要新牵一个fix_dec 分支
• 产品验收阶段 合并代码到release 分支，如果出现bug,需要重release 拉一个新分支fix_dec 修复完成和，同时合并到dev和relese 分支
• 上架成功 将release 代码合并到master 并打一个tag 如果线上出现bug 需要修复也需要拉一个fix_dec 分支，修复完成后需要同时合并到dev和release 分支