剖析阅读Sigma源码架构RuleAnalyzer规则解析流水线与 Room 数据库设计【免费下载链接】legado-E阅读Sigma是legado的继承保持开源免费延续开源精神。项目地址: https://gitcode.com/gh_mirrors/legado2/legado-E阅读Sigmalegado-E是一款开源免费的 Android 阅读 App其核心竞争力在于书源规则解析——用规则把网页和接口变成可读的正文。本文以RuleAnalyzer 规则解析流水线与Room 数据库设计为主线带你快速看懂这款开源阅读应用的源码架构新手也能轻松上手 。一、源码结构总览每个模块管什么项目主代码位于 app/src/main/java/io/legado/app/ 目录与本文相关的模块可分成三块模块路径职责规则解析model/analyzeRule/拆分、解析并执行书源规则数据存储data/Room 数据库、DAO 与实体定义业务模型model/阅读、下载、搜索等动作的编排项目自带了两份模块说明文档data/README.md 和 model/README.md是阅读源码的绝佳入口。二、规则解析流水线书源生效的魔法2.1 RuleAnalyzer先把规则切开一条书源规则常常长这样class.name;css:div.title;text前面是 XPath后面是 JSoup 的 css 选择器。麻烦在于规则字符串本身就可能含有、、||比如正则或 jsonPath 里就有简单按符号切分必然出错。RuleAnalyzer.kt 就是来解决这个问题的它的设计思路很巧妙不用正则、不复制中间串只在原字符串上标记起点和终点pos指针最后一次性切片源码注释原话是高效快速准确切割规则识别平衡组遇到[...]或(...)筛选器时成对匹配括号整体取出见 RuleAnalyzer.kt 中chompBalanced的调用筛选器内部的符号不会骗过它区分引号与转义单引号、双引号、转义字符分别跟踪状态见 RuleAnalyzer.kt 的chompCodeBalancedJS 代码块里的不会被当成分隔符tailrec 尾递归splitRule方法使用 Kotlin 的tailrec注解RuleAnalyzer.kt避免深递归的性能损耗。2.2 AnalyzeRule 调度器按类型分派解析器规则切分完成后由 AnalyzeRule.kt 作为总调度接手它内置了四个解析器解析器文件用途XPathAnalyzeByXPath.ktHTML 结构解析的默认语言JSoupAnalyzeByJSoup.ktcss 选择器语法JsonPathAnalyzeByJSonPath.kt解析 JSON 接口响应正则AnalyzeByRegex.kt按模式抽取内容规则里的分隔符让四个解析器可以任意串联使用。同时 AnalyzeRule 内置了三份缓存stringRuleCache、regexCache、scriptCacheAnalyzeRule.kt——同一条规则字符串、正则、JS 脚本只编译一次后续直接复用这对翻页、批量加载章节时的解析开销优化非常明显。2.3 JS 脚本与变量传递书源规则还支持 JS 脚本引擎来自内置的 modules/rhino/ 模块Rhino 引擎。RuleData.kt 负责用variableMap管理跨页面传递的大变量第一页脚本写入的 token下一页规则可以取回——这正是翻页加载登录态保持等复杂书源能跑通的底层机制。三、Room 数据库设计管理 21 张表的账本3.1 单一入口appDb 全局单例所有数据库操作都经过一个懒加载的全局单例AppDatabase.ktval appDb by lazy { Room.databaseBuilder(appCtx, AppDatabase::class.java, AppDatabase.DATABASE_NAME) .fallbackToDestructiveMigrationFrom(false, 1, 2, 3, 4, 5, 6, 7, 8, 9) .addMigrations(*DatabaseMigrations.migrations) ... }短短几行讲了三件事数据库首次使用时才构建by lazy1~9 的远古版本直接采用重建策略第 10 版起才开始正规的增量迁移。3.2 89 个版本与 AutoMigration 自动迁移AppDatabase.kt 的Database注解中可以看到version 89以及 Book、BookChapter、BookSource、Bookmark、RssSource、ReadRecord 等 21 张表定义和一个BookSourcePart视图。项目大量使用 Room 的AutoMigration 自动迁移普通改动加列、加表由 Room 自动生成迁移 SQL只有需要手工回填数据的版本如 54→55、80→81、84→85才在 DatabaseMigrations.kt 中编写对应 spec 类把成本压到最低。另一个亮点是exportSchema true每个版本的数据库结构会被自动导出到 app/schemas/io.legado.app.data.AppDatabase/共 89 个 json 文件。对贡献者来说数据库结构的每一次变化都能在版本控制中看见这是多版本协作项目非常友好的实践。3.3 DAO 与 Entity清晰的职责分工按照 Room 官方推荐的惯例data/ 目录分两层entities/21 个纯数据类表结构如 Book 书籍表、BookChapter 章节表dao/21 个数据库读写入口如 BookDao.kt、BookChapterDao.kt、BookSourceDao.ktUI 与业务层只与 DAO 打交道不直接接触表。这种实体定结构、DAO 开门面的划分正是数据库能稳定迭代到第 89 版而业务代码几乎不用改的原因。四、两者如何协作从书源到书架的数据流 把解析流水线和数据库串起来一次典型的搜索 → 加书架 → 阅读流程是用户输入关键词App 依次执行各书源的搜索规则RuleAnalyzer 切分 → AnalyzeRule 分派解析器结果写入SearchBook表SearchBookDao.kt供界面展示加入书架时从BookSource表提取规则数据书籍信息写入Book表打开书籍后按BookChapter表逐章取内容阅读进度实时写入ReadRecord表。一句话总结解析流水线负责取数Room 数据库负责存数两者互不越界层次干净利落。五、新手源码阅读路线30 分钟上手如果想自己动手读源码推荐这个顺序先看 data/README.md 与 model/README.md 建立模块概念再看 AppDatabase.kt仅凭Database注解就能列出这款 App 有哪 21 张表然后精读 RuleAnalyzer.kt注释详尽splitRule是核心方法最后看 AnalyzeRule.kt理解四个解析器与 JS 脚本如何组合。想本地运行项目可以克隆源码git clone https://gitcode.com/gh_mirrors/legado2/legado-E阅读Sigma 的架构并不复杂它的功力藏在持续迭代中保持分层清晰上RuleAnalyzer 的规则切分、AnalyzeRule 的总调度、Room 的 89 版自动迁移——这三件小事做到位才撑起了它赖以生存的书源生态。【免费下载链接】legado-E阅读Sigma是legado的继承保持开源免费延续开源精神。项目地址: https://gitcode.com/gh_mirrors/legado2/legado-E创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考