Architecture►第六章：通用业务规范

发布业务规范

[toc]

发布业务规范

一、流程

1、方案

参考：

问题：为了优化上传耗时，我们将上传所需的图片压缩提前到用户选择完图片之后。那么当点击上传的时候，需要做哪些处理？

答：1、需要先判断之前的压缩任务是否

publish_main_flowchart

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
class BaseAssetModel {
	AssetEntity? assetEntity;
}


mixin AssetEntityCompressProtocol {
  /// 🚗: 要压缩的文件 assetEntity 是一个公共的属性，其他功能也需要使用到。
  /// 🚗: 所以此类为了能够使用 assetEntity ，将在使用时【通过方法的参数传入】，以避免和其他功能冲突重复定义该属性，
  /// 🚗: 并在使用后额外将其赋值给 compressAssetEntity 变量，方便主控制器通过判断该值非空来得出有在处理本功能业务。
  AssetEntity? compressAssetEntity;
  // 1、选择完图片的时候就处理，避免进行上传的时候才去压缩导致时长增加
  Future<void> checkAndBeginCompress(AssetEntity assetEntity) async {
    compressAssetEntity = assetEntity;
    .......
  }

	// 2、选择完显示时候调用，用于获取要显示在列表上的图片
  ImageProvider? get compressedImageOrVideoThumbnailProvider {
    ......
  }

	// 3、点击发布的时候(进行上传文件、创建内容单)
	// 获取最后要上传的图片文件(会自动等待前面的压缩结束)
  Future<String?> lastUploadImagePath() async {
    _log("image choose bean hashCode = $hashCode");
    // 草稿里的图片已有压缩数据
    if (compressInfoProcess == CompressInfoProcess.finishCompress) {
      File resultFile = imageCompressResponseBean?.reslut;
      return resultFile.path;
    }

    await _compressCompleter.future; // 优化压缩流程，上传时候未完成压缩会自动等待，并在完成压缩后，自动继续
    File resultFile = imageCompressResponseBean?.reslut;
    return resultFile.path;
  }

结束语