KMP中common目录内嵌平台目录的适用场景咨询

你提到的这种在common目录内再设android、iOS等平台子目录的结构，和常规的androidMain、commonMain、iOSMain同级结构相比，主要适用于以下几种场景：

• 集中管理通用层的平台适配逻辑
  当你有一部分逻辑属于通用业务范畴，但必须针对不同平台做适配实现，又不想把这部分适配代码分散到各自的平台主目录（androidMain/iOSMain）时，就适合用这种结构。比如类似Koin示例项目里的情况，依赖注入的核心配置是通用的，但针对Android和iOS的初始化细节需要在通用层内区分开，放在common下的平台目录里，能让通用层的代码结构更完整，不用跨目录去引用平台层的适配代码。

• 封装供通用层直接调用的平台API
  如果需要封装一些平台特有的API，而且这些封装后的API要在通用层的业务代码里直接使用，而不是让平台层去处理，就可以把封装代码放在common内的平台目录。比如封装Android的Context工具类、iOS的UIApplication工具类，这些工具类是为通用业务服务的，实现是平台特定的，放在common下的对应目录，通用层代码能直接引用，避免复杂的跨模块依赖。

• 简化平台主目录的职责
  常规的androidMain/iOSMain本来应该专注于平台特有的业务逻辑，比如Android的页面跳转、iOS的视图控制器管理。把那些为通用层服务的平台适配代码移到common内的平台目录后，平台主目录的代码会更简洁，职责更清晰，不会混杂太多通用层的适配逻辑。

• 模块化拆分的过渡方案
  要是你打算把通用层拆分成更细的子模块，但暂时不想做彻底的模块分离，这种嵌套结构可以作为过渡。先把平台相关的通用逻辑集中在common下的对应目录，后续如果需要拆分独立模块，代码迁移会更平滑，不用大规模调整引用路径。

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