Android Kotlin SDK：内置协程支持与独立KTX包的选型疑问

我正在开发一款支持Kotlin与Java用户的Android Kotlin SDK，目前采用回调这类Java和Kotlin通用的异步操作模式。为提升Kotlin协程用户的开发体验（DX），我计划将各类回调操作改造为Kotlin挂起函数、Flows等形式。

我注意到Android KTX、OkHttp等主流库的常见做法是将协程重载方法放在独立包中，通常命名为xxx-ktx或xxx-coroutines。现提出两个疑问：

1. 将协程支持纳入主库包存在哪些弊端？
   （我已知：这可能会增加方法数量，进而触及DEX方法数限制，但可通过配置ProGuard移除未使用的协程相关方法来解决。）
2. 除上述点外，将协程支持放入主包与独立包还有哪些其他考量因素？

问题1：将协程支持纳入主库包的弊端 #

除你提到的DEX方法数问题外，还有这些核心弊端：

• 强制绑定协程依赖：所有依赖主库的用户（包括纯Java用户）都必须引入Kotlin协程核心依赖，这会无端增加他们的APK体积和依赖复杂度，对不需要协程的用户来说是不必要的负担。
• API冗余与认知混淆：主包同时存在回调式和协程式API，会让API文档变得臃肿，Java用户会看到大量无法直接使用的挂起函数，增加学习和查找成本，甚至可能误选不适合自己技术栈的API。
• 依赖冲突风险：协程库本身版本迭代频繁，如果主包绑定了特定版本的协程依赖，用户项目中若使用了其他版本的协程，很容易出现依赖冲突，引发难以排查的运行时异常。

问题2：主包与独立包的其他考量因素 #

选择主包的核心考量 #

• API使用流畅性：Kotlin用户无需额外引入依赖，就能直接在主包中找到协程形式的API，无需跨包查找，开发体验更连贯。
• 维护成本更低：所有异步逻辑集中在一个模块，无需维护多模块间的调用关系，减少重复代码和跨模块调试的复杂度。

选择独立包的核心考量 #

• 按需引入的灵活性：用户可根据自身技术栈自主选择是否引入协程支持包，纯Java用户完全可以只依赖主包，避免被强制带入无关依赖。
• 版本迭代独立性：协程支持包可独立于主库更新，比如协程库推出新特性时，无需发布整个主库的新版本，仅更新协程包即可，迭代效率更高。
• 职责划分更清晰：主包专注于通用异步逻辑（回调式），独立包专注于Kotlin协程适配，代码边界清晰，后续扩展Kotlin专属特性（如DSL）时也不会影响主包的通用性。
• 隔离Kotlin专属API：Java用户在IDE中查看主包代码时，不会被大量带suspend修饰符的挂起函数干扰，避免不必要的认知困惑。

内容的提问来源于stack exchange，提问作者Maciej Jastrzebski