MVP 架构最终审判 —— MVP 解决了哪些痛点，又引入了哪些坑？（二）

复杂度

Android 架构演进系列是围绕着复杂度向前推进的。

软件的首要技术使命是“管理复杂度” —— 《代码大全》

因为低复杂度才能降低理解成本和沟通难度，提升应对变更的灵活性，减少重复劳动，最终提高代码质量。

架构的目的在于“将复杂度分层”

复杂度为什么要被分层？

若不分层，复杂度会在同一层次展开，这样就太 ... 复杂了。

举一个复杂度不分层的例子：

小李：“你会做什么菜？”

小明：“我会做用土鸡生的土鸡蛋配上切片的番茄，放点油盐，开火翻炒的番茄炒蛋。”

听了小明的回答，你还会和他做朋友吗？

小明把不同层次的复杂度以不恰当的方式揉搓在一起，让人感觉是一种由“没有必要的具体”导致的“难以理解的复杂”。

小李其实并不关心土鸡蛋的来源、番茄的切法、添加的佐料、以及烹饪方式。

这样的回答除了难以理解之外，局限性也很大。因为它太具体了！只要把土鸡蛋换成洋鸡蛋、或是番茄片换成块、或是加点糖、或是换成电磁炉，其中任一因素发生变化，小明就不会做番茄炒蛋了。

再举个正面的例子，TCP/IP 协议分层模型自下到上定义了五层：

1. 物理层
2. 数据链路成
3. 网络层
4. 传输层
5. 应用层

其中每一层的功能都独立且明确，这样设计的好处是缩小影响面，即单层的变动不会影响其他层。

这样设计的另一个好处是当专注于一层协议时，其余层的技术细节可以不予关注，同一时间只需要关注有限的复杂度，比如传输层不需要知道自己传输的是 HTTP 还是 FTP，传输层只需要专注于端到端的传输方式，是建立连接，还是无连接。

有限复杂度的另一面是“下层的可重用性”。当应用层的协议从 HTTP 换成 FTP 时，其下层的内容不需要做任何更改。

引子

该系列的前三篇结合“搜索”这个业务场景，讲述了不使用架构写业务代码会产生的痛点：

1. 低内聚高耦合的绘制：控件的绘制逻辑散落在各处，散落在各种 Activity 的子程序中（子程序间相互耦合），分散在现在和将来的逻辑中。这样的设计增加了界面刷新的复杂度，导致代码难以理解、容易改出 Bug、难排查问题、无法复用。
2. 耦合的非粘性通信：Activity 和 Fragment 通过获取对方引用并互调方法的方式完成通信。这种通信方式使得 Fragment 和 Activity 耦合，从而降低了界面的复用度。并且没有一种内建的机制来轻松的实现粘性通信。
3. 上帝类：所有细节都在界面被铺开。比如数据存取，网络访问这些和界面无关的细节都在 Activity 被铺开。导致 Activity 代码不单纯、高耦合、代码量大、复杂度高、变化源不单一、改动影响范围大。
4. 界面 & 业务：界面展示和业务逻辑耦合在一起。“界面该长什么样？”和“哪些事件会触发界面重绘？”这两个独立的变化源没有做到关注点分离。导致 Activity 代码不单纯、高耦合、代码量大、复杂度高、变化源不单一、改动影响范围大、易改出 Bug、界面和业务无法单独被复用。

详细分析过程可以点击下面的链接：

1. 写业务不用架构会怎么样？（一）

2. 写业务不用架构会怎么样？（二）

3. 写业务不用架构会怎么样？（三）

这一篇试着引入 MVP 架构（Model-View-Presenter）进行重构，看能不能解决这些痛点。

在重构之前，先介绍下搜索的业务场景，该功能示意图如下：

业务流程如下：在搜索条中输入关键词并同步展示联想词，点联想词跳转搜索结果页，若无匹配结果则展示推荐流，返回时搜索历史以标签形式横向铺开。点击历史可直接发起搜索跳转到结果页。

将搜索业务场景的界面做了如下设计：

搜索页用Activity来承载，它被分成两个部分，头部是常驻在 Activity 的搜索条。下面的“搜索体”用Fragment承载，它可能出现三种状态 1.搜索历史页 2.搜索联想页 3.搜索结果页。

Fragment 之间的切换采用 Jetpack 的Navigation。关于 Navigation 详细的介绍可以点击关于 Navigation 更详细的介绍可以点击Navigation 组件使用入门  |  Android 开发者  |  Android Developers

业务和访问数据分离

上一篇使用 MVP 重构了搜索条，引出了 MVP 中的一些基本概念，比如业务接口，View 层接口，双向通信。

这一篇开始对搜索联想进行重构，它的交互如下：

输入关键词的同时请求网络拉取联想词并展示为列表，点击联想词跳转到搜索结果页。再次点击输入框时，对当前词触发联想。

新增了一个业务场景，就在 SearchPresenter 中新增接口：

interface SearchPresenter {

    fun init()

    fun backPress()

    fun touchSearchBar(text: String, isUserInput: Boolean)

    fun clearKeyword()

    fun search(keyword: String, from: SearchFrom)

    fun inputKeyword(input: Input)

    // 拉取联想词

    suspend fun fetchHint(keyword: String): List<String>

    // 展示联想页

    fun showHintPage(hints: List<SearchHint>)

}

若每次输入框内容发生变化都请求网络则浪费流量，所以得做限制。使用响应式编程使得问题的求解变得简单，详细讲解可以点击写业务不用架构会怎么样？（三）

现套用这个解决方案，并将它和 Presenter 结合使用：

// TemplateSearchActivity.kt

etSearch.textChangeFlow { isUserInput, char -> Input(isUserInput, char.toString()) }

    // 键入内容后高亮搜索按钮并展示 X

    .onEach { searchPresenter.inputKeyword(it) }

    .filter { it.keyword.isNotEmpty() }

    .debounce(300)

    // 拉取联想词

    .flatMapLatest { flow { emit(searchPresenter.fetchHint(it.keyword)) } }

    .flowOn(Dispatchers.IO)

    // 跳转到联想页并展示联想词列表

    .onEach { searchPresenter.showHintPage(it.map { SearchHint(etSearch.text.toString(), it) }) }

    .launchIn(lifecycleScope)

其中textChangeFlow() 是一个 EditText 的扩展方法，该方法把监听输入框内容变化的回调转换为一个Flow，而Input是一个 data class：

fun <T> EditText.textChangeFlow(elementCreator: (Boolean, CharSequence?) -> T): Flow<T> = callbackFlow {

    val watcher = object : TextWatcher {

        private var isUserInput = true

        override fun beforeTextChanged(p0: CharSequence?, p1: Int, p2: Int, p3: Int) {

        }


        override fun onTextChanged(char: CharSequence?, p1: Int, p2: Int, p3: Int) {

            isUserInput = this@textChangeFlow.hasFocus()

        }


        override fun afterTextChanged(p0: Editable?) {

            trySend(elementCreator(isUserInput, p0?.toString().orEmpty()))

        }


    }

    addTextChangedListener(watcher)

    awaitClose { removeTextChangedListener(watcher) }

}

//用于表达用户输入内容

data class Input(val isUserInput: Boolean, val keyword: String)

SearchPresenter.fetchHint()对界面屏蔽了访问网络的细节：

class SearchPresenterImpl(private val searchView: SearchView) : SearchPresenter {

    private val retrofit = Retrofit.Builder()

            .baseUrl("https://XXX")

            .addConverterFactory(MoshiConverterFactory.create())

            .client(OkHttpClient.Builder().build())

            .build()

    private val searchApi = retrofit.create(SearchApi::class.java)


    override suspend fun fetchHint(keyword: String): List<String> = suspendCancellableCoroutine { continuation ->

        searchApi.fetchHints(keyword)

            .enqueue(object : Callback<SearchHintsBean>() {

                override fun onResponse(call: Call<SearchHintsBean>, response: Response<SearchHintsBean>) {

                    if (response.body()?.result?.hints?.isNotEmpty() == true) {

                        val hints = if (result.data.hints.contains(keyword)) 

                            result.data.hints 

                        else listOf(keyword, *result.data.hints.toTypedArray())

                        continuation.resume(hints, null)

                    } else {

                        continuation.resume(listOf(keyword), null)

                    }

                }


                override fun onFailure(call: Call<SearchHintsBean>, t: Throwable) {

                    continuation.resume(listOf(keyword), null)

                }

        })

    }

}

访问网络的细节包括如何将 url 转换为请求对象、如何发起 Http 请求、怎么变换响应、如何将响应的异步回调转换为 suspend 方法。这些细节都被隐藏在 Presenter 层，界面无感知，它只要关心如何绘制。

按照这个思路，访问数据库，访问文件的细节也都不应该让界面感知。有没有必要把这些访问数据的细节再抽取出来成为新的一层叫“数据访问层”？

这取决于数据访问是否可供其他模块复用，或者数据访问的细节是否会发生变化。

若另一个 Presenter 也需要做同样的网络请求(新业务界面请求老接口还是挺常见的)，像上面这种写，请求的细节就无法被复用。此时只能祭出复制粘贴。

而且搜索可以发生在很多业务场景，这次是搜索模板，下次可能是搜索素材。它们肯定不是一个服务端接口。这就是访问的细节发生变化。若新的搜索场景想复用这次的 SearchPresenter，则访问网络的细节就不该出现在 Presenter 层。

为了增加 Presenter 和网络请求细节的复用性，通常的做法是新增一层 Repository：

class SearchRepository {

    private val retrofit = Retrofit.Builder()

            .baseUrl("https://XXX")

            .addConverterFactory(MoshiConverterFactory.create())

            .client(OkHttpClient.Builder().build())

            .build()

    private val searchApi = retrofit.create(SearchApi::class.java)


    override suspend fun fetchHint(keyword: String): List<String> = suspendCancellableCoroutine { continuation ->

        searchApi.fetchHints(keyword)

            .enqueue(object : Callback<SearchHintsBean>() {

                override fun onResponse(call: Call<SearchHintsBean>, response: Response<SearchHintsBean>) {

                    if (response.body()?.result?.hints?.isNotEmpty() == true) {

                        val hints = if (result.data.hints.contains(keyword)) result.data.hints else listOf(keyword, *result.data.hints.toTypedArray())

                        continuation.resume(hints, null)

                    } else {

                        continuation.resume(listOf(keyword), null)

                    }

                }


                override fun onFailure(call: Call<SearchHintsBean>, t: Throwable) {

                    continuation.resume(listOf(keyword), null)

                }

        })

    }

}

然后 Presenter 通过持有 Repository 具备访问数据的能力：

class SearchPresenterImpl(private val searchView: SearchView) : SearchPresenter {

    private val searchRepository: SearchRepository = SearchRepository()

    // 将访问数据委托给 repository

    override suspend fun fetchHint(keyword: String): List<String> {

        return searchRepository.fetchSearchHint(keyword)

    }

}

又引入了一个新的复杂度数据访问层，它封装了所有访问数据的细节，比如怎样读写内存缓存、怎样访问网络、怎样访问数据库、怎样读写文件。数据访问层通常向上层提供“原始数据”，即不经过任何业务封装的数据，这样的设计使得它更容易被复用于不同的业务。Presenter 会持有数据访问层并将所有访问数据的工作委托给它，并将数据做相应的业务转换，最终传递给界面。

Model 去哪了？

至此业务架构表现为如下状态：

业务架构分为三层：

1. 界面层：是 MVP 中的 V，它只描述了界面如何绘制，通过实现 View 层接口表达。它会持有 Presenter 的实例，用以发送业务请求。
2. 业务层：是 MVP 中的 P，它只描述业务逻辑，通过实现业务接口表达。它会持有 View 层接口的实例，以指导界面如何绘制。它还会持有带有数据存储能力的 Repository。
3. 数据存取层：它在 MVP 中找不到自己的位置。它描述了操纵数据的能力，包括读和写。它向上层屏蔽了读写数据的细节，是从网络读，还是从文件，数据库，上层都不需要关心。

MVP 中的 M 在哪里？难道是 Repository 吗？我不觉得！

若 Repository 代表 M，那就意味着 M 不仅代表了数据本身，还包含了获取数据的方式。

但 M 明明是 Model，模型（名词）。Trygve Reenskaug，MVC 概念的发明者，在 1979 年就对 MVC 中的 M 下过这样的结论：

The View observes the Model for changes

M 是用来被 View 观察的，而 Repository 获取的数据是原始数据，需要经过一次包装或转换才能指导界面绘制。

按照这个定义当前架构中的 M 应该如下图所示：

每一个从 Presenter 通过 View 层接口传递出去的参数才是 Model，因为它才直接指导界面该如何绘制。

正因为 Presenter 向界面提供了多个 Model，才导致上一节“有限内聚的界面绘制”，界面绘制无法内聚到一点的根本原因是因为有多个 Model。MVI 在这一点上做了一次升级，叫“唯一可信数据源”，真正地做到了界面绘制内聚于一点。（后续篇章会展开分析）

下面这个例子再一次展示出“多 Model 导致有限内聚的界面刷新”的缺点。

当前输入框的 Flow 如下：

整个流上有两个刷界面的点，一个在流的上游，一个在流的下游。所以不得不把上游切换到主线程执行，否则会报：

E CrashReport: android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.

这也是“有限的内聚”引出的没有必要的线程切换，理想状态下，刷界面应该内聚在一点且处于整个流的末端。（后续篇章会展开）

跨界面通信？

触发拉取联想词的动作在搜索页 Activity 中发生，联想接口的拉取也在 Activity 中进行。这就产生了一个跨界面通信场景，得把 Activity 中获取的联想词传递给联想页 Fragment。

当拉取联想词结束后，数据会流到 SearchPresenter.showHintPage()：

class SearchPresenterImpl(private val searchView: SearchView) : SearchPresenter {

    override fun showHintPage(hints: List<SearchHint>) {

        searchView.gotoHintPage(hints) // 跳转到联想页

    }

}


interface SearchView {

    fun gotoHintPage(hints: List<SearchHint>) // 跳转到联想页

}

为 View 层接口新增了一个界面跳转的方法，待 Activity 实现之：

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    override fun gotoHintPage(hints: List<SearchHint>) {

        // 跳转到联想页，联想词作为参数传递给联想页

        findNavController(NAV_HOST_ID.toLayoutId())

            .navigate(R.id.action_to_hint, bundleOf("hints" to hints))

    }

}

为了将联想词传递给联想页，得序列化之：

@Parcelize // 序列化注解

data class SearchHint( val keyword: String, val hint: String ):Parcelable

然后在联想页通过 getArguement() 就能获取联想词：

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

    super.onViewCreated(view, savedInstanceState)

    // 获取联想词

    val hints = arguments?.getParcelableArrayList<SearchHint>("hints").orEmpty()

}

当前传递的数据简单，若复杂数据采用这种方式传递，可能发生性能上的损耗，首先序列化和反序列化是耗时的。再者当通过 Intent 传递大数据时可能发生TransactionTooLargeException。

展示联想词的场景是“界面跳转”和“数据传递”同时发生，可以借用界面跳转携带数据。但有些场景下不发生界面跳转也得传递数据。比如下面这个场景：

点击联想词也记为一次搜索，也得录入搜索历史。

当点击联想词时发生的界面跳转是从联想页 Fragment 跳到搜索结果 Fragment，但数据传递却需要从联想页到历史页。在这种场景下无法通过界面跳转来携带参数。

因为 Activity 和 Fragment 都能轻松地拿到对方的引用，所以通过直接调对方的方法实现参数传递也不是不可以。只是这让 Activity 和 Fragment 耦合在一起，使得它们无法单独被复用。

正如写业务不用架构会怎么样？（三）中描述的那样，界面之间需要一种解耦的、高性能的、最好还带粘性能力的通信方式。

MVP 并未内建这种通信机制，只能借助于第三方库 EventBus：

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    override fun sendHints(searchHints: List<SearchHint>) {

        findNavController(NAV_HOST_ID.toLayoutId()).navigate(R.id.action_to_hint, bundleOf("hints" to hints))

        EventBus.getDefault().postSticky(SearchHintsEvent(searchHints))// 发送粘性广播

    }

}

// 将联想词封装成实体类便于广播发送

data class SearchHintsEvent(val hints: List<SearchHint>)


class SearchHintFragment : BaseSearchFragment() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        EventBus.getDefault().register(this) // 注册

    }


    override fun onDestroy() {

        super.onDestroy()

        EventBus.getDefault().unregister(this)// 注销

    }


    @Subscribe(threadMode = ThreadMode.MAIN,sticky = true)

    fun onHints(event: SearchHintsEvent) {

        hintsAdapter.dataList = event.hints // 接收粘性消息并刷新列表

    }

}

而 MVVM 和 MVI 就内建了粘性通信机制。（会在后续文章展开）

一切从头来过

产品需求：增加搜索条的过渡动画

搜索业务的入口是另一个 Activity，其中也有一个长得一模一样的搜索条，点击它会跳转到搜索页 Activity。在跳转过程中，两个 Activity 的搜索条有一个水平+透明度的过渡动画。

这个动画的加入引入了一个 Bug：进入搜索页键盘不再自动弹起，搜索历史页没加载出来。

那是因为原先初始化是在 onCreate() 中触发的：

// TemplateSearchActivity.kt

override fun onCreate(savedInstanceState: Bundle?) {

    super.onCreate(savedInstanceState)

    searchPresenter.init()

}

加入过渡动画后，onCreate() 执行的时候，动画还未完成，即初始化时机就太早了。解决方案是监听过渡动画结束后才初始化：

// TemplateSearchActivity.kt

override fun onCreate(savedInstanceState: Bundle?) {

    super.onCreate(savedInstanceState)

    window?.sharedElementEnterTransition?.doOnEnd {

        searchPresenter.init()

    }

}

做了这个调整之后，又引入了一个新 Bug：当在历史页横竖屏切换后，历史不见了。

那是因为横竖屏切换会重新构建 Activity，即重新执行 onCreate() 方法，但这次并没有产生过渡动画，所以初始化方法没有调用。解决办法如下：

// TemplateSearchActivity.kt

override fun onCreate(savedInstanceState: Bundle?) {

    super.onCreate(savedInstanceState)

    window?.sharedElementEnterTransition?.doOnEnd {

        searchPresenter.init()

    }

    // 横竖屏切换时也得再次初始化

    if(savedInstanceState != null) searchPresenter.init()

}

即当发生横竖屏切换时，也手动触发一下初始化。

虽然这样写代码就有点奇怪，因为有两个不同的初始化时机（增加了初始化的复杂度），不过问题还是是解决了。

但每一次横竖屏切换都会触发一次读搜索历史的 IO 操作。当前场景数据量较小，也无大碍。若数据量大，或者初始化操作是一个网络请求，这个方案就不合适了。

究其原因是因为没有一个生命周期比 Activity 更长的数据持有者在横竖屏切换时暂存数据，待切换完成后恢复之。

很可惜 Presenter 无法成为这样的数据持有者，因为它在 Activity 中被构建并被其持有，所以它的生命周期和 Activity 同步，即横竖屏切换时，Presenter 也重新构建了一次。

而 MVVM 和 MVI 就没有这样的烦恼。（后续篇章展开分析）

总结

• 在 MVP 中引入数据访问层是有必要的，这一层封装了存取数据的细节，使得访问数据的能力可以单独被复用。
• MVP 中没有内建一种解耦的、高性能的、带粘性能力的通信方式。
• MVP 无法应对横竖屏切换的场景。当横竖屏切换时，一切从头来过。
• MVP 中的 Model 表现为若干 View 层接口中传递的数据。这样的实现导致了“有限内聚的界面绘制”，增加了界面绘制的复杂度。