Kotlin 电商 APP 实战复盘：模块化 + MVP 架构下的完整开发心路下课仔：xingkeit.top/7781/

在参与并主导一个基于 Kotlin 开发的电商类 Android 应用项目后，回顾整个开发历程，我深刻体会到架构选择对项目成败的决定性影响。本文将从个人视角出发，分享我在采用“模块化 + MVP”架构过程中所经历的思考、挑战与收获。

初期：为何选择模块化 + MVP？

项目启动之初，团队面临几个核心问题：业务复杂度高、多人协作频繁、需求变更快。传统的单体式架构显然难以应对未来的扩展和维护压力。于是我们决定采用模块化设计，将首页、商品详情、购物车、订单、用户中心等核心功能拆分为独立模块，每个模块拥有自己的 UI、逻辑和数据层，彼此通过清晰的接口通信。

与此同时，在 UI 架构上，我们选择了 MVP（Model-View-Presenter） 模式。虽然 MVVM 在 Kotlin 协程和 LiveData 的加持下更为流行，但考虑到团队对响应式编程尚不熟悉，且 MVP 的职责划分更直观、测试边界更清晰，我们最终选择了它作为 UI 层的组织方式。

中期：模块化带来的自由与约束

模块化并非一蹴而就。初期我们曾陷入“过度拆分”的陷阱——把一些本应共享的基础组件（如网络请求封装、图片加载、日志工具）也放进业务模块中，导致重复代码和依赖混乱。后来我们意识到，必须设立一个 common 模块，用于承载所有跨模块共享的基础设施，并严格限制模块间的直接依赖，仅允许通过接口或路由跳转进行交互。

这一调整带来了显著好处：

• 编译速度提升：独立模块可单独构建，大幅缩短调试时间；
• 团队协作顺畅：不同小组可以并行开发各自模块，互不干扰；
• 功能复用性强：例如促销弹窗、地址选择器等组件，被多个模块调用而无需重复开发。

但模块化也带来了新的挑战：模块间通信成本增加。比如购物车数量变化需要通知首页徽标更新，我们不得不引入事件总线（EventBus）或自定义回调机制。这让我意识到，模块化不是“拆得越细越好”，而是要在解耦与效率之间找到平衡点。

MVP 实践中的得与失

MVP 的核心优势在于逻辑与视图分离。Presenter 负责业务逻辑和数据处理，View 只负责展示和用户交互。这种结构让单元测试变得可行——我们可以 mock Model 层，验证 Presenter 在不同输入下的行为是否符合预期。

然而，在实际开发中，我们也遇到了 MVP 的“痛点”：

• 接口膨胀：一个复杂的页面可能需要定义数十个 View 方法（如 showLoading、hideError、updateProductList 等），接口维护成本高；
• 生命周期管理繁琐：为避免内存泄漏，必须在 Activity/Fragment 销毁时手动解除 Presenter 与 View 的绑定；
• 状态恢复困难：旋转屏幕或进程重建后，Presenter 中的状态容易丢失，需额外设计缓存机制。

尽管如此，MVP 依然为我们提供了清晰的代码结构。尤其在电商场景中，商品列表、筛选条件、分页加载等逻辑高度集中于 Presenter，使得后期优化和 Bug 定位变得高效。

心态转变：从“快速实现”到“可持续交付”

项目初期，我和其他开发者一样，追求“快”——快速出功能、快速上线。但在经历几次因架构混乱导致的返工后，我逐渐意识到：好的架构不是拖慢进度的负担，而是保障长期交付能力的基石。

模块化让我们敢于重构——因为改动被限制在模块内部；MVP 让我们敢于迭代——因为 UI 和逻辑解耦，修改界面不会波及业务规则。这种“可控的自由”，是技术债最小化的关键。

总结：适合的才是最好的

回望整个项目，模块化 + MVP 并非银弹，但它非常适合我们当时的团队规模、技术栈和业务节奏。如果今天重新开始，我可能会尝试 模块化 + MVVM + Jetpack Compose 的组合，以进一步提升开发效率和用户体验。但正是这次 MVP 的实践，让我真正理解了“架构服务于业务”这一原则。

技术选型没有绝对的对错，只有是否契合当下。而作为开发者，我们的成长，往往就藏在这些权衡与反思之中。