ReVanced Manager 补丁包命名机制优化方案解析

背景与问题现状

在ReVanced Manager应用开发过程中，补丁包(Patch Bundle)的默认命名机制存在一定局限性。当前系统采用"Main"作为内置补丁包的默认名称，这种命名方式存在两个主要问题：

1. 语义模糊性："Main"无法直观表达该补丁包的实际含义
2. 信息缺失：用户无法通过名称了解补丁包的来源和特性

技术解决方案演进

开发团队经过多轮讨论，最终形成了分层次的命名优化方案：

1. 对于API源补丁包

从ReVanced API的info端点获取服务标识，采用"${apiName} Bundle"的命名格式。例如当API域名为revanced.app时，补丁包将显示为"revanced.app Bundle"。

技术实现要点：

• 调用API的/v2/info端点获取服务信息
• 自动拼接服务标识与"Bundle"后缀
• 保留用户手动修改名称的灵活性

2. 对于独立补丁包

实现自动读取补丁包清单(manifest)中的元数据作为默认名称。补丁包开发者可以在build.gradle.kts中配置如下元信息：

bundle {
    name = "自定义包名"
    description = "补丁包功能说明"
    version = "版本标识"
}

技术优势：

• 消除用户手动命名的操作负担
• 保持命名规范性和一致性
• 支持版本信息等扩展字段

架构设计考量

该方案体现了以下设计原则：

1. 智能默认值原则：系统自动提供有意义的默认值，减少用户决策负担
2. 显隐性信息平衡：既展示必要标识信息，又避免过度技术性描述
3. 扩展性设计：命名模板支持后续添加更多元数据字段

用户价值体现

对终端用户带来的直接改善：

• 更直观的补丁包来源识别
• 减少对技术概念的困惑
• 提升整体使用体验的一致性

对开发者的附加价值：

• 统一的补丁包元数据规范
• 便于多补丁包场景下的管理
• 为后续的包管理功能奠定基础

技术实现路线

实际开发时需要关注：

1. 异常处理机制：当API不可达或清单损坏时的降级方案
2. 本地化支持：考虑多语言环境下的命名策略
3. 缓存策略：对API信息进行合理缓存以提升性能
4. 用户自定义覆盖：保留修改默认名称的入口

该方案已在ReVanced Manager的最新开发分支中实施，预计将在下个稳定版中向用户推送。