为什么要使用MVP架构

1. MVC的弊端:
   理论上 布局文件属于视图层;java web基本处于mvc 层次展现更加丰盈;
   在android 上 采用了类似spi机制的方式 通过反射加载布局视图;
   在大型、长期、的项目中MVP架构更有优势
2. Jetpack 是在MVVM用的吗?
   并不是的,Jectpack是2018年google-IO出的,是一个为了开发App一整套的解决方案。
   为了解决开发常用解决问题方案  并不是专属于MVVM的。
   和MVVM紧密的是:Databinding库:数据驱动UI模型
为什么要使用MVP架构_第1张图片

3.MVP核心思想:
   相对于MVC,把原来的UI逻辑 抽象成View接口,原来的业务逻辑就抽象为Presenter接口,原来的Model 还是原来的Model。
View层:通过“View接口”来处理原来的“UI逻辑”;
               通过接口回调方法 一般在一个线程中调用
Model层:获取数据
Presenter表示层:将Model数据通过接口回调给调用方(Activity/Fragment)
为什么要使用MVP架构_第2张图片

思考:new Presenter(this)时候  将activity/fragment实例将给引用方 会有内存泄漏的风险。
比如:在过程中 打进来电话等 
方案1:如果有退出,将引用打断掉; 直接WeakReference 弱引用的方式避免内存泄漏; 
          弊端:没有及时性 过于依赖GC
方案2:绑定和解绑通过Api方式实现;为什么要使用MVP架构_第3张图片为什么要使用MVP架构_第4张图片

内存泄漏问题 打开Profiler查看;

在activity销毁 我们没有处理过fragment的销毁;
是因为 framwok层 
attach(). --->onAttach()
deatch()--->onDeatch()

 为什么要使用MVP架构_第5张图片

 将Presenter 持有View Model层实例的 通用代码 做基类封装处理:
为什么要使用MVP架构_第6张图片
通过泛型代码--- 获取View层实例 :
在attachView方法  通过弱引用Weakrefence 持有View层
在deatchView方法,将持有的View层实例 释放  --view=null;
目的:重复代码 向上抽离一层 做基类。


⭐️ 升级版MVP模式:
在Presenter和Model层解耦 之间做一条总线 
比如:eventbus3  rxbuus livedatabus等
dagger2 , hint
为什么要使用MVP架构_第7张图片

 在App架构设计时候 
1.新技术运用
2.APP的拓展和维护  重构 、三方框架 、SDK版本、协议切换
主流大厂会做:
1.启动任务框架
2.异常处理框架
3.日志处理框架 
 ...APM处理
    数据存储
    Jetpack库...
比如 QQ 微信不怎么闪退 :就是异常处理框架 崩溃处理框架的功劳

大厂招高工的原因:架构和结构的设计  搭架子  代码质量

技术提升的方式:
1、需要努力
2、需要方向正确
3、科学的方法
人生:
1、时间管理
2、学习方法    有人带、练习 、实战
3、分享
为什么要使用MVP架构_第8张图片为什么要使用MVP架构_第9张图片

要去写  手写十几套架构出来 才能理解架构的含义  不能在岸上学游泳

 

3.Jetpack 
  Lifecycle、ViewModel、LiveData 是Jetpack的基础 ,会在其他框架中反复使用

为什么要使用MVP架构_第10张图片

生命周期监听:
 在JetPack前 :
    在类里  定义一个接口 在生命周期方法里,会高耦合 内存泄漏风险巨大为什么要使用MVP架构_第11张图片


2018谷歌推出 Lifecycler  被观察者 
 任何类都可以当作一个观察者  观察生命周期变化 
为什么要使用MVP架构_第12张图片

 被观察者变化--->通知观察者

实现:被观察者实现 Lifecycler接口 为什么要使用MVP架构_第13张图片

 为什么要使用MVP架构_第14张图片

 Lifecycle是怎么实现的?
 

getLifecycle().addObserver(mPresenter);
代码只有一行  内部都是使用注解来实现的 

addObServer是将表示层presenter添加到Observer

 @MainThread
    public abstract void addObserver(@NonNull LifecycleObserver observer);

为什么要使用MVP架构_第15张图片

有一个包装类 observer包装进去 
observer有一个键 
mObserverMap 存放了所有的观察者对象   :表示可以有多个观察者 监听同一个Activity

一般情况下 从一个Map里去get一些数据 十有八九都是缓存

为什么要使用MVP架构_第16张图片

 为什么要使用MVP架构_第17张图片

 为什么要使用MVP架构_第18张图片

将传递进来的对象的  对应类的 calss对象传进去了
接着往下:getInfo
为什么要使用MVP架构_第19张图片
 

接着createInfo 
为什么要使用MVP架构_第20张图片

反射拿到 所有对象api。注解的所有方法对象
遍历 这个数组对象。包含 所有含有注解的方法 api
比如:
为什么要使用MVP架构_第21张图片

 为什么要使用MVP架构_第22张图片

判断个数 
 赋值类型   对应 0 1 2 其他就抛异常 

下面 会用MethodRefence 做个包装。
接着把mathodRefence方法 给到 verifyAndPutHandler
为什么要使用MVP架构_第23张图片

 verifyputhandler 做验证 
接下来 
为什么要使用MVP架构_第24张图片

 放在CallbackInfo里去 做返回return

oInfo:存放了所有有注解的方法 

所以:
 

getLifecycle().addObserver(mPresenter);

这行代码 就表示完成初始化  接下来看发通知 如何发的通知:

时序图

这部分有 状态同步的过程  
为什么要使用MVP架构_第25张图片

 Activity生命周期发生变化:
走到父类         ComponentActivity
为什么要使用MVP架构_第26张图片

如果要注入activity
接下来看          injectIfNeededIn
为什么要使用MVP架构_第27张图片

此时,熟悉的代码就出现了 
添加Fragment的步骤

Activity和Fragment的处理
生成子Fragment。好处就是 activity生命周期发生变化 也会调用Fragment生命周期方法

dispatch(XXXEvent) 分发生命周期

流程为 :
注解+反射 :
为什么要使用MVP架构_第28张图片
 

 
源码是提升技术最好的方法,没有之一。
从源码中分析 最牛的技术,归为己用  
看懂一部分源码 就能看懂新的 和 已有的库的原理 和解决方案。

 

如Rxjava 基于观察者模式的设计 
1.典型的通过观察者模式来完成 事件的发送。【红色】
2.操作符   事件发送的能力抽离出来。目的为了适配其他的操作符 可以自定义自己的事件发送
左下
3.线程切换相关的,最右两个 
4.Map操作 下


 

为什么要使用MVP架构_第29张图片

 

 为什么要使用MVP架构_第30张图片

这些组成一个装饰器模式,解决类爆炸的问题。

Framwork层源码
一些三方框架源码  
一线互联网公司项目源码 都需要去看  去学 才能做技术提升 ;
为什么要使用MVP架构_第31张图片为什么要使用MVP架构_第32张图片

 

 Java基础:注解 反射 泛型  JVM 并发模型 IO流 序列化 ;     内存问题必备
平台基础:Framework层(内核层):AMS PMS WMS  Handler Binder  ClassLoader  四大组件相关的原理  View UI相关  事件冲突 滑动冲突原理 VIew ViewGroup源码
通用基础:数据结构 算法 设计模式 不限语言都需要掌握 无底洞...


框架设计与维护:
手写Okhttp 
手写Glide 
手写组件化
手写插件化
手写热修复............
 

你可能感兴趣的:(总结,android,架构)