辨音项目阶段总结（2021-10-5）

末蓝、 2022-08-28 10:39 134阅读 0赞

该项目是一个处理音频的 PC 客户端，采用 QtQuick 框架开发，主要功能为对音频进行背景降噪、人声分离，以及音频批量比对、聚类等（就是调用下算法库和写写界面交互），在此基础上又增加了音频库（文件管理）、录音、微信语音转写等功能。从2020-11月参与项目到现在，历经多次迭代，也发现了不少软件设计上的问题，故做一个阶段总结。

# 回顾 #

先看看参与项目时已有代码的面貌：划分为主进程（UI交互）、封装的公共库、算法进程三个编译模块，UI 和 算法进程通过 rpc 交互。运行起来虽然像个 demo，但是基本的功能已经具备了。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6b6a5bu65rOi_size_20_color_FFFFFF_t_70_g_se_x_16][]

这个版本 UI 上还没什么交互，就是选择文件然后调用算法获取结果，每个模块之间关联性也很小。总体来说，遗留代码看起来结构还是比较清晰的，将算法调用拆解到独立进程也是不错的想法。不过，麻雀虽小，BUG 俱全。该版本的代码也有一些待改进的地方（有些后来也没时间重构）：

> 没有对文本编码进行规范，UTF8 带 BOM 和不带的都有，在 MSVC 环境下极容易出现中文乱码。
> 
> 注释很珍贵，估计这些人的注释是单独收费的吧。
> 
> 音频文件解析用到了 FFmpeg，但是有些地方逻辑是错的。
> 
> 绘制波形图的组件封装得很感人，而且后来还改了好几次崩溃问题。
> 
> 进程通信用到了 grpc，但是 channel 是他自己用共享内存做的，后面发现会有丢失请求/响应的情况。

后来产品重新设计了界面逻辑，增加了一个文件管理，从之前直接选择本地文件的方式改成了从音频文件库中去取。因为涉及编辑操作，所以现在需要各模块同步更新状态。UI 交互上也比之前更复杂了，不过需求越怪，程序蹦得越快。需要吐槽的是公司 UI 设计师的审美真的有问题。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6b6a5bu65rOi_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

在持续开发的过程中也挖了不少新坑：

> 接口混乱。负责人是根据 UI 功能分配给每个人，但是底层逻辑很多共用的。由于前期没有总体规划，每个人的开发进度也不同，导致大家写的接口不统一。
> 
> 数据库操作封装太差。前期的时候没啥数据库操作，每个表的操作封装到一个类中，但很多接口是通过传递 SQL 语句进行操作，数据结构也是全部转为字符串 map（这两项主要是同事干的，别赖我啊）。迭代几个版本后就发现扩展和修改都很不方便。
> 
> 没有编码规范，命名规则和注释不统一。

同时也解决了一些问题：

> 统一编码为 UTF8 无 BOM，MSVC 设置相应参数即可。这样基本上不会出现乱码问题了，唯一要注意的是第三方库的接口是传递 UTF8 编码还是 Local 等编码。
> 
> rpc 先是替换为 LocalSocket，后面又替换为 Qt Remote Object。虽然领导说要用 grpc，后面好配合公司后台服务，不过在我看来这是瞎扯，一是目前的代码没啥可移植性，二是公司目前客户端都是 http 没看到有 grpc。使用 grpc 有两个麻烦的点，编译麻烦（相对 QRO），数据结构转换麻烦（Qt 类型得转成 grpc 支持的一些 C++ 类型）。

期间我写的两个重大 BUG ：

> 某个需要频繁调用的算法接口，原本以为会比较耗时，所以将不同参数的结果保存到了数据库，这使整个操作的时长增加了很多。后来才发现写数据库用的时间比算法接口耗费的时间多得多。这也怪自己没有先进行测试比较，想当然了。
> 
> ShellExecuteExW 创建进程的 Win32 API 结构体参数没有初始化为 0，只设置了部分字段的值，导致执行该逻辑时程序偶尔会崩溃（异常访问）。在调试的时候没有直接蹦到这一句，而是在其后的 log 打印时，所以我就把问题定位在了日志打印上，搞了不少幺蛾子。后面在仔细查看代码时才发现问题是没初始化参数。

# 规划 #

针对当前遗留问题，有一些简单的构思（当然，有没有时间做就不是我决定的）：

> 数据库操作封装，以及部分表的优化。之后可以了解下 ORM 适不适合用在这个项目上，还是说再优化下操作类的接口。对于数据表，目前不少地方有绝对路径，然后有些值的类型不合适（应该用 int 的用了字符串等），还有一些扩展性问题等。
> 
> 波形绘制组件重写。以前写过一些，到时再参照下开源的代码以及公司需求进行重写。
> 
> 算法进程的管理。之前算法只有一个模块，根据启动参数来执行不同的算法服务，但是后面算法更新后出现了一些依赖冲突，放到一个模块没法编译，所以得做下拆分。此外，一些遗留的算法调用模块还没重写，目前仍旧通过 grpc 调用，计划等安排我修改相应功能的时候再去改。能用的代码就先让他保留现状。
> 
> FFmpeg 音视频编解码，目前封装还不是很好。需要进一步学习下，特别是视频部分，后面可能会用到。
> 
> QML 组件封装。需要封装一套支持换肤的组件，以及易用性上的调整。
> 
> 编码规范。公司也没啥要求，目前能做的就是代码尽量写清晰点，注释尽量详尽点。虽然别人不写注释自己写注释有点亏，不过，有好习惯的不一定是优秀的开发，但是优秀的开发一定有好习惯。

项目还在需求迭代中，还会遇到各种新的问题。对于新需求，应该谋定而后动，不能只想当前需求怎么完成，需要考虑扩展性、复用性、可维护性等；对于遇到过的问题，需进一步探索，下次才能拿出更好的解决方案。目前的策略是需求不变，对应模块就不做修改；需求变更时，在完成需求的基础上再优化对应模块的代码。

这个项目要说技术难点，除了有个提取并还原微信记录的没法做，基本上没啥难点，主要是代码设计上的问题，需要在不断的迭代中进行优化。有时间学习一些开源项目，并应用到自己的项目中。

完结

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6b6a5bu65rOi_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/fef8a4e7a9c84bc09a0c9d2063c80a5a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6b6a5bu65rOi_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/72d518feabbb4be9b04492ffa00ac0ed.png