移动开发教育【免费下载链接】Anki-AndroidAnkiDroid: Anki flashcards on Android. Your secret trick to achieve superhuman information retention.项目地址https://gitcode.com/gh_mirrors/an/Anki-Android点击查看免费下载导读本文以 Anki-AndroidAnkiDroid仓库中 anki-common/README.md 为骨架深入剖析:anki-common这一 Gradle 模块的设计动机、边界划分与未来演进方向。通过对照模块内源码CollectionManager.kt、DeckUtils.kt、destinations/、storage/等你将理解为什么在:AnkiDroid拆分为特性模块后需要一个独立的:anki-common来承载同时依赖:libanki与:compat的公共代码以及它如何在依赖图中充当断路器避免循环依赖并掌握该模块的准入/准出规则与后续拆分路径。模块定位为特性模块化而生的依赖层anki-common/README.md开宗明义地指出这个模块的存在目的是当:AnkiDroid被拆分为若干 feature 模块时打破循环依赖This module exists to break circular dependencies when:AnkiDroidis split into feature modules.。在settings.gradle.kts中:anki-common与:AnkiDroid、:libanki、:common、:compat等模块并列注册include(:anki-common)它处于依赖树中的中间位置向下依赖:libanki与:compat向上被:AnkiDroid及其 feature 模块消费。这种夹层定位使它天然成为依赖治理的关键节点。什么代码应该放进:anki-commonREADME 给出了两条明确的准入标准依赖:libanki且不属于上游pylib的公共类型与功能。:libanki的目标是成为上游 Anki 桌面端pylib的 1:1 实现负责定义CardId、DeckId等领域类型。AnkiDroid 特有的扩展例如与 Android 框架耦合的存储、导航逻辑需要足够强的理由才能合入:libanki因此这些扩展需要一个专属落脚点。依赖:compat的公共类型同时必须保证不存在:common - :compat的依赖方向。源码佐证从包结构看实际承载内容模块内com.ichi2.anki包下的组织方式与上述标准一一对应common/storage/CollectionHelper集合路径决策、目录初始化、StorageDecisionDecided/Undecided两种存储决策状态、AnkiDroidFolder、LegacyStorage。这些代码依赖:libanki的CollectionFiles类型且涉及 AndroidSharedPreferences正属于依赖:libanki的公共 Android 类型。common/destinations/Destinationsealed class及Navigator接口描述可导航到的目标屏幕。BrowserDestination引用了:libanki的CardId、DeckId领域类型sealed class BrowserDestination : Destination() { data object Open : BrowserDestination() data class ToDeck(val deckId: DeckId) : BrowserDestination() data class ScrollToCard(val deckId: DeckId, val cardId: CardId) : BrowserDestination() data class Search(val query: String, val allDecks: Boolean) : BrowserDestination() }CollectionManager.kt模块最核心的文件是com.ichi2.anki.libanki.Collection:libanki类型在 AnkiDroid 侧的唯一管理入口。DeckUtils.kt提供isDefaultDeckEmpty()、canUserAccessDeck(did)、isCollectionEmpty()等挂起函数全部基于withCol访问:libanki的Collection用于 Deck Picker 判空等 UI 逻辑。以CollectionManager为例理解模块边界CollectionManager是:anki-common承担依赖:libanki的公共逻辑职责的典型代表。它通过withQueue将所有集合操作串行化到Dispatchers.IO.limitedParallelism(1)的后台队列上并提供三个核心访问入口withCol(block: Collection.() - T)打开必要时并执行块保证并行调用串行、不会出现并发关闭/修改withOpenColOrNull(block: Collection.() - T)集合已打开才执行块否则返回 nullgetColUnsafe()同步上下文中返回集合引用注释明确警告不安全其他线程可能在持有引用期间打开/关闭集合推荐优先使用withCol。它还负责打开/关闭底层 backendensureBackendInner、discardBackendInner、处理存储未配置异常StorageNotConfiguredException与系统存储故障SystemStorageException并实现了compareAnswer答案比对与TRRust backend 提供的翻译等不依赖集合开关状态的快捷访问。从源码结构看它相当于把:libanki领域对象与 Android 生命周期、存储决策之间的胶水逻辑统一收敛到了:anki-common避免每个 feature 模块各自重复实现。什么代码不应该放进:anki-commonREADME 同样给出了两条准出红线Feature 专属业务逻辑应放在:AnkiDroid或 feature 模块中。例如刷题流程、卡片浏览器等具体业务的编排逻辑不应下沉到公共层。不依赖:libanki的公共代码应放在:common。:common与:anki-common的分工对照 common/README.md 可清晰看出两者差异:common是纯 JVM 模块位于 AnkiDroid 依赖树的最底层只定义通用工具与核心接口如CrashReportService、UsageAnalytics没有任何 Android 依赖依赖 Android API 的公共代码在:common:android:anki-common则是Android library专门收容同时依赖:libanki领域类型 Android/compat的代码。换言之判断放:common还是:anki-common的简单标准是是否依赖:libanki的领域类型。不依赖 → 放:common依赖且含 Android 内容 → 放:anki-common。为什么不能直接放进:common这是理解整个模块存在意义的关键README 用一句话点破:libankidepends on:common. Common code which needs domain types would cause a circular dependency if placed in:common.由于:libanki本身依赖:common若把需要领域类型如CardId的公共代码放进:common就会形成:common - :libanki - :common的循环依赖Gradle 无法解析。:anki-common作为:libanki与:common依赖方向之外的新节点为这类代码提供了合法落点从而解除了循环。未来演进方向README 的 Future direction 一节描述了模块的明确演进路径当前:anki-common是Android library原因在于它依赖的:libanki目前就是 Android library当:libanki变为JVM library后:anki-common将拆分为纯 JVM 半区 Android 半区镜像现有:common/:common:android的配对结构JVM 半区存放所有不依赖 Android 框架的内容。代码中已经能看到这一方向的预埋痕迹。例如 Navigator.kt 的源码注释明确写道// TODO: Move this into anki-common:android after libanki becomes a java-library而DeckUtils.kt中的isDefaultDeckEmpty()、isCollectionEmpty()等纯逻辑函数则属于未来可迁入 JVM 半区的候选——它们只通过withCol访问:libanki的Collection本身不直接触碰 Android 框架。相比之下CollectionHelper依赖SharedPreferences、Context与Navigator依赖Activity、Intent、Fragment显然属于 Android 半区。模块内的可复用测试设施:anki-common还提供了testFixtures供测试复用。在 NavigationTestUtils.kt 中launchActivity帮助函数利用DeferredNavigation上下文RobolectricTest实现了该接口将Destination直接解析为Intent并启动ActivityScenariocontext(_: DeferredNavigation) fun T : Activity launchActivity(destination: Destination): ActivityScenarioT ActivityScenario.launch(destination.toIntent())这意味着 feature 模块的测试可以像launchActivitySingleFragmentActivity(StatisticsDestination)这样用统一的Destination抽象驱动界面测试而无需关心具体 Activity 的构造细节——这正是将跨模块公共代码下沉到:anki-common后获得的复用收益。依赖治理的意义与总结回到依赖图视角:anki-common在 Anki-Android 模块化架构中承担的角色可以概括为角色说明循环依赖断路器承接依赖:libanki领域类型的公共代码避免:common - :libanki反向依赖公共 Android 代码层收容CollectionManager、CollectionHelper、Navigator等跨 feature 共享的实现:libanki的扩展缓冲带AnkiDroid 特有扩展不必挤进 1:1 对齐上游pylib的:libanki未来 JVM 化的孵化器待:libanki转为 JVM library 后按 JVM / Android 半区拆分对于阅读 Anki-Android 源码的开发者把握这一模块的边界规则依赖:libanki Android/compat→:anki-common纯 JVM 通用逻辑 →:commonfeature 业务 →:AnkiDroid及其特性模块可以快速定位代码归属对于从事大型 Android 工程模块化改造的团队:anki-common的中间共享层打破循环依赖思路则是一份可直接借鉴的依赖治理范本。赞分享移动开发教育【免费下载链接】Anki-AndroidAnkiDroid: Anki flashcards on Android. Your secret trick to achieve superhuman information retention.项目地址https://gitcode.com/gh_mirrors/an/Anki-Android点击查看免费下载相关推荐dlt 模块分层架构dlt/common 的边界规则、Protocol 接口与循环依赖防治dlt 模块分层架构dlt/common 的边界规则、Protocol 接口与循环依赖防治 dlt 采用严格的模块依赖分层来维持其库而非平台的定位底层数据工程数据集成批处理Thunderbird for Android 的 app-common 模块共享代码集成点与模块化架构解析Thunderbird for Android 的 app common 模块共享代码集成点与模块化架构解析 app common 是 Thunderbird移动开发企业应用LivePortrait技术深度解析高效肖像动画生成与拼接重定向控制LivePortrait技术深度解析高效肖像动画生成与拼接重定向控制 LivePortrait是由快手科技开发的实时肖像动画解决方案通过创新的拼接与重定向控人工智能计算机视觉媒体生成数字人上一篇Laravel Onboard部署实战从开发到生产环境的完整流程下一篇如何使用SkeletonView打造优雅的iOS骨架屏从入门到精通创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考