# standard-flutter

**Repository Path**: ZhangQQ_123/standard-flutter

## Basic Information

- **Project Name**: standard-flutter
- **Description**: flutter开发组件集合
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-09-10
- **Last Updated**: 2023-09-06

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 标准工程flutter版

# 开发指南

### 命名规范以及项目结构

1.所有dart文件命名，首字母小写，遵循驼峰式命名，如果源文件只包含一个顶级类，则文件命名与类名相同，如果包含多个类和方法，文件名描述共性即可，例：

```dart
//只包含一个顶级类，文件名：myPage.dart
class MyPage {}

//包含多个顶级方法，文件名：utils.dart
//方法1
void util_1() {}
//方法2
String util_2() {
  return "haha";
}

```

2.页面page和逻辑model的命名，page命名以xxxPage形式命名，model以xxxModel命名，原则上项目中的每一个page都要对应一个model，page和model的xxx部分保持一致，例：

```dart
//页面page,文件名：myPage.dart
class MyPage {}
//页面逻辑model,文件名：myModel.dart
class MyModel {}
```

3.项目模块划分，目前flutter开发有两种形式：1.新建flutter工程。2.新建flutter
module。无论哪种方式，对于flutter项目来说，都不会过于庞大，所以目前采用：组件分包，逻辑不分包的开发模式（通用组件，以pkg或plugin的形式依赖，项目逻辑在主工程），主工程模块划分如下：

```
--lib
  --common  //项目通用工具类
  --entity  //项目数据实体，json解析后的实体类
  --net     //网络请求相关，包括网络请求工具类，和api的定义
  --pages   //项目的UI页面
    --module//模块，页面内部按模块进行细化,模块内部定义page和model
      --myPage.dart
      --myModel.dart
  --widgets //项目通用的自定义控件以及组合控件
--main.dart //项目主函数
```

4.插件开发命名规范：

```
//如果只包含dart，没有原生逻辑，以pkg_开头，xxx描述插件功能，命名如下：
pkg_xxx
//如果有原生逻辑，以plugin_开头，xxx描述插件功能，命名如下：
plugin_xxx
//如果是示例代码，不建议在主工程写示例代码，可以作为一个入口，命名如下：
sample_xxx
```

5.Flutter常用命令：

```
//创建package包：xxxxx项目名称
flutter create --template=package xxxxx
//创建包含Android和iOS原生代码的plugin包，com.example包名，自定义修改，xxxx插件名自定义修改
flutter create --org com.example --template=plugin xxxx
```

### 注意事项：

1.为了使代码更具可读性，开发过程中，注意","的使用，使用studio的option+command+L可快速格式化代码，逗号的作用，可以让代码结尾的括号或者大括号在格式化的时候换行，便于阅读。

### 其他：

#### 1.如何减低项目后期维护成本

在开发过程中，通常会依赖很多的库，但是，如果有些库有别的更好的实现方案的时候，进行替换是件比较麻烦的事。所以：最好我们的项目逻辑，不去直接依赖第三方的库，我们可以抽象出一些接口或者定义一些管理类，作为项目和依赖的库进行沟通的桥梁，当我们需要替换掉一些库的时候，只需要按照我们定义好的接口，把实现逻辑替换掉就行了，而不用关心已开发好的上层的逻辑，这其实也就是设计模式中的门面模式，也是一种业务分层的实践方案，主要好处就是在做架构升级的时候，可以确保修改的影响范围是可控的。