2024年最新Android 使用 MvRx+Epoxy 构建 MVVM 应用，2024年最新15个经典面试问题及答案英语

最新推荐文章于 2024-08-13 08:53:47 发布

2401_84520271

最新推荐文章于 2024-08-13 08:53:47 发布

阅读量875

点赞数 22

分类专栏：程序员文章标签： android 面试职场和发展

本文链接：https://blog.csdn.net/2401_84520271/article/details/138561437

版权

程序员专栏收录该内容

185 篇文章 0 订阅

订阅专栏

总结

开发是面向对象。我们找工作应该更多是面向面试。哪怕进大厂真的只是去宁螺丝，但你要进去得先学会面试的时候造飞机不是么？

作者13年java转Android开发，在小厂待过，也去过华为，OPPO等，去年四月份进了阿里一直到现在。等大厂待过也面试过很多人。深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

相信它会给大家带来很多收获：

960页全网最全Android开发笔记

资料太多，全部展示会影响篇幅，暂时就先列举这些部分截图

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

背景

在 Android 开发世界里面，大家对于MVVM等架构设计都比较熟悉了，大多数项目中会使用 RxJava 来搭建 MVVM 架构。本文介绍Airbnb开源的 MvRx 和 Epoxy框架，主要包含如下内容：

MvRx 和 Epoxy 框架用法
MvRx 如何初始化 ViewModel 和 State
MvRx 如何实现数据和视图的关联 (修改 State 自动触发视图重绘)
Epoxy 如何实现 diff 更新

开源的世界丰富多彩，笔者希望能够打开一扇窗，让我们从更多的视角来一窥响应式编程框架之美。

MvRx+Epoxy基础介绍

简介

*MvRx (ModelView ReactiveX, pronounced mavericks) is the Android framework from Airbnb that we use for nearly all product development at Airbnb.When we began creating MvRx, our goal was not to create yet another architecture pattern for Airbnb, it was to make building products easier, faster, and more fun. All of our decisions have built on that. We believe that for MvRx to be successful, it must be effective for building everything from the simplest of screens to the most complex in our app.

Epoxy (iˈpäksē) is an Android library for building complex screens in a RecyclerView. We developed Epoxy at Airbnb to simplify the process of working with RecyclerViews, and to add the missing functionality we needed. We now use Epoxy for most of the main screens in our app and it has improved our developer experience greatly.

这两个库均出自与 airbnb，上面是摘自github 中的项目介绍：

MvRx 是 airbnb 构筑的一个应用架构，几乎用在了 airbnb 的全线产品上
Epoxy 主要帮助构建复杂的多 viewType 的 Recyclerview

可以看出，MvRx 和 Epoxy 的设计初衷均是为简化、提高开发效率的 (easier, faster, more fun)

设计理念

MvRx 综合运用了以下技术和概念：

Kotlin
Android Architecture Components
RxJava
React (conceptually)
Epoxy (optional)

实际上，MvRx 和 Epoxy 是可以分开使用的，在 MvRx 的架构说明中，Epoxy 也是可选的。MvRx 在 google architecture 的基础上引入了 React 的一系列概念，但更加偏向于数据层的响应式设计。单独使用 MvRx，数据变化后，视图还需要自己去更新，这个更新往往又是命令式的。 (在 React 中，数据变化 ➡️ diff 计算视图变化 ➡️ 重新渲染，都是由框架自动执行的，开发者的任务只是描述视图)

Epoxy 被描述成是 RecyclerView 的辅助工具。airbnb 认为 adapter 配置 item 的方式比较呆板和混乱，不能很好支持他们的一些复杂场景如：viewType、pagination、tablet、item animations，于是用了一种新的方式来描述列表。结合 epoxy 可以实现视图层的响应式，开发者只描述视图及和数据的关系，diff 和更新由框架完成。

MvRx+Epoxy，结合 kotlin 的语法糖，写出来的代码非常像 React。这样开发出来的应用有如下特征：

声明式 UI
响应式架构（MVVM）

使用方式

核心概念

State

MvRxState 包含渲染屏幕所需的所有数据，State 是不可变的，它的实现类必须是一个 immutable Kotlin data class，只有 ViewModel 能修改 State，修改 State 时应该调用 kotlin 数据类的 copy 方法，创建一个新的 State 对象，State 改变会触发 View 的 invalidate() 方法，从而进行界面重绘。

ViewModel

MvRxViewModel 完全继承自 Google 应用架构中的 ViewModel，不同的是，MvRxViewModel 包含一个 State 而不是 LiveData，View 只能观察 State 的变化。创建 ViewModel 时必须传入一个 initialState (View 的初始状态)。

View

一般是继承自 BaseMvRxFragment 的 Fragment，BaseMvRxFragment 实现了 MvRxView 接口，这个接口有一个 invalidate() 方法，每当 State 发生变化时 invalidate() 方法都会被调用。View 的状态是短暂的，需要重写 invalidate() 来不断更新视图，为了更好的优化，可以判断若 State 值与上次相同，则不执行更新操作，或者使用 epoxy (自动 diff)。View 既可以观察整个 State 的变化，也可以只观察 State 中的某个或某几个属性的变化。

Async

如果数据是来自网络的，需要描述加载过程，这类数据可以用 Async。Async 是一个 sealed class，有四个子类：Uninitialized、Loading、Success、Fail。MvRxViewModel 对 Observable 提供了一个扩展函数 execute，用于将 Observable 转换成 Async，当调用 Observable.execute() 时，它将自动被 subscribe，然后 emit Async 事件。

Simple Example

 //1.抽象数据State
data class HelloWorldState(val title: String = "Hello World") : MvRxState

 //2. 继承 MvRxViewModel，实现 ViewModel
class HelloWorldViewModel(initialState: HelloWorldState) : MvRxViewModel<HelloWorldState>(initialState){
    fun getMoreExcited() = setState { copy(title = "$title!") }
}

 //3. 继承 BaseMvRxFragment，重写 invalidate
class HelloWorldFragment : BaseMvRxFragment() {
    private val viewModel: HelloWorldViewModel by fragmentViewModel()
    private lateinit var marquee: Marquee

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? =
        inflater.inflate(R.layout.fragment_hello_world, container, false).apply {
 findViewById<Toolbar>(R.id.toolbar).setupWithNavController(findNavController())
            marquee = findViewById(R.id.marquee)
    }

 override fun invalidate() = withState(viewModel) { state->
     marquee.setTitle(state.title)
     marquee.setOnClickListener { viewModel.getMoreExcited() }
     }
}

1、抽象数据 State

State 必须是一个 immutable kotlin data class

2、继承 MvRxViewModel，实现 ViewModel

两种方式，定义一个 ViewModel：

ViewModel 不需要额外参数，如 example
ViewModel 包含有除 initialState 之外的其它构造参数，则需要实现工厂方法

// 第一个参数必须是 initialState

class HelloWorldViewModel(
        initialState: HelloWorldState,
        private val dadJokeService: DadJokeService
) : MvRxViewModel<HelloWorldState>(initialState) {

    fun getMoreExcited() = setState { copy(title = "$title!") }
 // 定义一个伴生对象，实现 MvRxViewModelFactory 接口

 companion object : MvRxViewModelFactory<HelloWorldViewModel, HelloWorldState> {
        override fun create(viewModelContext: ViewModelContext, state: HelloWorldState): HelloWorldViewModel {
            val service: DadJokeService by viewModelContext.activity.inject()
            return HelloWorldViewModel(state, service)
        }
    }
}

定义好后，MvRx 给 Fragment 提供了三种扩展函数，用于获取：

by fragmentViewModel()：Fragment 周期的 ViewModel
by activityViewModel()：Activity 周期的 ViewModel，主要用在不同 Fragment 之间共享 State
by existViewModel()：Activity 周期的 ViewModel，但必须已经存在，若不存在则会抛出异常。主要用在有前置数据依赖的情况，如多个 Fragment 协作时，依赖前一个 Fragment 设置的数据

同时注意：

ViewModel 构造函数必须传入一个 initialState
只有 ViewModel 能修改 State，修改时应该调用 kotlin 数据类的 copy 方法创建一个新的对象

3、继承 BaseMvRxFragment，重写 invalidate

通过工厂方法 withState() 得到 State 值，重新绘制视图

引入Epoxy

上述例子只使用了 MvRx。接下来我们引入 Epoxy 库，Fragment 需要进行一些改造。（State 和 ViewModel 部分完全一样）

首先，介绍 Epoxy 的两个主要组件：

EpoxyModel：描述（某个Item）视图长什么样
EpoxyController：用于控制哪些 EpoxyModel 要展示到 RecyclerView 上，以及展示在什么位置

1、创建 EpoxyModel

实际上，EpoxyModel 是框架自动生成的。我们只需要自定义 View，并标上相关注解，Epoxy 就会自动生成一个原类名加上 Model_ 后缀的类：

//1.自定义View，标上注解
@ModelView(autoLayout = ModelView.Size.MATCH_WIDTH_WRAP_HEIGHT)
class Marquee @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : LinearLayout(context, attrs, defStyleAttr) {
    private val titleView: TextView
    private val subtitleView: TextView

    init {
        inflate(context, R.layout.marquee, this)
        titleView = findViewById(R.id.title)
        subtitleView = findViewById(R.id.subtitle)
        orientation = VERTICAL
 }

    @ModelProp 
    fun setImgUrl(imgUrl: String) { 
        //show image with you own way 
    }

    @TextProp
    fun setTitle(title: CharSequence) {
        titleView.text = title
    }

    @TextProp
    fun setSubtitle(subtitle: CharSequence?) {
         subtitleView.visibility = if (subtitle.isNullOrBlank()) View.GONE else View.VISIBLE
         subtitleView.text = subtitle
    }

    @CallbackProp
    fun setClickListener(clickListener: OnClickListener?) {
        setOnClickListener(clickListener)
    }
}

@ModelView 标注类，autoLayout 描述该 item 加入到 RecyclerView 时的宽高
@ModelProp 标注方法，只能有一个参数。使用该注解，生成的 EpoxyModel 中将会有相应的字段
@TextProp 标注方法，参数类型必须为 CharSequence。当字段为字符串时，这个注解会更加方便，生成的 EpoxyModel 会包含若干重载方法，方便直接使用 Android String 资源
@CallbackProp 标注方法，参数类型是一个回调接口。回调接口不同于普通字段，它们不会影响View 显示，并且需要在 item 滚出屏幕时解绑（设为 null 防止内存泄漏），这些由该注解处理

2、在 Controller 中使用 EpoxyModel

上述会生成一个 MarqueeModel_ 类，在 buildModels() 中使用：

class HelloWorldEpoxyFragment : BaseFragment() {
    private val viewModel: HelloWorldViewModel by fragmentViewModel()

    //2.创建 epoxyController，重写 buildModels() 方法
    override fun epoxyController() = simpleController(viewModel) { state ->
        //这里配置的 item 会按顺序展示在 RecyclerView 中
        marquee {
            id("marquee")    //一定需要提供id，用于diff。否则会crash
            title(state.title)
            clickListener { _ -> viewModel.getMoreExcited() }
         }
     }
}

3、集成到 RecyclerView

最后修改 Fragment，在收到 invalidate() 通知时，调用 requestModelBuild() 来重绘界面：

 //3.数据更新时，触发重绘
override fun invalidate() = recyclerView.requestModelBuild()

可以看出，引入 Epoxy 后，RecyclerView 的开发方式不再是编写 Adapter，而是变成定义一个个 EpoxyModel，界面被拆分成一个个 EpoxyModel 后，元素的复用也变得很简单，整个界面的开发就跟搭积木一样。

实现原理

MvRx

定义与获取ViewModel

by fragmentViewModel()

注意到获取 ViewModel 时候，我们只是做了定义，并没有创建 initialState 和 ViewModel，这一步是框架帮我们做的。

按照 MvRx 规范，只能通过框架提供的 activityViewModel() / fragmentViewModel() / existingViewModel() 来获取 ViewModel。通过这几种方式获取 ViewModel，MvRx 会帮我们完成：

返回一个 Lazy 子类，在宿主 onCreate 时触发 ViewModel 的创建
反射构造 initialState 和 ViewModel
调用 ViewModel subscribe() 方法订阅 State 变更，若 State 改变则回调 View 的 invalidate() 方法

下面以 by fragmentViewModel() 为例，主要关注如何获取 initialState，并创建 ViewModel 返回的。

创建 ViewModel 的顺序如下：

反射执行 MvRxViewModel 的 Companion 对象的 create() 方法创建
若失败，则反射获取 MvRxViewModel 构造函数创建，要求 ViewModel 只能有一个构造函数，且该构造函数只能有一个 MvRxState 类型的参数（initialState）

创建 initialState 的顺序如下：

反射执行 MvRxViewModel 的 Companion 对象的 initialState() 方法创建
若失败，则反射获取 State 的含参构造函数创建，要求该构造函数只能有一个 Parcel 类型的参数
若失败，则反射获取 State 的默认无参构造函数创建

最后，注意到创建好 ViewModel 后，还用 lifecycleAwareLazy() 包裹了一下：

class lifecycleAwareLazy<out T>(private val owner: LifecycleOwner, initializer: () -> T) : Lazy<T>, Serializable {
    private var initializer: (() -> T)? = initializer
    
    @Volatile
    @SuppressWarnings("Detekt.VariableNaming")
    private var _value: Any? = UninitializedValue
    // final field is required to enable safe publication of constructed instance
    private val lock = this

    init {
        owner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
            fun onStart() {
                if (!isInitialized()) value
                owner.lifecycle.removeObserver(this)
            }
        })
    }
 }

lifecycleAwareLazy 是一个 Lazy 实现类，这里的 Lazy 并不是指到了用到 ViewModel 时候才创建，从实现中可以看出它监听了宿主的生命周期，在宿主 onCreate() 时就已经将 ViewModel 创建出来了。这样做是为了尽快执行一些初始数据的逻辑，如在 ViewModel init() 中请求网络。即 ViewModel 的 init() 在宿主 onCreate 时就开始执行了。

修改数据

fun setState(reducer: S.() -> S)

fun Observable.execute(stateReducer: S.(Async) -> S)

提个问题🤔：

setState/execute 的参数是为什么是一个 lambda？
execute 如何将 Observable 转换成 Async？

在 MvRxViewModel 中，更新 State 的两个主要方法是 setState 和 execute，这两个方法的参数都是一个 lambda（State 上的扩展函数）。execute 是 Observable 的一个扩展函数，在逻辑处理时候经常会用到 Rxjava，execute 能方便的将 Observable 转成 Async 对象。execute 调用的其实也是 setState。

//BaseMvRxViewModel.kt

protected fun setState(reducer: S.() -> S) {
    if (debugMode) {
        //...
 } else {
        stateStore.set(reducer)
    }
}

可以看出，setState 仅是简单转发调用了 MvRxStateStore 的 set() 方法，接下来这个 lambda block 会被存储到一个队列中等待执行。队列中任务的调度涉及一个双队列的设计。

双队列设计

//RealMvRxStateStore.kt
class RealMvRxStateStore<S : Any>(initialState: S) : MvRxStateStore<S> {
    // State 存储在 Observable 对象里
    private val subject: BehaviorSubject<S> = BehaviorSubject.createDefault(initialState)

    /**
 * A subject that is used to flush the setState and getState queue. The value emitted on the subject is
 * not used. It is only used as a signal to flush the queues.
 */

 private val flushQueueSubject = BehaviorSubject.create<Unit>()
    private val jobs = Jobs<S>()

    init {
        // 所有 set/get 任务都在同一条后台线程中处理
        flushQueueSubject.observeOn(Schedulers.newThread())
        // We don't want race conditions with setting the state on multiple background threads
        // simultaneously in which two state reducers get the same initial state to reduce.
            .subscribe( { _ -> flushQueues()  } , ::handleError)
        // Ensure that state updates don't get processes after dispose.
            .registerDisposable()

    }


    // 获取 State
 override fun get(block: (S) -> Unit) {
        jobs.enqueueGetStateBlock(block)
        flushQueueSubject.onNext(Unit)
    }


    // 更新 State
 override fun set(stateReducer: S.() -> S) {
        jobs.enqueueSetStateBlock(stateReducer)
        flushQueueSubject.onNext(Unit)
    }

 private class Jobs<S> {
        // 双队列设计，set/get 任务分别存储在两个队列中
        private val getStateQueue = LinkedList<(state: S) -> Unit>()
        private var setStateQueue = LinkedList<S.() -> S>()

        @Synchronized
        fun enqueueGetStateBlock(block: (state: S) -> Unit) {
            getStateQueue.add(block)
        }

        @Synchronized
        fun enqueueSetStateBlock(block: S.() -> S) {
            setStateQueue.add(block)
        }

        @Synchronized
        fun dequeueGetStateBlock(): ((state: S) -> Unit)? {
            return getStateQueue.poll()
        }

        @Synchronized
        fun dequeueAllSetStateBlocks(): List<(S.() -> S)>? {

            // do not allocate empty queue for no-op flushes
            if (setStateQueue.isEmpty()) return null

            val queue = setStateQueue
            setStateQueue = LinkedList()
            
            return queue
        }
    }

 private tailrec fun flushQueues() {
        // 1.将 set 任务全部执行完
        flushSetStateQueue() 

        // 2.执行第一个 get 任务 
        val block = jobs.dequeueGetStateBlock() ?: return
        
        block(state)
        // 3.再次执行（防止 block 中又调用了 set 任务） 
        flushQueues()
    }

    private fun flushSetStateQueue() {
        val blocks = jobs.dequeueAllSetStateBlocks() ?: return

        for (block in blocks) {
            val newState = state.block()
            // do not coalesce state change. it's more expected to notify for every state change.
            if (newState != state) {
                // 更新 State，触发变更回调
                subject.onNext(newState)
            }
        }
    }

}

可以看出，更新和获取 State 方法传入的参数均是一个 lambda block，这些 block 最后都会运行在一条后台线程中（解决并发修改 State 问题）。但在调度这些 block 的顺序上，MvRx 设计了双队列的任务调度算法，使得 setState block 的优先级高于 getState block。

在双队列中，setStateQueue 有更高的优先级，每次从 getStateQueue 中取任务前需要先将 setStateQueue 中的任务全部执行完。这么设计主要解决一个竞争问题，即 getState block 中又调用了 setState block。

考虑这样一段代码：

getState { state ->

     if (state.isLoading) return
     setState { state ->
     state.copy(isLoading = true)
     }

 // make a network call
 }

如果连续执行两次，可能会发出两次网络请求，但却是不符合本意的。这里原意是想：第一次执行判断状态为非 Loading，将值设为 Loading，接着请求网络；第二次执行判断已经 Loading 了就 return。

为了便于分析，把这两次调用简化如下：

getStateA {
    setStateA {}
}

getStateB {
    setStateB {}
}

如果只有一个队列，那么 block 的执行顺序和插入顺序一致：

getStateA -> getStateB -> setStateA -> setStateB（不符合原意）

但如果是双队列的设计：

两个 getState block 都插入队列后

setStateQueue: []
getStateQueue: [A, B]

第一个 getState block 执行完后

setStateQueue: [A]
getStateQueue: [B]

因为 setStateQueue 优先级更高，先执行 setStateA

setStateQueue: []
getStateQueue: [B]

最后执行 setStateB

setStateQueue: []
getStateQueue: []

最终 block 的执行顺序会是：

getStateA->setStateA->getStateB ->setStateB（符合原意）

渲染回调

fun invalidate()

从上小节可知，State 并不是简单以成员变量方式存放的，State 存在 BehaviorSubject 对象中。BehaviorSubject 继承自 Subject，Subject 同时实现了 Observable 和 Observer 接口，意味着 Subject 即可以是观察者，也可以是被观察者。在 MvRxStateStore 中，State 值一旦更新，就会触发观察者收到变更通知。

而注册观察者的地方，就在最初获取 ViewModel 时候：

inline fun <T, reified VM : BaseMvRxViewModel<S>, reified S : MvRxState> T.fragmentViewModel(
    viewModelClass: KClass<VM> = VM::class,
    crossinline keyFactory: () -> String = { viewModelClass.java.name }
) where T : Fragment, T : MvRxView = lifecycleAwareLazy(this) {

 MvRxViewModelProvider.get(
        viewModelClass.java,
        S::class.java,
        FragmentViewModelContext(this.requireActivity(), _fragmentArgsProvider(), this),
        keyFactory()
    ).apply {

        // 在创建 ViewModel 后，直接向其 State Observable 注册了变更监听
        subscribe(this@fragmentViewModel, subscriber = { postInvalidate() } ) }

 }

在创建 ViewModel 后，顺带就直接向这个 BehaviorSubject 注册了观察者，一旦 State 变化就回调 MvRxView. postInvalidate() 方法，最终触发 invalidate() 重新渲染视图。

提个问题🤔：

在向 LiveData 注册监听时是能自动感知 LifeCycleOwner 生命周期的，如果宿主已经不再处于活跃状态了，则观察者不会收到变更通知。这里注册的是 Observer，是否会感知到生命周期？若是则是怎样实现的呢？

小结

上述过程时序图：

CleanShot 2022-04-01 at 17.49.27@2x.png

当 Fragment onCreate() 时，会创建出 MvRxViewModel 实例
当 ViewModel 读取或修改数据时，这些操作被放到了双队列中，在一条后台线程中串行处理。双队列中写操作比读操作优先级更高，在执行读操作前总是得先把所有写操作执行完
State 是一个可观察对象，ViewModel 观察着 State，每当 State 变化就会通知 ViewModel，ViewModel 回调 Fragment invalidate() ，触发视图重新刷新