一、前言

作为开发者，可以很负责地说，问题是一定会有的。任何app，哪怕上线前经过了专业的测试和验收，最终到了用户手上，还是会出现各种各样的问题，这些问题或是逻辑缺陷导致、或是用户体验差。

总的来说，一款合格的app，必须在app内部提供反馈问题的渠道。具体到本系列博文所对应的 TxtEdit，提供的反馈问题的渠道，就是通过邮件的形式将必要的信息发送给开发者，如此设计，是因为 TxtEdit 是一个单击应用，并不存在一个远程的应用服务端。

在实现过程中，我会向大家分享如何压缩日志文件和生成带附件的邮件。

二、日志文件压缩处理工具类

在专门存放工具类的 lib_util 模块的源码目录里，新建一个 ets 脚本并命名为 ZipLogUtil：

ZipLogUtil.ets 文件中声明定义 ZipLogUtil 类，并将其通过 lib_util 模块的 index.ets 脚本中的导出语句 export { ZipLogUtil } from './src/main/ets/ZipLogUtil' 对外导出。

ZipLogUtil 类的整体实现如下：

不算构造方法，一共有五个静态方法：
1）getLogFileNum，获取日志文件总数
2）getLogFileName，获取日志文件名，当日志文件总数为1时使用
3）verifyLogZipIsExist，验证日志文件压缩包是否已经存在
4）generateLogZip，使用最后三份日志文件生成zip格式的压缩包
5）getLogZipUri，获取日志文件压缩包的文件URI

1、getLogFileNum

当日志文件只有一个，还去生成zip压缩包，显然不高效，高效的方式是直接将这唯一一个日志文件作为邮件的附件，所以，进行问题反馈时，对app已经生成的日志文件的数量，进行统计是有必要的，实现起来也比较简单，直接利用系统模块 @kit.CoreFileKit 的 fileIo 的 listFileSync 方法即可：

2、getLogFileName

该方法的实现，基本和上面的一样，唯一不同点，只是将 fs.listFileSync(path, option) 直接对外返回而已：

3、verifyLogZipIsExist

生成日志文件压缩包时，我采取文件名固定的策略，为了保证压缩包中的数据都是最新的，所以，当压缩包已经存在时，就必须先进行文件删除操作，因而，ZipLogUtil 类中封装了一个私有的静态方法 verifyLogZipIsExist：

4、generateLogZip

该方法的实现，相比前面的来说，代码量稍微多了一些：

过程步骤大致可以分为如下：
1）声明定义一个path变量，用于保存日志文件所在目录的路径值
2）获取日志文件名列表
3）将日志文件名列表的最后三个文件名，拼接上 path 并进行保存
4）设置文件压缩选项，如压缩级别、压缩策略等
5）判断日志压缩文件是否已经存在，是则先进行删除
6）使用系统API zlib.compressFiles 进行文件压缩。

5、getLogZipUri

该方法的实现比较简单：

如果日志文件压缩包存在，就将其对应的文件uri返回，否则返回空字符串。

三、实现问题反馈页

问题反馈页实现如下：

对应的实现代码如下：

比起结构和样式的实现，更应该重点关注响应的实现，也就是”提交“按钮点击之后的处理。

1、doSubmit

从上面的代码截图可以看到，提交按钮的响应处理，是由 doSubmit 方法负责的，而该方法的详细代码如下：

当用户没有勾选”上传应用日志“时，创建的邮件不包含附件，只是将用户输入的问题描述，作为邮件正文进行邮件生成，具体的邮件发送，需要通过 startAbilityByType 拉起的邮箱应用去完成，所以，这种问题反馈方式有个明显的不足，就是需要用户在手机提前登录好邮箱账号，如果没有邮箱账号将无法进行问题反馈。

当用户勾选了”上传应用日志“时，会先调用 packageLog 方法，并在该方法的异步回调中进行邮件生成操作。

2、packageLog

该方法的具体代码如下：

利用 ZipLogUtil 的日志文件数量统计方法，统计当前的日志文件总数，如果总数为1，则将唯一一份日志文件的沙箱路径转换为文件Uri，这个转换操作所用到的 FileUtil.getFileUri 的实现方法如下：

而当日志文件总数大于1时，则先调用 ZipLogUtil.generateLogZip(this.ctx) 创建日志文件压缩包，然后再调用 ZipLogUtil.getLogZipUri(this.ctx) 获取对应日志文件压缩包的文件 URI。

带附件的邮件生成结果如下：

四、总结

本篇最核心的干货，总共有两个，一是如何利用系统API实现文件压缩，二是如何利用系统API生成带附件的邮件。

日志文件压缩的实现，有个必要前提就是使用之前封装的 lib_log 模块进行日志打印，这样才能将日志信息采集到指定文件中，如果直接使用 hilog 或者 console.log 进行打印，那么要创建日志文件压缩包将会复杂很多，并且最终生成的压缩包大小可能超过邮件附件所允许的大小。

此外，对于生成的日志文件压缩包的上传，除了这里的邮件方式外，还可以用更为普通的http传输进行上传，有兴趣的读者可以自行探索一下。