环境

从问题发生的环境看，如果我们有一个好的氛围，好的企业文化。员工会不会突然突出离职？或者哪怕提出离职，会不会给我们更多一点时间，在离职期间仍然把事情做好？如果答案是肯定的，那么管理者可以尝试从问题发生的上游解决问题。

提前安排更多的资源来做项目，预防资源不足的情况发生。比如整体预留了20%的开发时间做缓冲，或者整体安排的工作量比规划的多20%。

问题本身

从问题本身思考，员工离职导致的问题是资源不够用。

新增资源，能不能快速找到替代离职员工的人？或者我们能不能使用外包方式完成需求？跟团队商量增加一些工作时间或提高工作效率？

减少需求，少做一些不是很重要的需求，把离职员工的需求分给其他人。

这2个解决方案其实都有一个前提，那就是离职人员的代码是遵循编码规范的，这样接手的人才看得懂。否则，需要增加的资源会比原来规划的多很多。这种问题不能靠员工自觉，而应该要有一套制度来规范编码。

问题的主体

我们不一定能解决问题，但可以解决让问题发生的人。这样问题就不存在了。比如，既然问题出现在张三面前，那就想办法搞定张三，让他愿意按计划把项目完成。如果公司里没人能搞定这个事，这里还有另一个思路，就是想想谁能解决这个问题，找那个能解决问题的人。

从环境、问题本身、问题的主体三个维度来分析，我们得到了好几个解决方案。我们接着分析哪种方案更靠谱。

解决方案分析

方案一，从环境角度分析，让问题不发生。这种成本是最小的。但如果问题已经发生，那这个方案就没用了。

方案二，在项目规划的时候，提前安排更多资源。这招好是好，但前提是你公司有那么多资源。大部分公司都是资源不足。

方案三，新增资源，这个招人不会那么快，就算招进来了，一时半会还发挥不出多大的价值。请外包的话，其实跟招人一样，一时半会还发挥不出多大的价值，成本还更高，也不适合。至于跟团队成员商量提高工作效率或者大家加个班赶上进度，这也是一个解决方案。不过前提是团队还有精力承担这些工作。

方案四，减少需求。这个成本最小，对大部分公司其实也适用。关键是需求管理要做好，对需求的优先级有共识。

方案五，解决让问题发生的人。这个如果不是有大的积怨，也是一个比较好的方案。对整个项目来说，成本也不会很大，项目时间和质量都有保证。

项目管理里有一个生命周期概念，越是在早期发生问题，成本越小。越到后期成本越大。所以，如果让我选，我会选择方案一。但如果已经发生，那只能在四和五里选一个。

实战经验

离职是一场危机管理

让问题不发生，那么解决之道就是不让员工离职。尤其是不让核心骨干员工提离职。离职就是一场危机管理。

这里的本质的是人才是资产，我们在市场上看到很多案例，很多企业的倒闭并不是因为经营问题，而是管理层的大批量流失，资本市场也不看好管理层流失的企业。了解这点，你就能理解为什么人才是资产了。所以对企业来说，核心员工离职不亚于一场危机。

下面分享一个危机管理矩阵，这样有助于我们对危机进行分类。

横轴是一件事情发生之后，危害性有多大，我们分为大、中、小。纵轴就是这件事发生的概率，也可以分为大、中、小。然后就形成了九种不同的类型。

复杂度

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 层接口中传递的数据。这样的实现导致了“有限内聚的界面绘制”，增加了界面绘制的复杂度。

复杂度

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 能否成为高耦合低内聚的终结者？

先来看看高耦合低内聚的代码长什么样。以搜索条为例，它的交互如下：

当输入框键入内容后，显示X按钮并高亮搜索按钮。点击搜索跳转到搜索结果页，同时搜索条拉长并隐藏搜索按钮。点击X时清空输入框并从搜索结果页返回，搜索条还原。

引用上一篇无架构的实现代码：

class TemplateSearchActivity : AppCompatActivity() {

    private fun initView() {

        // 搜索按钮初始状态

        tvSearch.apply {

            isEnabled = false

            textColor = "#484951"

        }

        // 初始状态下，清空按钮不展示

        ivClear.visibility = gone

        // 初始状态下，弹出搜索框

        KeyboardUtils.showSoftInputWithDelay(etSearch, 300)

        // 监听输入框，当有内容时更新搜索和X按钮状态

        etSearch.addTextChangedListener(object :TextWatcher{

            override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {}

            override fun onTextChanged(char: CharSequence?, start: Int, before: Int, count: Int) {

                val input = char?.toString() ?: ""

                if(input.isNotEmpty()) {

                    ivClear.visibility = visible

                    tvSearch.apply {

                        textColor = "#F2F4FF"

                        isEnabled = true

                    }

                }else {

                    ivClear.visibility = gone

                    tvSearch.apply {

                        textColor = "#484951"

                        isEnabled = false

                    }

                }

            }

            override fun afterTextChanged(s: Editable?) { }

        })

        // 监听键盘搜索按钮

        etSearch.setOnEditorActionListener { v, actionId, event ->

            if (actionId == EditorInfo.IME_ACTION_SEARCH) {

                val input = etSearch.text.toString() ?: ""

                if(input.isNotEmpty()) { searchAndHideKeyboard() }

                true

            } else false

        }

        // 监听搜索条搜索按钮

        tvSearch.setOnClickListener { searchAndHideKeyboard() }

    }

    // 跳转到搜索页 + 拉长搜索条 + 隐藏搜索按钮 + 隐藏键盘

    private fun searchAndHideKeyboard() {

        vInputBg.end_toEndOf = parent_id // 拉长搜索框（与父亲右边对齐）

        // 跳转到搜索结果页

        findNavController(NAV_HOST_ID.toLayoutId()).navigate(

            R.id.action_history_to_result,

            bundleOf("keywords" to etSearch?.text.toString())

        )

        tvSearch.visibility = gone

        KeyboardUtils.hideSoftInput(etSearch)

    }

}

这样写的坏处如下：

1. 业务 & 界面耦合

• “界面长什么样”和“哪些事件会触发界面重绘”是两个不同的关注点，它们可以独立变化，前者由 UI 设计发起变更，后者由产品发起变更。


• 耦合增加代码量以及复杂度，高复杂度增加理解难度且容易出错。比如当别人接手该模块看着 1000+ 的 Activity 无所适从时。再比如你修改了界面展示，而另一个同学修改了业务逻辑，合代码时，你俩可能发生冲突，冲突解决不好就会产生 Bug。


• 高耦合还降低了复用性。界面和业务耦合在一起，使得它们都无法单独被复用。即界面无法复用于另一个业务，而业务也无法复用于另一个界面。

2. 低内聚的界面绘制

• 同一个控件的绘制逻辑散落在各个地方，分散在不同的方法中，分散在现在和将来的逻辑中（回调）。


• 低内聚同样也增加了复杂度。就好比玩剧本杀，线索散落在场地的各个角落，你得先搜出线索，然后再将他们拼凑起来，才能形成完整的认知。再比如 y=f(x)，唯一x决定唯一y，而低内聚的代码就好比y=f(a,b,c,d)，任意一个变化源的改变的都会影响界面状态。当UI变更时极易产生“没改全”的 Bug，对于一个小的 UI 改动，不得不搜索整段代码，找出所有对控件的引用，漏掉一个就是 Bug。

搜索条的业务相对简单，initView()看上去也没那么复杂。如果延续“高业务耦合+低绘制内聚”的写法，当界面越来越复杂之后，1000+ 行的 Activity 不是梦。

用一张图来表达所有的复杂度在 Activity 层铺开：

业务和界面分离

业务逻辑和界面绘制是两个不同的关注点，它们本可以不在一个层次中被铺开。

MVP 架构引入了 P（Presenter）层用于承载业务逻辑，实现了复杂度分层：

interface SearchPresenter {

    // 初始化

    fun init()

    // 返回

    fun backPress()

    // 清空关键词

    fun clearKeyword()

    // 发起搜索

    fun search(keyword: String, from: SearchFrom)

    // 输入关键词

    fun inputKeyword(keyword: String)

}

Presenter 称为业务接口，它将所有界面可以发出的动作都表达成接口中的方法。接口是编程语言中表达“抽象”的手段。这是个了不起的发明，因为它把“做什么”和“怎么做”隔离。

界面会持有一个 Presenter 的实例，把业务逻辑委托给它，这使得界面只需要关注“做什么”，而不需要关注“怎么做”。所以业务接口做到了界面绘制和业务逻辑的解耦。

业务逻辑最终会指导界面如何绘制，在 MVP 中通过View 层界面来表达：

interface SearchView {

    fun onInit(keyword: String)

    fun onBackPress()

    fun onClearKeyword()

    fun onSearch()

    fun onInputKeyword(keyword:String)

}

Presenter 的实现者会持有一个 View 层接口实例：

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

    override fun init() {

        searchView.onInit("")

    }

    override fun backPress() {

        searchView.onBackPress()

    }

    override fun clearKeyword() {

        searchView.onClearKeyword()

    }

    override fun search(keyword: String, from: SearchFrom) {

        searchView.onSearch()

    }

    override fun inputKeyword(keyword: String) {

        searchView.onInputKeyword(keyword)

    }

}

Presenter 调用 View 层接口指导界面绘制，界面通过实现 View 层接口实现绘制：

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    private val searchPresenter: SearchPresenter = SearchPresenterImpl(this)

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        searchPresenter.init()

    }

    override fun onBackPressed() {

        super.onBackPressed()

        searchPresenter.backPress()

    }

    // 实现 View 层接口进行界面绘制

    override fun onInit(keyword: String) {...}

    override fun onBackPress() {...}

    override fun onClearKeyword() {...}

    override fun onSearch() {...}

    override fun onInputKeyword(keyword:String) {...}

}

分离了个寂寞？

这样的实现太脱裤子放屁了。就好比三楼同事想给五楼同事一样东西，非得叫顺丰快递，然后顺丰又托运给了申通快递。

非也！当持有一个“抽象”而不是“具体实现”时，好事就会发生！

Activity 和抽象的 SearchPresenter 接口互动，就能发生多态，即动态地替换业务逻辑的实现。

比如产品希望做一个实验，把用户分成A/B两组，A组在进入搜索页的同时把上一次用户搜索的历史直接展示在输入框中，B组则是展示今天的搜索热词。

同样的初始化动作，同样的在输入框中键入内容，不同的是获取数据的方式，A组从本地磁盘获取搜索历史，而B组从网络获取搜索热词。

初始化动作对应“做什么”，输入框中键入内容对应“展示什么”，获取数据的方式对应“怎么做”。如果这些逻辑没有分层而都写在一起，那只能通过在 Activity 中的 if-else 实现：

class TemplateSearchActivity : AppCompatActivity() {

    val abtest by lazy { intent.getStringExtra("ab-test") }

    fun initView() {

        if(abTest == "A"){

            // 输入框展示搜索历史

        } else {

            // 输入框展示搜索热词

        }

    }

}

若这种分类讨论用上瘾，Activity 代码会以极快的速度膨胀，可读性骤降，最糟糕的是一改就容易出 Bug。因为界面绘制没有内聚在一点，而是散落在各种逻辑分支中，不同分支之间的逻辑可能是互斥，或是协同。。。等等总之极其复杂。

有了抽象的 SearchPresenter 就好办了，抽象意味着可以发生多态。

多态是编程语言支持的一种特性，这种特性使得静态的代码运行时可能产生动态的行为，这样一来编程时不需要为类型所烦恼，可以编写统一的处理逻辑而不是依赖特定的类型。”

可见使用多态可以解耦，通过语言内建的机制实现 if-else 的效果：

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    private val abtest by lazy { intent.getStringExtra("ab-test") }

    // 根据命中实验组构建 SearchPresenter 实例

    private val searchPresenter:SearchPresenter by lazy {

        when(type){

            "A" -> SearchPresenterImplA(this)

            "B" -> SearchPresenterImplB(this)

            else -> SearchPresenterImplA(this) // 默认进A实验组

        }

    }



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        searchPresenter.init() // 不用做任何修改，也没有 if-else

    }

    

    override fun onInit(keyword: String){

        etSearch.setText(keyword, TextView.BufferType.EDITABLE)// 不用做任何修改，也没有 if-else

    }

}

然后只要实现两个不同的 SearchPresenter 即可：

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

    override fun init() {

        val keyword = loadFromLocal()// 拉取持久化的搜索历史

        searchView.onInit(keyword)

    }

}



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

    override fun init() {

        val keyword = loadFromRemote()// 从网络拉取搜索热词

        searchView.onInit(keyword)

    }

}

若使用依赖注入框架，比如 Dagger2 或 Hilt，还能把根据AB测实验组分类讨论构建 Presenter 实例的逻辑简化，真正做到业务代码中无分类讨论。

如果 SearchPresenter 中只有 init() 的逻辑在 AB 测场景下不同，那上述方案中其余相同的逻辑需要实现两份？

不需要，用装饰者模式就可以复用剩余的行为：

class SearchPresenterImplA(

    private val searchView: SearchView,

    private val presenter: SearchPresenter // 自己持有自己

) :SearchPresenter{

    override fun init() {

        val keyword = loadFromLocal()// 拉取持久化的搜索历史

        searchView.onInit(keyword)

    }

    override fun backPress() {

        presenter.backPress()// 实现委托给presenter

    }

    override fun touchSearchBar(text: String, isUserInput: Boolean) {

        presenter.touchSearchBar(text, isUserInput)// 实现委托给presenter

    }

    override fun clearKeyword() {

        presenter.clearKeyword()// 实现委托给presenter

    }

    override fun search(keyword: String, from: SearchFrom) {

        presenter.search(keyword, from)// 实现委托给presenter

    }

    override fun inputKeyword(keyword: String) {

        presenter.search(keyword)// 实现委托给presenter

    }

}



// 像这样构建 SearchPresenterImplA 

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    val presenter = SearchPresenterImplA(this, SearchPresenterImplB(this))

}

SearchPresenterImplA 持有另一个 SearchPresenter，并且把剩余方法的实现委托给它。

关于装饰者模式更详细的介绍可以点击使用组合的设计模式 | 美颜相机中的装饰者模式。

这样一来，就把“界面长什么样”和“AB测试”解耦，它们分处于不同的层次，前者在 Activity 属于 View 层，后者属于 Presenter 层。解耦的同时也发生了内聚，关于界面绘制的知识都内聚在 Activity，关于业务逻辑的知识都内聚在 Presenter。

假设界面和业务耦合在一起，后果不堪设想。因为业务的变化是飞快的，今天是 AB 测，明天可能是从不同入口进入搜索页，上报不同的埋点。类似这种情况 Activity 的逻辑会被成堆的 if-else 玩坏。

阶段性总结：

界面和业务分层之后（复杂度被分层），它们就能独立变化（高扩展性），独立复用（高复用性），再配合上“面向抽象编程”，使得业务的逻辑分支被巧妙的隐藏起来（复杂度被隐藏）。

有限的内聚

这样的 View 层接口定义会产生一个问题：

class TemplateSearchActivity : AppCompatActivity() {

    override fun onBackPress() {

        vInputBg.end_toStartOf = ID_SEARCH // 搜索框右侧对齐搜索按钮

        ivClear.visibility = visible

    }



    override fun onClearKeyword() {

        vInputBg.end_toStartOf = ID_SEARCH // 搜索框右侧对齐搜索按钮

        ivClear.visibility = gone

    }



    override fun onSearch() {

        vInputBg.end_toStartOf = parent_id // 搜索框右侧对齐父容器

    }

    

    override fun onInputKeyword(keyword: String) {

        ivClear.visibility = if(keyword.isNotEmpty()) visible else gone

    }

}

复制代码

一个控件应该长成什么样的代码依然散落在不同方法中，就像上一篇描述的一样。

这样容易发生“改不全”或“功能衰退”的 Bug，比如搜索页新增了一个业务逻辑，一个新的 View 层接口被实现，该接口的实现需要非常小心，因为它修改的控件也会在其他 View 层接口被修改，你得确保它们不会发生冲突。

之所以会这样，是因为“View 层接口面向业务进行抽象”，其实从接口的命名就可以看出。

更好的做法是“在 View 层接口屏蔽业务动作，只关心做怎么样的绘制”：

interface SearchView {

    fun initView() // 初始化

    fun showClearButton(show: Boolean)// 展示X

    fun highlightSearchButton(show: Boolean) // 高亮搜索按钮

    fun gotoSearchPage(keyword: String, from: SearchFrom) // 跳转到搜索结果页

    fun stretchSearchBar(stretch: Boolean) // 拉伸搜索框

    fun showSearchButton(highlight: Boolean, show: Boolean) // 展示搜索按钮

    fun clearKeyword(clear:Boolean) // 清空关键词

    fun gotoHistoryPage()// 返回历史页

}

这下 View 层接口描述的都是展示怎么样的界面，Presenter 和 Activity 的代码得做相应的修改：

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

    override fun init() {

        searchView.initView()

    }

    override fun backPress() {

        searchView.stretchSearchBar(false)

        searchView.showSearchButton(true)

        searchView.clearKeyword(true)

    }

    override fun clearKeyword() {

        searchView.highlightSearchButton(false)

        searchView.showClearButton(false)

        searchView.showSearchButton(true)

        searchView.stretchSearchBar(false)

        searchView.clearKeyword(true)

        searchView.gotoHistoryPage()

    }

    override fun search(keyword: String, from: SearchFrom) {

        searchView.gotoSearchPage(keyword, from)

        searchView.stretchSearchBar(true)

        searchView.showSearchButton(false)

    }

    override fun inputKeyword(keyword: String) {

        if (keyword.isNotEmpty()) {

            searchView.showClearButton(true)

            searchView.highlightSearchButton(true)

        } else {

            searchView.showClearButton(false)

            searchView.highlightSearchButton(false)

        }

    }

}

这样的 Presenter 看上去就没那么“脱裤子放屁”了，它不仅仅是一个界面动作的转发者，它包含了一点业务逻辑。

对应的 Activity 修改如下：

class TemplateSearchActivity : AppCompatActivity(), SearchView {

    private val searchPresenter: SearchPresenter = SearchPresenterImpl(this)

    

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        searchPresenter.init()

    }



    override fun onBackPressed() {

        super.onBackPressed()

        searchPresenter.backPress()

    }



    override fun initView() {

        etSearch.setOnTouchListener { v, event ->

            if (event.action == MotionEvent.ACTION_DOWN) {

                if (etSearch.text.toString().isNotEmpty())

                    searchPresenter.onSearchBarTouch(etSearch.text.toString(), true)

            }

            false

        }



        tvSearch.onClick = {

            searchPresenter.search(etSearch.text.toString(), SearchFrom.BUTTON)

        }



        etSearch.addTextChangedListener(object : TextWatcher {

            override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {

            }



            override fun onTextChanged(char: CharSequence?, start: Int, before: Int, count: Int) {

                val input = char?.toString() ?: ""

                searchPresenter.inputKeyword(input)

            }



            override fun afterTextChanged(s: Editable?) {

            }

        })

        etSearch.requestFocus()

        KeyboardUtils.showSoftInput(etSearch)

    }



    override fun showClearButton(show: Boolean) {

        ivClear.visibility = if (show) visible else gone

    }



    override fun gotoSearchPage(keyword: String, from: SearchFrom) {

        runCatching {

            findNavController(NAV_HOST_ID.toLayoutId()).navigate(

                R.id.action_to_result,

                bundleOf("keywords" to keyword)

            )

        }

        KeyboardUtils.hideSoftInput(etSearch)

        StudioReport.reportSearchButtonClick(keyword, from.typeInt)

    }



    override fun stretchSearchBar(stretch: Boolean) {

        vInputBg.apply {

            if (stretch) end_toEndOf = parent_id

            else end_toStartOf = ID_SEARCH

        }

    }



    override fun showSearchButton(highlight: Boolean, show: Boolean) {

        tvSearch.apply {

            visibility = if(show) visible else gone

            textColor = if(highlight) "#F2F4FF" else "#484951"

            isEnable = highlight

        }

    }



    override fun clearKeyword(clear: Boolean) {

        etSearch.apply {

            text = null

            requestFocus()

            KeyboardUtils.showSoftInputWithDelay(etSearch, 300)

        }

    }

    

    override fun gotoHistoryPage(clear: Boolean) {

        findNavController(NAV_HOST_ID.toLayoutId()).popBackStack()

    }

}

同一控件的绘制逻辑总算内聚到一个方法中了，但不同控件的绘制逻辑还是散落在不同的方法。

不同控件的显示是有协同或互斥关系的，比如搜索条拉长时，搜索按钮得隐藏。但拉长搜索条和搜索按钮的绘制分处于不同的 View 层接口，这里就有一个潜规则：“在调拉长搜索条方法的同时，必须同时调用隐藏搜索按钮方法”。当 Presenter 中充斥着这种潜规则时，就会发生界面状态不一致的问题。（最常见的比如，列表加载成功后，loading 还在转圈圈）

之所以会这样是因为 MVP 只是在“低内聚的界面绘制”基础上往前进了一小步，做到了单个控件绘制逻辑的内聚。而 MVI 又进了一步，做到了整个界面绘制逻辑的内聚。（实现细节在后面的篇章展开）

经过 MVP 的重构，现在架构如下图所示：

为啥看上去，比无架构方案还要复杂一点？

没错，MVP 架构引入了新的复杂度。首先是新增一个 Presenter 类，接着还引入了两个接口：业务接口+ View 层接口。这是实现解耦的必要代价。

引入 Presenter 层也有收益，与“复杂度在 View 层被铺开”相比，现在的 View 层要精简得多，也单纯的多。但复杂度被不是凭空消失了，而是被分层，被转移。从图中可以看出现在的复杂度聚集在 Presenter 中业务接口和 View 层接口的交互。MVI 用了一种新的思想方法来化解这个复杂度。（后续篇章会展开分析）

总结

• MVP 引入了业务逻辑层 P（Presenter），使得界面绘制和业务逻辑分开，降低了它们的耦合，形成相互独立的界面层 V 和业务逻辑层 P。界面代码的复杂度得以降低也变得更加单纯。


• MVP 通过接口实现界面层和业务逻辑层的双向通信，界面层通过业务接口向业务逻辑层发起请求。业务逻辑层通过 View 层接口指导界面绘制。接口是一种抽象手段，它把做什么和怎么做分离，为发生多态提供了便利。


• MVP 中 View 层接口的抽象应该面向“界面绘制”而不是“面向业务”。这样做不仅可以让界面绘制逻辑变得内聚，也让增加了代码的复用性。

BottomSheetDialog 是 Android Material 库中提供的一个弹窗类，其特点就是会从屏幕底部弹出，支持拖拽回弹效果，以及拖拽关闭弹窗，在 Android 应用开发中广泛应用

Jetpack Compose 也提供了一个同样的弹窗效果，即 Compose Material 库中的 BottomSheetScaffold，其将整体页面分为了 content 和 sheetContent 两个区域，content 代表的是常驻状态的主屏幕布局，sheetContent 代表的是想从底部弹出的布局

import androidx.compose.material.BottomSheetScaffold



@Composable

private fun BottomSheetScaffoldDemo() {

    BottomSheetScaffold(sheetContent = {



    }, content = {



    })

}

BottomSheetScaffold 完全足以拿来实现 BottomSheetDialog 的效果了，但目前 Google 已经推出了 Material 设计的最新版本，也即 Compose Material 3，而 Material 3 目前并没有提供 BottomSheetScaffold，因此在只想要使用 Material 3 的情况下，我只能自己来实现一个 Compose 版本的 BottomSheetDialog 了

最终的效果如下所示

此 Compose 版本的 BottomSheetDialog 和原生的 Dialog 一样，也支持 cancelable、canceledOnTouchOutside 两个属性，用于控制：是否允许通过点击返回键关闭弹窗、是否允许拖拽关闭弹窗、是否允许通过点击弹窗外部区域来关闭弹窗。此外，此弹窗也无需强制嵌套在某个布局以内，相对 BottomSheetScaffold 来说使用上会更加灵活

来讲下具体的实现思路

先定义好所有需要的参数。visible 属性用于控制弹窗当前是否可见，根据声明式 UI 的特点，该属性就需要交由外部来维护，BottomSheetDialog 再通过 onDismissRequest 方法将关闭弹窗的请求交由外部处理。content 代表的就是弹窗的具体布局

@Composable

fun BottomSheetDialog(

    modifier: Modifier = Modifier,

    visible: Boolean,

    cancelable: Boolean = true,

    canceledOnTouchOutside: Boolean = true,

    onDismissRequest: () -> Unit,

    content: @Composable () -> Unit

)

BottomSheetDialog 通过 BackHandler 来拦截点击返回键的事件，BackHandler 内部是通过原生的 OnBackPressedDispatcher 来实现的，这里设置其只在弹窗可见时才进行拦截，在 cancelable 为 true 时才将拦截的事件转交由外部处理

BackHandler(enabled = visible, onBack = {

    if (cancelable) {

        onDismissRequest()

    }

})

之后需要为弹窗设置一个淡入淡出的半透明背景色，通过 AnimatedVisibility 来实现即可。再通过 clickableNoRipple 拦截页面整体的点击事件，在 canceledOnTouchOutside 为 true 时才将拦截的事件转交由外部处理

AnimatedVisibility(

    visible = visible,

    enter = fadeIn(animationSpec = tween(durationMillis = 400, easing = LinearEasing)),

    exit = fadeOut(animationSpec = tween(durationMillis = 400, easing = LinearEasing))

) {

    Box(

        modifier = Modifier

            .fillMaxSize()

            .background(color = Color(0x99000000))

            .clickableNoRipple {

                if (canceledOnTouchOutside) {

                    onDismissRequest()

                }

            }

    )

}

由于 Compose 提供的 clickable 方法默认会带上水波纹的效果，点击弹窗背景时并不需要，因此我通过自定义的 clickable 方法去掉了水波纹

private fun Modifier.clickableNoRipple(onClick: () -> Unit): Modifier =

    composed {

        clickable(

            indication = null,

            interactionSource = remember { MutableInteractionSource() }) {

            onClick()

        }

    }

由于弹窗的背景色和弹窗内容区域 InnerDialog 应该是上下层叠的关系，所以两者应该位于同个 Box 下，Box 的 Modifier 开放给外部使用者

@Composable

fun BottomSheetDialog(

    modifier: Modifier = Modifier,

    visible: Boolean,

    cancelable: Boolean = true,

    canceledOnTouchOutside: Boolean = true,

    onDismissRequest: () -> Unit,

    content: @Composable () -> Unit

) {

    BackHandler(enabled = visible, onBack = {

        if (cancelable) {

            onDismissRequest()

        }

    })

    Box(modifier = modifier) {

        AnimatedVisibility(

            visible = visible,

            enter = fadeIn(animationSpec = tween(durationMillis = 400, easing = LinearEasing)),

            exit = fadeOut(animationSpec = tween(durationMillis = 400, easing = LinearEasing))

        ) {

            Box(

                modifier = Modifier

                    .fillMaxSize()

                    .background(color = Color(0x99000000))

                    .clickableNoRipple {

                        if (canceledOnTouchOutside) {

                            onDismissRequest()

                        }

                    }

            )

        }

        InnerDialog()

    }

}

InnerDialog 需要有从下往上弹出，并从上往下消失的效果，通过自定义 AnimatedVisibility 的 enter 和 exit 动画即可实现

@Composable

private fun BoxScope.InnerDialog(

    visible: Boolean,

    cancelable: Boolean,

    onDismissRequest: () -> Unit,

    content: @Composable () -> Unit

) {

    AnimatedVisibility(

        modifier = Modifier

            .clickableNoRipple {



            }

            .align(alignment = Alignment.BottomCenter),

        visible = visible,

        enter = slideInVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            initialOffsetY = { 2 * it }

        ),

        exit = slideOutVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            targetOffsetY = { it }

        ),

    ) {

        content()

    }

}

为了能够拖拽弹窗上下移动，这里通过 draggable 方法来检测拖拽手势，用 offsetY 来记录弹窗的 Y 坐标偏移量，同时通过 animateFloatAsState 以动画的形式平滑过度不同的 offsetY 值并触发重组，从而实现弹窗随用户的手势而上下滑动。此外，当用户松手 onDragStopped 时，再将 offsetY 重置为 0，从而实现弹窗拖拽回调的效果

@Composable

private fun BoxScope.InnerDialog(

    visible: Boolean,

    cancelable: Boolean,

    onDismissRequest: () -> Unit,

    content: @Composable () -> Unit

) {

    var offsetY by remember {

        mutableStateOf(0f)

    }

    val offsetYAnimate by animateFloatAsState(targetValue = offsetY)

    AnimatedVisibility(

        modifier = Modifier

            .clickableNoRipple {



            }

            .align(alignment = Alignment.BottomCenter)

            .offset(offset = {

                IntOffset(0, offsetYAnimate.roundToInt())

            })

            .draggable(

                state = rememberDraggableState(

                    onDelta = {

                        offsetY = (offsetY + it.toInt()).coerceAtLeast(0f)

                    }

                ),

                orientation = Orientation.Vertical,

                onDragStarted = {



                },

                onDragStopped = {

                    offsetY = 0f

                }

            ),

        visible = visible,

        enter = slideInVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            initialOffsetY = { 2 * it }

        ),

        exit = slideOutVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            targetOffsetY = { it }

        ),

    ) {

        content()

    }

}

此外，原生的 BottomSheetDialog 还有个特点：当用户向下拖拽的距离不超出某个界限值时，弹窗会有向上回弹恢复的效果；当超出界限值时，则会直接关闭整个弹窗。为了实现这个效果，我们可以定义当用户向下拖拽的偏移量大于弹窗的一半高度时就直接关闭弹窗，否则就让其回弹

通过查看 BottomSheetScaffold 的源码，可以看到其是通过 onGloballyPositioned 方法来拿到整个 sheetContent 的高度，这里可以仿照其思路拿到整个 InnerDialog 的高度 bottomSheetHeight ，在 onDragStopped 方法对比拖拽距离即可

@Composable

private fun BoxScope.InnerDialog(

    visible: Boolean,

    cancelable: Boolean,

    onDismissRequest: () -> Unit,

    content: @Composable () -> Unit

) {

    var offsetY by remember {

        mutableStateOf(0f)

    }

    val offsetYAnimate by animateFloatAsState(targetValue = offsetY)

    var bottomSheetHeight by remember { mutableStateOf(0f) }

    AnimatedVisibility(

        modifier = Modifier

            .clickableNoRipple {



            }

            .align(alignment = Alignment.BottomCenter)

            .onGloballyPositioned {

                bottomSheetHeight = it.size.height.toFloat()

            }

            .offset(offset = {

                IntOffset(0, offsetYAnimate.roundToInt())

            })

            .draggable(

                state = rememberDraggableState(

                    onDelta = {

                        offsetY = (offsetY + it.toInt()).coerceAtLeast(0f)

                    }

                ),

                orientation = Orientation.Vertical,

                onDragStarted = {



                },

                onDragStopped = {

                    if (cancelable && offsetY > bottomSheetHeight / 2) {

                        onDismissRequest()

                    } else {

                        offsetY = 0f

                    }

                }

            ),

        visible = visible,

        enter = slideInVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            initialOffsetY = { 2 * it }

        ),

        exit = slideOutVertically(

            animationSpec = tween(durationMillis = 400, easing = LinearOutSlowInEasing),

            targetOffsetY = { it }

        ),

    ) {

        content()

    }

}

此外，还有个小细节需要注意。当用户向下拖拽关闭了弹窗时，offsetY 可能还不等于 0，这就会导致下次弹出时弹窗还会保持该偏移量，导致弹窗只展示了部分。因此需要当 InnerDialog 退出重组时，手动将 offsetY 重置为 0

DisposableEffect(key1 = null) {

    onDispose {

        offsetY = 0f

    }

}

至此，BottomSheetDialog 就完成了，向 BottomSheetDialog 传入想要展示的布局即可

BottomSheetDialog(

    modifier = Modifier,

    visible = viewState.visible,

    cancelable = true,

    canceledOnTouchOutside = true,

    onDismissRequest = viewState.onDismissRequest

) {

    DialogContent()

}





@Composable

private fun DialogContent(onDismissRequest: () -> Unit) {

    Column(

        modifier = Modifier

            .fillMaxWidth()

            .fillMaxHeight(fraction = 0.7f)

            .clip(shape = RoundedCornerShape(topStart = 24.dp, topEnd = 24.dp))

            .background(color = Color(0xFF009688)),

        verticalArrangement = Arrangement.Center

    ) {

        Button(

            modifier = Modifier

                .align(alignment = Alignment.CenterHorizontally),

            onClick = {

                onDismissRequest()

            }) {

            Text(

                modifier = Modifier.padding(all = 4.dp),

                text = "dismissDialog",

                fontSize = 16.sp

            )

        }

    }

}

这里给出完整的源码：ComposeBottomSheetDialog

前言

Gradle是Android的构建工具，它的主要目标就是实现快速的编译构建，而这主要就是通过缓存实现的。本文主要介绍Gradle的缓存机制，具体包括以下内容

1. Gradle缓存机制


2. Gradle内存缓存


3. Gradle项目缓存


4. Gradle本机缓存


5. Gradle远程缓存

Gradle缓存机制

说起Gradle缓存，我们首先想到的可能就是build-cache，但是Gradle缓存机制远没有这么简单，如下图所示：

纵向来划分的话，Gradle缓存可以划分为配置阶段缓存，执行阶段缓存与依赖缓存三部分

横向来划分的话，Gradle缓存可以划分为内存缓存，项目缓存，本机缓存，远程缓存四个级别

下面我们就按照横向划分的方式来详细介绍一下Gradle的缓存机制

Gradle内存缓存

Gradle内存缓存主要是通过Gradle Daemon进程(即守护进程)实现的

那么Gradle守护进程是什么呢？起什么作用？

守护进程是作为后台进程运行的计算机程序，而不是在交互式用户的直接控制之下

Gradle 在 Java 虚拟机 (JVM) 上运行，并使用多个需要大量初始化时间的支持库。因此，有时启动起来似乎有点慢。

而这个问题的解决方案就是 Gradle Daemon：一个长期存在的后台进程，它可以更快地执行构建。主要是通过避免耗时的初始化操作，以及将有关的项目数据保存在内存中来实现

同时是否使用Daemon来执行构建对于使用都是透明的，它们使用起来基本一致，用户只需要配置是否使用它

获取守护进程状态

由于守护进程对用户来说几乎是透明的，因此我们在平常几乎不会接触到Daemon进程，但是当我们执行构建时可能会看到以下提示：

Starting a Gradle Daemon, 1 busy and 6 stopped Daemons could not be reused, use --status for details

这是说目前有6个已经终止的守护进程与一个忙碌的守护进程，因此需要重新启动一个守护进程，我们可以使用./gradlew --status命令来获取守护进程状态，可以获取以下输出

   PID STATUS   INFO

 82904 IDLE     7.3.3

 81804 STOPPED  (stop command received)

 50304 STOPPED  (by user or operating system)

 59118 STOPPED  (by user or operating system)

你可能会好奇，为什么我们的机器上会有多个守护进程？

Gradle 将创建一个新的守护进程而不是使用一个已经在运行的守护进程有几个原因。基本规则是，如果没有现有的空闲或兼容的守护程序可用，Gradle 将启动一个新的守护程序。Gradle 将杀死任何闲置 3 小时或更长时间的守护进程，因此您不必担心手动清理它们。

如何停止现有守护进程

如前所述，守护进程是一个后台进程。每个守护进程都会监控其内存使用量与系统总内存的比较，如果可用系统内存不足，则会在空闲时自行停止。如果您出于任何原因想明确停止运行守护进程，只需使用命令./gradlew --stop。

或者如果你想直接禁用守护程序的话，您可以通过命令行选项添加--no-daemon，或者在gradle.properties中添加org.gradle.daemon=false。

Gradle 3.0之后守护进程默认开启，构建速度得到了很大的提升，因此在通常情况下不建议关闭守护进程

守护进程如何使构建更快？

Gradle 守护进程是一个长期存在的进程。在多次构建之间，它将空闲地等待下一个构建。这有一个明显的好处，即多个构建只需要初始化一次，而不是每个构建一次。

同时现代 JVM 性能优化的一个重要部分是运行时代码优化(即JIT)。例如，HotSpot（Oracle 提供的 JVM 实现）在代码运行时将对其进行优化。优化是渐进的而不是瞬时的。也就是说，代码在执行过程中逐渐优化，这意味着后续构建可以更快的执行。使用 HotSpot 的实验表明，JIT优化通常需要 5 到 10 次构建才能稳定。因此守护进程的第一次构建和第十次构建之间的构建时间差异可能非常大。

守护进程还允许在多次构建之间进行内存缓存。例如，构建所需的类（例如插件、构建脚本）可以在构建之间保存在内存中。同样，Gradle 可以维护构建数据的内存缓存，例如任务输入和输出的哈希值，用于增量构建。

为了检测文件系统的变化并计算需要重新构建建的内容，Gradle 会在每次构建期间收集有关文件系统状态的大量信息。守护进程可以重用从上次构建中收集的信息并计算出需要重新构建的文件。这可以为增量构建节省大量时间，其中两次构建之间对文件系统的更改次数通常很少

总得来说，守护进程主要做了以下工作：

1. 在多次构建之间重用，只需初始化一次，节省初始化时间


2. 虚拟机JIT优化，代码越执行越快，因此在同一个守护进程中构建，后续构建也将越快


3. 多次构建之中可以对构建脚本，构建插件，构建数据等进行内存缓存，以加快构建速度


4. 可以检测两次构建之间的文件系统的变化，并计算出需要重新构建的文件，方便增量构建

Gradle项目缓存

在内存缓存之后，就是项目级别的缓存，项目级别的缓存主要存储在根目录的.gradle与各个模块的build目录中，其中configuration-cache存储在.gradle目录中，而各个Task的执行结果存储在我们熟悉的build目录中

配置阶段缓存

我们知道，Gradle 的生命周期可以分为大的三个部分：初始化阶段（Initialization Phase)，配置阶段（Configuration Phase），执行阶段（Execution Phase）。

其中任务执行的部分只要处理恰当，已经能够很好的进行缓存和重用——重用已有的缓存是加快编译速度十分关键的一环，如果把这个机制运用到其他阶段当然也能带来一些收益。

仅次于执行阶段耗时的一般是配置阶段， AGP现在也支持了配置阶段缓存 Configuration Cache ，它使得配置阶段的主要产出物：Task Graph 可以被重用

在越大的项目中配置阶段缓存的收益越大，module比较多的项目可能每次执行都要先配置20到30秒，尤其是增量编译时，配置的耗时可能都跟执行的耗时差不多了，而这正是configuration-cache的用武之地

目前configuration-cache还是实验特性，如果你想要开启的话可以在gradle.properties中添加以下代码

# configuration cache

org.gradle.unsafe.configuration-cache=true

org.gradle.unsafe.configuration-cache-problems=warn

第一次使用时会看到计算 Task Graph 的提示：

Calculating task graph as no configuration cache is available for tasks: 

成功后会在 Build 结束时提示：

Configuration cache entry stored.

之后 Cache 就可以被下一次构建复用（如果没有构建脚本修改）：

Reusing configuration cache.



...



51 actionable tasks: 2 executed, 49 up-to-date



Configuration cache entry reused.

当然打开Configuration Cache之后可能会有一些适配问题，如果是第三方插件，发现常用插件出现不支持的情况，可先搜索是否有相同的问题已经出现并修复

如果是项目中自定义Task不支持的话，还需要适配一下Configuration Cache，适配Configuration Cache的核心思路其实很简单：不要在Task执行阶段调用外部不可序列化的对象(比如Project与Variant)

android {

    applicationVariants.all { variant ->

        def mergeAssetTask = variant.getMergeAssetsProvider().get()

        mergeAssetTask.doLast {

           project.logger(variant.buildType.name)

        }

    }

}

如上所示，在doLast阶段调用了project与variant对象，这两个对象是在配置阶段生成的，但是又无法序列化，因此这段代码无法适配Configuration Cache，需要修改如下：

android {

    applicationVariants.all { variant ->

    	def buildTypeName = variant.buildType.name

        def mergeAssetTask = variant.getMergeAssetsProvider().get()

        mergeAssetTask.doLast {

           logger(buildTypeName)

        }

    }

}

如上所示，提前读取出buildTypeName，因为它是String类型，可以被序列化，后续在执行阶段调用也没有问题了

总得来说，Configuration Cache适配并不复杂，但如果你的项目中自定义Task比较多的等方面，那可能就是个体力活了，比如 AGP 兼容 Configuration Cache 就修了 400 多个 ISSUE

Task输出缓存

Task输出缓存即我们最熟悉的各模块build目录，当我们调用./gradlew clean时清理的也是这部分缓存

任何构建工具的一个重要部分是避免重复工作。在编译过程中，就是在编译源文件后，除非发生了影响输出的更改(例如源文件的修改或输出文件的删除），无需重新编译它们。因为编译可能会花费大量时间，因此在不需要时跳过该步骤可以节省大量时间。

如上图所示，Task最基本的功能就是接受一些输入，进行一系列运算后生成输出。比如在编译过程中，Java源文件是输入，生成的classes文件是输出。Task的输出通常在build目录

当Task的输入没有发生变化，则理论上它的输出也没有发生变化，那么此时该Task就可以标记up-to-date，跳过执行阶段，直接复用上次执行的输出，相信你在多次执行构建的时候看到过这个标记

当然，自定义Task要支持up-to-date需要明确输入与输出，关于具体的细节可以查看：Gradle 进阶(一)：深入了解 Tasks

Gradle本机缓存

Gradle本机缓存即Gradle User Home路径下的caches目录，有时当我们运行./gradlew clean之后，重新编译项目还是很快，这是因为还有本机Build Cache的原因

本质上Build Cache与项目内up-to-date检查类似，都是在判断输入没有发生变化时可以直接跳过Task，不同之处在于，Build Cache可以在多个项目间复用

Build Cache开启

默认情况下，Build Cache并未启用。您可以通过以下几种方式启用Build Cache：

1. 在命令行添加--build-cache，Gradle 将只为此构建使用Build Cache。


2. gradle.properties中添加org.gradle.caching=true,Gradle 将尝试为所有构建重用以前构建的输出，除非通过--no-build-cache明确禁用.

启用构建缓存后，它将在 Gradle 用户主目录中存储构建输出。

可缓存Task

由于Task描述了它的所有输入和输出，Gradle 可以计算一个构建缓存Key，Key基于其输入唯一地定义任务的输出。该构建缓存Key用于从构建缓存请求先前的输出或将新输出存储在构建缓存中。如果之前的构建输出已经被其他人存储在缓存中，那你就可以直接复用之前的结果

构建缓存Key由以下属性组成，与up-to-date检查类似：

• Task类型及其classpath


• 输出属性的名称


• DSL 通过TaskInputs添加的属性的名称和值


• Gradle 发行版、buildSrc 和插件的类路径


• 构建脚本影响任务执行时的内容

同时Task还需要添加@CacheableTask注解以支持构建缓存，需要注意的是@CacheableTask注解不会被子类继承

如果查看源码的话，可以发现JavaCompile，KotlinCompile等Task都添加了@CacheableTask注解

总得来说，支持构建缓存的Task与支持up-to-date的Task基本一致，只需要添加一个@CacheableTask注解，当up-to-date检查失效时(比如项目内缓存被清除)，则会尝试使用构建缓存，如下所示：

> gradle --build-cache assemble 

:compileJava FROM-CACHE 

:processResources 

:classes 

:jar 

:assemble 



BUILD SUCCESSFUL

如上所示，当build cache命中时，该Task会被标记为FROM-CACHE

本地依赖缓存

除了Build Cache之外，Gradle User Home目录还包括本地依赖缓存，所有远程下载的aar都在cache/modules-2目录下

这些aar可以在本地所有项目间共享，通过这种方式可以有效避免不同项目之间相同依赖的反复下载

需要注意的是，我们应该尽量使用稳定依赖，避免使用动态(Dynamic) 或者快照(SNAPSHOT) 版本依赖

当我们使用稳定依赖版本，当下载成功后，后续再有引用该依赖的地方都可以从缓存读取, 避免缓慢的网络下载

而动态和快照这两种版本引用会迫使 Gradle 链接远程仓库检查是否有更新的依赖可用, 如果有则下载后缓存到本地.默认情况下,这种缓存有效期为 24 小时. 可以通过以下方式调整缓存有效期:

configurations.all {

    resolutionStrategy.cacheDynamicVersionsFor(10, "minutes")     // 动态版本缓存时效

    resolutionStrategy.cacheChangingModulesFor(4, "hours")        // 快照版本缓存时效

}

动态版本和快照版本会影响编译速度, 尤其在网络状况不佳的情况下以及该依赖仅仅出现在内部repo的情况下. 因为Gradle会串行查询所有repo, 直到找到该依赖才会下载并缓存. 然而这两种依赖方式失效后就需要重新查询和下载.

同时这动态版本与快照版本也会导致Configuration Cache失效，因此应该尽量使用稳定版本

Gradle远程缓存

镜像repo

Gradle下载aar有时非常耗时，一种常见的操作时添加镜像repo，比如公开的阿里镜像等。或者部署公司内部的镜像repo，以加快在公司网络的访问速度，也是很常见的操作。

关于Gradle仓库配置还有一些小技巧：Gradle 在查找远程依赖的时候, 会串行查询所有repo中的maven地址, 直到找到可用的aar后下载. 因此把最快和最高命中率的仓库放在前面, 会有效减少configuration阶段所需的时间.

除了顺序以外, 并不是所有的仓库都提供所有的依赖, 尤其是有些公司会将业务aar放在内部搭建的仓库上. 这种情况下如果盲目增加repository会让Configuration时间变得难以接受. 我们通常需要将内部仓库放在最前, 同时明确指定哪些依赖可以去这里下载:

repositories {

    maven {

        url = uri("http://repo.mycompany.com/maven2")

        content {

            includeGroup("com.test")

        }

    }

    ...

}

如上所示，指定了com.test的group可以去指定的仓库下载

远程Build Cache

上面介绍了本地的Build Cache，Build Cache 可以把之前构建过的 task 结果缓存起来, 一旦后面需要执行该 task 的时候直接使用缓存结果. 与增量编译不同的是, cache 是全局的, 对所有构建都生效.

Build Cache 不仅可以保存在本地($GRADLE_USER_HOME/caches), 也可以使用网络路径。

在 settings.gradle 中加入如下代码:

// settings.gradle.kts

buildCache {

    local<DirectoryBuildCache> {

        directory = File(rootDir, "build-cache")



        // 编译结果是否同步到本地缓存. local cache 默认 true

        push = true



        // 无用缓存清理时间

        removeUnusedEntriesAfterDays = 30

    }



    remote<HttpBuildCache> {

        url = uri("https://example.com:8123/cache/")



        // 编译结果是否同步到远程缓存服务器. remote cache 默认 false

        push = false



        credentials {

            username = "build-cache-user"

            password = "some-complicated-password"

        }



        // 如果遇到 https 不授信问题, 可以关闭校验. 默认 false

        isAllowUntrustedServer = true

    }

}

通常我们在 CI 编译脚本中 push = true, 而开发人员的机器上 push = false 避免缓存被污染.

当然，要实现Build Cache在多个机器上的共享，需要一个缓存服务器，官方提供了两种方式搭建缓存服务器: Docker镜像和jar包，详情可参考Build Cache Node User Manual，这里就不缀述了

总得来说，远程Build Cache应该也是一个可行的方案，试想如果我们有一个高性能的打包机，当每次打码提交时，都自动编译生成Build Cache，那么开发人员都可以高效地复用同一份Build Cache，以加快编译速度，而不是每次更新代码都需要在本机重新编译

总结

本文主要从内存缓存，项目缓存，本机缓存，远程缓存四个级别详细介绍了Gradle的缓存机制，以及如何使用与配置它们。如果使用得当，相信可以有效地加快你的编译速度。如果本文对你有所帮助，欢迎点赞~

大家好，我是楼仔！

在电商高并发场景下，我们经常会使用一些常用方法，去应对流量高峰，比如限流、熔断、降级，今天我们聊聊限流。

什么是限流呢？限流是限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。

根据限流作用范围，可以分为单机限流和分布式限流；根据限流方式，又分为计数器、滑动窗口、漏桶限令牌桶限流，下面我们对这块详细进行讲解。

常用限流方式

计数器

计数器是一种最简单限流算法，其原理就是：在一段时间间隔内，对请求进行计数，与阀值进行比较判断是否需要限流，一旦到了时间临界点，将计数器清零。

这个就像你去坐车一样，车厢规定了多少个位置，满了就不让上车了，不然就是超载了，被交警叔叔抓到了就要罚款的，如果我们的系统那就不是罚款的事情了，可能直接崩掉了。

程序执行逻辑：

• 可以在程序中设置一个变量 count，当过来一个请求我就将这个数 +1，同时记录请求时间。


• 当下一个请求来的时候判断 count 的计数值是否超过设定的频次，以及当前请求的时间和第一次请求时间是否在 1 分钟内。


• 如果在 1 分钟内并且超过设定的频次则证明请求过多，后面的请求就拒绝掉。


• 如果该请求与第一个请求的间隔时间大于计数周期，且 count 值还在限流范围内，就重置 count。

那么问题来了，如果有个需求对于某个接口 /query 每分钟最多允许访问 200 次，假设有个用户在第 59 秒的最后几毫秒瞬间发送 200 个请求，当 59 秒结束后 Counter 清零了，他在下一秒的时候又发送 200 个请求。

那么在 1 秒钟内这个用户发送了 2 倍的请求，这个是符合我们的设计逻辑的，这也是计数器方法的设计缺陷，系统可能会承受恶意用户的大量请求，甚至击穿系统。这种方法虽然简单，但也有个大问题就是没有很好的处理单位时间的边界。

不过说实话，这个计数引用了锁，在高并发场景，这个方式可能不太实用，我建议将锁去掉，然后将 l.count++ 的逻辑通过原子计数处理，这样就可以保证 l.count 自增时不会被多个线程同时执行，即通过原子计数的方式实现限流。

为了不影响阅读，代码详见：github.com/lml20070115…

滑动窗口

滑动窗口是针对计数器存在的临界点缺陷，所谓滑动窗口（Sliding window）是一种流量控制技术，这个词出现在 TCP 协议中。滑动窗口把固定时间片进行划分，并且随着时间的流逝，进行移动，固定数量的可以移动的格子，进行计数并判断阀值。

上图中我们用红色的虚线代表一个时间窗口（一分钟），每个时间窗口有 6 个格子，每个格子是 10 秒钟。每过 10 秒钟时间窗口向右移动一格，可以看红色箭头的方向。我们为每个格子都设置一个独立的计数器 Counter，假如一个请求在 0:45 访问了那么我们将第五个格子的计数器 +1（也是就是 0:40~0:50），在判断限流的时候需要把所有格子的计数加起来和设定的频次进行比较即可。

那么滑动窗口如何解决我们上面遇到的问题呢？来看下面的图：

当用户在 0:59 秒钟发送了 200 个请求就会被第六个格子的计数器记录 +200，当下一秒的时候时间窗口向右移动了一个，此时计数器已经记录了该用户发送的 200 个请求，所以再发送的话就会触发限流，则拒绝新的请求。

其实计数器就是滑动窗口啊，只不过只有一个格子而已，所以想让限流做的更精确只需要划分更多的格子就可以了，为了更精确我们也不知道到底该设置多少个格子，格子的数量影响着滑动窗口算法的精度，依然有时间片的概念，无法根本解决临界点问题。

为了不影响阅读，代码详见：github.com/RussellLuo/…

漏桶

漏桶算法（Leaky Bucket），原理就是一个固定容量的漏桶，按照固定速率流出水滴。

用过水龙头都知道，打开龙头开关水就会流下滴到水桶里，而漏桶指的是水桶下面有个漏洞可以出水,如果水龙头开的特别大那么水流速就会过大，这样就可能导致水桶的水满了然后溢出。

图片如果看不清，可单击图片并放大。

一个固定容量的桶，有水流进来，也有水流出去。对于流进来的水来说，我们无法预计一共有多少水会流进来，也无法预计水流的速度。但是对于流出去的水来说，这个桶可以固定水流出的速率（处理速度），从而达到流量整形和流量控制的效果。

漏桶算法有以下特点：

• 漏桶具有固定容量，出水速率是固定常量（流出请求）


• 如果桶是空的，则不需流出水滴


• 可以以任意速率流入水滴到漏桶（流入请求）


• 如果流入水滴超出了桶的容量，则流入的水滴溢出（新请求被拒绝）

漏桶限制的是常量流出速率（即流出速率是一个固定常量值），所以最大的速率就是出水的速率，不能出现突发流量。

为了不影响阅读，代码详见：github.com/lml20070115…

令牌桶

令牌桶算法（Token Bucket）是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。

图片如果看不清，可单击图片并放大。

我们有一个固定的桶，桶里存放着令牌（token）。一开始桶是空的，系统按固定的时间（rate）往桶里添加令牌，直到桶里的令牌数满，多余的请求会被丢弃。当请求来的时候，从桶里移除一个令牌，如果桶是空的则拒绝请求或者阻塞。

令牌桶有以下特点：

• 令牌按固定的速率被放入令牌桶中


• 桶中最多存放 B 个令牌，当桶满时，新添加的令牌被丢弃或拒绝


• 如果桶中的令牌不足 N 个，则不会删除令牌，且请求将被限流（丢弃或阻塞等待）

令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌...），并允许一定程度突发流量，所以也是非常常用的限流算法。

为了不影响阅读，代码详见：github.com/lml20070115…

Redis + Lua 分布式限流

单机版限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。

而分布式限流，以集群为维度，可以方便的控制这个集群的请求限制，从而保护下游依赖的各种服务资源。

分布式限流最关键的是要将限流服务做成原子化，我们可以借助 Redis 的计数器，Lua 执行的原子性，进行分布式限流，大致的 Lua 脚本代码如下：

local key = "rate.limit:" .. KEYS[1] --限流KEY

local limit = tonumber(ARGV[1])        --限流大小

local current = tonumber(redis.call('get', key) or "0")

if current + 1 > limit then --如果超出限流大小

  return 0

else  --请求数+1，并设置1秒过期

  redis.call("INCRBY", key,"1")

   redis.call("expire", key,"1")

   return current + 1

end

限流逻辑（Java 语言）：

public static boolean accquire() throws IOException, URISyntaxException {

    Jedis jedis = new Jedis("127.0.0.1");

    File luaFile = new File(RedisLimitRateWithLUA.class.getResource("/").toURI().getPath() + "limit.lua");

    String luaScript = FileUtils.readFileToString(luaFile);



    String key = "ip:" + System.currentTimeMillis()/1000; // 当前秒

    String limit = "5"; // 最大限制

    List<String> keys = new ArrayList<String>();

    keys.add(key);

    List<String> args = new ArrayList<String>();

    args.add(limit);

    Long result = (Long)(jedis.eval(luaScript, keys, args)); // 执行lua脚本，传入参数

    return result == 1;

}

聊聊其它

上面的限流方式，主要是针对服务器进行限流，我们也可以对容器进行限流，比如 Tomcat、Nginx 等限流手段。

Tomcat 可以设置最大线程数（maxThreads），当并发超过最大线程数会排队等待执行；而 Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数。

对于 Java 语言，我们其实有相关的限流组件，比如大家常用的 RateLimiter，其实就是基于令牌桶算法，大家知道为什么唯独选用令牌桶么？

对于 Go 语言，也有该语言特定的限流方式，比如可以通过 channel 实现并发控制限流，也支持第三方库 httpserver 实现限流，详见这篇 《Go 限流的常见方法》。

在实际的限流场景中，我们也可以控制单个 IP、城市、渠道、设备 id、用户 id 等在一定时间内发送的请求数；如果是开放平台，需要为每个 appkey 设置独立的访问速率规则。

限流对比

下面我们就对常用的线程策略，总结它们的优缺点，便于以后选型。

计数器：

• 优点：固定时间段计数，实现简单，适用不太精准的场景；


• 缺点：对边界没有很好处理，导致限流不能精准控制。

滑动窗口：

• 优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；


• 缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。

漏桶：

• 优点：可以很好的控制消费频率；


• 缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。

令牌桶：

• 优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；


• 缺点：实现稍微复杂，其它缺点没有想到。

Redis + Lua 分布式限流：

• 优点：支持分布式限流，有效保护下游依赖的服务资源；


• 缺点：依赖 Redis，对边界没有很好处理，导致限流不能精准控制。

动态规划(Dynamic Programming)是一种分阶段求解决策问题的数学思想,它通过把原问题分解为简单的子问题来解决复杂问题。

打家劫舍

你是一个专业的小偷，计划偷窃沿街的房屋。每间房内都藏有一定的现金，影响你偷窃的唯一制约因素就是相邻的房屋装有相互连通的防盗系统，如果两间相邻的房屋在同一晚上被小偷闯入，系统会自动报警。

给定一个代表每个房屋存放金额的非负整数数组，计算你 不触动警报装置的情况下 ，一夜之内能够偷窃到的最高金额。

示例 1：
输入：[1,2,3,1]
输出：4
解释：偷窃 1 号房屋 (金额 = 1) ，然后偷窃 3 号房屋 (金额 = 3)。
  偷窃到的最高金额 = 1 + 3 = 4 。

示例 2：
输入：[2,7,9,3,1]
输出：12
解释：偷窃 1 号房屋 (金额 = 2), 偷窃 3 号房屋 (金额 = 9)，接着偷窃 5 号房屋 (金额 = 1)。
  偷窃到的最高金额 = 2 + 9 + 1 = 12 。

思路

根据题意我们知道不能不同偷窃相邻的两个房间，即：

1. 如果偷窃第i间房屋，那么就不能偷窃第i-1间房屋，一夜之内能够偷窃到的最高金额为前 i-2 间房屋的最高总金额与第i间房屋的金额之和。


2. 如果不偷窃第i间房屋，那么能够偷窃到的最高金额为前 i-1 间房屋的最高总金额。

所以如果房间总数为i，那么一晚上能偷到的最大金额为dp[i]=max(dp[i−2]+house[i],dp[i−1])。

考虑3种特殊情况：

1. 没有房间，偷无可偷，最大金额为0。


2. 只有一间房，那么直接偷窃该房屋。即dp[0]=house[0]。


3. 总共有2间房，因为不能偷窃相邻的，所以只能选金额最大的偷窃，即dp[1]=math(house[0],house[1])。

代码如下：

fun rob(nums: IntArray): Int {

    if (nums.isEmpty()) {

        return 0

    }

    val length = nums.size

    if (length == 1) {

        return nums[0]

    }

    val dp = IntArray(length)

    dp[0] = nums[0]

    dp[1] = Math.max(nums[0], nums[1])

    for (i in 2 until length) {

        dp[i] = Math.max(dp[i - 2] + nums[i], dp[i - 1])

    }

    return dp[length - 1]

}

复杂度分析

• 时间复杂度：O(n)，只需跑一遍房屋即可。


• 空间复杂度：O(n)。使用数组存储了房屋的最高总金额。