1. 整体设计与思路拆解1.1 三层架构到底分的是什么先聊一个我特别想纠正的误区。很多人一听说三层架构第一反应就是表现层、业务层、数据层这三个词背下来然后开始往项目里套目录。但真正干过几年项目的人都知道三层架构最难的不是分层而是知道你正在写的这行代码应该属于哪一层。我见过太多项目包名看起来是标准的model、view、presenter三层结果点进去一看presenter里写满了JSON解析view里直接操作SQLitemodel层躺着几百行网络请求。这种项目不是没分层是分了个寂寞。三层架构的本质是把界面怎么显示、业务怎么处理、数据从哪来这三件完全不同的事拆开。表现层只负责把用户看到的东西画出来把用户的操作传出去业务层只负责业务流程、逻辑判断、状态流转它不关心按钮长什么样数据层只负责从网络、数据库、文件里把数据取出来或者存进去它不关心界面上的事。这个拆分的核心逻辑是变化点隔离。界面是变化最快的今天改个样式明天加个弹窗业务规则是变化较慢的偶尔改改判断逻辑数据来源是最容易被替换的今天用远程接口后天可能改成本地缓存。如果这三类东西混在一起任何一个变化都会牵一发动全身。反过来如果分开了界面变化不影响业务换数据源也不影响业务这才是分层真正的价值。对于MVP模式来说三层架构的映射其实很自然View对应表现层Presenter对应业务层Model对应数据层。但要注意这里的Model不是数据模型类而是数据访问与数据源管理的统称。很多人写MVP时把Model理解成只放几个JavaBean这是不对的。Model应该包含数据获取的完整链路网络请求、数据库操作、缓存策略、数据转换甚至仓库模式的封装。1.2 MVP在三层架构里的定位MVP在Android项目中的核心作用是把View和业务逻辑彻底解耦。说的直白一点Activity和Fragment本质上就是View它们不应该去关心数据怎么来的和业务规则是什么只需要做三件事初始化界面、接收用户操作并告诉Presenter、根据Presenter的回调更新界面。Presenter承上启下。它从View接收事件然后调用Model去拿数据拿到结果后再决定View应该展示什么状态。这样一来业务逻辑就被从Activity里掏了出来放到了一个普通类里。这个普通类不依赖Android生命周期可以单元测试可以复用这就是MVP最大的红利。有人会问那MVP和三层架构是不是重复了不是。MVP解决的是表现层内部的View和业务逻辑的分离三层架构解决的是整个App的界面、业务、数据的层次划分。两者是配合关系MVP让表现层内部不再臃肿三层架构让整个项目从上到下都有清晰的归属。我还见过一种混乱的写法就是MVP三层各自为政View直接new一个Model去拿数据绕过了Presenter。这么写短期看起来省事但长期一定会出问题回调写在View里导致View层代码爆炸业务逻辑散落在数据回调里改一个需求要动三个文件。MVP模式的约束恰恰是单向依赖——View只依赖PresenterPresenter只依赖Model接口Model不知道View和Presenter的存在。破坏了这个约束MVP就名存实亡。1.3 为什么标准化比分层本身更重要分层的思路谁都能理解但把分层做成标准化的就不是每个人都能做到了。什么叫标准化就是同一个团队里的任何一个人拿到一个新需求能清楚地知道代码写在哪、方法起什么名、接口怎么定义、数据走什么流程不需要看文档也能靠惯例找到该改的文件。标准化分层解决的是一个团队协作效率问题。我接手过一些个人开发者写的项目架构不可谓不好包结构清晰命名也有讲究但只有作者本人能维护。为什么因为缺少统一约定。张三写的Presenter叫MainPresenter李四写的叫HomePagePresenter王五写的叫MainActivityPresenter三个人写的代码风格完全不一样协作起来成本极高。标准化的核心是把规范沉淀为代码骨架和文件模板。比如规定所有Activity必须继承BaseActivity所有Presenter必须继承BasePresenter所有View接口必须继承BaseView所有数据访问必须走Repository。这些约定一旦在项目里落地新成员上手速度会快很多review代码时也不用花大量时间讨论这样写行不行。另外我要多说一句标准化不是为了限制灵活性而是为了把常规的、重复性的决策从日常开发中剥离出去。每天纠结这个接口的命名风格、这个回调该放在哪一层是非常消耗精力的事。标准化之后这些决策都有了默认答案开发者的精力可以投入到真正需要思考的业务问题上。2. 核心细节解析与实操要点2.1 一个可以直接复制的包结构讲标准化的第一步先给出一套我用了很久的包结构。这套结构在多个项目里验证过不能说完美但至少能让你在项目规模膨胀到几十个模块时还能较快定位到目标文件。com.example.project ├── base // 基类与通用组件 │ ├── BaseActivity.java │ ├── BasePresenter.java │ ├── BaseView.java │ └── BaseRepository.java ├── data // 数据层 │ ├── local // 本地数据源数据库、SharedPreferences、文件 │ ├── remote // 远程数据源网络接口 │ ├── model // 数据实体Entity/DTO │ └── repository // 仓库实现对外暴露的统一数据入口 ├── ui // 表现层 │ ├── main // 按业务页面分包 │ │ ├── MainActivity.java │ │ ├── MainContract.java │ │ ├── MainPresenter.java │ │ └── MainAdapter.java │ ├── login │ └── profile └── utils // 工具类非业务相关注意几个关键点第一ui下面按页面分包而不是按类型分包也就是说不要用activity包、adapter包、fragment包这种组织方式。按页面放的好处是改一个页面功能时所有的相关文件都在同一个目录里不需要跳来跳去。第二data/remote只放接口定义和网络相关的封装真正的数据拼装在repository里做。第三model里放的是纯数据类它们不依赖任何框架可以被各层引用。这套结构本质上是对三层架构的目录映射ui对应表现层presenter和contract属于业务逻辑的入口data对应数据层。有同学会问业务层到底体现在哪MVP模式下业务逻辑主要写在Presenter里所以ui包下面的Presenter其实承载的就是业务层职责。如果你觉得业务逻辑太重可以在ui和data之间加一个domain包专门放用例UseCase但对大多数中小型项目来说Presenter直接面向Repository已经够用了再加一层反而冗余。2.2 命名规范背后的可维护性逻辑命名规范是标准化里最容易被忽视却最影响长期维护的部分。我见过最崩溃的项目是写一个获取用户信息的接口有人叫getUserInfo有人叫queryUserData有人叫fetchUserFromServer还有人叫getUserInfoById这些方法放在同一个类里功能几乎一样只是参数略有不同。我建议的命名规则是这样的。View接口里的方法用描述性动宾短语比如showLoading、showEmptyView、setUserListData。Presenter里的方法用业务动作命名比如loadUserList、submitOrder、handleLoginClick尽量不要用onClick这种与UI控件绑定太死的名字因为处理逻辑可能不只来自一个控件。Repository里的方法用数据动作命名比如fetchUserList、saveOrderToLocal、deleteCache让调用方一看就知道数据是从哪来的、要做什么。Contract接口的命名也值得规范。我通常在一个页面级的功能模块里把View接口和Presenter接口合并放在一个Contract类里比如MainContract内部定义interface View和interface Presenter。这样做的价值在于打开MainContract就能看到View和Presenter之间的所有交互契约。这在团队协作时特别有用新人接手一个页面只要看Contract就能知道页面有哪些交互、Presenter提供哪些能力。还有一个小技巧Model类不叫Model而是根据数据来源定义后缀。网络返回的叫Response本地表结构对应的叫Entity跨层传递的业务对象叫Bean。有些人会觉得这样太麻烦但在数据层出现混淆时这些后缀能帮你快速判断这个对象能不能往界面上传。能往界面上传的只有BeanResponse和Entity都必须在数据层内部转换成Bean后再往外传。2.3 依赖关系的硬性约束分层设计的核心约束就是依赖方向表现层依赖业务层业务层依赖数据层数据层谁都不依赖。在MVP的语境里这句话会拆成更具体的几条规则。第一View不能直接操作数据层。我在代码review中经常看到Activity里直接写网络请求回调的代码这表面上是绕过了Presenter实质上是把网络回调的线程切换和错误处理逻辑泄漏到了UI层。正确的做法是View把用户操作告诉PresenterPresenter决定去调哪个Repository方法数据回来后由Presenter决定View该怎么显示。第二Presenter不能持有View的强引用。这个坑几乎每个写过MVP的人都踩过——Activity销毁了但Presenter还在执行异步任务回调时View已经不存在了轻则空指针重则内存泄漏。解决办法有两个一是让Presenter持有View的弱引用二是在生命周期结束时主动解绑。两种做法不互斥我建议同时做具体实现后面会详细讲。第三Model层不能反向依赖Presenter或View。很多人写数据层时会把回调接口直接定义在Presenter内部然后让Repository去持有这个回调这就是反向依赖。正确的做法是数据层只通过接口回调返回数据这个接口的定义不依赖任何业务层面的东西Presenter去实现这个接口来接收结果。如果有一天你发现共同的Model被两个业务模块复用而Model里只有一份数据逻辑说明你的分层设计是健康的。依赖关系还需要在工程层面做保障。比如模块化项目里可以用Gradle依赖配置限制模块之间的引用关系比如data模块不能依赖ui模块。单一项目里则可以通过包名检查和code review来约束。我见过一个比较有效的做法是在CI脚本里加一个依赖检查任务扫描代码里是否出现了跨包引用如果data包里的文件import了ui包下的类构建直接失败。这种做法看着粗暴但对维持架构纪律非常有效。3. 实操过程与核心环节实现3.1 Base层封装把共性的东西沉淀下来标准化的第一步是先搭好Base层。Base层是项目的地基所有业务模块都要继承它所以设计一定要慎重不要图省事把所有东西都塞进去。我的经验是Base层只放跨模块可以复用且逻辑一致的东西如果一个方法只有一个页面用就不要进Base。BaseActivity是最常见的封装对象。我通常会在里面做这几件事初始化布局的抽象方法、初始化View的抽象方法、提供一个全局的上下文和安全的事件分发。但有一点要注意BaseActivity不要长成一个万能类不要在里面写公共的联网方法、公共的刷新方法那些应该由各层的Base去解决。BaseActivity的生命周期回调要尽量精简把逻辑留给子类覆盖。BaseView接口是所有View接口的父接口里面放的是所有页面都可能用到的通用UI状态方法比如showLoading、hideLoading、showToast、showErrorPage。这样做的好处是BasePresenter在调用这些方法时不需要知道具体的View实现类只要面向BaseView接口编程就行。BasePresenter负责两件事绑定View和解除View绑定。我在BasePresenter里维护一个WeakReference的View引用提供attachView和detachView两个方法。Presenter初始化时不需要传ViewActivity在onCreate时调用attachView在onDestroy时调用detachView。所有子类Presenter通过getView()方法来获取View引用这样能保证在异步回调时即使View已经销毁也不会出现强引用导致的内存泄漏。BaseRepository封装数据层的通用操作。比如统一的错误解析、线程调度、请求取消。但这里要克制只放数据层共有的逻辑不要把某个具体页面的接口放在这里。Repository更像是一个统一的数据出口门面它内部组合了多个数据源对外暴露的是业务模块需要的领域方法。3.2 Presenter与View的桥接Contract接口的设计Contract接口是MVP标准化里最容易被低估的部分。很多人只把Contract当作一个声明了方法名的壳并没有真正理解它在依赖治理中的作用。Contract其实定义了Presenter和View之间的一纸契约View能做什么Presenter能提供什么都在里面说清楚了。我的设计模式是一个页面一个Contract接口内部放两个子接口。下面是一个典型示例public interface LoginContract { interface View extends BaseView { void showLoginSuccess(UserBean user); void showLoginError(String message); void setSubmitButtonEnabled(boolean enabled); } interface Presenter extends BasePresenter { void login(String username, String password); } }LoginActivity实现LoginContract.ViewLoginPresenter实现LoginContract.Presenter。Activity持有一个Presenter实例创建Presenter后调用attachView(this)。这样Activity就可以直接调用presenter.login()而Presenter可以通过getView().showLoginSuccess()来回调。为什么要把View接口和Presenter接口放在同一个文件而不是分开建两个文件主要是为了方便。打开LoginContract一眼就能看到这个页面的所有交互点View要展示哪些状态Presenter要提供哪些操作。对新人来说这比去翻两个文件轻松得多。需要注意的是业务场景变化时Contract要同步更新。如果一个页面新增了一个下拉刷新先改Contract接口再加实现这个顺序不能反。先改Contract再实现的好处是强迫你提前梳理清楚这个操作应该由谁发起、结果由谁展示而不是直接把代码写到Activity里补丁式地实现。3.3 生命周期绑定与线程安全MVP在Android里最经典的问题就是生命周期管理。我总结过一条经验只要遇到打开页面之后马上做网络请求然后快速退出崩溃了这种问题十有八九是生命周期处理不当。解决方案不只是用WeakReference这么简单。你还需要判断这个异步操作在Presenter触发时View已经有被销毁的可能了。具体地说在Presenter回调View的方法里加一个安全判断protected boolean isViewAttached() { return mViewRef ! null mViewRef.get() ! null; }每次在回调里使用getView()之前先调用isViewAttached()判断一下。如果没有附加View就直接return不再执行UI更新逻辑。这是一种延迟安全的做法虽然不能完全避免逻辑执行但至少不会因为UI操作而崩溃。还有一种情况是页面销毁后异步任务还在执行数据很快会被丢弃。这种情况更好的处理方式是生命周期感知的取消。如果你用的是RxJava可以在Activity的onDestroy时调用compositeDisposable.dispose()如果你用协程可以在Presenter里维护一个Job页面销毁时cancel掉。如果项目里还是用早期的回调式网络库可以启用一个请求取消标记。我特别想提醒的是不要在View被销毁后还在回调里做重量级操作。比如拿到数据后写数据库、更新本地缓存这些逻辑应该在数据层完成而不是在View的回调里做。因为View销毁后这些操作不仅没有意义还可能因为Context引用问题导致内存泄漏。另外一个容易被忽略的点是把回调切换到主线程。Android要求UI操作必须在主线程执行如果你的网络回调发生在子线程直接调用getView().showLoginSuccess()就会出现CalledFromWrongThreadException。所以Base层里应该做好线程切换所有的View回调统一切到主线程。这也是为什么我倾向于在BasePresenter里提供runOnUiThread方法或者在BaseView接口的实现中统一做线程切换而不是让每个子类去处理。3.4 数据层仓库模式的统一封装设计数据层的时候我推荐使用仓库模式Repository Pattern。这是三层架构里数据层最经典的实践它对外屏蔽了数据的来源让上层调用方只关心拿到数据这个结果。仓库模式的核心思想是把数据来自网络还是来自本地缓存这个决策从业务层下放到数据层。业务层不需要知道数据是实时的还是缓存的只需要告诉Repository给我用户列表Repository自己决定去查缓存还是发请求以及如何用缓存回填。这是一个简单的Repository接口和实现public interface UserRepository { ObservableUserBean fetchUserInfo(); } public class UserRepositoryImpl implements UserRepository { private final UserApi mUserApi; // 远程数据源 private final UserDao mUserDao; // 本地数据源 Override public ObservableUserBean fetchUserInfo() { // 先读缓存 UserBean cache mUserDao.queryUser(); if (cache ! null) { return Observable.just(cache); } // 缓存没有走网络成功写入缓存 return mUserApi.getUserInfo() .doOnNext(user - mUserDao.saveUser(user)); } }Repository接口的粒度要跟业务对齐不要按网络接口一比一映射。一个网络接口可以被多个业务场景复用但Repository方法应该根据业务来定义。比如getUserInfo和getUserInfoFromNetwork是两个不同的方法前者可能走缓存优先策略后者强制刷新。业务层调哪个完全看当时的需求场景。还有一个经验是不要把网络调用直接露在外面让Presenter去调用。如果Presenter直接操作Retrofit创建的Api接口那么网络层的变更比如加公共参数、改签名机制就会涉及到所有Presenter改动面很大。Repository存在的意义不仅在于缓存还在于把网络层的实现细节隔离在数据层内部。4. 从单一模块到项目级实践的要点4.1 多模块MVP的协作模式前面讲的都是单一模块内部的标准化但项目规模大了之后单一App模块会逐渐拆成多个Gradle模块比如app模块、common模块、data模块、business模块等。三层架构和MVP在这个阶段依然有效但需要做一层适配。app模块是入口负责初始化各种框架和配置。ui相关的页面根据业务拆分成多个模块比如login模块、home模块、profile模块。每个模块内部依然是MVP三层Contract、Presenter、View、Adapter都在模块内部模块对外暴露的只是一个Fragment或者Activity的入口类。data模块是一个独立的Gradle模块里面只放数据层的东西网络接口、数据库、实体、Repository。ui模块之间的通信不直接依赖具体页面而是依赖data模块暴露的接口。这种模式下common模块承载Base层的东西ui模块们懒加载注入Presenter的实现。这种模式的好处是模块之间的依赖关系变成了编译期可见的如果你在home模块中直接引用了login模块的类编译就会报错。架构破坏在编译阶段就被拦截了这就是前面说的依赖约束从约定上升到了工程保障。4.2 标准化分层的落地步骤与迁移策略如果你正在维护一个没有分层的项目现在想引入三层架构MVP不建议一口气全部重写。一口气重写意味着大量的回归风险业务测试要全部重跑出问题后很难定位是新架构引入的bug还是原逻辑本身就有的问题。我建议走渐进式改造路线。第一步把与UI无关的业务逻辑从Activity/Fragment中搬出来放到新建的Presenter里。这时候不需要急着建Contract接口先做到Activity只做View的事把业务逻辑从Activity里剥离出去。做这一步时先把最复杂、最常改动的页面拿出来改比如首页、登录页、购物车页不要先改一些边缘页面。第二步为每个改造完成的页面补一个Contract接口把View的方法和Presenter的方法固定下来。这一步的意义是明确交互边界。当代码规模变大以后这一步是防止写着写着又回到Activity里写逻辑的关键。第三步整理数据层。把散落各处的Retrofit、OkHttp、数据库操作统一收拢到data包的Repository中。这一步要注意网络请求方法尽量先定义接口再在Impl中实现方便以后替换数据源时不影响上层业务。迁移过程中最需要警惕的是过渡期混乱项目里既有旧的直连式代码又有新的MVP代码。这种混搭会降低开发效率。我的建议是在过渡期间新写的代码必须走新的分层规范旧的代码只有在被修改时才顺手迁移。不要专门安排一个大版本去重构全部旧代码除非你有一个相对空闲的版本周期。4.3 新项目如何导入这个规范如果你是从零开始一个新项目导入这套规范就简单得多。但你依然要避免一个坑不要一上来就把所有抽象都建好什么BaseViewModel、BaseRepositoryCallBack、IBaseListPage都写给子孙后代留着。过度设计是标准化最大的敌人。我建议先按照最小可用的规范启动比如UI按页面分包页面内MVP三层三个文件Contract数据层Repository两层接口、实现Adapter放在页面包内。先跑起来在真实需求中逐渐补充AbstractPage、BaseList等更上层的抽象而不是事先把它全都写出来。项目初期一个团队最需要的是简单的规范和严格的自律。简单意味着新人进来成本低自律意味着三个人也要遵守一致的代码风格。很多新项目走上正轨之后的第一个难题不是功能写不出来而是代码风格迅速就分叉了——今天张三写了一个方便快捷的直连网络明天李四照着写后天项目就变回了老样子。从第一天就要建立code review的习惯而且在最开始的一两个版本里review的重点不要只放在业务正确性上架构是否符合分层规范同样重要。一旦项目中已经出现了违反架构的代码并被合并后面再纠正的阻力会成倍上升。5. 常见问题与排查技巧实录5.1 内存泄漏排查从崩溃到预防MVP项目里最典型的问题就是内存泄漏。表现通常是页面反复进出几次后内存明显上涨或者LeakCanary弹窗提醒MainActivity泄漏。泄漏根源绝大多数出在Presenter的异步回调上。你的Activity虽然onDestroy了但Presenter还活着执行着网络回调回调里又持有了Activity的引用Activity就永远无法被回收。这也就是为什么我在前文反复强调WeakReference和isViewAttached()检查的原因。要排查现有的泄漏可以先靠LeakCanary定位泄漏的引用链找到持有Activity的对象。然后检查这个对象是不是Presenter是不是回调接口是不是Handler。一旦确认是异步回调导致的改法就明确了在onDestroy时解绑或者取消回调。额外提醒一个角落静态变量。Project里经常会有为了图方便而写的静态工具类或静态Manager里面持有Context或者View的引用。这种泄漏比MVP的弱引用问题更隐蔽。标准化的Base层设计里禁止在静态变量中直接持有Activity或View的引用应该持有Application级别的Context或者使用弱引用。5.2 View层臃肿与Contract爆炸的对策MVP使用一段时间后有两种典型的坏味道。一种是View接口里方法越来越多从showLoginSuccess到showUserNameValidationError到showNetworkError再到showUploadProgress渐渐地一个页面的View接口可能有三十多个方法。另一种是Presenter也臃肿login、logout、register、forgotPassword、checkToken全部堆在一个LoginPresenter里。这两种情况其实是一个问题的两面你在一个页面里塞了太多职责。解决思路是把页面的子模块拆成多个Contract和Presenter而不是试图用一个Presenter撑起整个页面。举个例子一个订单详情页由订单基本信息、订单物流、售后申请三个部分组成如果我们用一个OrderDetailContract的接口来定义所有交互那么这个接口一定很庞大。正确的拆法是把订单信息、物流信息、售后申请分别抽成三个子模块每个子模块都有自己的Contract和Presenter它们挂在一个Fragment里。这样每个Presenter的职责单一View接口也各自独立改动物流模块不会碰售后逻辑。拆分之后还有个细节要注意各个子Presenter和Fragment的生命周期绑定要清晰。Fragment的onDestroy只解绑Fragment自身对应的Presenter不要把所有子Presenter一次性清掉否则会误伤还在执行的任务。5.3 数据层混乱的表现与修复数据层的混乱代码写起来很快清理起来极难。最常见的三种症状是一是数据源获取逻辑散落在很多页面里同一个网络接口在三个页面里被重复调用了三次二是Repository里全是转发方法一个方法只是简单地把网络接口返回给Presenter没有做任何缓存或者数据转换三是缓存策略严重不一致一个页面读缓存另一个页面不读同一个接口有的页面强制刷新有的页面优先缓存。修复的第一步是梳理所有网络接口和缓存需求的清单想想这个数据的时效性要求如何实时性要求高的就走网络容忍延迟的就走缓存优先策略。第二步是明确哪些数据必须在Repository层做缓存哪些必须实时获取把这些决策集中写在Repository的实现里而不是散落在各个Presenter中。第三步是统一数据转换的入口Response转Bean的逻辑只在Repository层做禁止在View层做。行到此处数据层就慢慢恢复了秩序。但后面要注意新接口上线时不要在页面里直接联网发请求必须先问一句Repository里有没有类似的方法如果没有再新建。这个习惯能避免数据层腐烂。5.4 性能与包体积的额外提醒MVP模式的引入会增加类的数量Base层、Contract、Presenter、Repository一个页面多出三四个类整个项目的类文件数量会上升。这对编译时间、包体积都有一定影响但影响很小现代化项目不必过度担忧。真正需要注意的性能问题是重复创建对象。很多MVP框架会通过反射或注解动态创建Presenter和Repository实例反射在低端机上的性能损耗虽然不算大但也不值得在这种地方浪费。推荐的做法是用简单的工厂方法或者直接用new先保证性能再考虑更优雅的姿势。包体积方面建议对Base层做精简不要为了放一个通用头像控件就引入一个图片库不要把只在某个页面用到的工具类放到common模块。依赖库的收敛也和分层设计相关如果common模块被所有模块依赖里面引入的任何一个库都会被传到所有模块所以common的建设要克制。6. 最后聊几句实操心得我做了这么多年项目最大的感悟是架构模式不是拿来炫耀的是拿来省心的。MVP模式真正发挥作用的地方不是在代码刚写完的那一刻而是在半年后、一年后你回去改一个老需求的时候。如果那时候你发现自己打开一个页面包看到Contract、Presenter、View各司其职、逻辑清晰你会感谢当初那个坚持标准化的自己。如果你正在犹豫要不要给项目引入这套规范我的建议是先找一个小模块试试水比如登录功能、个人资料编辑这类边界清晰、不涉及复杂列表的页面。把这一两个页面按标准化分层做完比较一下改造前后改需求的体验差异再决定是否推广到全项目。不要一上来就大动干戈。最后分享一个避免项目腐烂的小习惯每次提交代码之前回头看看diff里的目录结构和包引用关系看看有没有破坏分层依赖的私货夹带进来这比你背多少次架构原则都管用。架构是靠细节维护出来的。