站在巨人的肩膀上 -- MVP 模式的理解

1. 最基本的MVP理解

链接

• 最顶层的接口

  • BasePresenter接口：提供了一个抽象方法start，约定了所有的Presenter的初始化操作都放在 start()方法中

  • BaseView接口 : T是Presenter类类型，主要是将Presenter类实例让View持有

  • 契约接口

    • 用户信息的契约接口

      • UserInfoContract 接口：提供两个内部接口，View和Presenter

        • View接口继承BaseView，针对该功能逻辑 提供不同操作UI的抽象方法
        • Presenter接口继承BasePresenter , 针对该功能逻辑提供不同操作数据的抽象方法

2. 针对MVP模式中的内存泄漏，对其进行封装

链接

• 最顶层的接口

  • IBaseView接口: 提供setPresenter函数，主要是将Presenter类实例让View持有

  • IPresenter接口 : 提供了3个抽象方法，其中的start( )方法用于存放所有的Presenter的初始化操作；一个添加View的函数; 一个销毁View的函数; 在页面显示时，Presenter持有View，在页面销毁时，调用销毁View的函数进行销毁，从而Presenter不再持有View的引用，避免内存泄漏

• 实现mvp页面和数据部分的公共抽取类

  • ModelActivity抽象类: 继承AppCompatActivity和实现IBaseView，在onCreate初始化Presenter类，在onDestroy销毁Presenter类，将初始化Presenter类的操作以抽象函数的方式提供出去，供实现类去实现

  • BasePresenter抽象类: 继承IPresenter接口： 对添加/销毁View的函数进行了实现，采用弱引用的方式存储Activity的引用

  • BaseModel抽象类: 提供了操作数据的函数

    • BaseApi接口： 对公共的接口方法进行封装，比如根据网络请求的get方式/post方式等进行封装

    • BaseApiService接口：对Retrofit中的接口进行封装，根据网络请求的get方式/post方式等进行封装

    • Network类： 对Retrofit的初始化进行了单例实现

    • BaseResponse数据类： 对接口返回的数据格式进行统一封装,比如数据格式一般是(看描述)

        { "status": "success", "code": 200, "msg": "登录成功", "data": "" }
      

• mvp三层逻辑

  • 登录逻辑的契约接口

    • LoginContract : 提供两个内部接口，View和Presenter

      • View接口主要对登录逻辑涉及到UI操作部分进行了抽象
      • Presenter接口主要对登录逻辑涉及到数据操作部分进行了抽象

    • LoginActivity: 负责UI的逻辑操作，初始化Presenter层， 调用Presenter层封装的函数(比如P调用M去请求网络)，提供UI操作的函数给Presenter层去调用(比如显示/取消进度条)

    • LoginPresenter类: 继承BasePresenter抽象类和实现LoginContract.Presenter接口，调用了Model层的网络操作函数，这些函数提供给View层去调用, Presenter相当于中介

    • LoginModel类: 继承BaseModel，封装了对LoginApi的初始化操作 & 调用LoginApi进行网络操作的函数

    • LoginApi类: 提供了访问网络操作的函数

      • Login类的内部接口LoginService：登录逻辑的retrofit接口

3. 从Google MVP Samples的思考

链接

• Activity 作为容器，装在Fragment，Fragment作为MVP的View层，activity中对View和Presenter进行了初始化

• View层主要涉及到UI操作，Presenter作为逻辑层，在View和Model之间起着中介的作用

• Model层主要涉及到数据部分，访问网络数据/数据库CURD数据都在Model层里操作

4.MVP的优点及缺陷

• 优点

  • 1.Presenter层负责业务逻辑、Model和View的中介，View层负责UI操作, Model层负责数据的操作，主要针对网络+数据库+缓存等, 使得代码分工明细

  • 2.契约类(合约类)的存在，使得View层和Presenter层的工作得以抽象化，也可将Model层的工作抽象化，整进契约类中。从契约类中各层的方法大致可看到相应功能的逻辑

  • 3.一定程度上避免Activity的内存泄漏，当然这个得妥善处理三层的引用关系

• 缺陷

  • 1.Presenter层和View层虽然逻辑清晰, 但是V层调用P层，P层执行完逻辑，再回调V层，使得函数在这两层不断往返调用，不管在开发还是维护，都一定程度上增加成本

  • 2.同上面1，函数间的调用，使得函数数量增加, Presenter臃肿，维护困难.

  • 3.数据始终是单向的，UI变动，Model也得变动，重新作用UI，在一个界面上假设有多处地方用到相同的数据，那就得改变多处地方

  • 4.P层负责业务逻辑(比如获取/存储数据等)，假设当P层前去获取数据，获取数据中~页面已经销毁，刚好这时数据响应回来，那P层将数据传输到V层时，就得做下判断，否则V层都不存在了，就很容易崩溃咯…这种现象在mvc架构中普遍存在，在MVP也未得到处理，从而衍生出AAC