CrowdAnki 项目架构解析从 Adapters 到 Hooks 的 Anki 插件设计模式完整指南【免费下载链接】CrowdAnkiPlugin for Anki SRS designed to facilitate cooperation on creation of notes and decks.项目地址: https://gitcode.com/gh_mirrors/cr/CrowdAnkiCrowdAnki 是一款专为 Anki 打造的开源插件SRS 记忆卡片工具它的核心能力是把牌组和笔记导出为 JSON 格式并与 Git 深度集成从而实现多人协作共创卡牌库。想要深入理解Anki 插件架构吗本文带你逐层拆解 CrowdAnki 的源码设计看懂它如何用适配器模式Adapters隔离 Anki 内部 API、如何用钩子系统Hooks优雅注入功能——这套插件设计模式对想开发 Anki 插件的初学者极具参考价值。CrowdAnki 是做什么的先搞懂插件的使命在聊架构之前先快速建立直觉。CrowdAnki 解决的痛点是Anki 官方导出格式不利于多人协作。它的方案分三步走导出把整个牌组笔记、模板、设置、媒体文件导出为一个 JSON 目录协作把这个目录放进 Git 仓库多人各自修改、提交、合并快照每次打开/关闭 Anki 自动打一个 Git commit形成牌组编辑历史。下面这张图展示了协作流程中用 GitHub Desktop 为导出目录创建仓库这一步是理解插件协作模式最直观的画面要支撑这套流程插件必须在不动 Anki 核心代码的前提下稳定地读写 Anki 内部数据、拦截导出菜单、监听启动/退出事件——这正是它的架构设计要回答的问题。整体架构一览一次启动发生了什么插件入口是 main.py。Anki 加载插件时调用anki_init(window)整个初始化只做三件事anki_init(window) ├── HookVendor(...).setup_hooks() # 1. 注册所有钩子 ├── anki_actions_init(...) # 2. 向菜单注入 导入/导出/快照 操作 └── initialize_config_window(...) # 3. 注册自定义配置窗口也就是说插件与 Anki 的全部交互最终都收敛为注册钩子 注入菜单动作两个动作。这种入口极简、能力分散的结构是 Anki 插件开发的典型范式。Adapters 层用适配器模式隔离 Anki 内部 APIcrowd_anki/anki/adapters/目录是整个项目架构中最能体现设计功力的部分。它的目标只有一个让上层业务代码永远不直接接触 Anki 的内部对象。AnkiDeck把内部 dict 包装成只读视图anki_deck.py 定义了三个层层递进的类类职责设计要点AnkiDeck包装 Anki 内部返回的 dict暴露name、is_dynamic等只读属性数据访问的统一门面LazyDeck用cached_property实现懒加载首次访问data才真正取数避免一次性加载全部牌组NamedLazyDeck只知道名字、内容按需用名查询按名批量操作时的轻量句柄这一层还顺带兼容了 Anki 不同版本 API 的改名问题如byNamevsby_name把版本差异挡在适配器里。DeckManager抽象接口 具体实现的经典分离deck_manager.py 是适配器模式的教科书示例DeckManager是一个抽象基类ABC声明了all()、leaf_decks()、for_names()三个契约方法并基于 trie.py 工具用前缀树计算叶子牌组即不含子牌组的路径AnkiStaticDeckManager是面向真实 Anki 数据的具体实现内部还用了函数式链seq(...).map(...).filter(...)把内部数据流映射为AnkiDeck列表。收益任何依赖DeckManager的业务代码比如导出器都不关心数据来自 Anki 内存还是 JSON 文件——测试时甚至可以注入一个假的 DeckManager这也是项目里 test/ 目录大量单元测试能跑起来的关键。FileProvider 与 NoteModelFileProvider连文件读取都被抽象file_provider.py 只声明了一个get_files()抽象方法而 note_model_file_provider.py 则把读笔记模板文件这件小事也包了起来。抽象粒度细到这种程度说明作者对隔离外部依赖贯彻得很彻底。Hooks 层钩子系统如何把插件缝进Anki如果说 Adapters 负责读数据那么 Hooks 负责插动作。Anki 在关键生命周期点预留了钩子hook插件只需把自己的函数挂上去。AnkiHookManager两行代码封装挂/卸钩hook_manager.py 只有 16 行却值得细品def hook(self, hook_name, handler): # 挂钩 def unhook(self, hook_name, handler): # 卸钩它把 Ankihooks模块的addHook/remHook收口成hook/unhook两个方法。好处是将来想换成 Anki 新版gui_hooksAPI 时只需改这一个文件想写测试时可以注入一个假 hook 对象——依赖注入 接口收口小工具里藏着大心思。HookVendor钩子注册中心hook_vendor.py 是钩子的总装配车间setup_hooks()依次挂了三组钩子导出钩子L24-L27监听 Anki 导出列表初始化事件把 CrowdAnki JSON Representation 选项塞进导出菜单。这里还做了版本兼容判断——新版 Anki 用exporters_list_did_initialize旧版用exportersList快照钩子L29-L32把同一个snapshot_on_sync处理器同时挂到profileLoaded和unloadProfile上实现打开/关闭 Anki 自动打 Git 快照配置钩子L34-L35牌组配置新增时做 UUID 去歧义处理防止导入时配置串位。可以看到钩子的语义全部集中在一个类里插件到底监听了什么、何时动作看这一个文件就能讲完。这正是 Hooks 架构的可读性红利。Representation 层让 JSON 与 Anki 数据同模同形适配器把 Anki 数据包装好了那 JSON 数据呢答案在 representation/ 目录Deck、Note、NoteModel等纯 Python 数据模型不依赖 Anki 运行时。关键桥梁是 deck_initializer.pyfrom_collection(collection, name)从 Anki 集合递归构建Deck树处理子牌组、跳过筛选牌组from_json(json_dict)从导出的 JSON递归还原出同一棵Deck树。两条路径产出同一个类型的Deck对象。这意味着导出器、导入器、快照器都可以只面向Deck编程完全无差别对待来自 Anki 内存和来自磁盘文件两种数据源——这也是 JSON 导入/导出对称设计的根基。顺带一提history/ 目录archiver.py、dulwich_repo.py等则负责快照落盘时基于纯 Python 的 dulwich 库操作 Git不依赖系统安装 git 命令行同样是把外部依赖关在笼子里的思路。这套架构给了插件开发者什么启发 复盘一遍CrowdAnki 的架构可以提炼成三条通用法则几乎适用于任何 Anki 插件开发适配器模式隔离不稳定 API。Anki 内部接口随版本变化频繁把所有byNamevsby_name这类脏活收敛到anki/adapters/业务层代码就不会被版本升级冲垮钩子注册集中管理。用HookVendorAnkiHookManager把挂了哪些钩子变成一目了然的清单而不是散落在各个文件里维护与排查成本骤降统一中间模型打通双向数据流。representation层的Deck树让Anki 内存 → JSON与JSON → Anki 内存复用同一套逻辑导入导出天然对称、天然可测试。对初学者来说阅读路线建议是先从 main.py 看懂启动流程再看 hook_vendor.py 掌握钩子全貌最后深入 adapters/ 体会适配器模式的落地细节——按这个顺序你会发现一个功能完整的 Anki 协作插件其骨架其实清晰得超乎想象。【免费下载链接】CrowdAnkiPlugin for Anki SRS designed to facilitate cooperation on creation of notes and decks.项目地址: https://gitcode.com/gh_mirrors/cr/CrowdAnki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CrowdAnki 项目架构解析：从 Adapters 到 Hooks 的 Anki 插件设计模式完整指南
CrowdAnki 项目架构解析从 Adapters 到 Hooks 的 Anki 插件设计模式完整指南【免费下载链接】CrowdAnkiPlugin for Anki SRS designed to facilitate cooperation on creation of notes and decks.项目地址: https://gitcode.com/gh_mirrors/cr/CrowdAnkiCrowdAnki 是一款专为 Anki 打造的开源插件SRS 记忆卡片工具它的核心能力是把牌组和笔记导出为 JSON 格式并与 Git 深度集成从而实现多人协作共创卡牌库。想要深入理解Anki 插件架构吗本文带你逐层拆解 CrowdAnki 的源码设计看懂它如何用适配器模式Adapters隔离 Anki 内部 API、如何用钩子系统Hooks优雅注入功能——这套插件设计模式对想开发 Anki 插件的初学者极具参考价值。CrowdAnki 是做什么的先搞懂插件的使命在聊架构之前先快速建立直觉。CrowdAnki 解决的痛点是Anki 官方导出格式不利于多人协作。它的方案分三步走导出把整个牌组笔记、模板、设置、媒体文件导出为一个 JSON 目录协作把这个目录放进 Git 仓库多人各自修改、提交、合并快照每次打开/关闭 Anki 自动打一个 Git commit形成牌组编辑历史。下面这张图展示了协作流程中用 GitHub Desktop 为导出目录创建仓库这一步是理解插件协作模式最直观的画面要支撑这套流程插件必须在不动 Anki 核心代码的前提下稳定地读写 Anki 内部数据、拦截导出菜单、监听启动/退出事件——这正是它的架构设计要回答的问题。整体架构一览一次启动发生了什么插件入口是 main.py。Anki 加载插件时调用anki_init(window)整个初始化只做三件事anki_init(window) ├── HookVendor(...).setup_hooks() # 1. 注册所有钩子 ├── anki_actions_init(...) # 2. 向菜单注入 导入/导出/快照 操作 └── initialize_config_window(...) # 3. 注册自定义配置窗口也就是说插件与 Anki 的全部交互最终都收敛为注册钩子 注入菜单动作两个动作。这种入口极简、能力分散的结构是 Anki 插件开发的典型范式。Adapters 层用适配器模式隔离 Anki 内部 APIcrowd_anki/anki/adapters/目录是整个项目架构中最能体现设计功力的部分。它的目标只有一个让上层业务代码永远不直接接触 Anki 的内部对象。AnkiDeck把内部 dict 包装成只读视图anki_deck.py 定义了三个层层递进的类类职责设计要点AnkiDeck包装 Anki 内部返回的 dict暴露name、is_dynamic等只读属性数据访问的统一门面LazyDeck用cached_property实现懒加载首次访问data才真正取数避免一次性加载全部牌组NamedLazyDeck只知道名字、内容按需用名查询按名批量操作时的轻量句柄这一层还顺带兼容了 Anki 不同版本 API 的改名问题如byNamevsby_name把版本差异挡在适配器里。DeckManager抽象接口 具体实现的经典分离deck_manager.py 是适配器模式的教科书示例DeckManager是一个抽象基类ABC声明了all()、leaf_decks()、for_names()三个契约方法并基于 trie.py 工具用前缀树计算叶子牌组即不含子牌组的路径AnkiStaticDeckManager是面向真实 Anki 数据的具体实现内部还用了函数式链seq(...).map(...).filter(...)把内部数据流映射为AnkiDeck列表。收益任何依赖DeckManager的业务代码比如导出器都不关心数据来自 Anki 内存还是 JSON 文件——测试时甚至可以注入一个假的 DeckManager这也是项目里 test/ 目录大量单元测试能跑起来的关键。FileProvider 与 NoteModelFileProvider连文件读取都被抽象file_provider.py 只声明了一个get_files()抽象方法而 note_model_file_provider.py 则把读笔记模板文件这件小事也包了起来。抽象粒度细到这种程度说明作者对隔离外部依赖贯彻得很彻底。Hooks 层钩子系统如何把插件缝进Anki如果说 Adapters 负责读数据那么 Hooks 负责插动作。Anki 在关键生命周期点预留了钩子hook插件只需把自己的函数挂上去。AnkiHookManager两行代码封装挂/卸钩hook_manager.py 只有 16 行却值得细品def hook(self, hook_name, handler): # 挂钩 def unhook(self, hook_name, handler): # 卸钩它把 Ankihooks模块的addHook/remHook收口成hook/unhook两个方法。好处是将来想换成 Anki 新版gui_hooksAPI 时只需改这一个文件想写测试时可以注入一个假 hook 对象——依赖注入 接口收口小工具里藏着大心思。HookVendor钩子注册中心hook_vendor.py 是钩子的总装配车间setup_hooks()依次挂了三组钩子导出钩子L24-L27监听 Anki 导出列表初始化事件把 CrowdAnki JSON Representation 选项塞进导出菜单。这里还做了版本兼容判断——新版 Anki 用exporters_list_did_initialize旧版用exportersList快照钩子L29-L32把同一个snapshot_on_sync处理器同时挂到profileLoaded和unloadProfile上实现打开/关闭 Anki 自动打 Git 快照配置钩子L34-L35牌组配置新增时做 UUID 去歧义处理防止导入时配置串位。可以看到钩子的语义全部集中在一个类里插件到底监听了什么、何时动作看这一个文件就能讲完。这正是 Hooks 架构的可读性红利。Representation 层让 JSON 与 Anki 数据同模同形适配器把 Anki 数据包装好了那 JSON 数据呢答案在 representation/ 目录Deck、Note、NoteModel等纯 Python 数据模型不依赖 Anki 运行时。关键桥梁是 deck_initializer.pyfrom_collection(collection, name)从 Anki 集合递归构建Deck树处理子牌组、跳过筛选牌组from_json(json_dict)从导出的 JSON递归还原出同一棵Deck树。两条路径产出同一个类型的Deck对象。这意味着导出器、导入器、快照器都可以只面向Deck编程完全无差别对待来自 Anki 内存和来自磁盘文件两种数据源——这也是 JSON 导入/导出对称设计的根基。顺带一提history/ 目录archiver.py、dulwich_repo.py等则负责快照落盘时基于纯 Python 的 dulwich 库操作 Git不依赖系统安装 git 命令行同样是把外部依赖关在笼子里的思路。这套架构给了插件开发者什么启发 复盘一遍CrowdAnki 的架构可以提炼成三条通用法则几乎适用于任何 Anki 插件开发适配器模式隔离不稳定 API。Anki 内部接口随版本变化频繁把所有byNamevsby_name这类脏活收敛到anki/adapters/业务层代码就不会被版本升级冲垮钩子注册集中管理。用HookVendorAnkiHookManager把挂了哪些钩子变成一目了然的清单而不是散落在各个文件里维护与排查成本骤降统一中间模型打通双向数据流。representation层的Deck树让Anki 内存 → JSON与JSON → Anki 内存复用同一套逻辑导入导出天然对称、天然可测试。对初学者来说阅读路线建议是先从 main.py 看懂启动流程再看 hook_vendor.py 掌握钩子全貌最后深入 adapters/ 体会适配器模式的落地细节——按这个顺序你会发现一个功能完整的 Anki 协作插件其骨架其实清晰得超乎想象。【免费下载链接】CrowdAnkiPlugin for Anki SRS designed to facilitate cooperation on creation of notes and decks.项目地址: https://gitcode.com/gh_mirrors/cr/CrowdAnki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考