Compose Destinations 多模块项目中路由重复问题的解决方案

问题背景

在使用 Compose Destinations 构建多模块导航项目时，开发者可能会遇到一个常见问题：当尝试在多个导航图中包含同一个目的地时，系统会抛出 java.lang.IllegalStateException: Duplicate route found 异常。这是因为 Compose Destinations 要求每个路由必须是唯一的。

问题分析

在典型的场景中，开发者可能会：

1. 在一个外部模块中定义了一个带有 @Destination 注解的可组合函数
2. 尝试在主模块的不同导航图中引用这个目的地
3. 导致系统检测到重复的路由路径

例如，开发者可能有一个 SettingsDestination 可组合函数，既想在底部导航图中使用，又想在某个特定功能模块的导航图中使用。

解决方案

核心思路

正确的做法是将导航逻辑与UI展示逻辑分离：

1. 分离UI组件：将实际的UI组件(可组合函数)从导航注解中解耦
2. 创建包装器：为每个需要该组件的导航图创建专门的@Destination包装器
3. 复用UI逻辑：这些包装器都调用同一个基础UI组件

具体实现步骤

1. 重构原始模块：
   • 将原来的@Destination注解移除
   • 暴露一个普通的可组合函数，只包含UI逻辑

// 在共享模块中
@Composable
fun SettingsScreen() {
    // 实际的UI实现
}

2. 在需要导航的模块中创建目的地：
   • 为每个导航图创建专门的@Destination
   • 这些目的地都调用共享的UI组件

// 在主模块中
@Destination<BottomNavigationGraph>
@Destination<XGraph>
@Composable
fun SettingsDestination() {
    SettingsScreen()
}

方案优势

1. 保持路由唯一性：每个导航图都有自己独立的路由
2. 代码复用：UI逻辑只实现一次，多处复用
3. 模块解耦：导航逻辑与UI实现分离，架构更清晰
4. 灵活性：可以为不同导航图定制不同的导航行为

最佳实践建议

1. 模块划分：将纯UI组件放在共享模块，导航相关放在特性模块
2. 命名规范：为包装器使用清晰的命名，如FeatureXSettingsDestination
3. 参数传递：如果需要传递参数，确保在包装器中正确处理
4. 测试策略：单独测试UI组件和导航逻辑

总结

Compose Destinations 在多模块项目中的应用需要特别注意路由的唯一性要求。通过将UI组件与导航逻辑分离，并采用包装器模式，可以既保持代码的复用性，又满足导航系统的约束条件。这种架构方式不仅解决了路由冲突问题，还提高了代码的可维护性和可测试性。