鸿蒙电子书阅读器五格式适配与DJVU原生解析移植

鸿蒙专家

在鸿蒙上做电子书阅读器，最直接的问题是格式支持不能只靠一个阅读组件。不同格式背后对应不同的系统能力：PDF 有 PDF Kit，EPUB、MOBI、AZW3 可走 Reader Kit，而 DJVU 在鸿蒙侧没有官方解析服务，需要在三方方案和跨平台库移植之间做取舍。

一、从安卓电子书项目到鸿蒙版

原文作者此前在安卓实战书中实现过具备翻页浏览功能的电子书 APP，支持 PDF、EPUB、DJVU 三种格式。后续在编写《鸿蒙HarmonyOS 6应用开发:从零基础到App上线》时，大部分安卓实战项目已改造为鸿蒙版本，但电子书阅读项目因时间进度和项目难度未能同步完成。该书出版后，作者借助鸿蒙官网文档和 AI 编程工具继续改造，最终把鸿蒙版电子书 APP 源码放入该书第 17 章新增源码，托管在 Gitee 的 harmony 仓库 chapter17 目录。

鸿蒙版仍保持简洁界面，但格式支持从安卓版的 PDF、EPUB、DJVU 三种扩充到 PDF、EPUB、MOBI、AZW3、DJVU 五种。这个扩充并不是简单增加文件后缀判断，而是分别对接系统 Kit、阅读组件和第三方/移植解析库。

二、PDF：PdfView 浏览与 pdfService 精细化处理

鸿蒙从 5.0.0 版本（API 12）开始引入 PDF Kit。PDF Kit 提供打开 PDF 文件、导出 PDF 图片，以及为页面添加批注、页眉页脚、水印、背景和书签等能力。其组成包括 pdfService 和 PdfView 组件，PdfView 又涉及 PdfView、pdfViewManager 和 PdfController。

落到开发上，PDF 有两种处理路线。若只需要简单浏览 PDF，可在 ArkUI 布局中嵌入 PdfView 组件，再配合 PdfController 加载指定路径的 PDF 文件。若需要对 PDF 做增删改等精细化操作，则应使用 pdfService 加载文档，通过 Image 组件渲染 PDF 页面，再按定制化需求处理。也就是说，PdfView 更适合快速完成阅读入口，pdfService 更适合需要页面渲染控制和二次处理的场景。

三、EPUB、MOBI、AZW3：用 Reader Kit 构建阅读交互

鸿蒙从 5.0.4 版本（API 16）开始引入 Reader Kit，提供 EPUB、MOBI、AZW3 等格式电子书的解析、排版和阅读交互能力。Reader Kit 包含三个关键组件：ReadPageComponent、bookParser 和 readerCore。

ReadPageComponent 是 ArkUI 组件，负责书籍排版内容显示、多种翻页交互和翻页动效，并在翻页阅读过程中提供进度和行为感知能力。bookParser 提供书籍解析能力，支持解析 txt、epub、mobi、azw、azw3 等格式，可解析出书籍基本信息、书脊内容列表、目录列表和章节内容。readerCore 提供阅读页面数据基础类、页面状态、内容分页信息、页面排版属性和组件控制器等能力，主要用于播放、翻页等动作。

因此，EPUB、MOBI、AZW3 的适配重点不是自己从头写排版引擎，而是把书籍解析、阅读页展示和翻页控制分别交给 bookParser、ReadPageComponent 与 readerCore，并在应用层管理书架、阅读进度和格式入口。需要注意的是，PDF Kit 与 Reader Kit 的 API 起点不同，实际适配时应把系统版本和 API 可用性作为能力边界来设计格式入口。

四、DJVU：没有官方服务时的三种改造路线

DJVU 是鸿蒙版电子书适配中最特殊的一类。鸿蒙尚未提供官方 DJVU 解析服务，OpenHarmony 三方库中心仓中也没有发现支持 djvu 格式的三方解析库，这意味着开发者要么自行实现，要么改造其他平台已有的 DJVU 库。原文给出三条可选路线。

第一条是采用开源 JavaScript 库 djvu.js。该库可在 HTML5 前端解析、渲染 djvu 文档，不需要后端服务，也不用安装本地 DjVu 阅读器。对应到鸿蒙应用，需要开发 H5 网页并嵌入 Web 组件，不能由 APP 原生解析和渲染 djvu 文档。这条路线适合快速复用 Web 生态，但阅读体验和原生能力边界受 Web 容器限制。

第二条是采用开源 C/C++ 库 DjVuLibre。该库由 djvu 格式原作者维护，包含完整的 C++ 解码库、编码器和 ddjvu、djvused 等命令行工具，兼容性较好，绝大多数 DjVu 文件以它为基准测试。原文提到 GitHub 上 DjVuLibre 最新稳定版为 3.5.30，同时依赖 zlib、libjpeg-turbo 等三方库，移植时需要连带处理依赖库。这条路线更接近原生解析，但移植工作量也更大。

第三条是采用 Android 平台现有的 VuDroid/DjvuDroid。该库是 DjVuLibre 的安卓封装版本，属于 Android 上的成品移植工程。原文作者的安卓实战书第 15 章“15.5 实战项目：笔墨飘香之电子书架”就基于 VuDroid 浏览 DJVU 文件。

五、DJVU 鸿蒙移植：从 Android.mk 到 CMakeLists.txt

综合考虑后，作者选择从 VuDroid 库着手，把它的 NDK 编译方式从 Android 改为 HarmonyOS，同时把 APP 页面布局代码从安卓的 Java+XML 改造为鸿蒙的 ArkTS+ArkUI。就 DjvuDroid 库的鸿蒙版改造而言，核心工作之一是把安卓端编译文件 Android.mk 改写为鸿蒙端编译文件 CMakeLists.txt。

这条路径的价值在于：DJVU 解析和渲染继续走原生库，应用层则用 ArkTS+ArkUI 重写交互与页面。相比只把 DJVU 放进 Web 组件，原生移植更贴近鸿蒙应用架构，但也要求开发者同时理解 NDK 构建、C/C++ 依赖和 ArkUI 页面组织。

六、适配启示

这个电子书项目的技术要点可以归纳为三层：能用系统 Kit 的格式优先用 Kit，PDF 走 PdfView/pdfService，EPUB、MOBI、AZW3 走 Reader Kit；系统没有官方能力的格式，先查三方库中心仓，再评估 Web 复用、原生 C/C++ 库移植和成熟平台封装库移植三条路线；跨平台移植时，构建系统、页面框架和依赖库要一起改，不能只替换业务代码。对于学习鸿蒙开发而言，这类项目同时覆盖 ArkUI、ArkTS、系统 Kit 调用、Web 组件和 NDK 移植，比单一页面 Demo 更接近真实应用适配。