开篇

• 最近在合并几个项目的代码，把功能拼一拼简称项目拼多多。


• 但是几个系统都没有 eslint 之类的东西，我也不知道怎么想的居然想给 拼多多 加上代码检查。


• 我还真的干了，于是就有了下面这些奇奇怪怪甚至有些可爱的代码。算是给大家做个反面教材。

一些示例

• ps 示例代码来源于网络社区。

循环不要声明无用的变量

不要在 template中写很长的判断、运算，因为有个东西叫做计算属性。

使用 getCurrentInstance 获取 proxy 时候，请仔细想想你真的需要吗？ 最重要的不要声明了但不使用它！

不要声明未使用变量函数！

• 当然可能有时候，业务变更忘记改了！ 如果是这样，那应该安装 eslint 并增加代码提交检查！

请在data 中声明所有已知变量及其子属性

请不要太随意的对文件进行命名

• 如果有疑问可以查看vue风格指南那里会有答案！

请不要写一些奇怪的逻辑，如果写了请写上注释，对于重复的东西，有必要进行提取，这会使代码更整洁。

如果你使用了 v-for 请记得加上 key 不然它就像没穿内裤一样会很难受！

一个组件是需要一个名字的，就像人一样！

不要混用 v-if、v-for，更不要像下图这样写！

• 组件在使用 v-for 遍历时 需要使用 v-if 判断是否加载，可以使用计算属性先处理一遍再把数据用于v-for遍历。


• 下边这种写法，我猜测可能是数据不存在则不展示，但是 v-for 没有数据本身就不会展示啊！

不要混合使用使用不同的操作符

它是想做什么呢？

• obj[next.id] 存在不做操作， 不存在赋值为 true 且执行 cur.push(next)

写vue的强烈建议查看官网的风格指南 猛击查看

一、前言

• 观察者模式
  
  
  
  • 作用：定义了一个一对多的依赖关系，让一个或多个观察者对象监听一个主题对象。这样一来，当被观察者状态发生改变时，需要通知相应的观察者，使这些观察者对象能够自动更新。
  
  
  • 核心操作：
    
    
    
    • 观察者（订阅者）添加或删除对 被观察者（主题）的状态监听
    
    
    • 被观察者（主题）状态改变时，将事件通知给所有观察者，观察者执行响应逻辑
    
    
    
    
  
  
  
  

二、使用观察者模式

• 例子：监听股票价格变动


• 重点：使用 Java API 或 自定义实现 观察者模式

1、使用 Java API 实现观察者模式

Java 标准库中提供了通用观察者模式的 API，分别是：

• java.util.Observable：被观察者（主题）
  
  
  
  • setChanged()：标记状态更新
  
  
  • addObserver()：添加观察者
  
  
  • deleteObserver()：删除观察者
  
  
  • countObservers()：获取观察者数量
  
  
  • notifyObservers()：通知所有观察者
  
  
  • notifyObservers(Object arg)：通知所有观察者（携带参数 arg）
  
  
  
  


• java.util.Observer：观察者（订阅者）

利用 Java API，可以实现监听股票价格变动这个功能：

import java.util.Observable

import java.util.Observer



/**

 * 被观察者（主题）

 *

 * @author GitLqr

 */

class StockSubject : Observable() {

    fun changeStockPrice(price: Int) {

        this.setChanged() // 标识状态更新

        this.notifyObservers(price) // 通知所有观察者当前股票价格

    }

}



/**

 * 观察者（订阅者）

 *

 * @author GitLqr

 */

class StockDisplay(val name: String) : Observer {

    override fun update(o: Observable?, price: Any?) {

        println("$name receive stock price : $price") // 注意 price 的类型是 Any?

    }

}



// 使用

val subject = StockSubject()

subject.addObserver(StockDisplay("observer 1"))

subject.addObserver(StockDisplay("observer 2"))

subject.changeStockPrice(200)



// 输出

// observer 2 receive stock price : 200

// observer 1 receive stock price : 200

注意：在主题中通过 notifyObservers() 方法通知订阅者之前，需要先调用 setChanged() 标识状态更新，才能正常通知给订阅者，这是使用 Java API 实现观察者模式时需要注意的一点。

Java 提供的 API 已经涵盖了观察者模式的完整实现，所以我们在使用的时候，只需要关注业务本身，而不用自己去做模式的具体实现，但是呢，Java 提供的 API 是一种通用实现，从上面的例子中可以注意到，StockDisplay.update(o: Observable?, price: Any?) 中的 price 参数类型是 Any? ，这就会有以下几个问题：

• 参数判断：因为参数类型是 Any?，所以开发中不得不对 参数是否为空 以及 参数的实际类型 做判断。


• 通知入口单一：实际业务需求会更加复杂，而 java.util.Observer 只有唯一一个通知入口 update(o: Observable?, arg: Any?)，所以我们不得不在该方法中分离响应逻辑，比如股票价格升降，这会让代码显得臃肿。

2、自定义实现观察者模式

虽然 Java 提供了现成的观察者模式 API，但是实际开发中，我们通常还是会自定义实现观察者模式，以便更好的控制代码结构：

/**

 * 回调接口（解耦业务通知入口）

 *

 * @author GitLqr

 */

interface StockUpdateListener {

    fun onRise(price: Int)

    fun onFall(price: Int)

}



/**

 * 被观察者（主题）

 *

 * @author GitLqr

 */

class StockSubject {

    val listeners = mutableSetOf<StockUpdateListener>()

    var price: Int = 0



    fun subscribe(observer: StockUpdateListener) {

        listeners.add(observer)

    }



    fun unsubscribe(observer: StockUpdateListener) {

        listeners.remove(observer)

    }



    fun changeStockPrice(price: Int) {

        val isRise = price > this.price

        listeners.forEach { if (isRise) it.onRise(price) else it.onFall(price) }

        this.price = price

    }

}



/**

 * 观察者（订阅者）

 *

 * @author GitLqr

 */

class StockDisplay : StockUpdateListener {

    override fun onRise(price: Int) {

        println("The latest stock price has rise to $price")

    }



    override fun onFall(price: Int) {

        println("The latest stock price has fell to $price")

    }

}



// 使用

val subject = StockSubject()

subject.subscribe(StockDisplay())

subject.changeStockPrice(200) // The latest stock price has rise to 200

可见，自定义实现观察者模式，可以让代码结构变得更加简单直观。

三、改良观察者模式

• 例子：监听股票价格变动


• 重点：委托属性 Delegates.observable()

Kotlin 标准库引入了可被观察的委托属性，可通过 xxx by Delegates.observable() 的方式，用来监听 xxx 属性的改变，于是可以用来改良上面的自定义观察者模式：

import kotlin.properties.Delegates



/**

 * 观察者模式改良：使用委托属性监听值变化后通知

 *

 * @author GitLqr

 */

class StockSubject {

    val listeners = mutableSetOf<StockUpdateListener>()



    var price: Int by Delegates.observable(0) { prop, old, new ->

        val isRise = new > old

        listeners.forEach { if (isRise) it.onRise(price) else it.onFall(price) }

    }



    fun subscribe(observer: StockUpdateListener) {

        listeners.add(observer)

    }



    fun unsubscribe(observer: StockUpdateListener) {

        listeners.remove(observer)

    }



    // fun changeStockPrice(price: Int) { ... }

}



// 使用

val subject = StockSubject()

subject.subscribe(StockDisplay())

subject.price = 250 // The latest stock price has rise to 200

使用 Delegates.observable() 之后，StockSubject 相比之前减少了一个 changeStockPrice() 方法。使用上，一旦对 price 属性赋值，就可以触发通知，显然，这对使用者更加友好了（直观，少记一个方法）。

四、补充

前面说到，Kotlin 标准库引入可被观察的委托属性，除了 Delegates.observable() 之外，还有
Delegates.vetoable() 也很实用，当我们不希望被监控的属性被随意修改时，就可以用它来否决属性赋值：

import kotlin.properties.Delegates



var value: Int by Delegates.vetoable(0) { prop, old, new ->

    // 新值大于0时，才给属性赋值

    new > 0

}



// 使用

value = 1

println(value) // 1

value = -1

println(value) // 1（没能赋值成功）

在一个类中，为了不让外界访问到某些属性和方法，通常将其设置为private，用正常的方式（对象名.属性名，对象名.方法名）将无法访问此属性与方法，但有没有其他方法可以访问呢？答案是有的，这就是java反射带来的便利。利用反射访问类的私有属性及方法如下：

/**  * @Description: 反射  * @author: Mr_VanGogh  */

public class Reflect {

 

    private String name;

    private int age;

 

    private Reflect(int age) {

        this.age = age;

    }

 

    private void speak(String name) {

        System.out.println("My name is" + name);

    }

 

    public Reflect(String name) {

        this.name = name;

    }

}

首先，我们要了解三个反射包中的类：

• Constructor：代表类的单个构造方法，通过Constructor我们可执行一个类的某个构造方法（有参或者无参）来创建对象时。


• Method：代表类中的单个方法，可以用于执行类的某个普通方法，有参或无参，并可以接收返回值。


• Field：代表类中的单个属性，用于set或get属性


• AccessibleObject：以上三个类的父类，提供了构造方法，普通方法，和属性的访问控制的能力。

使用Class类中的方法可以获得该类中的所有Constructor对象，Method对象，和Field对象。但是任然无法访问私有化的构造方法，普通方法，和私有属性，此时我们可以使用他们继承父类(AccessibleObject)中的setAccessible（）方法，来设置或取消访问检查，以达到访问私有对象的目的。

public static void main(String[] args)  throws Exception {

 

        Reflect reflect = new Reflect("a");

 

        Method[] methods = Reflect.class.getMethods();

        Field[] fields = Reflect.class.getDeclaredFields();

 

        for (int i = 0; i < fields.length; i ++) {

            fields[i].setAccessible(true);

            System.out.println(fields[i].getName());

        }

 

        for (int j = 0; j < methods.length; j ++) {

            methods[j].setAccessible(true);

            System.out.println(methods[j].getName());

 

            methods[j].invoke(reflect);

            System.out.println(methods[j].getName());

        }

    }

这样，我们就获得了私有属性的值

当然，凡事有利就有弊，然后我们再来说一下java反射的优缺点；

优点：

• 能够运行时动态获取类的实例，大大提高了系统的灵活性和扩展性；


• 与java动态编译相结合，可以实现无比强大的功能。

缺点：

• 使用反射的性能较低；


• 使用反射来说相对不安全；


• 破坏了类的封装性，可以通过反射来获取这个类的属性，和私有方法。

Q：private修饰的方法可以通过反射访问，那么private的意义是什么？

A：

1、Java的private修饰符不是为了绝对安全设计的，而是对用户常规使用Java的一种约束。就好比饭店厨房门口挂着“闲人免进”的牌子，但是你还是能够通过其他方法进去。

2、从外部对对象进行常规调用时，能够看到清晰的类结构

快慢指针是双指针的一种典型用法，通常控制两个指针以不同的速度移动来解决问题。采用快慢指针解决问题往往都很巧妙。本文我们通过分析几个例子来学习快慢指针的用法，并分析其本质，最终达到方便记忆、灵活使用的目的。

接下来我们先看四个例子：判断链表是否有环、寻找链表中环的入口、寻找链表的中间结点、寻找链表的倒数第 n 个结点。

判断链表是否有环

题目（来源Leetcode）

“给你一个链表的头结点 head ，判断链表中是否有环。

如果链表中有某个结点，可以通过连续跟踪 next 指针再次到达，则链表中存在环。 为了表示给定链表中的环，评测系统内部使用整数 pos 来表示链表尾连接到链表中的位置（索引从 0 开始）。注意：pos 不作为参数进行传递 。仅仅是为了标识链表的实际情况。

如果链表中存在环 ，则返回 true 。 否则，返回 false 。”

环形链表：leetcode-cn.com/problems/li…

分析

这道题有两种常见解法：1. 哈希表 2. 快慢指针。我们主要分析快慢指针的解法：

我们定义两个指针：一个移动的慢叫慢指针，一个移动的快叫快指针。慢指针在链表中一次移动一个结点，快指针在链表中一次移动两个结点，如果两个指针最终相遇了，说明有环；如果快指针顺利到达了链表的终点说明没有环。

相遇：快指针 = 慢指针；到达终点：快指针的下一个结点为Null。

要想理解这个解决办法需要先了解：Floyd 判圈算法。

Floyd 判圈算法又称为龟兔赛跑算法（Tortoise and Hare Algorithm）。乌龟跑得慢、兔子跑得快。乌龟和兔子在赛跑，如果存在环的话，兔子必然会追上乌龟（乌龟被套圈了）。

我们把乌龟比作慢指针、兔子比作快指针同时在链表中移动。跑步和指针移动不太相同的是，跑步的路程是连续的，快指针一次移动两个结点是不连续的。又反过来想一下如果链表中存在环，那最小的环也需要两个结点，所以对于是否有环来说快指针一次移动两个结点也是不会错过任何一个环的。而且环的结点不管是奇数还是偶数个，快指针也最终会和慢指针在某个结点重合。

答案

基于上面的分析我们给出代码如下：

func hasCycle(head *ListNode) bool {

    if head == nil || head.Next == nil { // 如果链表有0个或者1个结点，则链表不存在环

        return false

    }

    slowPoint, fastPoint := head, head.Next // 定义快慢指针

    for fastPoint != slowPoint { // 如果快慢指针相等则结束循环，证明有环

        if fastPoint == nil || fastPoint.Next == nil { // 如果快指针到达终点或者终点前的倒数第一个结点，说明没有环

            return false

        }

        slowPoint = slowPoint.Next

        fastPoint = fastPoint.Next.Next

    }

    return true

}

寻找链表中环的入口

题目（来源Leetcode）

“给定一个链表的头结点 head ，返回链表开始入环的第一个结点。 如果链表无环，则返回 null。

如果链表中有某个结点，可以通过连续跟踪 next 指针再次到达，则链表中存在环。 为了表示给定链表中的环，评测系统内部使用整数 pos 来表示链表尾连接到链表中的位置（索引从 0 开始）。如果 pos 是 -1，则在该链表中没有环。注意：pos 不作为参数进行传递，仅仅是为了标识链表的实际情况。”

环形链表 II：leetcode-cn.com/problems/li…

分析

这道题和上题一样，通常有哈希表、快慢指针两种解法。我们主要分析快慢指针的解法：

我们定义两个指针：一个移动的慢叫慢指针，一个移动的快叫快指针。慢指针在链表中一次移动一个结点，快指针在链表中一次移动两个结点，如果两个指针最终相遇了，说明有环；如果快指针顺利到达了链表的终点说明没有环。

当有环存在时，我们假设快慢指针在 D 点相遇。a 代表入环之前的长度，b 代表慢指针进入环后又走了b的长度，c 代表环余下的长度。指针的指向是圆的顺时针方向。

1. 如果快指针和慢指针在 D 点相遇，此时快指针比慢指针多走了 n 圈，也就是 n*(b+c) 的长度。


2. 此时快指针走过的距离是 a+n*(b+c)+b，慢指针走过的距离是 a+b。


3. 因为快指针每次走两步，慢指针每次走一步，所以快指针走过的距离永远是慢指针的两倍，所以 a+n* (b+c)+b=2(a+b)*


4. 上述公式可以推导出a = (n-1)*(b+c)+c，也就是a的长度是恰好是 n-1 圈环的长度加上从 D 点到相遇点的距离。

根据上面的推论，当快慢指针相遇之后，我们再申请一个指针从链表的头部开始，每次移动一个结点，同时慢指针一次移动一个结点，这两个指针最终的相遇点就是环的入口点。

答案

func detectCycle(head *ListNode) *ListNode {

    slowPoint, fastPoint := head, head

    for fastPoint != nil && fastPoint.Next != nil { // 如果快指针到达终点或者终点前的倒数第一个结点，说明没有环。

        slowPoint = slowPoint.Next

        fastPoint = fastPoint.Next.Next

        if fastPoint == slowPoint { // 如果快慢指针相等，说明有环，后面开始寻找环的入口。

            delectPoint := head

            for delectPoint != slowPoint { // 慢指针和从头开始的delectPoint指针相等，则说明当前结点就是环的入口。

                delectPoint = delectPoint.Next

                slowPoint = slowPoint.Next

            }

            return delectPoint

        }

    }

    return nil

}

寻找链表的中间结点

题目（来源Leetcode）

给定一个头结点为 head 的非空单链表，返回链表的中间结点。

如果有两个中间结点，则返回第二个中间结点。

链表的中间结点：leetcode-cn.com/problems/mi…

分析

这道题有多种解法，但是快慢指针的解法十分巧妙。我们定义两个指针：一个移动的慢叫慢指针，一个移动的快叫快指针。慢指针在链表中一次移动一个结点，快指针在链表中一次移动两个结点。因为快指针移动的距离始终是慢指针的两倍，所以当快指针移动到链表尾部时，慢指针刚好在链表中间位置。

答案

func middleNode(head *ListNode) *ListNode {

    slowPoint, fastPoint := head, head

    for fastPoint!= nil && fastPoint.Next != nil{

        slowPoint = slowPoint.Next

        fastPoint = fastPoint.Next.Next

    }

    return slowPoint

}

寻找链表的倒数第 N 个结点

题目

给你一个链表，找到链表的倒数第 n 个结点并返回。

分析

这道题有多种解法，但是快慢指针的解法十分巧妙。我们定义两个指针：两个指针每次移动一个结点。我们让其中一个指针先移动 n 个结点，先移动的这个指针我们叫它快指针，另外一个叫慢指针。然后两个指针同时移动。因为移动速度相同所以两个指针之间的距离始终是 n ，当快指针到达链表尾部时，慢指针刚好指向了链表的倒数第 n 个结点。

这里叫“快慢指针”有点牵强，感觉叫前后指针更合适，不过为了方便记忆就先归为快慢指针吧。

答案

func findNthFromEnd(head *ListNode, n int) *ListNode {

    fastPoint,slowPoint := node,node

    for i:=0; i<n+1; i++{

        fastPoint  = fastPoint.Next

    }

    for fastPoint != nil {

        fastPoint=  fastPoint.Next

        slowPoint = slowPoint.Next

    }

    return slowPoint

}

总结

本文我们介绍了快慢指针的常见用法：

1. 利用 Floyd 判圈算法找环。


2. 利用 Floyd 判圈算法找环的入口。


3. 寻找链表的中间结点。


4. 寻找链表的倒数第 n 个结点。

在 Floyd 判圈算法中，把判断环的问题抽象成两个指针围绕环运动最终会相遇的问题，通过环形跑道这个生动场景解决了问题；在寻找链表中间节点时，利用两个指针的速度差，使一个指针运动的距离始终是另外一个指针的一半，用指针的速度、路程解决了问题；在寻找链表倒数第 n 个节点时，让相同速度的两个指针始终保持 n 的相对距离，把链表问题抽象成了距离问题。

这几种方法都是把算法问题抽象成了两个指针的距离、速度问题，最终通过数学公式推导得出结论。推而广之，我们以后遇到链表的相关问题也可以采用类似的方式去抽象问题，推导解决办法。

前言

Android开发发展到今天已经相当成熟了，各种架构大家也都耳熟能详，如MVC,MVP,MVVM等，其中MVVM更是被官方推荐，成为Android开发中的显学。

不过软件开发中没有银弹，MVVM架构也不是尽善尽美的，在使用过程中也会有一些不太方便之处，而MVI可以很好的解决一部分MVVM的痛点。

本文主要包括以下内容

1. MVC,MVP,MVVM等经典架构介绍


2. MVI架构到底是什么?


3. MVI架构实战

需要重点指出的是,标题中说MVI架构是MVVM的进阶版是指MVI在MVVM非常相似，并在其基础上做了一定的改良，并不是说MVI架构一定比MVVM适合你的项目

各位同学可以在分析比较各个架构后，选择合适项目场景的架构

经典架构介绍

MVC架构介绍

MVC是个古老的Android开发架构，随着MVP与MVVM的流行已经逐渐退出历史舞台，我们在这里做一个简单的介绍,其架构图如下所示：



MVC架构主要分为以下几部分

1. 视图层（View）：对应于xml布局文件和java代码动态view部分


2. 控制层（Controller）：主要负责业务逻辑，在android中由Activity承担，同时因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。


3. 模型层（Model）：主要负责网络请求，数据库处理，I/O的操作，即页面的数据来源

由于android中xml布局的功能性太弱,Activity实际上负责了View层与Controller层两者的工作，所以在android中mvc更像是这种形式：



因此MVC架构在android平台上的主要存在以下问题：

1. Activity同时负责View与Controller层的工作，违背了单一职责原则


2. Model层与View层存在耦合，存在互相依赖，违背了最小知识原则

MVP架构介绍

由于MVC架构在Android平台上的一些缺陷，MVP也就应运而生了,其架构图如下所示



MVP架构主要分为以下几个部分

1. View层：对应于Activity与XML,只负责显示UI,只与Presenter层交互，与Model层没有耦合


2. Presenter层： 主要负责处理业务逻辑，通过接口回调View层


3. Model层：主要负责网络请求，数据库处理等操作，这个没有什么变化

我们可以看到，MVP解决了MVC的两个问题，即Activity承担了两层职责与View层与Model层耦合的问题

但MVP架构同样有自己的问题

1. Presenter层通过接口与View通信，实际上持有了View的引用


2. 但是随着业务逻辑的增加，一个页面可能会非常复杂，这样就会造成View的接口会很庞大。

MVVM架构介绍

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。

唯一的区别是，它采用双向数据绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然

MVVM架构图如下所示：



可以看出MVVM与MVP的主要区别在于,你不用去主动去刷新UI了，只要Model数据变了，会自动反映到UI上。换句话说，MVVM更像是自动化的MVP。

MVVM的双向数据绑定主要通过DataBinding实现，不过相信有很多人跟我一样，是不喜欢用DataBinding的，这样架构就变成了下面这样

1. View观察ViewModle的数据变化并自我更新,这其实是单一数据源而不是双向数据绑定，所以其实MVVM的这一大特性我其实并没有用到


2. View通过调用ViewModel提供的方法来与ViewMdoel交互

小结

1. MVC架构的主要问题在于Activity承担了View与Controller两层的职责，同时View层与Model层存在耦合


2. MVP引入Presenter层解决了MVC架构的两个问题，View只能与Presenter层交互，业务逻辑放在Presenter层


3. MVP的问题在于随着业务逻辑的增加，View的接口会很庞大，MVVM架构通过双向数据绑定可以解决这个问题


4. MVVM与MVP的主要区别在于,你不用去主动去刷新UI了，只要Model数据变了，会自动反映到UI上。换句话说，MVVM更像是自动化的MVP。


5. MVVM的双向数据绑定主要通过DataBinding实现，但有很多人(比如我)不喜欢用DataBinding，而是View通过LiveData等观察ViewModle的数据变化并自我更新,这其实是单一数据源而不是双向数据绑定

MVI架构到底是什么?

MVVM架构有什么不足?

要了解MVI架构，我们首先来了解下MVVM架构有什么不足

相信使用MVVM架构的同学都有如下经验，为了保证数据流的单向流动，LiveData向外暴露时需要转化成immutable的，这需要添加不少模板代码并且容易遗忘，如下所示

class TestViewModel : ViewModel() {

    //为保证对外暴露的LiveData不可变，增加一个状态就要添加两个LiveData变量

    private val _pageState: MutableLiveData<PageState> = MutableLiveData()

    val pageState: LiveData<PageState> = _pageState

    private val _state1: MutableLiveData<String> = MutableLiveData()

    val state1: LiveData<String> = _state1

    private val _state2: MutableLiveData<String> = MutableLiveData()

    val state2: LiveData<String> = _state2

    //...

}

如上所示，如果页面逻辑比较复杂，ViewModel中将会有许多全局变量的LiveData,并且每个LiveData都必须定义两遍，一个可变的，一个不可变的。这其实就是我通过MVVM架构写比较复杂页面时最难受的点。

其次就是View层通过调用ViewModel层的方法来交互的，View层与ViewModel的交互比较分散，不成体系

小结一下，在我的使用中，MVVM架构主要有以下不足

1. 为保证对外暴露的LiveData是不可变的，需要添加不少模板代码并且容易遗忘


2. View层与ViewModel层的交互比较分散零乱，不成体系

MVI架构是什么?

MVI 与 MVVM 很相似，其借鉴了前端框架的思想，更加强调数据的单向流动和唯一数据源,架构图如下所示



其主要分为以下几部分

1. Model: 与MVVM中的Model不同的是，MVI的Model主要指UI状态（State）。例如页面加载状态、控件位置等都是一种UI状态


2. View: 与其他MVX中的View一致，可能是一个Activity或者任意UI承载单元。MVI中的View通过订阅Model的变化实现界面刷新


3. Intent: 此Intent不是Activity的Intent，用户的任何操作都被包装成Intent后发送给Model层进行数据请求

单向数据流

MVI强调数据的单向流动，主要分为以下几步：

1. 用户操作以Intent的形式通知Model


2. Model基于Intent更新State


3. View接收到State变化刷新UI。

数据永远在一个环形结构中单向流动，不能反向流动：

上面简单的介绍了下MVI架构，下面我们一起来看下具体是怎么使用MVI架构的

MVI架构实战

总体架构图

我们使用ViewModel来承载MVI的Model层，总体结构也与MVVM类似,主要区别在于Model与View层交互的部分

1. Model层承载UI状态，并暴露出ViewState供View订阅，ViewState是个data class,包含所有页面状态


2. View层通过Action更新ViewState，替代MVVM通过调用ViewModel方法交互的方式

MVI实例介绍

添加ViewState与ViewEvent

ViewState承载页面的所有状态，ViewEvent则是一次性事件，如Toast等,如下所示

data class MainViewState(val fetchStatus: FetchStatus, val newsList: List<NewsItem>)  



sealed class MainViewEvent {

    data class ShowSnackbar(val message: String) : MainViewEvent()

    data class ShowToast(val message: String) : MainViewEvent()

}

1. 我们这里ViewState只定义了两个，一个是请求状态，一个是页面数据


2. ViewEvent也很简单，一个简单的密封类，显示Toast与Snackbar

ViewState更新

class MainViewModel : ViewModel() {

    private val _viewStates: MutableLiveData<MainViewState> = MutableLiveData()

    val viewStates = _viewStates.asLiveData()

    private val _viewEvents: SingleLiveEvent<MainViewEvent> = SingleLiveEvent()

    val viewEvents = _viewEvents.asLiveData()



    init {

        emit(MainViewState(fetchStatus = FetchStatus.NotFetched, newsList = emptyList()))

    }



    private fun fabClicked() {

        count++

        emit(MainViewEvent.ShowToast(message = "Fab clicked count $count"))

    }



    private fun emit(state: MainViewState?) {

        _viewStates.value = state

    }



    private fun emit(event: MainViewEvent?) {

        _viewEvents.value = event

    }

}

如上所示

1. 我们只需定义ViewState与ViewEvent两个State,后续增加状态时在data class中添加即可，不需要再写模板代码


2. ViewEvents是一次性的，通过SingleLiveEvent实现，当然你也可以用Channel当来实现


3. 当状态更新时，通过emit来更新状态

View监听ViewState

    private fun initViewModel() {

        viewModel.viewStates.observe(this) {

            renderViewState(it)

        }

        viewModel.viewEvents.observe(this) {

            renderViewEvent(it)

        }

    }

如上所示，MVI 使用 ViewState 对 State 集中管理，只需要订阅一个 ViewState 便可获取页面的所有状态，相对 MVVM 减少了不少模板代码。

View通过Action更新State

class MainActivity : AppCompatActivity() {

	private fun initView() {

        fabStar.setOnClickListener {

            viewModel.dispatch(MainViewAction.FabClicked)

        }

    }

}

class MainViewModel : ViewModel() {

    fun dispatch(action: MainViewAction) =

        reduce(viewStates.value, action)



    private fun reduce(state: MainViewState?, viewAction: MainViewAction) {

        when (viewAction) {

            is MainViewAction.NewsItemClicked -> newsItemClicked(viewAction.newsItem)

            MainViewAction.FabClicked -> fabClicked()

            MainViewAction.OnSwipeRefresh -> fetchNews(state)

            MainViewAction.FetchNews -> fetchNews(state)

        }

    }

}

如上所示，View通过Action与ViewModel交互，通过 Action 通信，有利于 View 与 ViewModel 之间的进一步解耦，同时所有调用以 Action 的形式汇总到一处，也有利于对行为的集中分析和监控

总结

本文主要介绍了MVC,MVP,MVVM与MVI架构，目前MVVM是官方推荐的架构，但仍然有以下几个痛点

1. MVVM与MVP的主要区别在于双向数据绑定，但由于很多人(比如我)并不喜欢使用DataBindg，其实并没有使用MVVM双向绑定的特性，而是单一数据源


2. 当页面复杂时，需要定义很多State,并且需要定义可变与不可变两种,状态会以双倍的速度膨胀，模板代码较多且容易遗忘


3. View与ViewModel通过ViewModel暴露的方法交互，比较零乱难以维护

而MVI可以比较好的解决以上痛点，它主要有以下优势

1. 强调数据单向流动，很容易对状态变化进行跟踪和回溯


2. 使用ViewState对State集中管理，只需要订阅一个 ViewState 便可获取页面的所有状态，相对 MVVM 减少了不少模板代码


3. ViewModel通过ViewState与Action通信，通过浏览ViewState 和 Aciton 定义就可以理清 ViewModel 的职责，可以直接拿来作为接口文档使用。

当然MVI也有一些缺点，比如

1. 所有的操作最终都会转换成State，所以当复杂页面的State容易膨胀


2. state是不变的，因此每当state需要更新时都要创建新对象替代老对象，这会带来一定内存开销

软件开发中没有银弹，所有架构都不是完美的，有自己的适用场景,读者可根据自己的需求选择使用。

但通过以上的分析与介绍，我相信使用MVI架构代替没有使用DataBinding的MVVM是一个比较好的选择~

更多

关于MVI架构更佳实践，支持局部刷新，可参见: MVI 架构更佳实践：支持 LiveData 属性监听

关于MVI架构封装，优雅实现网络请求，可参见: MVI 架构封装：快速优雅地实现网络请求

项目地址

本文所有代码可见：github.com/shenzhen201…

注意，本篇讨论的是不基于pc的
这个是9月份初弄出来的，自己一直在使用，一直没来得及分享，前段时间在b站看到了一个差不多的方案。

背景

vs code 大部分是由 ts 编写，上层 UI 可以运行在各个系统的浏览器中，但 vs code 基于 electron 框架，这个框架提供了对 node 的支持，一些浏览器内核中的 js 引擎没有的 api，例如 I/O，系统内核的一些交互等。
而 code-server 则是解决了脱离 electron 的问题。
目前安卓上有一个叫 aid learing 的软件，自带 VS Code ，看了一下原理差不多，并不是 linux 图形界面打开的 VS Code，也是打开的 webview 连接本地的服务，但这个玩意占磁盘内存太高，整个下载安装完就干掉6个g。

客户端框架

客户端是用 Flutter 进行的开发，而这个框架的选用并不是为了跨端，仅仅是为了快速尝试，还有基础能力的使用。

实现方法分析

code-server 在 github 发布的版本中是有 arm64 架构的，整个下载后，开终端解压执行就挂了，这个虽然是 arm64，并且带有一个 arm64 的 node，但是是为完整 linux 准备的。也就是说，node 中硬编码了 /usr /lib 等这些路径，并且附带的 node_modules 中也有大量的使用到 linux 特有节点的路径，这些安卓上都没有。
后来一想，termux 中自带的环境也是有 libllvm gcc nodejs 的，把整个 node_mudules 一删，再手动 install 一下，就行了。
所以整个流程大致分为两类。

初始尝试方案：非完整Linux

1. 启动 termux 环境


2. 安装 node,python,libllvm,clang


3. 下载 code-server arm64，解压


4. 处理兼容，删除 node_modules ，重新 yarn install


5. 执行 bin/code-server 启动服务

经过一些测试发现，这种模式有一些问题。

• 下载的依赖太多，由于源都在我的个人服务器，会下很久。


• 编译太久，yarn install 的时候调用了 gcc 的编译，整个过程特别耗时。


• 启动的 vs code 用不了搜索代码(正常情况能支持这个功能)


• 磁盘占用太大，一阵操作下来，直接1.6g磁盘空间给干没了，主要是 npm install 拉了很多东西，还生成了一堆缓存，node_modules 嘛，比黑洞还重的东西。

不过按照以上的流程过一遍后，code-server 内的 node_modules 已经是安卓 arm64 可用的模块了，二次打包 code-server，流程就可以简化成如下

1. 启动 termux 环境


2. 安装 node


3. 下载 code-server arm64，解压


4. 执行 bin/code-server

但还是会存在编辑器无法搜索代码的 bug，node 虽然只有 20m ，但还是在个人服务器，下行带宽 5mb，大概 700kb/s ，emmm，要集成到 apk 内的话，得集成 deb ，调 dpkg 去安装，放弃。

最后使用方案：完整Linux

1. 启动 termux 环境


2. 下载并安装完整 Linux(30m)


3. 下载 code-server arm64(自带node能用了)


4. 执行 bin/code-server 启动服务

最终是选用了完整 Linux 的方式，除了安装需要的体积更小之外，还有完整源的支持，异常 bug 的避免等。
由于整个 VS Code 的启动需要的 130mb 的内存都是第一次打开需要的，所以将这些内存的占用放到服务器上，由 app 启动再下载的意义并不大，最后就全都作为资源文件集成到了 apk 内。

具体实现

启动 termux 环境

这个过程之前有现成的轮子了，只需要按照 termux-package 的编译脚本编译一个 bootstrap 集成到 apk，app 启动进行解压，然后根据符号链接格式进行恢复就行。
终端是 termare_view。

bootstrap 是一个带有最小依赖的类 linux 环境，有bash,apt 等。

具体实现代码

function initApp(){

  cd ${RuntimeEnvir.usrPath}/

  echo 准备符号链接...

  for line in `cat SYMLINKS.txt`

  do

    OLD_IFS="\$IFS"

    IFS="←"

    arr=(\$line)

    IFS="\$OLD_IFS"

    ln -s \${arr[0]} \${arr[3]}

  done

  rm -rf SYMLINKS.txt

  TMPDIR=/data/data/com.nightmare.termare/files/usr/tmp

  filename=bootstrap

  rm -rf "\$TMPDIR/\$filename*"

  rm -rf "\$TMPDIR/*"

  chmod -R 0777 ${RuntimeEnvir.binPath}/*

  chmod -R 0777 ${RuntimeEnvir.usrPath}/lib/* 2>/dev/null

  chmod -R 0777 ${RuntimeEnvir.usrPath}/libexec/* 2>/dev/null

  apt update

  rm -rf $lockFile

  export LD_PRELOAD=${RuntimeEnvir.usrPath}/lib/libtermux-exec.so

  install_vs_code

  start_vs_code

  bash

}

RuntimeEnvir.usrPath 是 /data/data/$package/files/usr/bin

安装完整 Linux 和 code-server

这个我从好几个方案进行了筛选，起初用的 atlio 这个开源，整个开源依赖 python，并且有一个requirement.txt ，需要执行 python -r requirement.txt，依赖就是一大堆，后来换了 proot-distro，纯 shell，所以只需要直接集成到 apk 内就行。

1.安装 ubuntu

install_ubuntu(){

  cd ~

  colorEcho - 安装Ubuntu Linux

  unzip proot-distro.zip >/dev/null

  #cd ~/proot-distro

  bash ./install.sh

  apt-get install -y proot

  proot-distro install ubuntu

  echo '$source' > $ubuntuPath/etc/apt/sources.list

}

2.安装 code-server

install_vs_code(){

  if [ ! -d "$ubuntuPath/home/code-server-$version-linux-arm64" ];then

    cd $ubuntuPath/home

    colorEcho - 解压 Vs Code Arm64

    tar zxvf ~/code-server-$version-linux-arm64.tar.gz >/dev/null

    cd code-server-$version-linux-arm64

  fi

}

启动 code－server

直接用 proot-distro 启动就行，非常方便

--termux-home 参数:开启 app 沙盒的 home 挂载到 ubuntu 的 /root 下，这样 ubuntu 就能用 app 里面的文件夹了。

start_vs_code(){

  install_vs_code

  mkdir -p $ubuntuPath/root/.config/code-server 2>/dev/null

  echo '

  bind-addr: 0.0.0.0:8080

  auth: none

  password: none

  cert: false

  ' > $ubuntuPath/root/.config/code-server/config.yaml

  echo -e "\x1b[31m- 启动中..\x1b[0m"

  proot-distro login ubuntu -- /home/code-server-$version-linux-arm64/bin/code-server

}

其实整个实现其实是没啥难度的，全都是一些 shell 脚本，也是得益于之前的 Termare 系列的支持，有兴趣的可以看下这个组织。
然后就是打开 webview 的过程了，如果觉得性能不好，你可以用局域网的电脑来进行连接。
看一下非首次的启动过程

WebView 实现方案

首先去 pub 看了一下 webview 的插件，官方目前正在维护的 webview 有这样的提示

• Hybrid composition mode has a built-in keyboard support while Virtual displays mode has multiple keyboard issues


• Hybrid composition mode requires Android SKD 19+ while Virtual displays mode requires Android SDK 20+


• Hybrid composition mode has performence limitations when working on Android versions prior to Android 10 while Virtual displays is performant on all supported Android versions

也就是说开启 hybird 后，安卓10以下有性能限制，而使用虚拟显示器的话，键盘问题会很多。

实际尝试的时候，OTG 连接的键盘基本是没法用的。

再分析了下这个场景，最后还是用的原生 WebView，这里有些小坑。

必须启用项

        WebSettings mWebSettings = mWebView.getSettings();

        //允许使用JS

        mWebSettings.setJavaScriptEnabled(true);

        mWebSettings.setJavaScriptCanOpenWindowsAutomatically(true);

        mWebSettings.setUseWideViewPort(true);

        mWebSettings.setAllowFileAccess(true);

        // 下面这行不写不得行

        mWebSettings.setDomStorageEnabled(true);

        mWebSettings.setDatabaseEnabled(true);

        mWebSettings.setAppCacheEnabled(true);

        mWebSettings.setLoadWithOverviewMode(true);

        mWebSettings.setDefaultTextEncodingName("utf-8");

        mWebSettings.setLoadsImagesAutomatically(true);

        mWebSettings.setSupportMultipleWindows(true);

路由重定向

有些场景 VS Code 会打开一个新的窗口，例如点击 file -> new window 的时候，不做处理，webview 会调起系统的浏览器。

        //系统默认会通过手机浏览器打开网页，为了能够直接通过WebView显示网页，必须设置

        mWebView.setWebViewClient(new WebViewClient() {

            @Override

            public boolean shouldOverrideUrlLoading(WebView view, String url) {

                //使用WebView加载显示url

                view.loadUrl(url);

                //返回true

                return true;

            }

        });

浏览器正常跳转

例如终端输出了 xxx.xxx，ctrl + 鼠标点击，预期是会打开浏览器的。

mWebView.setWebChromeClient(webChromeClient);

WebChromeClient webChromeClient = new WebChromeClient() {



        @Override

        public boolean onCreateWindow(WebView view, boolean isDialog, boolean isUserGesture, Message resultMsg) {

            WebView childView = new WebView(context);//Parent WebView cannot host it's own popup window.

            childView.setBackgroundColor(Color.GREEN);

            childView.setWebViewClient(new WebViewClient() {

                @Override

                public boolean shouldOverrideUrlLoading(WebView view, String url) {

                    context.startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse(url)));

                    return true;

                }

            });

            WebView.WebViewTransport transport = (WebView.WebViewTransport) resultMsg.obj;

            transport.setWebView(childView);//setWebView和getWebView两个方法

            resultMsg.sendToTarget();

            return true;

        }

    };

可行性探索

这个能干嘛？安卓屏幕那么小，电脑能本地用 VsCode 干嘛要连安卓的？

• 有一个 vs code 加一个完整的 linux 环境，能 cover 住一些场景的开发了，安卓开发等除外。


• 开发程序到 arm 板子的同学，PC 上还得弄一堆交叉编译工具链，并且每次编译调试过程也很繁琐，现在就能本地写本地编译。

正巧，买了一个平板，爱奇艺之余，也能作为程序员的一波生产力了。

编译 C 语言

选了一个一直在学习的项目，scrcpy，一堆 c 源码，最后很顺利的编译下来了。

Web 开发

移动端的网页调试一直都是问题，作为野路子前端的我也很无奈，一般会加一些 vconsole 的组件来获取调试日志。

之前个人项目速享适配移动端 web 就是这么干的

现在，我们可以本地开发，本地调试，有 node 整个前端大部分项目都能拉下来了，真实的移动端物理环境。
试试

写博客

本篇文章完全是在这个安卓版的 VS Code 中完成的，使用 hexo 本地调式

写文档

写后台，接口测试

写一点简单的后台，如 python 的 fastapi，flask，并通过 rest client 进行接口测试

最后

为了让其他的用户能直接使用到这个 app，我将其上架到了酷安。

看了下 vscodium 和 code-server 的开源协议都是 MIT，如果有侵权的地方辛苦评论区提醒一下鄙人。

Code FA 酷安下载地址

Code FA 个人服务器下载地址

个人软件快捷下载地址

开源地址

随便玩，有问题评论区留言，觉得不错的给个 star，文章不错的给个赞，🤔

其实还想尝试下 Flutter for web 的，折腾了半天还是失败了，能写代码，能有提示，编译会引发 dart runtime 的 crash。

1. 前言

如果你对CoroutineContext不了解，本文值得你细细品读，如果一遍看不懂，不妨多读几遍。写作该文的过程也是我对CoroutineContext理解加深的过程。CoroutineContext是协程的基础，值得投入学习

Android开发者对Context都不陌生。在Android系统中，Context可谓神通广大，它可以获取应用资源，可以获取系统资源，可以启动Activity。Context有几个大名鼎鼎的子类，Activity、Application、Service，它们都是应用中非常重要的组件。

协程中也有个类似的概念，CoroutineContext。它是协程中的上下文，通过它我们可以控制协程在哪个线程中执行，可以设置协程的名字，可以用它来捕获协程抛出的异常等。

我们知道，通过CoroutineScope.launch方法可以启动一个协程。该方法第一个参数的类型就是CoroutineContext。默认值是EmptyCoroutineContext单例对象。 

在开始讲解CoroutineContext之前我们来看一段协程中经常会遇到的代码 

刚开始学协程的时候，我们经常会和Dispatchers.Main、Job、CoroutineName、CoroutineExceptionHandler打交道，它们都是CoroutineContext的子类。我们也很容易单独理解它们，Dispatchers.Main指把协程分发到主线程执行，Job可以管理协程的生命周期，CoroutineName可以设置协程的名字，CoroutineExceptionHandler可以捕获协程的异常。但是+操作符对大部分的Java开发者甚至Kotlin开发者而言会感觉到新鲜又难懂，在协程中CoroutineContext+到底是什么意思？

其实+操作符就是把两个CoroutineContext合并成一个链表，后文会详细讲解

2. CoroutineContext类图一览

根据类图结构我们可以把它分成四个层级：

1. CoroutineContext 协程中所有上下文相关类的父接口。
2. CombinedContext、Element、EmptyCoroutineContext。它们是CoroutineContext的直接子类。
3. AbstractCoroutineContextElement、Job。这两个是Element的直接子类。
4. CoroutineName、CoroutineExceptionHandler、CoroutineDispatcher(包含Dispatchers.Main和Dispatchers.Default)。它们是AbstractCoroutineContextElement的直接子类。

图中红框处，CombinedContext定义了size()和contains()方法，这与集合操作很像，CombinedContext是CoroutineContext对象的集合，而Element和EmptyCoroutineContext却没有定义这些方法，真正实现了集合操作的协程上下文只有CombinedContext，后文会详细讲解

3. CoroutineContext接口

CoroutineContext源码如下：  首先我们看下官方注释，我将它的作用归纳为：

Persistent context for the coroutine. It is an indexed set of [Element] instances. An indexed set is a mix between a set and a map. Every element in this set has a unique [Key].

1. CoroutineContext是协程的上下文。
2. CoroutineContext是element的set集合，没有重复类型的element对象。
3. 集合中的每个element都有唯一的Key，Key可以用来检索元素。

相信大多数的人看到这样的解释时，都会心生疑惑，既然是set类型为啥不直接用HashSet来保存Element。CoroutineContext的实现原理又是什么呢？原因是考虑到协程嵌套，用链表实现更好。

接着我们来看下该接口定义的几个方法 

4. Key接口

Key是一个接口定义在CoroutineContext中的一个接口，作为接口它没有声明任何的方法，那么其实它没有任何真正有用的意义，它只是用来检索。我们先来看下，协程库中是如何使用Key接口的。  通过观察协程官方库中的例子，我们发现Element的子类都必须重写Key这个属性，而且Key的泛型类型必须和类名相同。以CoroutineName为例，Key是一个伴生对象，同时Key的泛型类型也是CoroutineName。

为了方便理解，我仿照写了MyElement类，如下：

通过对比kt类和反编译的java类我们看到 Key就是一个静态变量，而且它的实现类，其实啥也没干。它的作用与HashMap中的Key类似：

1. 实现key-value功能，为插入和删除提供检索功能
2. Key是static静态变量，全局唯一，为Element提供唯一性保障

Kotlin语法糖

coroutineContext.get(CoroutineName.Key)

coroutineContext.get(CoroutineName)

coroutineContext[CoroutineName]

coroutineContext[CoroutineName.Key]

写法是等价的

5. CoroutineContext.get方法

源码(整理在一起，下同) 

使用方式 

讲解

通过Key检索Element。返回值只能是Element或者null，链表节点中的元素值。

1. Element get方法：只要Key与当前Element的Key匹配上了，返回该Element否则返回null。
2. CombinedContext get方法：遍历链表，查询与Key相等的Element，如果没找到返回null。

6. CoroutineContext.plus方法

源码 

使用方式 

讲解

将两个CoroutineContext组合成一个CoroutineContext，如果是两个类型相同的Element会返回一个新的Element。如果是两个不同类型的Element会返回一个CombinedContext。如果是多个不同类型的Element会返回一条CombinedContext链表。

我将上述算法总结成了5种场景，不过在介绍这5种场景前，我们先讲解CombinedContext的数据结构。

7. CombinedContext分析

因为CombinedContext是CoroutineContext的子类，left也是CoroutineContext类型的，所以它的数据结构是链表。我们经常用next来表示链表的下一个节点。那么为什么这里取名叫left呢？我甚至怀疑写这段代码的是个左撇子。真正的原因是，协程可以启动子协程，子协程又可以启动孙协程。父协程在左边，子协程在右边

嵌套启动协程  越是外层的协程的Context越在左边，大概示意图如下 (真实并非如此，比这更复杂) 

链表的两个知识点在此都有体现。CoroutineContext.plus方法中使用的是头插法。CombinedContext的toString方法采用的是链表倒序打印法。

8. 五种plus场景

根据plus源码，我总结出会覆盖到五种场景。 

1. plus EmptyCoroutineContext
2. plus 相同类型的Element
3. plus方法的调用方没有Dispatcher相关的Element
4. plus方法的调用方只有Dispatcher相关的Element
5. plus方法的调用方是包含Dispatcher相关Element的链表

结果如下：

1. Dispatchers.Main + EmptyCoroutineContext 结果:Dispatchers.Main。
2. CoroutineName("c1") + CoroutineName("c2")结果: CoroutineName("c2")。相同类型的直接替换掉。
3. CoroutineName("c1") + Job()结果:CoroutineName("c1") <- Job。头插法被plus的(Job)放在链表头部
4. Dispatchers.Main + Job()结果:Job <- Dispatchers.Main。虽然是头插法，但是ContinuationInterceptor必须在链表头部。
5. Dispatchers.Main + Job() + CoroutineName("c5")结果:Job <- CoroutineName("c5") <- Dispatchers.Main。Dispatchers.Main在链表头部，其它的采用头插法。

如果不考虑Dispatchers.Main的情况。我们可以把+用<-代替。CoroutineName("c1") + Job()等价于CoroutineName("c1") <- Job

9. CoroutineContext的minusKey方法

源码 

讲解

1. Element minusKey方法：如果Key与当前element的Key相等，返回EmptyCoroutineContext，否则相当于没减成功，返回当前element
2. CombinedContext minusKey方法：删除链表中符合条件的节点，分三种情况。

三种情况以下面链表为例

Job <- CoroutineName("c5") <-Dispatchers.Main

1. 没找到节点：minusKey(MyElement)。在Job节点处走newLeft === left分支，依此类推，在CoroutineName处走同样的分支，在Dispatchers.Main处走同样的分支。

2. 节点在尾部：minusKey(Job)。在CoroutineName("c5")节点走newLeft === EmptyCoroutineContext分支，依此往头部递归

3. 节点不在尾部：minusKey(CoroutineName)。在Dispatchers.Main节点处走else分支

10. 总结

学习CoroutineContext首先要搞清楚各类之间的继承关系，其次，CombinedContext各具体Element的集合，它的数据结构是链表，如果读者对链表增删改查操作熟悉的话，那么很容易就能搞懂CoroutineContext原理，否则想要搞懂CoroutineContext那简直如盲人摸象。

前言

实际开发项目中，后端返回的数据大多数是json格式，例如上一篇 Flutter 自定义数据选择器 中显示的数据都是dart模型的数据，由于dart本身数据格式并没有json格式，所以需要转化成dart模型数据。

解决方案

1. 小项目手动序列化

dart:convert 中内置的JSON解码器 它将原始JSON字符串传递给JSON.decode() 方法，然后在返回的Map<String, dynamic>中查找所需的值。 它没有外部依赖或其它的设置，对于小项目很方便

2.对于大中型项目 使用 json to Dart 网站生成model类

3. 使用插件 json_serializable package

实际应用

以方案1 和方案2 在实际项目中展示，还是以上一篇的[Flutter 自定义数据选择器] 为例

由于json to Dart 这个转换已经支持空安全，所以如果需要改动

pubspec.yaml文件

environment:

  sdk: ">=2.12.0 <3.0.0" #如果需要支持空安全，只需要这里改一下版本 >=2.7.0 改成2.12.0

执行：

flutter clean



flutter pub get

area-data-jsonString.dart 文件

定义一个json 字符串数据(由于dart 没有json数据类型, 本地模拟数据就用json数据组装成 字符串格式，'''XXX ''' 包裹起来， 注意是 三个单引号)

进入 json to Dart
粘贴 ，定义类型

转化的模型数据如下：

area-data-json.dart

class AreaDataToJson {

  String? id;

  String? name;

  String? center;

  int? level;

  List<Children>? children;



  AreaDataToJson({this.id, this.name, this.center, this.level, this.children});



  AreaDataToJson.fromJson(Map<String, dynamic> json) {

    id = json['id'];

    name = json['name'];

    center = json['center'];

    level = json['level'];

    if (json['children'] != null) {

      children = <Children>[];

      json['children'].forEach((v) {

        children!.add(new Children.fromJson(v));

      });

    }

  }



  Map<String, dynamic> toJson() {

    final Map<String, dynamic> data = new Map<String, dynamic>();

    data['id'] = this.id;

    data['name'] = this.name;

    data['center'] = this.center;

    data['level'] = this.level;

    if (this.children != null) {

      data['children'] = this.children!.map((v) => v.toJson()).toList();

    }

    return data;

  }

}



class Children {

  String? id;

  String? name;

  String? center;

  int? level;



  Children({this.id, this.name, this.center, this.level});



  Children.fromJson(Map<String, dynamic> json) {

    id = json['id'];

    name = json['name'];

    center = json['center'];

    level = json['level'];

  }



  Map<String, dynamic> toJson() {

    final Map<String, dynamic> data = new Map<String, dynamic>();

    data['id'] = this.id;

    data['name'] = this.name;

    data['center'] = this.center;

    data['level'] = this.level;

    return data;

  }

}

仔细对比发现这里生成数据有问题，省市区是有三层数据，这里只有两层（chilren下面下面可能还存在一层，这里后面再研究一下）

custom-pick.dart 这里就不贴出来，跟上一篇[Flutter 自定义数据选择器] 一样，去上面查看或者查看github源码

如下调用：
json-picker-page.dart

import 'dart:convert';

import 'package:flutter/material.dart';

import 'package:personal_app/components/custom-picker.dart';

import 'package:personal_app/data/area-data-jsonString.dart';

import 'package:personal_app/Modal/area-data-json.dart';



class JsonPickerPage extends StatefulWidget {



  @override

  _JsonPickerPageState createState() => _JsonPickerPageState();

}



class _JsonPickerPageState extends State<JsonPickerPage> {

  // 方案一

  List<dynamic> provAreaDataIdxs = [];//省市区的选择数据下标集合

  String provAreaName = '';// 省市区名称

  dynamic provAreaValue; //省市区选的数据id

  List<Map<String, dynamic>> resetAreaData = []; //省市区数据转换后的数据



  // 方案二

  List<dynamic> provAreaDataIdxs2 = [];//省市区的选择数据下标集合

  String provAreaName2 = '';// 省市区名称

  dynamic provAreaValue2; //省市区选的数据id

  List<Map<String, dynamic>> resetAreaData2 = []; //省市区数据转换后的数据





  @override

  void initState() {

    //方式1，因为数据是本地的数据，dart本身是没有dart数据格式，

    // 所以在定义json数据格式时，需要加上'''XXX''' 先包裹成字符串

    //所以需要解析成List ,真实的接口请求不需要这么处理

    List<dynamic> AreaDataJson = json.decode(areaDataJsonSting);//Json 改成小写，升级原因

    //需要注意的是 areaData 数据字段不是label 和value； 需要转化一下

    resetAreaData =recursionDataHandle(AreaDataJson);



    //方式 2

    List<dynamic> AreaDataJson2 = json.decode(areaDataJsonSting);

    List<dynamic> AreaDataDart2 = AreaDataJson2.map((item) =>

    new AreaDataToJson.fromJson(item)).toList();

    print(AreaDataDart2.toString()); //这里打印才发现AreaDataToJson类有问题，该网站不能对于这种树形结构的数据生成还存在问题，下面放开2层 即 省市是没问题的



    // // List<Map<String, dynamic>> AreaDataDart = AreaDataToJson.fromJson(AreaDataJson);

    //需要注意的是 areaData 数据字段不是label 和value； 需要转化一下

    resetAreaData2 =recursionDataHandle(AreaDataDart2);

    super.initState();

  }



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: Text("自定义数据选择器"),

      ),

      body: Center(

        child: GestureDetector(

          onTap: (){

          },

          child: Column(

              crossAxisAlignment: CrossAxisAlignment.stretch,

              mainAxisSize: MainAxisSize.max,

              children: [

                RaisedButton(

                  padding: EdgeInsets.all(0),

                  onPressed: () {

                    customPicker(context,

                        {"indexs":provAreaDataIdxs, "initData": resetAreaData, "colNum":3},

                            (opt) {

                          setState(() {

                            provAreaDataIdxs = opt['indexs'];

                            List names = opt['names'];

                            provAreaName = '';

                            for(int i = 0; i< names.length; i++) {

                              provAreaName += names[i]['label'] != '' ?  i== 0 ? names[i]['label'] : '/' + names[i]['label'] : '';

                            }

                            provAreaValue = names[names.length-1]['value'];//value 这里逻辑只需要取最后一个

                          });

                        });

                  },

                  child: Row(

                    children: [

                      Text('省市区选择方案1'),



                    ],

                  ),

                ),

                Text(provAreaName),

                Container(

                  height: 26.0,

                ),

                RaisedButton(

                  padding: EdgeInsets.all(0),

                  onPressed: () {

                    customPicker(context,

                        {"indexs":provAreaDataIdxs2, "initData": resetAreaData2, "colNum":2},

                            (opt) {

                          setState(() {

                            provAreaDataIdxs2 = opt['indexs'];

                            List names = opt['names'];

                            provAreaName2 = '';

                            for(int i = 0; i< names.length; i++) {

                              provAreaName2 += names[i]['label'] != '' ?  i== 0 ? names[i]['label'] : '/' + names[i]['label'] : '';

                            }

                            provAreaValue2 = names[names.length-1]['value'];//value 这里逻辑只需要取最后一个

                          });

                        });

                  },

                  child: Row(

                    children: [

                      Text('省市区选择方案2'),

                    ],

                  ),

                ),

                Text(provAreaName2),

                Container(

                  height: 26.0,

                ),

              ]

          ),

        ),

      ),

    );

  }



  //数据格式转换

  recursionDataHandle(data) {

    List<Map<String, dynamic>> resetData = [];

    if(data?.length > 0) {

      for (var i = 0; i <data?.length; i++) {

        Map<String, dynamic> tmpData;

        try {

          tmpData = data?[i].toJson();

        } catch(e) {

          tmpData = data?[i];

        }



        resetData.add({

          'value': tmpData['id'],

          'label': tmpData['name'],

          'center': tmpData['center'],

          'level':  tmpData['level'],

          // 'children': data[i]['children'] ? recursionDataHandle(data[i]['children']): []

        });

        if(tmpData.containsKey('children')) { //是否包含key值children

          if(tmpData['children']?.length > 0)  {

            resetData[i]['children'] = recursionDataHandle(tmpData['children']);

          } else {

            resetData[i]['children'] = [];

          }

        }

      }

    }

    return resetData;

  }

}

方式1 和方式2 分别对应着上面的方案1 和方案2

效果：

问题

需要研究一下 json to Dart 类似多层树形结构数据存在问题？

@Autowired注解相信每个Spring开发者都不陌生了！在DD的Spring Boot基础教程和Spring Cloud基础教程中也都经常会出现。

但是当我们使用IDEA写代码的时候，经常会发现@Autowired注解下面是有小黄线的，我们把小鼠标悬停在上面，可以看到这个如下图所示的警告信息：

那么为什么IDEA会给出Field injection is not recommended这样的警告呢？

下面带着这样的问题，一起来全面的了解下Spring中的三种注入方式以及他们之间在各方面的优劣。

Spring中的三种依赖注入方式

Field Injection

@Autowired注解的一大使用场景就是Field Injection。

具体形式如下：

@Controller

public class UserController {



    @Autowired

    private UserService userService;



}

这种注入方式通过Java的反射机制实现，所以private的成员也可以被注入具体的对象。

Constructor Injection

Constructor Injection是构造器注入，是我们日常最为推荐的一种使用方式。

具体形式如下：

@Controller

public class UserController {



    private final UserService userService;



    public UserController(UserService userService){

        this.userService = userService;

    }



}

这种注入方式很直接，通过对象构建的时候建立关系，所以这种方式对对象创建的顺序会有要求，当然Spring会为你搞定这样的先后顺序，除非你出现循环依赖，然后就会抛出异常。

Setter Injection

Setter Injection也会用到@Autowired注解，但使用方式与Field Injection有所不同，Field Injection是用在成员变量上，而Setter Injection的时候，是用在成员变量的Setter函数上。

具体形式如下：

@Controller

public class UserController {



    private UserService userService;



    @Autowired

    public void setUserService(UserService userService){

        this.userService = userService;

    }

}

这种注入方式也很好理解，就是通过调用成员变量的set方法来注入想要使用的依赖对象。

三种依赖注入的对比

在知道了Spring提供的三种依赖注入方式之后，我们继续回到本文开头说到的问题：IDEA为什么不推荐使用Field Injection呢？

我们可以从多个开发测试的考察角度来对比一下它们之间的优劣：

可靠性

从对象构建过程和使用过程，看对象在各阶段的使用是否可靠来评判：

• Field Injection：不可靠


• Constructor Injection：可靠


• Setter Injection：不可靠

由于构造函数有严格的构建顺序和不可变性，一旦构建就可用，且不会被更改。

可维护性

主要从更容易阅读、分析依赖关系的角度来评判：

• Field Injection：差


• Constructor Injection：好


• Setter Injection：差

还是由于依赖关键的明确，从构造函数中可以显现的分析出依赖关系，对于我们如何去读懂关系和维护关系更友好。

可测试性

当在复杂依赖关系的情况下，考察程序是否更容易编写单元测试来评判

• Field Injection：差


• Constructor Injection：好


• Setter Injection：好

Constructor Injection和Setter Injection的方式更容易Mock和注入对象，所以更容易实现单元测试。

灵活性

主要根据开发实现时候的编码灵活性来判断：

• Field Injection：很灵活


• Constructor Injection：不灵活


• Setter Injection：很灵活

由于Constructor Injection对Bean的依赖关系设计有严格的顺序要求，所以这种注入方式不太灵活。相反Field Injection和Setter Injection就非常灵活，但也因为灵活带来了局面的混乱，也是一把双刃剑。

循环关系的检测

对于Bean之间是否存在循环依赖关系的检测能力：

• Field Injection：不检测


• Constructor Injection：自动检测


• Setter Injection：不检测

性能表现

不同的注入方式，对性能的影响

• Field Injection：启动快


• Constructor Injection：启动慢


• Setter Injection：启动快

主要影响就是启动时间，由于Constructor Injection有严格的顺序要求，所以会拉长启动时间。

所以，综合上面各方面的比较，可以获得如下表格：

结果一目了然，Constructor Injection在很多方面都是优于其他两种方式的，所以Constructor Injection通常都是首选方案！

而Setter Injection比起Field Injection来说，大部分都一样，但因为可测试性更好，所以当你要用@Autowired的时候，推荐使用Setter Injection的方式，这样IDEA也不会给出警告了。同时，也侧面也反映了，可测试性的重要地位啊！

总结

最后，对于今天的问题讨论，我们给出两个结论，方便大家记忆：

1. 依赖注入的使用上，Constructor Injection是首选。


2. 使用@Autowired注解的时候，要使用Setter Injection方式，这样代码更容易编写单元测试。

好了，今天的学习就到这里！如果您学习过程中如遇困难？可以加入我们超高质量的Spring技术交流群，参与交流与讨论，更好的学习与进步！

题目

杨辉三角

给定一个非负整数 numRows， 生成「杨辉三角」的前 numRows 行。

在「杨辉三角」中，每个数是它左上方和右上方的数的和。

示例 1:

输入: numRows = 5

输出: [[1],[1,1],[1,2,1],[1,3,3,1],[1,4,6,4,1]]

示例 2:

输入: numRows = 1

输出: [[1]]

提示:

• 1 <= numRows <= 30

题解

解题分析

杨辉三角介绍：

杨辉三角，是二项式系数在三角形中的一种几何排列，南宋时期数学家杨辉在 1261年 所著《详解九章算法》中出现。

在欧洲，帕斯卡（1623-1662）在1654年发现这一数学规律，所以这个又叫做帕斯卡三角形。帕斯卡的发现比 杨辉 要迟393年，比 贾宪 迟600年。
杨辉三角是中国数学史上的一个伟大成就。

杨辉三角形的规律如题目中所示。

题解思路

1. 定义一个集合存储结果集


2. 定义一个两重循环，分别进行运算，row 数为 numRows, 列数的值为 0 -> i 其中 i 表示当前是第几行.


3. 如果当前 row 的列是第一列或最后一个列的当前的值为 1。


4. 当前行其他的列的其他数据, 等于 re.get(i-1).get(j-) + re.get(i -1).get(j) 之和

复杂度分析

• 时间复杂度：O(num * numRow ^2)


• 空间复杂度：O(1)

解题代码

题解代码如下（代码中有详细的注释说明）：

class Solution {

    public List<List<Integer>> generate(int numRows) {

        List<List<Integer>> re = new ArrayList<>();

        for (int i =0; i< numRows; i++) {

            List<Integer>  row = new ArrayList<>();

            for (int j=0; j<=i; j++) {

                // 行中的第一数据和最后一个数据的值为 1

                if (j == 0 || j == i) {

                    row.add(1);

                } else {

                    // 其他数据, 等于 re.get(i-1).get(j-) + re.get(i -1).get(j) 之和

                    row.add(re.get(i -1).get(j -1) + re.get(i -1).get(j));

                }

            }

            re.add(row);

        }

        return re;

    }

}

提交后反馈结果：

前言

打开Android架构组件页面,我们可以发现一些最新发布的jetpack组件，如Room，DataStore, Paging3,DataBinding 等都支持了Flow

Google开发者账号最近也发布了几篇使用Flow的文章，比如：从 LiveData 迁移到 Kotlin 数据流

看起来官方在大力推荐使用Flow取代LiveData，那么问题来了,有必要吗？

我LiveData用得好好的，有必要再学Flow吗?本文主要回答这个问题,具体包括以下内容

1.LiveData有什么不足?

2.Flow介绍以及为什么会有Flow

3.SharedFlow与StateFlow的介绍与它们之间的区别

本文具体目录如下所示：

1. LiveData有什么不足?

1.1 为什么引入LiveData?

要了解LiveData的不足，我们先了解下LiveData为什么被引入

LiveData 的历史要追溯到 2017 年。彼时，观察者模式有效简化了开发，但诸如 RxJava 一类的库对新手而言有些太过复杂。为此，架构组件团队打造了 LiveData: 一个专用于 Android 的具备自主生命周期感知能力的可观察的数据存储器类。LiveData 被有意简化设计，这使得开发者很容易上手；而对于较为复杂的交互数据流场景，建议您使用 RxJava，这样两者结合的优势就发挥出来了

可以看出,LiveData就是一个简单易用的，具备感知生命周期能力的观察者模式

它使用起来非常简单，这是它的优点，也是它的不足，因为它面对比较复杂的交互数据流场景时，处理起来比较麻烦

1.2 LiveData的不足

我们上文说过LiveData结构简单，但是不够强大，它有以下不足

1.LiveData只能在主线程更新数据

2.LiveData的操作符不够强大,在处理复杂数据流时有些捉襟见肘

关于LiveData只能在主线程更新数据，有的同学可能要问，不是有postValue吗？其实postValue也是需要切换到到主线程的,如下图所示：



这意味着当我们想要更新LiveData对象时，我们会经常更改线程（工作线程→主线程）,如果在修改LiveData后又要切换回到工作线程那就更麻烦了,同时postValue可能会有丢数据的问题。

2. Flow介绍

Flow 就是 Kotlin 协程与响应式编程模型结合的产物，你会发现它与 RxJava 非常像，二者之间也有相互转换的 API，使用起来非常方便。

2.1 为什么引入Flow

为什么引入Flow，我们可以从Flow解决了什么问题的角度切入

1. LiveData不支持线程切换，所有数据转换都将在主线程上完成，有时需要频繁更改线程，面对复杂数据流时处理起来比较麻烦


2. 而RxJava又有些过于麻烦了，有许多让人傻傻分不清的操作符，入门门槛较高，同时需要自己处理生命周期，在生命周期结束时取消订阅

可以看出，Flow是介于LiveData与RxJava之间的一个解决方案，它有以下特点

• Flow 支持线程切换、背压


• Flow 入门的门槛很低，没有那么多傻傻分不清楚的操作符


• 简单的数据转换与操作符，如 map 等等


• 冷数据流，不消费则不生产数据,这一点与LiveData不同：LiveData的发送端并不依赖于接收端。


• 属于kotlin协程的一部分，可以很好的与协程基础设施结合

关于Flow的使用，比较简单，有兴趣的同学可参阅文档：Flow文档

3. SharedFlow介绍

我们上面介绍过,Flow 是冷流，什么是冷流？

• 冷流 :只有订阅者订阅时，才开始执行发射数据流的代码。并且冷流和订阅者只能是一对一的关系，当有多个不同的订阅者时，消息是重新完整发送的。也就是说对冷流而言，有多个订阅者的时候，他们各自的事件是独立的。


• 热流:无论有没有订阅者订阅，事件始终都会发生。当 热流有多个订阅者时，热流与订阅者们的关系是一对多的关系，可以与多个订阅者共享信息。

3.1 为什么引入SharedFlow

上面其实已经说得很清楚了，冷流和订阅者只能是一对一的关系，当我们要实现一个流，多个订阅者的需求时(这在开发中是很常见的)，就需要热流了

从命名上也很容易理解，SharedFlow即共享的Flow，可以实现一对多关系,SharedFlow是一种热流

3.2 SharedFlow的使用

我们来看看SharedFlow的构造函数

public fun <T> MutableSharedFlow(

    replay: Int = 0,

    extraBufferCapacity: Int = 0,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND

): MutableSharedFlow<T>

其主要有3个参数

1.replay表示当新的订阅者Collect时，发送几个已经发送过的数据给它，默认为0，即默认新订阅者不会获取以前的数据

2.extraBufferCapacity表示减去replay，MutableSharedFlow还缓存多少数据，默认为0

3.onBufferOverflow表示缓存策略，即缓冲区满了之后Flow如何处理，默认为挂起

简单使用如下：

//ViewModel

val sharedFlow=MutableSharedFlow<String>()



viewModelScope.launch{

      sharedFlow.emit("Hello")

      sharedFlow.emit("SharedFlow")

}



//Activity

lifecycleScope.launch{

    viewMode.sharedFlow.collect { 

       print(it)

    }

}

3.3 将冷流转化为SharedFlow

普通flow可使用shareIn扩展方法，转化成SharedFlow

    val sharedFlow by lazy {

        flow<Int> {

        //...

        }.shareIn(viewModelScope, WhileSubscribed(500), 0)

    }

shareIn主要也有三个参数：

@param scope 共享开始时所在的协程作用域范围

@param started 控制共享的开始和结束的策略

@param replay 状态流的重播个数

started 接受以下的三个值:

1.Lazily: 当首个订阅者出现时开始，在scope指定的作用域被结束时终止。

2.Eagerly: 立即开始，而在scope指定的作用域被结束时终止。

3.WhileSubscribed: 这种情况有些复杂，后面会详细讲解

对于那些只执行一次的操作，您可以使用Lazily或者Eagerly。然而，如果您需要观察其他的流，就应该使用WhileSubscribed来实现细微但又重要的优化工作

3.4 Whilesubscribed策略

WhileSubscribed策略会在没有收集器的情况下取消上游数据流,通过shareIn运算符创建的SharedFlow会把数据暴露给视图 (View)，同时也会观察来自其他层级或者是上游应用的数据流。

让这些流持续活跃可能会引起不必要的资源浪费，例如一直通过从数据库连接、硬件传感器中读取数据等等。当您的应用转而在后台运行时，您应当保持克制并中止这些协程。

public fun WhileSubscribed(

   stopTimeoutMillis: Long = 0,

   replayExpirationMillis: Long = Long.MAX_VALUE

)

如上所示，它支持两个参数：

• 1.stopTimeoutMillis 控制一个以毫秒为单位的延迟值，指的是最后一个订阅者结束订阅与停止上游流的时间差。默认值是 0 (立即停止).这个值非常有用，因为您可能并不想因为视图有几秒钟不再监听就结束上游流。这种情况非常常见——比如当用户旋转设备时，原来的视图会先被销毁，然后数秒钟内重建。


• 2.replayExpirationMillis表示数据重播的过时时间，如果用户离开应用太久，此时您不想让用户看到陈旧的数据，你可以用到这个参数

4. StateFlow介绍

4.1 为什么引入StateFlow

我们前面刚刚看了SharedFlow，为什么又冒出个StateFlow?

StateFlow 是 SharedFlow 的一个比较特殊的变种，StateFlow 与 LiveData 是最接近的，因为:

• 1.它始终是有值的。


• 2.它的值是唯一的。


• 3.它允许被多个观察者共用 (因此是共享的数据流)。


• 4.它永远只会把最新的值重现给订阅者，这与活跃观察者的数量是无关的。

可以看出，StateFlow与LiveData是比较接近的，可以获取当前的值，可以想像之所以引入StateFlow就是为了替换LiveData

总结如下：

1.StateFlow继承于SharedFlow,是SharedFlow的一个特殊变种

2.StateFlow与LiveData比较相近，相信之所以推出就是为了替换LiveData

4.2 StateFlow的简单使用

我们先来看看构造函数：

public fun <T> MutableStateFlow(value: T): MutableStateFlow<T> = StateFlowImpl(value ?: NULL)

1.StateFlow构造函数较为简单，只需要传入一个默认值

2.StateFlow本质上是一个replay为1，并且没有缓冲区的SharedFlow,因此第一次订阅时会先获得默认值

3.StateFlow仅在值已更新，并且值发生了变化时才会返回，即如果更新后的值没有变化，也没会回调Collect方法，这点与LiveData不同

与SharedFlow类似，我们也可以用stateIn将普通流转化成StateFlow

val result: StateFlow<Result<UiState>> = someFlow

    .stateIn(

        scope = viewModelScope, 

        started = WhileSubscribed(5000), 

        initialValue = Result.Loading

    )

与shareIn类似，唯一不同的时需要传入一个默认值

同时之所以WhileSubscribed中传入了5000，是为了实现等待5秒后仍然没有订阅者存在就终止协程的功能，这个方法有以下功能

• 用户将您的应用转至后台运行，5 秒钟后所有来自其他层的数据更新会停止，这样可以节省电量。


• 最新的数据仍然会被缓存，所以当用户切换回应用时，视图立即就可以得到数据进行渲染。


• 订阅将被重启，新数据会填充进来，当数据可用时更新视图。


• 在屏幕旋转时，因为重新订阅的时间在5s内，因此上游流不会中止

4.3 在页面中观察StateFlow

与LiveData类似，我们也需要经常在页面中观察StateFlow

观察StateFlow需要在协程中，因此我们需要协程构建器，一般我们会使用下面几种

1. lifecycleScope.launch : 立即启动协程，并且在本 Activity或Fragment 销毁时结束协程。


2. LaunchWhenStarted 和 LaunchWhenResumed,它会在lifecycleOwner进入X状态之前一直等待，又在离开X状态时挂起协程

如上图所示：

1.使用launch是不安全的，在应用在后台时也会接收数据更新，可能会导致应用崩溃

2.使用launchWhenStarted或launchWhenResumed会好一些，在后台时不会接收数据更新，但是，上游数据流会在应用后台运行期间保持活跃，因此可能浪费一定的资源

这么说来，我们使用WhileSubscribed进行的配置岂不是无效了吗？订阅者一直存在，只有页面关闭时才会取消订阅

官方推荐repeatOnLifecycle来构建协程

在某个特定的状态满足时启动协程，并且在生命周期所有者退出该状态时停止协程,如下图所示。



比如在某个Fragment的代码中:

onCreateView(...) {

    viewLifecycleOwner.lifecycleScope.launch {

        viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {

            myViewModel.myUiState.collect { ... }

        }

    }

}

当这个Fragment处于STARTED状态时会开始收集流，并且在RESUMED状态时保持收集，最终在Fragment进入STOPPED状态时结束收集过程。

结合使用repeatOnLifecycle API和WhileSubscribed,可以帮助您的应用妥善利用设备资源的同时，发挥最佳性能

4.4 页面中观察Flow的最佳方式

通过ViewModel暴露数据，并在页面中获取的最佳方式是:

• ✔️ 使用带超时参数的 WhileSubscribed 策略暴露 Flow。示例 1


• ✔️ 使用 repeatOnLifecycle 来收集数据更新。示例 2

最佳实践如上图所示，如果采用其他方式，上游数据流会被一直保持活跃，导致资源浪费

当然，如果您并不需要使用到Kotlin Flow的强大功能，就用LiveData好了 :)

5 StateFlow与SharedFlow有什么区别？

从上文其实可以看出，StateFlow与SharedFlow其实是挺像的，让人有些傻傻分不清，有时候也挺难选择该用哪个的

我们总结一下，它们的区别如下:

1. SharedFlow配置更为灵活，支持配置replay,缓冲区大小等，StateFlow是SharedFlow的特化版本，replay固定为1，缓冲区大小默认为0


2. StateFlow与LiveData类似，支持通过myFlow.value获取当前状态，如果有这个需求，必须使用StateFlow


3. SharedFlow支持发出和收集重复值，而StateFlow当value重复时，不会回调collect


4. 对于新的订阅者，StateFlow只会重播当前最新值，SharedFlow可配置重播元素个数（默认为0，即不重播）

可以看出,StateFlow为我们做了一些默认的配置，在SharedFlow上添加了一些默认约束，这些配置可能并不符合我们的要求

1. 它忽略重复的值，并且是不可配置的。这会带来一些问题，比如当往List中添加元素并更新时，StateFlow会认为是重复的值并忽略


2. 它需要一个初始值，并且在开始订阅时会回调初始值，这有可能不是我们想要的


3. 它默认是粘性的，新用户订阅会获得当前的最新值，而且是不可配置的,而SharedFlow可以修改replay

StateFlow施加在SharedFlow上的约束可能不是最适合您，如果不需要访问myFlow.value，并且享受SharedFlow的灵活性，可以选择考虑使用SharedFlow

总结

简单往往意味着不够强大，而强大又常常意味着复杂,两者往往不能兼得，软件开发过程中常常面临这种取舍。

LiveData的简单并不是它的缺点，而是它的特点。StateFlow与SharedFlow更加强大，但是学习成本也显著的更高.

我们应该根据自己的需求合理选择组件的使用

1. 如果你的数据流比较简单，不需要进行线程切换与复杂的数据变换，LiveData对你来说相信已经足够了


2. 如果你的数据流比较复杂，需要切换线程等操作，不需要发送重复值，需要获取myFlow.value，StateFlow对你来说是个好的选择


3. 如果你的数据流比较复杂，同时不需要获取myFlow.value，需要配置新用户订阅重播无素的个数，或者需要发送重复的值，可以考虑使用SharedFlow