虽然图片、音频、视频等多媒体文件拥有众多格式，但开发它们的APP应用并不难，因为常见的多媒体格式都被纳入系统底层支持，开发者只要使用原生组件即可加载多媒体文件，比如鸿蒙系统加载图片的Image组件，加载视频的Video组件，以及播放音频的MediaPlayer组件等。

然而文档不同于这些多媒体格式，文档的格式不仅多，而且复杂，有的甚至闭源，这让电子书APP的开发者倍感头疼。即使鸿蒙系统已经原生支持PDF、TXT、EPUB、MOBI、AZW3等多种文档格式，但仍有多种格式未能支持，比如DjVu、RTF、DOCX等等。

虽然DjVu、RTF、DOCX等文档格式在其他平台已经有成熟的应用案例，可是相关的实现代码又多又乱，而且C、Java、JavasScrpit等语言混杂其中。如果按照以前的处理办法，往往要求开发者精通多种编程语言，甚至精通多种平台的开发技术，才能把其他平台的电子书解析代码一步步迁移到鸿蒙平台。

更要命的是，代码语言转换只是迁移改造的其中一步，转换语言后的App工程还得想办法通过编译，还得想办法通过各种文档的调试，最终才能交付支持新格式的鸿蒙App。这一整套流程下来，不仅要求开发者投入大量的时间，还得烧掉大量的脑细胞，非但无利可图，简直是用爱发电。

不过现在有了AI编程，像这种繁重的工程代码迁移，完全可以交给AI处理，接下来就来看看我是怎么利用AI编程，让鸿蒙App快捷支持RTF文档的过程吧。

一、寻找其他平台支持RTF格式的开源库

为什么选择RTF格式呢？因为RTF是一种基于ASCII纯文本的跨平台文档格式，可在不同系统和软件间交换带格式的文档。它不像DOCX格式那么复杂，却支持字体、颜色、样式、图像等基本格式，大多数文字处理软件都能读取和保存，很多软件的License文档就采用RTF格式。

一开始我完全不懂要怎么解析RTF文档，也不知道有哪些RTF格式的开源解析框架，于是我问豆包“安卓app可使用哪些开源框架打开rtf格式的电子书？”，豆包给出了OpenReadEra、CoolReader、KOReader、LibreraReader这四个开源项目，如下图所示：

进一步分析上述四个电子书开源项目，发现前三个都用到了C++，而最后一个采用纯Java代码，于是初步决定将LibreraReader作为突破口。

按照LibreraReader的简介，它支持的电子书格式包括PDF、EPUB、EPUB3、MOBI、DjVu、FB2、TXT、RTF、AZW、AZW3、HTML、CBZ、CBR、DOC、DOCX等等，而我的需求只是解析RTF格式，所以又问豆包“Librera Reader开源的app工程中，哪个模块用来支持rtf格式？”。豆包回答道“Java层RtfParserKit（levigo/rtfparserkit）第三方库 +自己封装的 RtfExtract / RtfExtract2 适配器”，如下图所示：

豆包还指出LibreraReader中的RTF解析方式不是原生C++渲染，这和OpenReadEra、EraEPUB、CoolReader不一样，因此采用LibreraReader+RtfParserKit解析RTF文档拥有如下优势：
1、纯Java，不需要NDK编译，集成成本低；
2、rtfparserkit协议宽松（BSD），比GPL友好；
3、转HTML之后，你可以复用任意HTML/EPUB渲染引擎做电子书分页。

于是确定了以LibreraReader+RtfParserKit组合来解析RTF，这两个开源项目都能在GitHub上找到，那么先把它们的源码下载下来。

二、从LibreraReader剥离出RTF部分的解析代码

本来我还想尝试从LibreraReader源码手工剥离RTF部分代码，但实践发现很不好处理，费时费力折腾了几个小时都没搞定。我又想到了让AI帮忙剥离代码，不过此时豆包已经爱莫能助了，于是我打开Trae，让它试试能不能帮上什么忙。下面是我向Trae提的要求内容：

你是安卓APP开发专家，现有一份电子书阅读APP的LibreraReader源码（源码路径位于“xxx”），要求从LibreraReader源码抽取出rtf文件的解析和阅读部分代码并输出新的APP工程代码。具体要求如下：
1、我已经创建好了新的APP工程rtftest，路径位于“xxx”，其中gradle、jdk与sdk版本都使用该路径现有的工程配置；
2、LibreraReader源码的rtf文件解析入口位于LibreraReader工程的“app\src\main\java\com\foobnix\ext\RtfExtract.java”，请从该文件开始抽取与rtf处理有关的其他代码；
3、RTF解析底层用到的rtfparserkit库，我已经弄到了它的源码，并放在rtftest工程的“app\src\main\java\com\rtfparserkit”目录下，不必在新工程的build.gradle中导入该库了；
4、请把新工程中所有的“import com.foobnix.pdf.info.R;”都改为“import com.example.rtftest2.R;”；
5、如果新工程需要用到greendao的部分代码，请把调用greendao库的相关代码改为使用谷歌官方的room库；
6、如需使用 Android Studio 构建rtftest工程，注意 Android Studio 的本地安装目录为“xxx”；

然后Trae吭哧吭哧干了半小时，竟然成功剥离出了RTF部分代码，并且通过编译打包生成了debug安装包。下面是Trae的剥离工作结果：

接着我打开Trae编译好的安卓APP工程，简单调试发现正常解析纯文本RTF文件，但在解析图文RTF文件时无法显示图片，于是我又向Trae提问道“我改了几个代码，在真机上测试可以显示rtf文件的文本部分，但kuaipan.rtf的图片部分无法显示，抽取出来的3张png图片都只有16B大小，请看下为何没有正确提取出图片内容？”

然后Trae又吭哧吭哧干了15分钟，竟然成功定位RTF图片无法显示的问题，并且直接修改源码修复了这个bug，下面是Trae的bug修复结果：

接着我重新编译Trae修改后的APP工程，调试发现在解析图文RTF文件时也能正常显示图片了。

三、把支持RTF格式的安卓工程转换为鸿蒙App工程

没想到AI编程竟然这么快速就改造了RTF解析的APP工程，这让我信心倍增，打算一鼓作气让AI把对应的鸿蒙APP也一块搞定。于是我又向Trae提问道：

你是个鸿蒙APP开发专家，rtftest是个android的app工程代码，请把这个安卓app工程代码改写为鸿蒙app代码，要求如下：
1、android工程中的java代码和xml文件改造为鸿蒙的ets代码；
2、改造后的鸿蒙App工程保存路径为“xxx”；
3、APP要兼容鸿蒙6；
4、工程名称叫做RtfApp；
5、如需使用DevEco Studio构建鸿蒙app工程，注意DevEco Studio的本地安装目录为“xxx”；

当然，鸿蒙APP转换不同于安卓APP剥离，剥离操作处于两个安卓APP工程之间，只是从一个完整的安卓工程剥离出部分代码到另一个安卓工程；而转换操作位于安卓APP工程与鸿蒙APP工程之间，整个实现逻辑都从原来安卓工程的Java代码重新改写为鸿蒙工程的ArkTS代码。因此饶是AI编程，也足足花了近一个小时才把RTF解析的安卓APP工程转换为鸿蒙APP工程。下面是Trae的转换工作结果：

因为鸿蒙APP的debug安装包也要开发者手动签名，所以AI只生成了未签名的裸包。
接着我打开Trae编译好的鸿蒙APP工程，简单调试发现两个问题：出现字母混合数字的奇怪字符串、图文RTF未显示内部携带的图片。于是我又向Trae提问道：

在鸿蒙真机上测试RtfApp时，发现下面两个问题，请分析具体原因并给予修复：
1、tiaozhuan.rtf解析出来的内容除了正常的中文之外，还出现很多字母混合数字的奇怪字符串混杂其中；
2、kuaipan.rtf只解析出了文本内容，内部携带的3张图片并未显示；

然后Trae分析调研了半小时，对两个问题都已定位并修复，发现根因是同一个：readCommand()对控制字分隔符的处理逻辑写错了（比Java原版的RawRtfParser差了一位）。具体的分析过程如下图所示：

光看这分析结果，简直是专家级别，如果由人工排查，估计要排查大半天呢。
我又换了其他RTF文件继续调试，发现解析出来的文本只有一个字体，既无粗体也无黑体也无超链接。于是我又向Trae提问道“我在鸿蒙真机上用QQLicense.rtf测试文本RTF的解析功能，发现解析出来的内容文本只有一个字体，无法显示黑体或者粗体，而且html中的超链接也变成了无超链的普通文本，请修复这两个问题。”

然后Trae仔细分析了15分钟，发现这是安卓版本就有的缺陷，鸿蒙版本不过是把安卓APP的缺陷原样带了过来。同时AI寻找解决方案并修复了相关代码，修复过程如下图所示：

接着我重新编译修复后的鸿蒙APP工程，在真机上调试发现能够完整显示RTF文档的丰富样式了。比如下面是纯文本RTF的解析结果，不但显示了黑体文字，还显示了超链接：

再如下面是图文RTF的解析结果，除了区别显示不同字体以外，还能正确显示相关配图：

以上就是我采用AI编程实现鸿蒙APP解析RTF文档的全过程，除了开头的技术方向调研和末尾的实际文档调试之外，中间的代码剥离、代码转换和bug修复全由AI完成，这让鸿蒙APP适配其他平台的各种功能变得方便多了。