您当前的位置: 首页 > 

龚建波

暂无认证

  • 5浏览

    0关注

    313博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

辨音项目阶段总结(2021-10-5)

龚建波 发布时间:2021-10-05 12:38:33 ,浏览量:5

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

回顾

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

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

没有对文本编码进行规范,UTF8 带 BOM 和不带的都有,在 MSVC 环境下极容易出现中文乱码。

注释很珍贵,估计这些人的注释是单独收费的吧。

音频文件解析用到了 FFmpeg,但是有些地方逻辑是错的。

绘制波形图的组件封装得很感人,而且后来还改了好几次崩溃问题。

进程通信用到了 grpc,但是 channel 是他自己用共享内存做的,后面发现会有丢失请求/响应的情况。

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

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

接口混乱。负责人是根据 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 组件封装。需要封装一套支持换肤的组件,以及易用性上的调整。

编码规范。公司也没啥要求,目前能做的就是代码尽量写清晰点,注释尽量详尽点。虽然别人不写注释自己写注释有点亏,不过,有好习惯的不一定是优秀的开发,但是优秀的开发一定有好习惯。

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

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

完结

关注
打赏
1655829268
查看更多评论
立即登录/注册

微信扫码登录

0.2564s