企业官网建设流程全解析

• 移动开发
• 前端
• 应用

本文以 app/src/main/assets/updateLog.md 为蓝本，逐段拆解这份内置更新日志在 Legado 阅读（本仓库 legado-with-MD3）中的定位与内容：它既是用户打开"关于/检查更新"时看到的版本说明与使用须知，也是理解该项目发布节奏（cronet 内核、Kotlin/KSP 工程链、功能迭代）的一手资料。读完本文，你将掌握这份日志的结构、每条更新背后的含义，以及日志内容是如何被 App 内的更新检查与渲染链路（GitHub API、Markwon）驱动呈现的。

一、updateLog.md 在应用中的定位

updateLog.md位于应用的主资源目录 app/src/main/assets/updateLog.md，是随安装包内置在assets中的 Markdown 文档，而不是运行时从网络临时拉取的文本。它的内容同时服务于两个界面场景：

1. 检查更新弹窗：当 App 通过更新检查接口拿到新版本信息后，把发布说明（release note）作为updateLog字段传入弹窗并渲染。见 AppUpdate.kt 中UpdateInfo数据类的定义：
   • tagName：目标版本号；
   • updateLog：更新日志正文；
   • downloadUrl/fileName：下载地址与文件名。
2. 关于页展示"已安装版本"日志：在"关于"页面中以VIEW_LOG模式把当前内置日志渲染出来，见 AboutSheets.kt 与 UpdateDialog.kt。

渲染层面，更新日志并非以纯文本展示，而是经过 Markdown 解析：

• 弹窗 UpdateDialog.kt 使用 Markwon 构建器，挂载了GlideImagesPlugin（支持日志内嵌图片）、HtmlPlugin（支持内联 HTML）与TablePlugin（支持表格）；
• 关于页则使用 Compose 的MarkdownBlock渲染同一份updateLog内容。

这意味着日志文件里出现列表、加粗、分隔线、链接等 Markdown 语法时，用户端都能得到对应的排版效果，而非一坨纯文本。

二、更新日志的「必读」板块：写给用户的四条关键须知

文档开头在正式版本条目之前专门设置了一段必读，这是理解该产品使用方式的核心信息，也是新用户最容易踩坑的地方。四条须知逐条展开如下：

其中"净化规则"与"简繁转换"两条，与仓库中实际可配置能力一一对应：书源解析依赖 assets/defaultData/bookSources.json 与 assets/defaultData/replace 相关默认数据 所承载的净化/替换体系；而简繁转换在依赖清单中由quick-chinese-transfer-core（见 gradle/libs.versions.toml）提供底层能力。因此当读者看到"正文异常先查净化与简繁"的提示时，可以在 App 的正文替换规则与简繁转换开关中实际验证。

三、版本要点逐条解读

日志主体按时间倒序记录了几轮关键更新，下面结合仓库源码逐条说明其技术含义。

3.1 cronet 内核版本：128.0.6613.40（当前基线）

文档顶部固定标注cronet版本: 128.0.6613.40。cronet 是 Chromium 的网络栈，Legado 用它作为可选的底层 HTTP 实现，以获取更优的 HTTP/2、QUIC 等协议能力。

仓库内的实现证据非常具体：

• 预编译的 cronet 库以 jar 形式存放在 app/cronetlib/（cronet_api.jar、cronet_impl_common_java.jar、cronet_impl_native_java.jar、cronet_impl_platform_java.jar、cronet_shared_java.jar），并在 app/build.gradle.kts 中以fileTree方式整体引入；
• 是否启用 cronet 由偏好键控制：PreferKey.kt 定义const val cronet = "Cronet"，对应设置项cronetEnabled（默认关闭，见 DownloadCacheSettings.kt）；
• HttpHelper.kt 在cronetEnabled为真时启用 cronet 通道，实际拦截逻辑位于io.legado.app.lib.cronet包的CronetInterceptor/CronetLoader（见 Cronet.kt）。

值得对照的是历史条目2024/02/20中的更新cronet: 121.0.6167.180——日志记录了从 121 系列升级到当前 128 系列的轨迹。若遇到部分站点加载异常，可先确认是否启用了 cronet 并尝试切换。

3.2 工程链版本：Kotlin 与 KSP 的升级路径

2024/02/20条目还记录了更新 kotlin->1.9.22 ksp->1.0.17。从当前仓库的 gradle/libs.versions.toml 看，版本号已经进一步推进到kotlin = "2.4.20"、ksp = "2.3.12"，即这份日志是 2024 年初工程链升级的快照，后续仍在持续演进。KSP 是仓库中 Room 注解处理与依赖注入代码生成的关键支撑（见同文件ksp插件声明与room-compiler依赖），这类升级通常伴随构建产物与序列化行为的变更，属于"界面绘制优化 / Bug 修复"之外最需要留意的工程层改动。

3.3 2024/10/03：功能型更新

这是日志中功能信息最密集的一条，包括：

• web 书架：支持加载网络字体、试读非书架书籍后弹窗、自定义后端 IP。对应的前端实现在 modules/web/（Vue 3 + TypeScript 的 Web 书架工程，含 BookShelf.vue、ReadSettings.vue 等组件），说明该功能是"App 端服务 + 浏览器端界面"的协同形态；
• RSS 收藏分组管理：对应仓库内置的 assets/defaultData/rssSources.json 所代表的 RSS 源体系，新增了收藏分组能力；
• 朗读功能：添加流式播放音频、来电自动暂停播放。朗读底层依赖的media3-exoplayer等库同样可以在 gradle/libs.versions.toml 中确认；
• 其他 Bug 修复与优化。

3.4 2024/02/27：数据导出与文档维护

• 添加备用 URL 导出：即给书源等数据在常规导出之外提供备用地址导出方式，降低单一导出通道不可用时的迁移成本；
• 更新书源制作的帮助文档链接：保证用户引用的书源编写指南与当前版本规则保持同步。

四、更新日志背后的更新检查机制

这份日志之所以能被用户看到，是因为 App 内置了完整的更新检查链路，而updateLog正是链路末端被展示的载荷。其核心实现位于 AppUpdateGitHub.kt：

1. 渠道选择：根据设置项updateToVariant决定检查范围——official_version（正式版）、beta_release_version（预览版）或all_version（全部），映射到 AppReleaseInfo.kt 中的AppVariant.OFFICIAL/BETA_RELEASE/ALL；
2. 双通道拉取：优先从update-manifests仓库分支读取official.json/beta.json清单（带 2.5 秒超时），失败或缺失时回退到 GitHub Releases API；同时针对 403/429 限流会解析Retry-After、X-RateLimit-Remaining、X-RateLimit-Reset响应头给出用户可读的重试提示；
3. 版本比较：内置手写的 SemVer 解析器（AppUpdateGitHub.kt）处理major.minor.patch及-beta之类的预发布后缀，只有比当前BuildConfig.VERSION_NAME更新的版本才会触发提示；
4. 超时与空态：整体检查在 10 秒内超时，无新版本时抛出"已是最新版本"的本地提示，避免无意义的 UI 干扰。

当检查到新版本后，UpdateInfo.updateLog即携带发布说明进入 UpdateDialog.kt 的更新弹窗：展示当前版本、ABI、更新渠道，渲染日志正文，并通过Download.start(...)发起安装包下载。

五、历史日志归档与版本追踪

updateLog.md 末尾将 2021、2022、2023 年的日志分别归档在项目对应的历史记录分支中（原文以record2021、record2022、record2023区分），因此当前这份文件只保留最新若干条目，避免主分支文档无限膨胀。这一做法与"更新日志既面向新用户也面向开发者"的双重定位相符：

• 普通用户：通过弹窗/关于页快速了解本次更新要点与注意事项；
• 开发者与维护者：通过条目中的版本号（cronet、Kotlin、KSP）与功能列表追踪工程链与能力的演进节点。

此外，更新弹窗的VIEW_LOG模式（UpdateDialog.kt）允许用户在未检测到新版本时也能直接查看当前内置日志，保证这份文档始终可读、可引用。

六、小结

updateLog.md不是一份普通的版本公告：它把产品使用红线（备份、书源导入、净化/简繁排查、漫画源不通用）、工程链版本基线（cronet 128、Kotlin/KSP 演进）和功能迭代记录（web 书架、RSS 分组、朗读流式播放）浓缩在一份 Markdown 中，并通过更新检查链路（GitHub API + Manifest + SemVer 比较）与 Markwon 渲染，在用户端以结构化形式呈现。想进一步了解某个条目对应的实现，可按本文给出的路径直接阅读 app/src/main/java/io/legado/app/help/update/ 与 app/src/main/java/io/legado/app/ui/about/ 下的源码。

• 移动开发
• 前端
• 应用