Android MVP架构疑问：单Presenter适配三个Fragment的可行性咨询

嘿，针对你在Android MVP架构实践里遇到的这三个疑问，我结合实际开发经验给你分析下：

a) 每个Fragment onCreate创建Presenter实例是否合理？ #

这种实现方式得看你的业务场景来判断：

• 如果三个Fragment的业务逻辑完全独立（比如一个是列表页、一个是详情页、一个是设置页，各自处理互不关联的数据和操作），那每个Fragment对应一个Presenter实例是合理的，因为它们的职责边界清晰，各自维护自己的业务逻辑，不会互相干扰。
• 但如果三个Fragment共享同一业务逻辑或数据（比如都是展示同一类数据的不同维度视图），那这种做法就不合理了——多个Presenter实例会导致数据不一致（比如同一个请求发起三次）、重复逻辑代码，还会浪费内存资源。这种场景下更推荐由宿主Activity持有唯一的Presenter实例，每个Fragment在onAttach()时从Activity获取这个Presenter并绑定自己的View，这样整个流程中只有一个Presenter在工作，避免重复实例化。

另外，你当前的代码里在onCreate()创建Presenter，记得要在Fragment销毁时（比如onDestroyView()或onDestroy()）解除View和Presenter的绑定，避免内存泄漏。

b) 空实现视图方法导致代码冗余是否合理？ #

当然不合理，这明显是你的View接口设计得太臃肿了。解决思路是拆分接口，不要让所有Fragment强制实现同一个大而全的View接口：

1. 先抽取出所有Fragment都需要的通用方法，比如showLoading()、hideLoading()、showError(String msg)，定义成BaseView接口。
2. 为每个Fragment单独定义专属的View接口，继承自BaseView，只声明当前Fragment需要用到的方法。比如：

   // 通用基础View
   interface BaseView {
       void showLoading();
       void hideLoading();
   }
   
   // Fragment1专属View接口
   interface Fragment1View extends BaseView {
       void updateTaskList(List<Task> tasks);
   }
   
   // Fragment2专属View接口
   interface Fragment2View extends BaseView {
       void showTaskDetail(Task task);
   }
   

3. 每个Fragment只实现自己对应的专属View接口，这样就不用再写那些无用的空实现了，代码会更简洁，职责也更清晰。

c) Presenter实例能否被垃圾回收？ #

只要你的Presenter没有被其他强引用持有，当Fragment被销毁后，对应的Presenter实例是可以被GC回收的：

• 你在BasePresenter的onDestroy()里把view置为null，这一步很关键——切断了Presenter对Fragment的强引用，避免Fragment因为被Presenter持有而无法回收。
• 如果Fragment被销毁后，这个Presenter没有其他地方的强引用（比如没有被单例持有、没有被未完成的异步任务持有），那当Fragment被GC回收时，Presenter也会跟着被回收。
• 不过要注意，如果Presenter里有正在执行的异步任务（比如网络请求、定时器），即使你把view置为null，异步任务如果持有Presenter的引用，那Presenter暂时不会被回收。所以建议在Presenter.onDestroy()里同时取消所有异步任务（比如调用disposable.dispose()、cancel()等），彻底切断潜在的引用链。

另外，如果你担心多个Presenter实例同时运行，最好的解决办法还是回到问题a的优化方案——用宿主Activity管理唯一的Presenter实例，这样整个流程中只会有一个Presenter在工作，从根源上避免多个实例的问题。

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