漫谈MVVM(3)案例实操与框架优化

设计一个框架，除了面向对象思想的封装继承和多态之外，还需要了解设计模式，注解技术，泛型约束，反射原理，有可能还需要了解一些 数据结构来追求高效。

提取基类，M和V层其实还是一样，需要BaseModel和BaseView来约束基本行为，就算是接口是空，也必须有，空接口可以作为类型标记。

BaseModel

interface BaseModel {
}

后续的Model层子接口以及实现类，都要以它为父类：

BaseView

// View层基类，
interface BaseView {
fun showLoading()// 展示加载中
fun hideLoading()// 隐藏加载中
}

所有View层类都是它的子类：

ViewModel不用提取

至于VM层，个人习惯，一般不用接口约束，因为它不再像MVP的P层一样持有View的引用。提取不提取都问题不大。

BaseActivity/BaseFragment

MVP中，一个V，对应一个P，同样，MVVM中，一个V对应一个VM，所以，BaseActivity中，VM可以用泛型来进行约束。 抽离VM泛型之后，BaseActivity如下：

open abstract class BaseActivity : AppCompatActivity() {
/**

• 布局ID
  */
  abstract fun getLayoutId(): Int
  private fun getViewModelClz(): Class {
  return analysisClassInfo(this)
  }

fun getViewModel(): T {
return ViewModelProvider(this).get(getViewModelClz())
}

/**

• 获取对象的参数化类型,并且把第一个参数化类型的class对象返回出去
• @param obj
• @return
  */
  private fun analysisClassInfo(obj: Any): Class {
  val type = obj.javaClass.genericSuperclass //
  val param = (type as ParameterizedType?)!!.actualTypeArguments // 获取参数化类型
  return param[0] as Class
  }

/**

• 界面元素初始化
  */
  abstract fun init()
  override fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
  setContentView(getLayoutId())
  init()
  }
  }

这里有个难点：

由于通过ViewModelProvider需要传入具体的ViewModel的Class对象，所以要从BaseActivity的泛型参数中将泛型的具体类型解析出来，也就是这里的 **analysisClassInfo()**方法 . 具体的，这里不是重点，详情就略过了。

在使用了这个BaseActivity之后，LoginActivity就变成了如下模样：

BaseFragment也是类似：

open abstract class BaseFragment : Fragment() {
/**

• 布局ID
  */
  abstract fun getLayoutId(): Int

private fun getViewModelClz(): Class {
return analysisClassInfo(this)
}

fun getViewModel(): T {
return ViewModelProvider(this).get(getViewModelClz())
}

/**

• 获取对象的参数化类型,并且把第一个参数化类型的class对象返回出去
• @param obj
• @return
  */
  private fun analysisClassInfo(obj: Any): Class {
  val type = obj.javaClass.genericSuperclass //
  val param = (type as ParameterizedType?)!!.actualTypeArguments // 获取参数化类型
  return param[0] as Class
  }

/**

• 界面元素初始化
  */
  abstract fun init()

override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
return inflater.inflate(getLayoutId(), container, false)
}

/**

• onViewCreated之后，才能用kotlin的viewId去操作view
  */
  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
  init()
  }
  }

使用BaseFragment也是一样：

基类统一管理

将基类移动到基础lib模块中，

解决Bug,提升兼容性和使用体验

Demo只是Demo，实际使用MVVM的过程中，还会遇到不可预知的问题。

LiveData成员属性膨胀

一般我们认定，一个Activity/Fragment对应一个ViewModel，但是一个ViewModel中可以认定多个数据源，也就是LiveData, 一旦业务代码积累过多，就可能会出现一个ViewModel中N个liveData成员属性 ：

class LoginActivityViewModel : ViewModel() {
private val userLiveData: MutableLiveData by lazy { MutableLiveData() }
private val noticeLiveData: SingleLiveData by lazy { SingleLiveData() }

// 业务积累
private val noticeLiveData2: SingleLiveData2 by lazy { SingleLiveData() }
private val noticeLiveData3: SingleLiveData3 by lazy { SingleLiveData() }
private val noticeLiveData4: SingleLiveData4 by lazy { SingleLiveData() }
private val noticeLiveData5: SingleLiveData5 by lazy { SingleLiveData() }
private val noticeLiveData6: SingleLiveData6 by lazy { SingleLiveData() }
private val noticeLiveData7: SingleLiveData7 by lazy { SingleLiveData() }
//…
}

而且多个ViewModel还有可能公用同一个类型的 LiveData，比如有一个Fragment也在用 NoticeLiveData:

class NoticeFragmentViewModel : ViewModel() {
val noticeLiveData: SingleLiveData by lazy { SingleLiveData() }
}

那每个地方都去写一遍，并不是最理想的写法。

解决方案：提炼出LiveDataHolder类，让每一个ViewModel子类都拥有一个自己的LiveDataHolder对象，从holder中去获取LiveData, 去执行数据的发送和监听.

import androidx.lifecycle.MutableLiveData

// 三种LiveData的类别
enum class EventType {
SINGLE,// 单次通知
ALIVE,// 只通知存活的lifeCycleOwner
DEFAULT// 默认，粘性消息
}

/**

• 这个函数是为了简化一个ViewModel中存在N个LiveData定义的情况，其实只需要一个类，去获取就行了
• 每个ViewModel应该有自己的LiveDataHolder，应该是每一个ViewModel都有一个LiveDataHolder, 用来获取LiveData
  */
  class LiveDataHolder {

companion object {
fun get(): LiveDataHolder {
return LiveDataHolder()
}
}

private val map: HashMap<Class<out Any?>, MutableList<MutableLiveData<out Any?>>> = HashMap()
fun getLiveData(key: Class): MutableLiveData {
return getLiveData(key, EventType.DEFAULT)
}

/**
*

• 获得一个指定的LiveData
• @param key 指定返回值类型
• @param eventType 消息通道的类别
• @see EventType
  */
  fun getLiveData(key: Class, eventType: EventType): MutableLiveData {
  val liveDataClz: Class<MutableLiveData> = when (eventType) {
  EventType.SINGLE -> {
  SingleLiveData().javaClass
  }
  EventType.ALIVE -> {
  AliveOwnerMutableLiveData().javaClass
  }
  else -> {
  MutableLiveData().javaClass
  }
  }

if (map[key] == null) {
map[key] = ArrayList()
}
val currentList = map[key]!!
for (a in currentList) {
if (liveDataClz.isInstance(a)) {
return a as MutableLiveData
}
}
val newLiveData = liveDataClz.getConstructor().newInstance()
currentList.add(newLiveData)
return newLiveData
}
}

为了防止在每一个ViewModel子类中都去定义一次LiveDataHolder，我把它提炼到 ViewModel的基类中去：

// ViewModel基类
abstract class BaseViewModel : ViewModel() {
// 一个ViewModel可以存在多个LiveData，所以使用LiveDataHolder管理所有的LiveData
val liveDataHolder = LiveDataHolder.get()
}

经过此次优化，所有ViewModel子类中不再需要去存放LiveData成员属性，要使用的时候直接如下这样写

class LoginActivityViewModel : BaseViewModel() {

/**

• 触发业务
  */
  fun getMsg() {
  val noticeLiveData =
  liveDataHolder.getLiveData(String::class.java)
  noticeLiveData.postValue(NoticeModel().getNotice())
  }

/**

• 监听业务
• 为了不向外界暴露LiveData成员,提供一个注册监听的函数
  */
  fun observerGetMsg(lifecycleOwner: LifecycleOwner, observer: Observer) {
  val noticeLiveData =
  liveDataHolder.getLiveData(String::class.java)
  noticeLiveData.observe(lifecycleOwner, observer)
  }

/**

• 触发登录业务
  */
  fun doLogin(userName: String, password: String) {
  // 发送网络请求，并且执行回调
  UserModel().login(userName, password, object : HttpCallback {
  override fun onSuccess(result: UserBean?) {
  liveDataHolder.getLiveData(UserBean::class.java, EventType.ALIVE).postValue(result)
  }

override fun onFailure(e: Exception?) {
liveDataHolder.getLiveData(UserBean::class.java, EventType.ALIVE)
.postValue(UserBean())
}
})
}

/**

• 监听登录业务
  */
  fun observerDoLogin(lifecycleOwner: LifecycleOwner, observer: Observer) {
  liveDataHolder.getLiveData(UserBean::class.java, EventType.ALIVE)
  .observe(lifecycleOwner, observer)
  }

}

多个Fragment公用所在Activity的ViewModel

同一个Activity上，可能多个Fragment都会共用Activity的viewModel来达到数据同步的目的。如果按照常规方式，我们只能进行类型强转，然后调用 activity的viewModel的方法。

但是这种写法耦合性很高，不方便后期维护。

解决方案：使用泛型，改变一下BaseFragment的泛型约束，改变之后如下：

之后，使用BaseFragment的地方就应该写成如下这样：

如果存在另外一个相同的Fragment，也在使用父Activity的ViewModel，他们就能够达成数据同步，如下图这样：

效果：

MVVM优缺点

优点

• 屏幕旋转时，界面数据不会重建

在ViewModel出现之前，屏幕的旋转，会导致Activity/Fragment的完全重建，所牵涉到的数据也会重新创建，如果页面复杂，可能会导致卡顿掉帧等问题。但是使用ViewModel作为数据模型层之后，屏幕旋转并不会重新创建数据，而是直接绑定已有ViewModel.

• MVP的接口膨胀问题解决

MVVM是由MVP进化而来，进化的过程只做了一件事，数据驱动。当然，在ViewModel结合DataBinding时代，也就是LiveData出世之前，就已经形成了由数据驱动UI的机制，甚至可以进行反向驱动，由UI变动来驱动数据变动。在LiveData，LiveCycle出世之后，由数据驱动UI这一点仍然保持，再也不用写MVP那样无限膨胀的P接口了。

• 杜绝内存泄漏

之前MVP的由P层来驱动UI，以及调用业务，P层必须持有Activity/Fragment的引用，可能会导致内存泄露，开发者必须在适当的时机释放引用（比如本文使用LifeCycle注解接口，或者手段）。但是MVVM架构中，DataBinding和LiveData都集成了 lifeCycleOwner监听机制，如果耗时任务执行完毕之时，Activity/Fragment已经不处于STARTED状态，并不会去驱动UI。

缺点

• DataBinding时代混合代码难看，难以调试

可能曾经一段时间DataBinding兴起时，数据的单向双向绑定，确实让开发体验提升了不少。但是DataBinding所引起的负面效果，xml中的粘性代码，AndroidStudio编译偶尔会由于DataBinding出现故障，程序出错之后调试也更加困难。但是有一说一，使用LiveData之后，这个问题可以不用管，因为我根本就不会再去考虑DataBinding。

• 学习成本较高

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

【Android 详细知识点思维脑图（技能树）】

其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。

虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

薪资真的特别高（钱多也不一定能找到合适的），所以努力让自己成为高级工程师才是最重要的。

这里附上上述的面试题相关的几十套字节跳动，京东，小米，腾讯、头条、阿里、美团等公司19年的面试题。把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

由于篇幅有限，这里以图片的形式给大家展示一小部分。

[外链图片转存中…(img-qMSEprm3-1712471182963)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！