人们经常忽略Iterable和Sequence之间的区别。这是可以理解的，因为即使它们的定义也几乎是相同的。

interface Iterable<out T> {
    operator fun iterator(): Iterator<T>
}

interface Sequence<out T> {
    operator fun iterator(): Iterator<T>
}

你可以说它们之间唯一的正式区别就是名字。尽管Iterable和Sequence有着完全不同的用途（有不同的契约），它们的处理函数几乎都以不同的方式工作。Sequence是Lazy的，所以Sequence处理的中间函数不做任何计算。相反，它们返回一个新的Sequence，用新的操作来装饰以前的Sequence。所有这些计算在终端操作（如toList或count）中被处理。而另一方面，Iterable的处理在每一步都会返回一个类似List的集合。

public inline fun <T> Iterable<T>.filter(
   predicate: (T) -> Boolean
): List<T> {
   return filterTo(ArrayList<T>(), predicate)
}

public fun <T> Sequence<T>.filter(
   predicate: (T) -> Boolean
): Sequence<T> {
   return FilteringSequence(this, true, predicate)
}

Sequence过滤器是一个中间操作，所以它不做任何计算，而是用新的处理步骤来装饰Sequence。计算是在终端操作中完成的，比如toList。

因此，集合处理操作一旦被使用就会被调用。Sequence处理函数直到终端操作（一个返回其他东西而不是Sequence的操作）才会被调用。例如，对于Sequence来说，filter是一个中间操作，所以它不做任何计算，而是用新的处理步骤来装饰Sequence。计算是在toList这样的终端操作中完成的。

val seq = sequenceOf(1,2,3)
val filtered = seq.filter { print("f$it "); it % 2 == 1 }
println(filtered)  // FilteringSequence@...val asList = filtered.toList() // f1 f2 f3
println(asList) // [1, 3]val list = listOf(1,2,3)
val listFiltered = list
  .filter { print("f$it "); it % 2 == 1 } // f1 f2 f3
println(listFiltered) // [1, 3]

在Kotlin中，Sequence是Lazy的，这有几个重要的优点。

它们保持了操作的自然顺序

它们只做最少的操作

它们可以是无限的

它们不需要在每个步骤中都创建集合

让我们来逐一讨论这些优点。

Order is important

由于iterable和Sequence处理的实现方式，它们的操作顺序是不同的。在Sequence处理中，我们取第一个元素并应用所有的操作，然后我们取下一个元素，以此类推。我们将其称为逐个元素或Lazy的顺序。在可迭代处理中，我们取第一个操作，并将其应用于整个集合，然后转到下一个操作。他们是一步一步被执行的。

sequenceOf(1,2,3)
       .filter { print("F$it, "); it % 2 == 1 }
       .map { print("M$it, "); it * 2 }
       .forEach { print("E$it, ") } // Prints: F1, M1, E2, F2, F3, M3, E6,listOf(1,2,3)
       .filter { print("F$it, "); it % 2 == 1 }
       .map { print("M$it, "); it * 2 }
       .forEach { print("E$it, ") } // Prints: F1, F2, F3, M1, M3, E2, E6,

请注意，如果我们不使用任何集合处理函数来实现这些操作，而是使用经典的循环和条件，我们就会像在Sequence处理中一样是逐个元素的顺序。

for (e in listOf(1,2,3)) {
   print("F$e, ")
   if(e % 2 == 1) {
       print("M$e, ")
       val mapped = e * 2
       print("E$mapped, ")
   }
}
// Prints: F1, M1, E2, F2, F3, M3, E6,

因此，在Sequence处理中使用的逐个元素的顺序是比较自然的。它还为低级别的编译器优化打开了大门--Sequence处理可以被优化为基本的循环和条件。也许在未来，它将是这样。

Sequences do the minimal number of operations

通常我们不需要在每一步都处理整个集合来产生结果。比方说，我们有一个有数百万个元素的集合，在处理之后，我们只需要取前10个。为什么要处理其他所有的元素呢？Iterable处理没有中间操作的概念，所以整个集合的处理就像在每个操作上都要返回一样。Sequence不需要这样，所以它们会做最小数量的操作来获得结果。

看一下这个例子，我们有几个处理步骤，我们用find来结束我们的处理。

(1..10).asSequence()
   .filter { print("F$it, "); it % 2 == 1 }
   .map { print("M$it, "); it * 2 }
   .find { it > 5 }
// Prints: F1, M1, F2, F3, M3,(1..10)
   .filter { print("F$it, "); it % 2 == 1 }
   .map { print("M$it, "); it * 2 }
   .find { it > 5 }
// Prints: F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, M1, M3, M5, M7, M9,

出于这个原因，当我们有一些中间处理步骤，并且我们的终端操作不一定需要遍历所有的元素时，使用一个Sequence很可能对你的处理性能更好。所有这些，同时看起来与标准的集合处理几乎一样。这类操作的例子有first, find, take, any, all, none或indexOf等。

Sequences can be infinite

由于Sequence是按需进行处理的，我们可以有无限的Sequence。创建一个无限Sequence的典型方法是使用Sequence生成器，如generateSequence或sequence。第一个生成器需要第一个元素和一个指定如何计算下一个元素的函数。

generateSequence(1) { it + 1 }
       .map { it * 2 }
       .take(10)
       .forEach { print("$it, ") }
// Prints: 2, 4, 6, 8, 10, 12, 14, 16, 18, 20,

第二个提到的Sequence生成器--sequence--使用一个suspend函数（coroutine），按要求生成下一个数字。每当我们要求下一个数字时，Sequence生成器就会运行，直到使用yield产生一个值。然后停止执行，直到我们要求得到另一个数字。下面是一个无限的下一个斐波那契数字的列表。

val fibonacci = sequence {
   yield(1)
   var current = 1
   var prev = 1
   while (true) {
       yield(current)
       val temp = prev
       prev = current
       current += temp
   }
}
print(fibonacci.take(10).toList()) 
// [1, 1, 2, 3, 5, 8, 13, 21, 34, 55]

请注意，无限Sequence在某些时候需要有有限的元素数量。我们不能在无穷大上迭代。

print(fibonacci.toList()) // Runs forever

因此，我们要么需要使用像take这样的操作来限制它们，要么需要使用一个不需要所有元素的终端操作，比如first、find、any、all、none或indexOf。基本上，这些都是Sequence更有效的操作，因为它们不需要处理所有元素。尽管注意到对于大多数这些操作来说，很容易陷入无限循环。any操作符只能返回true或者永远运行。同样，all和none操作符在一个无限的集合上也只能返回false。因此，我们通常要么通过take来限制元素的数量，要么就用first来要求第一个元素。

Sequences do not create collections at every processing step

标准的集合处理函数在每一步都会返回一个新的集合。大多数情况下，它是一个列表。这可能是一个优势--在每一个点之后，我们都有一些准备好的东西可以使用或存储。但它也是有代价的。这样的集合在每一步都需要被创建并填充数据。

numbers
   .filter { it % 10 == 0 } // 1 collection here
   .map { it * 2 } // 1 collection here
   .sum() 
// In total, 2 collections created under the hoodnumbers
   .asSequence()
   .filter { it % 10 == 0 }
   .map { it * 2 }
   .sum() 
// No collections created

这是个问题，特别是当我们处理大的或重的集合时。让我们从一个极端但又常见的案例开始：文件读取。文件可以达到数千兆字节。在每个处理步骤中分配一个集合中的所有数据将是对内存的巨大浪费。这就是为什么我们默认使用Sequence来处理文件。

作为一个例子，让我们分析一下芝加哥市的犯罪。这个城市和其他许多城市一样，在互联网上分享了自2001年以来发生在那里的全部犯罪数据库（你可以在www.data.cityofchicago.org找到这些记录）。这个数据集目前的Size超过1.53GB。比方说，我们的任务是找出有多少犯罪行为的描述中有大麻。下面就是一个使用集合处理的天真解决方案的样子（readLines返回List）。

// BAD SOLUTION, DO NOT USE COLLECTIONS FOR 
// POSSIBLY BIG FILES
File("ChicagoCrimes.csv").readLines()
   .drop(1) // Drop descriptions of the columns
   .mapNotNull { it.split(",").getOrNull(6) } 
    // Find description
   .filter { "CANNABIS" in it } 
   .count()
   .let(::println)

我的电脑上的结果是OutOfMemoryError。

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

不难理解为什么。我们创建了一个集合，然后我们有3个中间处理步骤，加起来有4个集合。其中3个包含了这个数据文件的大部分，需要1.53GB，所以它们都需要消耗超过4.59GB。这是对内存的巨大浪费。正确的实现应该是使用一个Sequence，我们使用函数useLines来实现，它总是在一个单行上操作。

File("ChicagoCrimes.csv").useLines { lines ->
// The type of `lines` is Sequence<String>
   lines
       .drop(1) // Drop descriptions of the columns
       .mapNotNull { it.split(",").getOrNull(6) } 
       // Find description
       .filter { "CANNABIS" in it } 
       .count()
       .let { println(it) } // 318185

在我的电脑上，这需要8.3秒。为了比较这两种方法的效率，我又做了一个实验，我通过删除不需要的列来减少这个数据集的大小。这样我就得到了CrimeData.csv文件，其中包含了同样的罪行，但大小只有728MB。然后我做了同样的处理。在第一个实现中，使用集合处理，大约需要13秒；而第二个实现中，使用Sequence，大约需要4.5秒。正如你所看到的，对较大的文件使用Sequence，不仅是为了内存，也是为了性能。

虽然一个集合不需要很重。事实上，每一步我们都在创建一个新的集合，这本身也是一种成本，当我们处理具有较大数量元素的集合时，这种成本就会体现出来。差别并不是非常巨大的原因是--主要是因为经过许多步骤创建的集合被初始化为预期的大小，所以当我们添加元素时，只是把它们放在下一个位置。但这种差异仍然是不可忽视的，这也是为什么我们更愿意使用Sequence来处理超过一个处理步骤的大集合的主要原因。

我所说的 "大集合 "是指许多元素和真正的大集合。它可能是一个有几万个元素的整数列表。它也可能是一个只有几个字符串的列表，但每个字符串都很长，以至于它们都需要很多兆字节的数据。这些情况并不常见，但它们有时会发生。

我所说的一个处理步骤，是指超过一个函数的集合处理。因此，如果你比较这两个函数。

fun singleStepListProcessing(): List<Product> {
   return productsList.filter { it.bought }
}

fun singleStepSequenceProcessing(): List<Product> {
   return productsList.asSequence()
           .filter { it.bought }
           .toList()
}

你会注意到在性能上几乎没有差别（实际上简单的列表处理更快，因为它的过滤功能是内联的）。尽管当你比较有多个处理步骤的函数时，比如下面的函数，它使用了过滤器，然后是Map，对于更大的集合来说，差异将是可见的。为了看到区别，让我们比较一下5000个产品的典型处理，有两个和三个处理步骤。

fun twoStepListProcessing(): List<Double> {
   return productsList
           .filter { it.bought }
           .map { it.price }
}

fun twoStepSequenceProcessing(): List<Double> {
   return productsList.asSequence()
           .filter { it.bought }
           .map { it.price }
           .toList()
}

fun threeStepListProcessing(): Double {
   return productsList
           .filter { it.bought }
           .map { it.price }
           .average()
}

fun threeStepSequenceProcessing(): Double {
   return productsList.asSequence()
           .filter { it.bought }
           .map { it.price }
           .average()
}

下面你可以看到在MacBook Pro（处理器2.6 GHz Intel Core i7，内存16 GB 1600 MHz DDR3）上对产品清单中5000个产品的平均结果。

twoStepListProcessing                        81 095 ns
twoStepSequenceProcessing                    55 685 ns
twoStepListProcessingAndAcumulate            83 307 ns
twoStepSequenceProcessingAndAcumulate         6 928 ns

很难预测我们应该期待什么样的性能改进。根据我的观察，在一个典型的有多个步骤的集合处理中，对于至少几千个元素，我们可以期望有20-40%左右的性能改进。

When aren’t sequences faster?

有一些操作我们不能从这种Sequence的使用中获益，因为我们必须对整个集合进行操作，sorted是Kotlin stdlib中的一个例子（目前是唯一的例子）。sorted使用了最佳实现。它将Sequence累积到List中，然后使用Java stdlib中的sort。缺点是，如果我们将其与在一个集合上的相同处理进行比较，这个积累过程需要一些额外的时间（尽管如果Iterable不是一个集合或数组，那么区别并不明显，因为它也需要进行积累）。

Sequence是否应该有sorted这样的方法是有争议的，因为Sequence流式的操作符中，只是部分操作符是Lazy的（当我们需要得到第一个元素时才进行计算），并且在无限的Sequence上不起作用。添加它是因为它是一个流行的函数，而且这样使用它要容易得多。尽管Kotlin开发者应该记住它的缺陷，特别是它不能用于无限Sequence。

generateSequence(0) { it + 1 }.take(10).sorted().toList() 
// [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
generateSequence(0) { it + 1 }.sorted().take(10).toList() 
// Infinite time. Does not return.

sorted是一个罕见的处理例子，它在Collection上比在Sequence上快。尽管如此，当我们做一些处理步骤和单一的排序函数（或其他需要在整个集合上工作的函数）时，我们可以期望使用Sequence处理来提高性能。

// Benchmarking measurement result: 150 482 ns
fun productsSortAndProcessingList(): Double {
   return productsList
           .sortedBy { it.price }
           .filter { it.bought }
           .map { it.price }
           .average()
}

// Benchmarking measurement result: 96 811 ns
fun productsSortAndProcessingSequence(): Double {
   return productsList.asSequence()
           .sortedBy { it.price }
           .filter { it.bought }
           .map { it.price }
           .average()
}

What about Java stream?

Java 8引入了流，允许集合处理。它们的行为和代码外观类似于Kotlin的Sequence。

productsList.asSequence()
       .filter { it.bought }
       .map { it.price }
       .average()productsList.stream()
       .filter { it.bought }
       .mapToDouble { it.price }
       .average()
       .orElse(0.0)

Java 8的流是Lazy的，在最后一个（终端）处理步骤中开始计算。Java流和KotlinSequence的三大区别如下。

KotlinSequence有更多的处理函数（因为它们被定义为扩展函数），它们通常更容易使用（这是由于KotlinSequence是在Java streams已经被使用时设计的--例如，我们可以使用toList()来收集，而不是collectors.toList()）。

Java流处理可以使用并行函数以并行模式启动。当我们的机器有多个经常未使用的内核时（这在现在很常见），这可以给我们带来巨大的性能提升。虽然要谨慎使用，因为这个功能有已知的隐患（问题来自于他们使用的常见的连接-分叉线程池。因为，一个Task可能会阻塞另一个Task。还有一个问题是单元素处理会阻塞其他元素。在此阅读更多信息：https://dzone.com/articles/think-twice-using-java-8）。

KotlinSequence可以在普通模块、Kotlin/JVM、Kotlin/JS和Kotlin/Native模块中使用。Java流只在Kotlin/JVM中使用，而且只在JVM版本至少为8时使用。

一般来说，当我们不使用并行模式时，很难给出一个简单的答案，Java流和KotlinSequence哪个更有效。我的建议是很少使用Java流，只在计算量大的处理中使用，这样可以从并行模式中获益。否则，使用Kotlin stdlib函数，以获得同质化的、干净的代码，可以在不同的平台上或共同的模块上使用。

Kotlin Sequence debugging

Kotlin Sequence和Java Stream都有支持，可以帮助我们在每一步调试元素流。对于Java Stream，它需要一个名为 "Java Stream Debugger "的插件。KotlinSequence也需要名为 "Kotlin Sequence Debugger "的插件，不过现在这个功能已经集成到Kotlin插件中了。下面是一个显示Sequence处理的每一步的屏幕。

Summary

Collection和Sequence的处理非常相似，都支持几乎相同的处理方法。然而这两者之间有重要的区别。Sequence处理更复杂，所以我们通常将元素保存在集合中，然后转换集合为Sequence，最后往往还需要回到所需的集合。但Sequence是Lazy的，这带来了一些重要的优势。

• 它们保持操作的自然顺序
• 它们只做最少的操作
• 它们可以是无限的
• 它们不需要在每一步都创建集合

因此，它们更适合于处理大尺寸的对象或具有多个处理步骤的大型集合。Sequence也得到了KotlinSequence调试器的支持，它可以帮助我们直观地看到元素的处理情况。Sequence不能取代经典的集合处理。你应该只在有充分理由的情况下使用它们，而且你会得到显著的性能优化的回报。

原文翻译自 https://blog.kotlin-academy.com/effective-kotlin-use-sequence-for-bigger-collections-with-more-than-one-processing-step-649a15bb4bf

在Android中，Handler是一个使用的非常频繁的东西，输入事件机制和系统状态，都通过Handler来进行流转，而在Handler中，有一个很少被人提起但是却很有用的东西，那就是IdleHandler，它的源码如下。

/**
 * Callback interface for discovering when a thread is going to block
 * waiting for more messages.
 */
public static interface IdleHandler {
    /**
     * Called when the message queue has run out of messages and will now
     * wait for more.  Return true to keep your idle handler active, false
     * to have it removed.  This may be called if there are still messages
     * pending in the queue, but they are all scheduled to be dispatched
     * after the current time.
     */
    boolean queueIdle();
}

从注释我们就能发现，这是一个IdleHandler的静态接口，可以在消息队列没有消息时或是队列中的消息还没有到执行时间时才会执行的一个回调。

这个功能在某些重要但不紧急的场景下就非常有用了，比如我们要在主页上做一些处理，但是又不想影响原有的初始化逻辑，避免卡顿，那么我们就需要等系统闲下来的时候再来执行我们的操作，这个时候，我们就可以通过IdleHandler来进行回调。

它的使用也非常简单，代码示例如下。

Looper.myQueue().addIdleHandler {
    // Do something
    false
}

在Handler的消息循环中，一旦队列里面没有需要处理的消息，该接口就会回调，也就是Handler空闲的时候。

这个接口有返回值，代表是否需要持续执行，如果返回true，那么一旦Handler空闲，就会执行IdleHandler中的回调，而如果返回false，那么就只会执行一次。

当返回true时，可以通过removeIdleHandler的方式来移除循环的处理，如果是false，那么在处理完后，它自己会移除。

综上，IdleHandler的使用主要有下面这些场景。

• 低优先级的任务处理：替换之前为了不在初始化的时候影响性能而使用的Handler.postDelayed方法，通过IdleHandler来自动获取空闲的时机。
• Idle时循环处理任务：通过控制返回值，在系统空闲时，不断重复某个操作。

但是要注意的是，如果Handler过于繁忙，那么IdleHandler的执行时机是有可能被延迟很久的，所以，要注意一些比较重要的处理逻辑的处理时机。

在很多第三方库里面，都有IdleHandler的使用，例如LeakCanary，它对内存的dump分析过程，就是在IdleHandler中处理的，从而避免对主线程的影响。

最后一篇文章，我们在掌握了如何读取状态值，并知道如何根据不同场景选择不同类型的Provider，以及如何对Provider进行搭配使用之后，再来了解一下它的一些其它特性，看看它们是如何帮助我们更好的进行状态管理的。

Provider Modifiers

所有的Provider都有一个内置的方法来为你的不同Provider添加额外的功能。

它们可以为 ref 对象添加新的功能，或者稍微改变Provider的consume方式。Modifiers可以在所有Provider上使用，其语法类似于命名的构造函数。

final myAutoDisposeProvider = StateProvider.autoDispose<int>((ref) => 0);
final myFamilyProvider = Provider.family<String, int>((ref, id) => '$id');

目前，有两个Modifiers可用。

• .autoDispose，这将使Provider在不再被监听时自动销毁其状态
• .family，它允许使用一个外部参数创建一个Provider

一个Provider可以同时使用多个Modifiers。

final userProvider = FutureProvider.autoDispose.family<User, int>((ref, userId) async {
  return fetchUser(userId);
});

.family

.family修饰符有一个目的：根据外部参数创建一个独特的Provider。family的一些常见用例是下面这些。

• 将FutureProvider与.family结合起来，从其ID中获取一个Message对象
• 将当前的Locale传递给Provider，这样我们就可以处理国际化

family的工作方式是通过向Provider添加一个额外的参数。然后，这个参数可以在我们的Provider中自由使用，从而创建一些状态。

例如，我们可以将family与FutureProvider结合起来，从其ID中获取一个Message。

final messagesFamily = FutureProvider.family<Message, String>((ref, id) async {
  return dio.get('http://my_api.dev/messages/$id');
});

当使用我们的 messagesFamily Provider时，语法会略有不同。

像下面这样的通常语法将不再起作用。

Widget build(BuildContext context, WidgetRef ref) {
  // Error – messagesFamily is not a provider
  final response = ref.watch(messagesFamily);
}

相反，我们需要向 messagesFamily 传递一个参数。

Widget build(BuildContext context, WidgetRef ref) {
  final response = ref.watch(messagesFamily('id'));
}

我们可以同时使用一个具有不同参数的变量。

例如，我们可以使用titleFamily来同时读取法语和英语的翻译。

@override
Widget build(BuildContext context, WidgetRef ref) {
final frenchTitle = ref.watch(titleFamily(const Locale('fr')));
final englishTitle = ref.watch(titleFamily(const Locale('en')));

return Text('fr: $frenchTitle en: $englishTitle');
}

参数限制

为了让families正确工作，传递给Provider的参数必须具有一致的hashCode和==。

理想情况下，参数应该是一个基础类型（bool/int/double/String），一个常数（Provider），或者一个重写==和hashCode的不可变的对象。

当参数不是常数时，更倾向于使用autoDispose

你可能想用family来传递一个搜索字段的输入，给你的Provider。但是这个值可能会经常改变，而且永远不会被重复使用。这可能导致内存泄漏，因为在默认情况下，即使不再使用，Provider也不会被销毁。

同时使用.family和.autoDispose就可以修复这种内存泄漏。

final characters = FutureProvider.autoDispose.family<List<Character>, String>((ref, filter) async {
  return fetchCharacters(filter: filter);
});

给family传递多重参数

family没有内置支持向一个Provider传递多个值的方法。另一方面，这个值可以是任何东西（只要它符合前面提到的限制）。

这包括下面这些类型。

• tuple类型，类似Python的元组，https://pub.dev/packages/tuple
• 用Freezed或build_value生成的对象，https://pub.dev/packages/freezed
• 使用equatable的对象，https://pub.dev/packages/equatable

下面是一个对多个参数使用Freezed或equatable的例子。

@freezed
abstract class MyParameter with _$MyParameter {
  factory MyParameter({
    required int userId,
    required Locale locale,
  }) = _MyParameter;
}

final exampleProvider = Provider.autoDispose.family<Something, MyParameter>((ref, myParameter) {
  print(myParameter.userId);
  print(myParameter.locale);
  // Do something with userId/locale
});

@override
Widget build(BuildContext context, WidgetRef ref) {
  int userId; // Read the user ID from somewhere
  final locale = Localizations.localeOf(context);

  final something = ref.watch(
    exampleProvider(MyParameter(userId: userId, locale: locale)),
  );

  ...
}

.autoDispose

它的一个常见的用例是，当一个Provider不再被使用时，要销毁它的状态。

这样做的原因有很多，比如下面这些场景。

• 当使用Firebase时，要关闭连接并避免不必要的费用
• 当用户离开一个屏幕并重新进入时，要重置状态

Provider通过.autoDisposeModifiers内置了对这种使用情况的支持。

要告诉Riverpod当它不再被使用时销毁一个Provider的状态，只需将.autoDispose附加到你的Provider上即可。

final userProvider = StreamProvider.autoDispose<User>((ref) {

});

就这样了。现在，userProvider的状态将在不再使用时自动被销毁。

注意通用参数是如何在autoDispose之后而不是之前传递的--autoDispose不是一个命名的构造函数。

如果需要，你可以将.autoDispose与其他Modifiers结合起来。

final userProvider = StreamProvider.autoDispose.family<User, String>((ref, id) {

});

ref.keepAlive

用autoDispose标记一个Provider时，也会在ref上增加了一个额外的方法：keepAlive。

keep函数是用来告诉Riverpod，即使不再被监听，Provider的状态也应该被保留下来。

它的一个用例是在一个HTTP请求完成后，将这个标志设置为true。

final myProvider = FutureProvider.autoDispose((ref) async {
  final response = await httpClient.get(...);
  ref.keepAlive();
  return response;
});

这样一来，如果请求失败，UI离开屏幕然后重新进入屏幕，那么请求将被再次执行。但如果请求成功完成，状态将被保留，重新进入屏幕将不会触发新的请求。

示例：当Http请求不再使用时自动取消

autoDisposeModifiers可以与FutureProvider和ref.onDispose相结合，以便在不再需要HTTP请求时轻松取消。

我们的目标是：

• 当用户进入一个屏幕时启动一个HTTP请求
• 如果用户在请求完成前离开屏幕，则取消HTTP请求
• 如果请求成功，离开并重新进入屏幕不会启动一个新的请求

在代码中，这将是下面这样。

final myProvider = FutureProvider.autoDispose((ref) async {
  // An object from package:dio that allows cancelling http requests
  final cancelToken = CancelToken();
  // When the provider is destroyed, cancel the http request
  ref.onDispose(() => cancelToken.cancel());

  // Fetch our data and pass our `cancelToken` for cancellation to work
  final response = await dio.get('path', cancelToken: cancelToken);
  // If the request completed successfully, keep the state
  ref.keepAlive();
  return response;
});

异常

当使用.autoDispose时，你可能会发现自己的应用程序无法编译，出现类似下面的错误。

The argument type 'AutoDisposeProvider' can't be assigned to the parameter type 'AlwaysAliveProviderBase'

不要担心! 这个错误是正常的。它的发生是因为你很可能有一个bug。

例如，你试图在一个没有标记为.autoDispose的Provider中监听一个标记为.autoDispose的Provider，比如下面的代码。

final firstProvider = Provider.autoDispose((ref) => 0);

final secondProvider = Provider((ref) {
  // The argument type 'AutoDisposeProvider<int>' can't be assigned to the
  // parameter type 'AlwaysAliveProviderBase<Object, Null>'
  ref.watch(firstProvider);
});

这是不可取的，因为这将导致firstProvider永远不会被dispose。

为了解决这个问题，可以考虑用.autoDispose标记secondProvider。

final firstProvider = Provider.autoDispose((ref) => 0);

final secondProvider = Provider.autoDispose((ref) {
  ref.watch(firstProvider);
});

provider状态关联与整合

我们之前已经看到了如何创建一个简单的Provider。但实际情况是，在很多情况下，一个Provider会想要读取另一个Provider的状态。

要做到这一点，我们可以使用传递给我们Provider的回调的ref对象，并使用其watch方法。

作为一个例子，考虑下面的Provider。

final cityProvider = Provider((ref) => 'London');

我们现在可以创建另一个Provider，它将消费我们的cityProvider。

final weatherProvider = FutureProvider((ref) async {
  // We use `ref.watch` to listen to another provider, and we pass it the provider
  // that we want to consume. Here: cityProvider
  final city = ref.watch(cityProvider);

  // We can then use the result to do something based on the value of `cityProvider`.
  return fetchWeather(city: city);
});

这就是了。我们已经创建了一个依赖另一个Provider的Provider。

这个其实在前面的例子中已经讲到了，ref是可以连接多个不同的Provider的，这是Riverpod非常灵活的一个体现。

FAQ

What if the value being listened to changes over time?

根据你正在监听的Provider，获得的值可能会随着时间的推移而改变。例如，你可能正在监听一个StateNotifierProvider，或者被监听的Provider可能已经通过使用ProviderContainer.refresh/ref.refresh强制刷新。

当使用watch时，Riverpod能够检测到被监听的值发生了变化，并将在需要时自动重新执行Provider的创建回调。

这对计算的状态很有用。例如，考虑一个暴露了todo-list的StateNotifierProvider。

class TodoList extends StateNotifier<List<Todo>> {
  TodoList(): super(const []);
}

final todoListProvider = StateNotifierProvider((ref) => TodoList());

一个常见的用例是让用户界面过滤todos的列表，只显示已完成/未完成的todos。

实现这种情况的一个简单方法是。

• 创建一个StateProvider，它暴露了当前选择的过滤方法。

enum Filter {
  none,
  completed,
  uncompleted,
}

final filterProvider = StateProvider((ref) => Filter.none);

• 做一个单独的Provider，把过滤方法和todo-list结合起来，暴露出过滤后的todo-list。

final filteredTodoListProvider = Provider<List<Todo>>((ref) {
  final filter = ref.watch(filterProvider);
  final todos = ref.watch(todoListProvider);

  switch (filter) {
    case Filter.none:
      return todos;
    case Filter.completed:
      return todos.where((todo) => todo.completed).toList();
    case Filter.uncompleted:
      return todos.where((todo) => !todo.completed).toList();
  }
});

然后，我们的用户界面可以监听filteredTodoListProvider来监听过滤后的todo-list。使用这种方法，当过滤器或todo-list发生变化时，用户界面将自动更新。

要看到这种方法的作用，你可以看一下Todo List例子的源代码。

这种行为不是特定于Provider的，它适用于所有的Provider。

例如，你可以将watch与FutureProvider结合起来，实现一个支持实时配置变化的搜索功能。

// The current search filter
final searchProvider = StateProvider((ref) => '');

/// Configurations which can change over time
final configsProvider = StreamProvider<Configuration>(...);

final charactersProvider = FutureProvider<List<Character>>((ref) async {
  final search = ref.watch(searchProvider);
  final configs = await ref.watch(configsProvider.future);
  final response = await dio.get('${configs.host}/characters?search=$search');

  return response.data.map((json) => Character.fromJson(json)).toList();
});

这段代码将从服务中获取一个字符列表，并在配置改变或搜索查询改变时自动重新获取该列表。

Can I read a provider without listening to it?

有时，我们想读取一个Provider的内容，但在获得的值发生变化时不需要重新创建值。

一个例子是一个 Repository，它从另一个Provider那里读取用户token用于认证。

我们可以使用观察并在用户token改变时创建一个新的 Repository，但这样做几乎没有任何用处。

在这种情况下，我们可以使用read，这与listen类似，但不会导致Provider在获得的值改变时重新创建它的值。

在这种情况下，一个常见的做法是将ref.read传递给创建的对象。然后，创建的对象将能够随时读取Provider。

final userTokenProvider = StateProvider<String>((ref) => null);

final repositoryProvider = Provider((ref) => Repository(ref.read));

class Repository {
  Repository(this.read);

  /// The `ref.read` function
  final Reader read;

  Future<Catalog> fetchCatalog() async {
    String token = read(userTokenProvider);

    final response = await dio.get('/path', queryParameters: {
      'token': token,
    });

    return Catalog.fromJson(response.data);
  }
}

你也可以把ref而不是ref.read传给你的对象。

final repositoryProvider = Provider((ref) => Repository(ref));

class Repository {
  Repository(this.ref);

  final Ref ref;
}

传递ref.read带来的唯一区别是，它略微不那么冗长，并确保我们的对象永远不会使用ref.watch。

但是，永远不要像下面这样做。

final myProvider = Provider((ref) {
  // Bad practice to call `read` here
  final value = ref.read(anotherProvider);
});

如果你使用read作为尝试去避免太多的刷新重建，可以参考后面的FAQ

How to test an object that receives read as a parameter of its constructor?

如果你正在使用《我可以在不监听Provider的情况下读取它吗》中描述的模式，你可能想知道如何为你的对象编写测试。

在这种情况下，考虑直接测试Provider而不是原始对象。你可以通过使用ProviderContainer类来做到这一点。

final repositoryProvider = Provider((ref) => Repository(ref.read));

test('fetches catalog', () async {
  final container = ProviderContainer();
  addTearOff(container.dispose);

  Repository repository = container.read(repositoryProvider);

  await expectLater(
    repository.fetchCatalog(),
    completion(Catalog()),
  );
});

My provider updates too often, what can I do?

如果你的对象被重新创建得太频繁，你的Provider很可能在监听它不关心的对象。

例如，你可能在监听一个配置对象，但只使用host属性。

通过监听整个配置对象，如果host以外的属性发生变化，这仍然会导致你的Provider被重新评估--这可能是不希望的。

这个问题的解决方案是创建一个单独的Provider，只公开你在配置中需要的东西（所以是host）。

应当避免像下面的代码一样，对整个对象进行监听。

final configProvider = StreamProvider<Configuration>(...);

final productsProvider = FutureProvider<List<Product>>((ref) async {
  // Will cause productsProvider to re-fetch the products if anything in the
  // configurations changes
  final configs = await ref.watch(configProvider.future);

  return dio.get('${configs.host}/products');
});

当你只需要一个对象的单一属性时，更应该使用select。

final configProvider = StreamProvider<Configuration>(...);

final productsProvider = FutureProvider<List<Product>>((ref) async {
  // Listens only to the host. If something else in the configurations
  // changes, this will not pointlessly re-evaluate our provider.
  final host = await ref.watch(configProvider.selectAsync((config) => config.host));

  return dio.get('$host/products');
});

这将只在host发生变化时重建 productsProvider。

通过这三篇文章，相信大家已经能熟练的对Riverpod进行使用了，相比package:Provider，Riverpod的使用更加简单和灵活，这也是我推荐它的一个非常重要的原因，在入门之后，大家可以根据文档中作者提供的示例来进行学习，充分的了解Riverpod在实战中的使用技巧。

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

前面一篇文章，我们了解了如何正确的去读取状态值，这一篇，我们来了解下不同的Provider都有哪些使用场景。这篇文章，我们将真正的深入了解，如何在不同的场景下，选择合适的种类的Provider，以及这些不同类型的Provider，都有哪些作用。

不同类型的Provider

Provider有多种类型的变种，可以用于多种不同的使用场景。

在所有这些Provider中，有时很难理解何时使用一种Provider类型而不是另一种。使用下面的表格，选择一个适合你想提供给Widget树的Provider。

Provider Type	Provider Create Function	Example Use Case
Provider	Returns any type	A service class / computed property (filtered list)
StateProvider	Returns any type	A filter condition / simple state object
FutureProvider	Returns a Future of any type	A result from an API call
StreamProvider	Returns a Stream of any type	A stream of results from an API
StateNotifierProvider	Returns a subclass of StateNotifier	A complex state object that is immutable except through an interface
ChangeNotifierProvider	Returns a subclass of ChangeNotifier	A complex state object that requires mutability

虽然所有的Provider都有他们的目的，但ChangeNotifierProviders不被推荐用于可扩展的应用程序，因为它存在可变的状态问题。它存在于flutter_riverpod包中，以提供一个简单的从package:provider的迁移组件，并允许一些flutter特定的使用情况，如与一些Navigator 2包的集成。

Provider

Provider是所有Providers中最基本的。它返回了一个Value... 仅此而已。

Provider通常用于下面的场景。

• 缓存计算后的值
• 将一个值暴露给其他Provider（比如Repository/HttpClient)
• 提供了一个可供测试的覆写Provider
• 通过不使用select，来减少Provider/widget的重建

通过Provider来对计算值进行缓存

当与ref.watch结合时，Provider是一个强大的工具，用于缓存同步操作。

一个典型的例子是过滤一个todos的列表。由于过滤一个列表的成本较高，我们最好不要在我们的应用程序每次需要重新渲染的时候，就过滤一次我们的todos列表。在这种情况下，我们可以使用Provider来为我们做过滤工作。

为此，假设我们的应用程序有一个现有的StateNotifierProvider，它管理一个todos列表。

class Todo {
  Todo(this.description, this.isCompleted);
  final bool isCompleted;
  final String description;
}

class TodosNotifier extends StateNotifier<List<Todo>> {
  TodosNotifier() : super([]);

  void addTodo(Todo todo) {
    state = [...state, todo];
  }
  // TODO add other methods, such as "removeTodo", ...
}

final todosProvider = StateNotifierProvider<TodosNotifier, List<Todo>>((ref) {
  return TodosNotifier();
});

在这里，我们可以使用Provider来管理一个过滤后的todos列表，只显示已完成的todos。

final completedTodosProvider = Provider<List<Todo>>((ref) {
  // We obtain the list of all todos from the todosProvider
  final todos = ref.watch(todosProvider);

  // we return only the completed todos
  return todos.where((todo) => todo.isCompleted).toList();
});

有了这段代码，我们的用户界面现在能够通过监听 completedTodosProvider来显示已完成的todos列表。

Consumer(builder: (context, ref, child) {
  final completedTodos = ref.watch(completedTodosProvider);
  // TODO show the todos using a ListView/GridView/...
});

有趣的是，现在的过滤后的列表是被缓存的。这意味着在添加/删除/更新todos之前，已完成的todos列表不会被重新计算，即使我们多次读取已完成的todos列表。

请注意，当todos列表发生变化时，我们不需要手动使缓存失效。由于有了ref.watch，Provider能够自动知道何时必须重新计算结果。

通过Provider来减少provider/widget的重建

Provider的一个独特之处在于，即使Provider被重新计算（通常在使用ref.watch时），它也不会更新监听它的widgets/providers，除非其值发生了变化。

一个真实的例子是启用/禁用一个分页视图的上一个/下一个按钮。

在我们的案例中，我们将特别关注 "上一页 "按钮。这种按钮的一个普通的实现，是一个获得当前页面索引的Widget，如果该索引等于0，我们将禁用该按钮。

这段代码可以是这样。

final pageIndexProvider = StateProvider<int>((ref) => 0);

class PreviousButton extends ConsumerWidget {
  const PreviousButton({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // if not on first page, the previous button is active
    final canGoToPreviousPage = ref.watch(pageIndexProvider) != 0;

    void goToPreviousPage() {
      ref.read(pageIndexProvider.notifier).update((state) => state - 1);
    }

    return ElevatedButton(
      onPressed: canGoToPreviousPage ? null : goToPreviousPage,
      child: const Text('previous'),
    );
  }
}

这段代码的问题是，每当我们改变当前页面时，"上一页 "按钮就会重新Build。在理想的世界里，我们希望这个按钮只在激活和停用之间变化时才重新build。

这里问题的根源在于，我们正在计算用户是否被允许在 "上一页 "按钮中直接转到上一页。

解决这个问题的方法是把这个逻辑从widget中提取出来，放到一个Provider中。

final pageIndexProvider = StateProvider<int>((ref) => 0);

// A provider which computes whether the user is allowed to go to the previous page
final canGoToPreviousPageProvider = Provider<bool>((ref) {
  return ref.watch(pageIndexProvider) != 0;
});

class PreviousButton extends ConsumerWidget {
  const PreviousButton({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // We are now watching our new Provider
    // Our widget is no longer calculating whether we can go to the previous page.
    final canGoToPreviousPage = ref.watch(canGoToPreviousPageProvider);

    void goToPreviousPage() {
      ref.read(pageIndexProvider.notifier).update((state) => state - 1);
    }

    return ElevatedButton(
      onPressed: canGoToPreviousPage ? null : goToPreviousPage,
      child: const Text('previous'),
    );
  }
}

通过这个小的重构，我们的PreviousButton Widget将不会在页面索引改变时重建，这都要归功于Provider的缓存作用。

从现在开始，当页面索引改变时，我们的canGoToPreviousPageProviderProvider将被重新计算。但是如果Provider暴露的值没有变化，那么PreviousButton将不会重建。

这个变化既提高了我们的按钮的性能，又有一个有趣的好处，就是把逻辑提取到我们的Widget之外。

StateProvider

我们再来看下StateProvider，它是一个公开了修改其状态的方法的Provider。它是StateNotifierProvider的简化版，旨在避免为非常简单的用例编写一个StateNotifier类。

StateProvider的存在主要是为了允许用户对简单的变量进行修改。一个StateProvider所维护的状态通常是下面几种。

• 一个枚举，比如一个filter，用来做筛选
• 一个字符串，通常是一些固定的文本，可以借助family关键字来做Switch
• 一个布尔值，用于checkbox这类的状态切换
• 一个数字，用于分页或者Pager的Index

而下面这些场景，就不适合使用StateProvider。

• 你的状态中包含对校验逻辑
• 你的状态是一个复杂的对象，比如一个自定义类，一个List、Map等
• 状态的修改逻辑比较复杂

对于这些场景，你可以考虑使用StateNotifierProvider代替，并创建一个StateNotifier类。

虽然StateNotifierProvider的模板代码会多一些，但拥有一个自定义的StateNotifier类对于项目的长期可维护性至关重要--因为它将你的状态的业务逻辑集中在一个地方。

由此，我们可以了解，Riverpod最合适的场景，就是「单一状态值的管理」。例如，PageView的切换Index、ListView的切换Index，或者是CheckBox、dropdown的内容改变监听，这些是非常适合用StateProvider的。

一个filter的示例

官方给出了一个dropdown的例子，用来演示如何根据filter来修改列表的排序。

StateProvider在现实世界中的一个使用案例是管理简单表单组件的状态，如dropdown/text fields/checkboxes。特别是，我们将看到如何使用StateProvider来实现一个允许改变产品列表排序方式的dropdown。为了简单起见，我们将获得的产品列表将直接在应用程序中建立，其内容如下。

class Product {
  Product({required this.name, required this.price});

  final String name;
  final double price;
}

final _products = [
  Product(name: 'iPhone', price: 999),
  Product(name: 'cookie', price: 2),
  Product(name: 'ps5', price: 500),
];

final productsProvider = Provider<List<Product>>((ref) {
  return _products;
});

在现实世界的应用中，这个列表通常是通过使用FutureProvider进行网络请求来获得的，然后，用户界面可以显示产品列表，就像下面这样。

Widget build(BuildContext context, WidgetRef ref) {
  final products = ref.watch(productsProvider);
  return Scaffold(
    body: ListView.builder(
      itemCount: products.length,
      itemBuilder: (context, index) {
        final product = products[index];
        return ListTile(
          title: Text(product.name),
          subtitle: Text('${product.price} \$'),
        );
      },
    ),
  );
}

由于这里是写死了products，所以使用Provider来作为数据Provider，是一个很好的选择。

现在我们已经完成了基础框架，我们可以添加一个dropdown，这将允许我们通过价格或名称来过滤产品。为此，我们将使用DropDownButton。

// An enum representing the filter type
enum ProductSortType {
  name,
  price,
}

Widget build(BuildContext context, WidgetRef ref) {
  final products = ref.watch(productsProvider);
  return Scaffold(
    appBar: AppBar(
      title: const Text('Products'),
      actions: [
        DropdownButton<ProductSortType>(
          value: ProductSortType.price,
          onChanged: (value) {},
          items: const [
            DropdownMenuItem(
              value: ProductSortType.name,
              child: Icon(Icons.sort_by_alpha),
            ),
            DropdownMenuItem(
              value: ProductSortType.price,
              child: Icon(Icons.sort),
            ),
          ],
        ),
      ],
    ),
    body: ListView.builder(
      // ... 
    ),
  );
}

现在我们有了一个dropdown，让我们创建一个StateProvider并将dropdown的状态与我们的StateProvider同步。首先，让我们创建StateProvider。

final productSortTypeProvider = StateProvider<ProductSortType>(
  // We return the default sort type, here name.
  (ref) => ProductSortType.name,
);

然后我们可以通过下面这个方式，将StateProvider和dropdown联系起来。

DropdownButton<ProductSortType>(
  // When the sort type changes, this will rebuild the dropdown
  // to update the icon shown.
  value: ref.watch(productSortTypeProvider),
  // When the user interacts with the dropdown, we update the provider state.
  onChanged: (value) =>
      ref.read(productSortTypeProvider.notifier).state = value!,
  items: [
    // ...
  ],
),

有了这个，我们现在应该能够改变排序类型。不过，这对产品列表还没有影响。现在是最后一个部分了。更新我们的productsProvider来对产品列表进行排序。

实现这一点的一个关键部分是使用ref.watch，让我们的productProvider获取排序类型，并在排序类型改变时重新计算产品列表。实现的方法如下。

final productsProvider = Provider<List<Product>>((ref) {
  final sortType = ref.watch(productSortTypeProvider);
  switch (sortType) {
    case ProductSortType.name:
      return _products.sorted((a, b) => a.name.compareTo(b.name));
    case ProductSortType.price:
      return _products.sorted((a, b) => a.price.compareTo(b.price));
  }
});

这就是全部代码，这一改变足以让用户界面在排序类型改变时自动重新对产品列表进行排序。

更新状态的简化

参考下面的这个场景，有时候，我们需要根据前一个状态值，来修改后续的状态值，例如Flutter Demo中的加数器。

final counterProvider = StateProvider<int>((ref) => 0);

class HomeView extends ConsumerWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return Scaffold(
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          // We're updating the state from the previous value, we ended-up reading
          // the provider twice!
          ref.read(counterProvider.notifier).state = ref.read(counterProvider.notifier).state + 1;
        },
      ),
    );
  }
}

这种更新State的方法，我们可以使用update函数来简化，简化之后，代码如下。

ref.read(counterProvider.notifier).update((state) => state + 1);

所以，如果是对StateProvider的state进行赋值，那么直接使用下面的代码即可。

ref.read(counterProvider.notifier).state = xxxx

那么如果是根据前置状态的值来修改状态值，则可以使用update来简化。

StateNotifierProvider

StateNotifierProvider是一个用于监听和管理StateNotifier的Provider。StateNotifierProvider和StateNotifier是Riverpod推荐的解决方案，用于管理可能因用户交互而改变的状态。

它通常被用于下面这些场景。

• 暴露一个不可变的，跟随时间和行为而发生改变的状态
• 将修改某些状态的逻辑（又称 "业务逻辑"）集中在一个地方，提高长期的可维护性

作为一个使用例子，我们可以使用StateNotifierProvider来实现一个todo-list。这样做可以让我们暴露出诸如addTodo这样的方法，让UI在用户交互中修改todos列表。

// The state of our StateNotifier should be immutable.
// We could also use packages like Freezed to help with the implementation.
@immutable
class Todo {
  const Todo({required this.id, required this.description, required this.completed});

  // All properties should be `final` on our class.
  final String id;
  final String description;
  final bool completed;

  // Since Todo is immutable, we implement a method that allows cloning the
  // Todo with slightly different content.
  Todo copyWith({String? id, String? description, bool? completed}) {
    return Todo(
      id: id ?? this.id,
      description: description ?? this.description,
      completed: completed ?? this.completed,
    );
  }
}

// The StateNotifier class that will be passed to our StateNotifierProvider.
// This class should not expose state outside of its "state" property, which means
// no public getters/properties!
// The public methods on this class will be what allow the UI to modify the state.
class TodosNotifier extends StateNotifier<List<Todo>> {
  // We initialize the list of todos to an empty list
  TodosNotifier(): super([]);

  // Let's allow the UI to add todos.
  void addTodo(Todo todo) {
    // Since our state is immutable, we are not allowed to do `state.add(todo)`.
    // Instead, we should create a new list of todos which contains the previous
    // items and the new one.
    // Using Dart's spread operator here is helpful!
    state = [...state, todo];
    // No need to call "notifyListeners" or anything similar. Calling "state ="
    // will automatically rebuild the UI when necessary.
  }

  // Let's allow removing todos
  void removeTodo(String todoId) {
    // Again, our state is immutable. So we're making a new list instead of
    // changing the existing list.
    state = [
      for (final todo in state)
        if (todo.id != todoId) todo,
    ];
  }

  // Let's mark a todo as completed
  void toggle(String todoId) {
    state = [
      for (final todo in state)
        // we're marking only the matching todo as completed
        if (todo.id == todoId)
          // Once more, since our state is immutable, we need to make a copy
          // of the todo. We're using our `copyWith` method implemented before
          // to help with that.
          todo.copyWith(completed: !todo.completed)
        else
          // other todos are not modified
          todo,
    ];
  }
}

// Finally, we are using StateNotifierProvider to allow the UI to interact with
// our TodosNotifier class.
final todosProvider = StateNotifierProvider<TodosNotifier, List<Todo>>((ref) {
  return TodosNotifier();
});

现在我们已经定义了一个StateNotifierProvider，我们可以用它来与用户界面中的todos列表进行交互。

class TodoListView extends ConsumerWidget {
  const TodoListView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // rebuild the widget when the todo list changes
    List<Todo> todos = ref.watch(todosProvider);

    // Let's render the todos in a scrollable list view
    return ListView(
      children: [
        for (final todo in todos)
          CheckboxListTile(
            value: todo.completed,
            // When tapping on the todo, change its completed status
            onChanged: (value) => ref.read(todosProvider.notifier).toggle(todo.id),
            title: Text(todo.description),
          ),
      ],
    );
  }
}

FutureProvider

FutureProvider相当于Provider，但仅用于异步代码。

FutureProvider通常用于下面这些场景。

• 执行和缓存异步操作（如网络请求）
• 更好地处理异步操作的错误、加载状态
• 将多个异步值合并为另一个值

FutureProvider在与ref.watch结合时收获颇丰。这种组合允许在一些变量发生变化时自动重新获取一些数据，确保我们始终拥有最新的值。

FutureProvider不提供在用户交互后直接修改计算的方法。它被设计用来解决简单的用例。

对于更高级的场景，可以考虑使用StateNotifierProvider。

示例：读取一个配置文件

FutureProvider可以作为一种方便的方式来管理一个通过读取JSON文件创建的配置对象。

创建配置将用典型的async/await语法完成，但在Provider内部。使用Flutter的asset，这将是下面的代码。

final configProvider = FutureProvider<Configuration>((ref) async {
  final content = json.decode(
    await rootBundle.loadString('assets/configurations.json'),
  ) as Map<String, Object?>;

  return Configuration.fromJson(content);
});

然后，用户界面可以像这样监听配置。

Widget build(BuildContext context, WidgetRef ref) {
  AsyncValue<Configuration> config = ref.watch(configProvider);

  return config.when(
    loading: () => const CircularProgressIndicator(),
    error: (err, stack) => Text('Error: $err'),
    data: (config) {
      return Text(config.host);
    },
  );
}

这将在Future完成后自动重建UI。同时，如果多个widget想要这些解析值，asset将只被解码一次。

正如你所看到的，监听Widget内的FutureProvider会返回一个AsyncValue - 它允许处理错误/加载状态。

StreamProvider

StreamProvider类似于FutureProvider，但用于Stream而不是Future。

StreamProvider通常被用于下面这些场景。

• 监听Firebase或web-sockets
• 每隔几秒钟重建另一个Provider

由于Streams自然地暴露了一种监听更新的方式，有些人可能认为使用StreamProvider的价值很低。特别是，你可能认为Flutter的StreamBuilder也能很好地用于监听Stream，但这是一个错误。

使用StreamProvider而不是StreamBuilder有许多好处。

• 它允许其他Provider使用ref.watch来监听Stream
• 由于AsyncValue的存在，它可以确保加载和错误情况得到正确处理
• 它消除了区分broadcast streams和normal stream的需要
• 它缓存了stream所发出的最新值，确保如果在事件发出后添加了监听器，监听器仍然可以立即访问最新的事件
• 它允许在测试中通过覆盖StreamProvider的方式来mock stream

ChangeNotifierProvider

ChangeNotifierProvider是一个用来管理Flutter中的ChangeNotifier的Provider。

Riverpod不鼓励使用ChangeNotifierProvider，它的存在主要是为了下面这些场景。

• 从package:provider的代码迁移到Riverpod时，替代原有的ChangeNotifierProvider
• 支持可变的状态管理，但是，不可变的状态是首选推荐的

更倾向于使用StateNotifierProvider来代替。

只有当你绝对确定你想要可变的状态时，才考虑使用ChangeNotifierProvider。

使用可变的状态而不是不可变的状态有时会更有效率。但缺点是，它可能更难维护，并可能破坏各种功能。

例如，如果你的状态是可变的，使用provider.select来优化Widget的重建可能就会失效，因为select会认为值没有变化。

因此，使用不可变的数据结构有时会更快。而且，针对你的用例进行基准测试很重要，以确保你通过使用ChangeNotifierProvider真正获得了性能。

作为一个使用例子，我们可以使用ChangeNotifierProvider来实现一个todo-list。这样做将允许我们公开诸如addTodo的方法，让UI在用户交互中修改todos列表。

class Todo {
  Todo({
    required this.id,
    required this.description,
    required this.completed,
  });

  String id;
  String description;
  bool completed;
}

class TodosNotifier extends ChangeNotifier {
  final todos = <Todo>[];

  // Let's allow the UI to add todos.
  void addTodo(Todo todo) {
    todos.add(todo);
    notifyListeners();
  }

  // Let's allow removing todos
  void removeTodo(String todoId) {
    todos.remove(todos.firstWhere((element) => element.id == todoId));
    notifyListeners();
  }

  // Let's mark a todo as completed
  void toggle(String todoId) {
    for (final todo in todos) {
      if (todo.id == todoId) {
        todo.completed = !todo.completed;
        notifyListeners();
      }
    }
  }
}

// Finally, we are using StateNotifierProvider to allow the UI to interact with
// our TodosNotifier class.
final todosProvider = ChangeNotifierProvider<TodosNotifier>((ref) {
  return TodosNotifier();
});

现在我们已经定义了一个ChangeNotifierProvider，我们可以用它来与用户界面中的todos列表进行交互。

class TodoListView extends ConsumerWidget {
  const TodoListView({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // rebuild the widget when the todo list changes
    List<Todo> todos = ref.watch(todosProvider).todos;

    // Let's render the todos in a scrollable list view
    return ListView(
      children: [
        for (final todo in todos)
          CheckboxListTile(
            value: todo.completed,
            // When tapping on the todo, change its completed status
            onChanged: (value) =>
                ref.read(todosProvider.notifier).toggle(todo.id),
            title: Text(todo.description),
          ),
      ],
    );
  }
}

这些不同类型的各种Provider，就是我们的军火库，我们需要根据不同的场景和它们的特性来选择不同的「武器」，通过文中给出的例子，相信大家能够很好的理解它们的作用了。

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

熟悉我的朋友应该都知道，我好几年前写过一个「Flutter状态管理之路」系列，那个时候介绍的是Provider，这也是官方推荐的状态管理工具，但当时没有写完，因为写着写着，觉得有很多地方不尽人意，用着很别扭，所以在写了7篇文章之后，就暂时搁置了。

一晃时间过了这么久，Flutter内部依然没有一个能够碾压一切的状态管理框架，GetX可能是，但是我觉得不是，InheritedWidget系的状态管理，才应该是正统的状态管理。

最近在留意Provider的后续进展时，意外发现了一个新的库——Riverpod，号称是新一代的状态管理工具，仔细一看，嘿，居然还是Provider的作者，好家伙，这是搬起石头砸自己的脚啊。

就像作者所说，Riverpod就是对Provider的重写，可不是吗，字母都没变，就换了个顺序，这名字也是取的博大精深。

其实Provider在使用上已经非常不错了，只不过随着Flutter的更加深入，大家对它的需求也就越来越高，特别是对Provider中因为InheritedWidget层次问题导致的异常和BuildContext的使用这些问题诟病很多，而Riverpod，正是在Provider的基础上，探索出了一条心的状态管理之路。

大家可以先把官方文档看一看 https://riverpod.dev ，看完之后发现还是一脸懵逼，那就对了，Riverpod和Provider一样，有很多类型的Provider，分别用于不同的场景，所以，理清这些Provider的不同作用和使用场景，对于我们用好Riverpod是非常有帮助的。

官网的文档，虽然是作者精心编写的，但它的教程，站在的是一个创作者的角度，所以很多入门的初学者看上去会有点摸不清方向，所以，这才有了这个系列的文章。

我将在这个系列中，带领大家对文档进行一次精读，进行一次赏析，本文不全是对文档的翻译，而且讲解的顺序也不一样，所以，如果你想入门Riverpod进行状态管理，那么本文一定是你的最佳选择。

Provider第一眼

首先，我们为什么要进行状态管理，状态管理是解决申明式UI开发，关于数据状态的一个处理操作，例如Widget A依赖于同级的Widget B的数据，那么这个时候，就只能把数据状态上提到它们的父类，但是这样比较麻烦，Riverpod和Provider这样的状态管理框架，就是为了解决类似的问题而产生的。

将一个state包裹在一个Provider中可以有下面一些好处。

• 允许在多个位置轻松访问该状态。Provider可以完全替代Singletons、Service Locators、依赖注入或InheritedWidgets等模式
• 简化了这个状态与其他状态的结合，你有没有为，如何把多个对象合并成一个而苦恼过？这种场景可以直接在Provider内部实现
• 实现了性能优化。无论是过滤Widget的重建，还是缓存昂贵的状态计算；Provider确保只有受状态变化影响的部分才被重新计算
• 增加了你的应用程序的可测试性。使用Provider，你不需要复杂的setUp/tearDown步骤。此外，任何Provider都可以被重写，以便在测试期间有不同的行为，这可以轻松地测试一个非常具体的行为
• 允许与高级功能轻松集成，如logging或pull-to-refresh

首先，我们通过一个简单的例子，来感受下，Riverpod是怎么进行状态管理的。

Provider是Riverpod应用程序中最重要的部分。Provider是一个对象，它封装了一个state并允许监听该state。Provider有很多变体形式，但它们的工作方式都是一样的。

最常见的用法是将它们声明为全局常量，例如下面这样。

final myProvider = Provider((ref) {
  return MyValue();
});

不要被Provider的全局变量所吓倒。Provider是完全final的。声明一个Provider与声明一个函数没有什么不同，而且Provider是可测试和可维护的。

这段代码由三个部分组成。

• final myProvider，一个变量的声明。这个变量是我们将来用来读取我们Provider的状态的。Provider应该始终是final的
• Provider，我们决定使用的Provider类型。Provider是所有Provider类型中最基本的。它暴露了一个永不改变的对象。我们可以用其他Provider如StreamProvider或StateNotifierProvider来替换Provider，以改变值的交互方式
• 一个创建共享状态的函数。该函数将始终接收一个名为ref的对象作为参数。这个对象允许我们读取其他Provider，在我们Provider的状态将被销毁时执行一些操作，以及其它一些事情

传递给Provider的函数返回的对象的类型，取决于所使用的Provider。例如，一个Provider的函数可以创建任何对象。另一方面，StreamProvider的回调将被期望返回一个Stream。

你可以不受限制地声明你想要的多个Provider。与使用package:provider不同的是，Riverpod允许创建多个暴露相同 "类型 "的状态的provider。

final cityProvider = Provider((ref) => 'London');
final countryProvider = Provider((ref) => 'England');

两个Provider都创建了一个字符串，但这并没有任何问题。

为了使Provider发挥作用，您必须在Flutter应用程序的根部添加ProviderScope。

void main() {
  runApp(ProviderScope(child: MyApp()));
}

以上就是Riverpod最简单的使用，我们看下完整的示例代码。

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

// We create a "provider", which will store a value (here "Hello world").
// By using a provider, this allows us to mock/override the value exposed.
final helloWorldProvider = Provider((_) => 'Hello world');

void main() {
  runApp(
    // For widgets to be able to read providers, we need to wrap the entire
    // application in a "ProviderScope" widget.
    // This is where the state of our providers will be stored.
    ProviderScope(
      child: MyApp(),
    ),
  );
}

// Extend ConsumerWidget instead of StatelessWidget, which is exposed by Riverpod
class MyApp extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final String value = ref.watch(helloWorldProvider);

    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('Example')),
        body: Center(
          child: Text(value),
        ),
      ),
    );
  }
}

可以发现，Riverpod的使用比package:Provider还要简单，申明一个全局变量来管理状态数据，然后就可以在任意地方获取数据了。

如何读取Provider的状态值

在有了一个简单的了解后，我们先来了解下关于状态中的「读」。

在Riverpod中，我们不像package:Provider那样需要依赖BuildContext，取而代之的是一个「ref」变量。这个东西，就是联系存取双方的纽带，这个对象允许我们与Provider互动，不管是来自一个Widget还是另一个Provider。

从Provider中获取ref

所有Provider都有一个 "ref "作为参数。

final provider = Provider((ref) {
  // use ref to obtain other providers
  final repository = ref.watch(repositoryProvider);

  return SomeValue(repository);
})

这个参数可以安全地传递给其它Provider或者类，来获取所需要的值。

例如，一个常见的用例是将Provider的 "ref "传递给一个StateNotifier。

final counterProvider = StateNotifierProvider<Counter, int>((ref) {
  return Counter(ref);
});

class Counter extends StateNotifier<int> {
  Counter(this.ref): super(0);

  final Ref ref;

  void increment() {
    // Counter can use the "ref" to read other providers
    final repository = ref.read(repositoryProvider);
    repository.post('...');
  }
}

这样做，可以使我们的Counter类能够读取Provider。

这种方式是联系组件和Provider的一个重要方式。

从Widget中获取ref

Widgets自然没有一个ref参数。但是Riverpod提供了多种解决方案来从widget中获得这个参数。

扩展ConsumerWidget

在widget树中获得一个ref的最常见的方法是用ConsumerWidget代替StatelessWidget。

ConsumerWidget在使用上与StatelessWidget相同，唯一的区别是它的构建方法上有一个额外的参数："ref "对象。

一个典型的ConsumerWidget看起来像这样。

class HomeView extends ConsumerWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // use ref to listen to a provider
    final counter = ref.watch(counterProvider);
    return Text('$counter');
  }
}

扩展ConsumerStatefulWidget

与ConsumerWidget类似，ConsumerStatefulWidget和ConsumerState相当于一个带有状态的StatefulWidget，不同的是，state有一个 "ref "对象。

这一次，"ref "不是作为构建方法的参数传递，而是作为ConsumerState对象的一个属性。

class HomeView extends ConsumerStatefulWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  HomeViewState createState() => HomeViewState();
}

class HomeViewState extends ConsumerState<HomeView> {
  @override
  void initState() {
    super.initState();
    // "ref" can be used in all life-cycles of a StatefulWidget.
    ref.read(counterProvider);
  }

  @override
  Widget build(BuildContext context) {
    // We can also use "ref" to listen to a provider inside the build method
    final counter = ref.watch(counterProvider);
    return Text('$counter');
  }
}

通过ref来获取状态

现在我们有了一个 "ref"，我们可以开始使用它。

ref "有三个主要用途。

• 获得一个Provider的值并监听变化，这样，当这个值发生变化时，这将重建订阅该值的Widget或Provider。这是通过ref.watch完成的
• 在一个Provider上添加一个监听器，以执行一个action，如导航到一个新的页面或在该Provider发生变化时执行一些操作。这是通过 ref.listen 完成的
• 获取一个Provider的值，同时忽略它的变化。当我们在一个事件中需要一个Provider的值时，这很有用，比如 "点击操作"。这是通过ref.read完成的

只要有可能，最好使用 ref.watch 而不是 ref.read 或 ref.listen 来实现一个功能。
通过依赖ref.watch，你的应用程序变得既是反应式的又是声明式的，这使得它更容易维护。

通过ref.watch观察Provider的状态

ref.watch在Widget的构建方法中使用，或者在Provider的主体中使用，以使得Widget/Provider可以监听另一个Provider。

例如，Provider可以使用 ref.watch 来将多个Provider合并成一个新的值。

一个例子是过滤一个todo-list，我们需要两个Provider。

• filterTypeProvider，一个暴露当前过滤器类型的Provider（None，表示只显示已完成的任务）
• todosProvider，一个暴露整个任务列表的Provider

通过使用ref.watch，我们可以制作第三个Provider，结合这两个Provider来创建一个过滤后的任务列表。

final filterTypeProvider = StateProvider<FilterType>((ref) => FilterType.none);
final todosProvider = StateNotifierProvider<TodoList, List<Todo>>((ref) => TodoList());

final filteredTodoListProvider = Provider((ref) {
  // obtains both the filter and the list of todos
  final FilterType filter = ref.watch(filterTypeProvider);
  final List<Todo> todos = ref.watch(todosProvider);

  switch (filter) {
    case FilterType.completed:
      // return the completed list of todos
      return todos.where((todo) => todo.isCompleted).toList();
    case FilterType.none:
      // returns the unfiltered list of todos
      return todos;
  }
});

有了这段代码，filteredTodoListProvider现在就可以管理过滤后的任务列表。

如果过滤器或任务列表发生变化，过滤后的列表也会自动更新。同时，如果过滤器和任务列表都没有改变，过滤后的列表将不会被重新计算。

类似地，一个Widget可以使用ref.watch来显示来自Provider的内容，并在该内容发生变化时更新用户界面。

final counterProvider = StateProvider((ref) => 0);

class HomeView extends ConsumerWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // use ref to listen to a provider
    final counter = ref.watch(counterProvider);

    return Text('$counter');
  }
}

这段代码显示了一个Widget，它监听了一个存储计数的Provider。如果该计数发生变化，该Widget将重建，用户界面将更新以显示新的值。

ref.watch方法不应该被异步调用，比如在ElevatedButton的onPressed中。也不应该在initState和其他State的生命周期内使用它。在这些情况下，考虑使用 ref.read 来代替。

通过ref.listen监听Provider的变化

与ref.watch类似，可以使用ref.listen来观察一个Provider。

它们之间的主要区别是，如果被监听的Provider发生变化，使用ref.listen不会重建widget/provider，而是会调用一个自定义函数。

这对于在某个变化发生时执行某些操作是很有用的，比如在发生错误时显示一个snackbar。

ref.listen方法需要2个参数，第一个是Provider，第二个是当状态改变时我们要执行的回调函数。回调函数在被调用时将被传递2个值，即先前状态的值和新状态的值。

ref.listen方法也可以在Provider的体内使用。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

final anotherProvider = Provider((ref) {
  ref.listen<int>(counterProvider, (int? previousCount, int newCount) {
    print('The counter changed $newCount');
  });
  // ...
});

或在一个Widget的Build方法中使用。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

class HomeView extends ConsumerWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    ref.listen<int>(counterProvider, (int? previousCount, int newCount) {
      print('The counter changed $newCount');
    });
    
    return Container();
  }
}

ref.listen也不应该被异步调用，比如在ElevatedButton的onPressed中。也不应该在initState和其他State的生命周期内使用它。

通过ref.read来读取Provider的状态

ref.read方法是一种在不监听的情况下获取Provider的状态的方法。

它通常用于由用户交互触发的函数中。例如，当用户点击一个按钮时，我们可以使用ref.read来增加一个计数器的值。

final counterProvider = StateNotifierProvider<Counter, int>((ref) => Counter(ref));

class HomeView extends ConsumerWidget {
  const HomeView({Key? key}): super(key: key);

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return Scaffold(
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          // Call `increment()` on the `Counter` class
          ref.read(counterProvider.notifier).increment();
        },
      ),
    );
  }
}

应该尽可能地避免使用ref.read，因为它不是响应式的。

它存在于使用watch或listen会导致问题的情况下。如果可以的话，使用watch/listen几乎总是更好的，尤其是watch。

关于ref.read到底什么时候用

首先，永远不要在Widget的build函数中直接使用ref.read。

你可能很想使用ref.read来优化一个Widget的性能，例如通过下面的代码来实现。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) {
  // use "read" to ignore updates on a provider
  final counter = ref.read(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );
}

但这是一种非常糟糕的做法，会导致难以追踪的错误。

以这种方式使用 ref.read 通常与这样的想法有关："Provider所暴露的值永远不会改变，所以使用'ref.read'是安全的"。这个假设的问题是，虽然今天该Provider可能确实从未更新过它的值，但不能保证明天也是如此。

软件往往变化很大，而且很可能在未来，一个以前从未改变的值需要改变。

如果你使用ref.read，当这个值需要改变时，你必须翻阅整个代码库，将ref.read改为ref.watch--这很容易出错，而且你很可能会忘记一些情况。

如果你一开始就使用ref.watch，你在重构时就会减少问题。

但是如果我想用ref.read来减少我的widget重构的次数呢？

虽然这个目标值得称赞，但需要注意的是，你可以用ref.watch代替来达到完全相同的效果（减少构建的次数）。

Provider提供了各种方法来获得一个值，同时减少重建的次数，你可以用这些方法来代替。

例如下面的代码（bad）。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) {
  StateController<int> counter = ref.read(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );
}

我们可以这样改。

final counterProvider = StateProvider((ref) => 0);

Widget build(BuildContext context, WidgetRef ref) {
  StateController<int> counter = ref.watch(counterProvider.notifier);
  return ElevatedButton(
    onPressed: () => counter.state++,
    child: const Text('button'),
  );
}

这两个片段代码都达到了同样的效果：当计数器增加时，我们的按钮将不会重建。

另一方面，第二种方法支持计数器被重置的情况。例如，应用程序的另一部分可以调用。

ref.refresh(counterProvider);

这将重新创建StateController对象。

如果我们在这里使用ref.read，我们的按钮仍然会使用之前的StateController实例，而这个实例已经被弃置，不应该再被使用。

而使用ref.watch则可以正确地重建按钮，使用新的StateController。

关于ref.read可以读哪些值

根据你想监听的Provider，你可能有多个可能的值可以监听。

作为一个例子，考虑下面的StreamProvider。

final userProvider = StreamProvider<User>(...);

当读取这个userProvider时，你可以像下面这样。

• 通过监听userProvider本身同步读取当前状态。

Widget build(BuildContext context, WidgetRef ref) {
  AsyncValue<User> user = ref.watch(userProvider);

  return user.when(
    loading: () => const CircularProgressIndicator(),
    error: (error, stack) => const Text('Oops'),
    data: (user) => Text(user.name),
  );
}

• 通过监听userProvider.stream来获得相关的Stream。

Widget build(BuildContext context, WidgetRef ref) {
  Stream<User> user = ref.watch(userProvider.stream);
}

• 通过监听userProvider.future获得一个Future，该Future以最新发出的值进行解析。

Widget build(BuildContext context, WidgetRef ref) {
  Future<User> user = ref.watch(userProvider.future);
}

其他Provider可能提供不同的替代值。

欲了解更多信息，请查阅API参考资料，参考每个Provider的API文档。

通过select来控制精确的读范围

最后要提到的一个与读取Provider有关的功能是，能够减少Widget/Provider从ref.watch重建的次数，或者ref.listen执行函数的频率的功能。

这一点很重要，因为默认情况下，监听一个Provider会监听整个对象的状态。但有时，一个Widget/Provider可能只关心一些属性的变化，而不是整个对象。

例如，一个Provider可能暴露了一个User对象。

abstract class User {
  String get name;
  int get age;
}

但一个Widget可能只使用用户名。

Widget build(BuildContext context, WidgetRef ref) {
  User user = ref.watch(userProvider);
  return Text(user.name);
}

如果我们简单地使用ref.watch，当用户的年龄发生变化时，这将重建widget。

解决方案是使用select来明确地告诉Riverpod我们只想监听用户的名字属性。

更新后的代码将是这样。

Widget build(BuildContext context, WidgetRef ref) {
  String name = ref.watch(userProvider.select((user) => user.name));
  return Text(name);
}

通过使用select，我们能够指定一个函数来返回我们关心的属性。

每当用户改变时，Riverpod将调用这个函数并比较之前和新的结果。如果它们是不同的（例如当名字改变时），Riverpod将重建Widget。然而，如果它们是相等的（例如当年龄改变时），Riverpod将不会重建Widget。

这个场景也可以使用select和ref.listen。

ref.listen<String>(
      userProvider.select((user) => user.name),
          (String? previousName, String newName) {
         print('The user name changed $newName');
      }
  );

这样做也将只在名称改变时调用listener。

另外，你不一定要返回对象的一个属性。任何覆盖==的值都可以使用。例如，你可以这样做。

final label = ref.watch(userProvider.select((user) => 'Mr ${user.name}'));

读取状态，是一个非常重要的部分，什么时候用什么样的方式来读，都会有不同的效果。

ProviderObserver

ProviderObserver可以监听一个ProviderContainer的变化。

要使用它，你可以扩展ProviderObserver类并覆盖你想使用的方法。ProviderObserver有三个方法。

• didAddProvider：在每次初始化一个Provider时被调用
• didDisposeProvider：在每次销毁Provider的时候被调用
• didUpdateProvider：每次在Provider更新时都会被调用

ProviderObserver的一个简单用例是通过覆盖didUpdateProvider方法来记录Provider的变化。

// A Counter example implemented with riverpod with Logger

class Logger extends ProviderObserver {
  @override
  void didUpdateProvider(
    ProviderBase provider,
    Object? previousValue,
    Object? newValue,
    ProviderContainer container,
  ) {
    print('''
{
  "provider": "${provider.name ?? provider.runtimeType}",
  "newValue": "$newValue"
}''');
  }
}

void main() {
  runApp(
    // Adding ProviderScope enables Riverpod for the entire project
    // Adding our Logger to the list of observers
    ProviderScope(observers: [Logger()], child: const MyApp()),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(home: Home());
  }
}

final counterProvider = StateProvider((ref) => 0, name: 'counter');

class Home extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider);

    return Scaffold(
      appBar: AppBar(title: const Text('Counter example')),
      body: Center(
        child: Text('$count'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: () => ref.read(counterProvider.notifier).state++,
        child: const Icon(Icons.add),
      ),
    );
  }
}

现在，每当我们的Provider的值被更新时，logger将记录它。

I/flutter (16783): {
I/flutter (16783):   "provider": "counter",
I/flutter (16783):   "newValue": "1"
I/flutter (16783): }

对于诸如StateController（StateProvider.state的状态）和ChangeNotifier等可改变的状态，previousValue和newValue将是相同的。因为它们引用的是同一个StateController / ChangeNotifier。

这些是对Riverpod的最基本了解，但是却是很重要的部分，特别是如何对状态值进行读取，这是我们用好Riverpod的核心。

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

又到了Flutter稳定版发布的时候了--我们非常自豪地宣布Flutter 3! 仅仅三个月前，我们宣布Flutter支持Windows。今天，我们很高兴地宣布，除了Windows之外，Flutter现在在macOS和Linux上也是稳定的!

感谢我们的Flutter贡献者的辛勤工作，我们已经合并了5248个pull requests!

作为这个版本的一部分，我们有几件令人兴奋的事情要宣布，包括Flutter对macOS和Linux的支持的更新，显著的性能改进，移动和网络的更新--以及更多。此外，我们还有关于减少对旧版Windows的支持的消息，以及一个简短的breaking变化清单。所以，让我们开始谈正事吧!

Ready for production on all desktop platforms

Linux和macOS已经达到稳定，包括以下功能。

Cascading menus and support for the macOS system menu bar

你现在可以使用PlatformMenuBar部件在macOS上创建平台渲染的菜单栏，该部件支持插入平台专用的菜单，并控制macOS应用程序菜单中出现的内容。

gif太大，再见。

Full support for international text input on all desktop platforms

国际文本输入，包括使用文本输入法编辑器（IME）的语言，如中文、日文和韩文，在所有三个桌面平台上都得到完全支持，包括第三方输入法，如搜狗和谷歌日文输入。

Accessibility on all desktop platforms

用于Windows、macOS和Linux的Flutter支持无障碍服务，如读屏器、无障碍导航和颜色反转。

Universal binaries by default on macOS

从Flutter 3开始，Flutter macOS桌面应用程序被构建为通用二进制文件，对现有基于英特尔的Mac和苹果最新的Apple Silicon设备都有原生支持。

Deprecating Windows 7/8 for development

在这个版本中，我们将开发的推荐Windows版本提高到Windows 10。虽然我们没有阻止在旧版本（Windows 7、Windows 8、Windows 8.1）上的开发，但这些版本不再受到微软的支持，我们在这些版本上提供有限的测试。虽然我们将继续为旧版本提供 "最大努力 "的支持，但我们鼓励你升级。

注意：我们继续为在Windows 7和Windows 8上运行的Flutter应用程序提供支持；这一变化只影响到推荐的开发环境。

Mobile updates

我们对移动平台的更新包括以下内容。

Foldable phone support

Flutter 3版本支持可折叠移动设备。在微软带头的合作中，新的功能和部件允许你在可折叠设备上创建动态和令人愉快的体验。

作为这项工作的一部分，MediaQuery现在包含一个DisplayFeatures列表，描述了设备元素的边界和状态，如铰链、折叠和切口。此外，DisplayFeatureSubScreen小组件现在在定位其子小组件时不会与DisplayFeatures的边界重叠，并且已经与框架的默认对话框和弹出式窗口集成，使Flutter能够感知并响应这些元素的改变。

非常感谢微软团队，特别是@andreidiaconu，感谢他们的贡献!

试试Surface Duo模拟器的Sample：https://docs.microsoft.com/en-us/dual-screen/flutter/samples，包括一个带有Flutter图库的特殊分支的sample，看看Flutter的双显示器的运行情况。

iOS variable refresh rate support

Flutter现在支持带有ProMotion显示器的iOS设备上的可变刷新率，包括iPhone 13 Pro和iPad Pro。在这些设备上，Flutter应用程序可以在刷新率达到120 hz的情况下进行渲染，而以前则限制在60 hz。这使得在滚动等快速动画中的体验更加顺畅。更多细节见flutter.dev/go/variable-refresh-rate。

Simplified iOS releases

我们在flutter build ipa命令中添加了新的选项，以简化发布您的iOS应用。当您准备发布到TestFlight或App Store时，运行flutter build ipa来构建一个Xcode归档文件（.xcarchive文件）和一个应用包（.ipa文件）。你可以选择添加 --export-method ad-hoc, --export-method development, 或 --export-method enterprise。一旦应用程序捆绑完成，通过Apple Transport macOS应用程序或在命令行中使用xcrun altool（运行man altool获取App Store Connect API密钥验证说明）将其上传到苹果。上传后，您的应用程序可以发布到TestFlight或App Store。在设置了最初的Xcode项目设置，如显示名称和应用程序图标后，您不再需要打开Xcode来发布您的应用程序。

Gradle version update

如果你用Flutter工具创建一个新的项目，你可能会注意到，现在生成的文件使用最新版本的Gradle和Android Gradle插件。对于现有项目，你需要手动将Gradle的版本提升到7.4，将Android Gradle插件的版本提升到7.1.2。

Sunsetting 32-bit iOS/iOS 9/iOS 10

正如我们在2022年2月宣布的2.10稳定版，Flutter对32位iOS设备和iOS 9和10版本的支持即将结束。这一变化影响到iPhone 4S、iPhone 5、iPhone 5C以及第二代、第三代和第四代iPad设备。Flutter 3是支持这些iOS版本和设备的最后一个稳定版本。

要了解有关这一变化的更多信息，请看RFC：结束对32位iOS设备的支持。

Web updates

我们对网络应用的更新包括以下内容。

Image decoding

Flutter web现在能自动检测并在支持它的浏览器中使用ImageDecoder API。截至今天，大多数基于Chromium的浏览器（Chrome、Edge、Opera、Samsung Browser等）都增加了这个API。

新的API使用浏览器内置的图像编解码器在主线程外异步地解码图像。这使图像解码的速度提高了2倍，而且它从不阻塞主线程，消除了以前由图像引起的所有干扰。

Web app lifecycles

Flutter网络应用程序的新生命周期API使您能够灵活地从托管HTML页面控制Flutter应用的启动过程，并帮助Lighthouse分析您的应用的性能。这适用于许多用例，包括以下经常要求的场景。

• A splash screen
• A loading indicator
• 在Flutter应用程序之前显示的普通HTML交互页面

欲了解更多信息，请查看docs.flutter.dev上的自定义Web应用初始化：https://docs.flutter.dev/development/platform-integration/web/initialization。

Tooling updates

我们对Flutter和Dart工具的更新包括。

Updated lint package

2.0版的lint软件包已经发布。

• Flutter: https://pub.dev/packages/flutter_lints/versions/2.0.0
• Dart: https://pub.dev/packages/lints/versions/2.0.0

在Flutter 3中用flutter create生成的应用程序会自动启用v2.0版的lints包。我们鼓励现有的应用程序、软件包和插件通过运行 flutter pub upgrade --major-versions flutter_lints 迁移到 v2.0，以遵循 Flutter 世界中最新和最伟大的最佳实践。

在v2版中，大多数新增加的lint警告都有自动修复功能。因此，在你的应用程序的pubspec.yaml文件中升级到最新的软件包版本后，你可以在你的代码库中运行dart fix --apply来自动修复大多数lint警告（有些警告仍然需要一些手工操作）。还没有使用package:flutter_lints的应用程序、软件包或插件可以按照迁移指南进行迁移。

Performance improvements

感谢开源贡献者knopp，partial repaint已经在支持它的Android设备上启用。在我们的本地测试中，这一变化将Pixel 4 XL设备上backdrop_filter_perf基准的平均、第90个百分点和第99个百分点的帧栅格化时间缩短了5倍。在iOS和较新的安卓设备上，当存在单一rectangular dirty区域时，现在启用了partial repaint。

我们进一步提高了简单情况下Opacity动画的性能。特别是，当一个Opacity小组件只包含一个渲染基元时，通常由Opacity调用的saveLayer方法被省略。在为衡量这种优化的好处而构建的基准中，这种情况下的光栅化时间提高了一个数量级。在未来的版本中，我们计划将这种优化应用到更多的场景中。

由于开源贡献者JsouLiang的工作，引擎的光栅和UI线程现在在Android和iOS上的运行优先级高于其他线程；例如，Dart VM后台垃圾收集线程。在我们的基准测试中，这导致平均帧构建时间快了约20%。

在第3版发布之前，光栅缓存的接纳策略只看图片中的绘制操作数，假设任何超过几个操作数的图片都是缓存的好候选。不幸的是，这导致了引擎花费内存来缓存那些实际上渲染速度非常快的图片。这个版本引入了一种机制，根据它所包含的绘制操作的成本来估计图片的渲染复杂性。在我们的基准测试中，使用这种方法作为光栅缓存的接纳策略，在不降低性能的情况下减少了内存的使用。

感谢开源贡献者ColdPaleLight，他修复了帧调度中的一个bug，该bug导致iOS上少量的动画帧被丢弃。感谢所有报告这个问题并提供掉帧视频的人。

Impeller

该团队一直在努力工作，以解决iOS和其他平台上的早期jank问题。在Flutter 3版本中，你可以在iOS上预览一个名为Impeller的实验性渲染后端。Impeller在引擎构建时预编译一套更小、更简单的着色器，这样它们就不会在应用程序运行时被编译；这一直是Flutter中jank的一个主要来源。Impeller还没有为生产做好准备，也远未完成。并非所有的Flutter功能都已实现，但我们对其在flutter/gallery应用程序中的保真度和性能感到足够满意，因此我们正在分享我们的进展。特别是，画廊应用的过渡动画中最差的一帧速度大约是20倍。

Impeller在iOS的一个标志下可用。你可以向flutter运行传递--enable-impeller，或者将你的Info.plist文件中的FLTEnableImpeller标志设置为true，来尝试一下Impeller。Impeller的开发在Flutter的主频道继续进行，我们希望在未来的版本中提供进一步的更新。

Inline ads on android

当你使用google_mobile_ads软件包时，你应该看到在用户的关键互动方面有更好的表现，如滚动和页面之间的转换。这在新兴市场流行的设备上尤其明显。最重要的是，不需要修改代码!

在引擎盖下，Flutter现在以异步方式组成Android视图，通常称为平台视图。这意味着Flutter光栅线程不需要等待Android视图的渲染。相反，Flutter引擎使用其管理的OpenGL纹理将视图放在屏幕上。

More exciting updates

Flutter生态系统的其他更新包括以下内容。

Material 3

Flutter 3支持Material Design 3，即新一代的Material Design。Flutter 3提供了对Material 3的选择支持；这包括Material You功能，如动态颜色、更新的颜色系统和排版，对许多组件的更新，以及在Android 12中引入的新视觉效果，如新的触摸波纹设计和拉伸过卷效果。在新的Take your Flutter app from Boring to Beautiful codelab中尝试Material 3功能。有关如何选择使用这些新功能以及哪些组件支持Material 3的详细信息，请参见API文档。关注正在进行的Material 3 Umbrella问题的工作。

Theme extensions

Flutter现在可以向素材库的ThemeData添加任何东西，有一个概念叫做Theme extensions。你可以指定ThemeData.extensions，而不是扩展（Dart意义上的）ThemeData并重新实现其copyWith、lerp和其他方法。另外，作为一个包的开发者，你可以提供ThemeExtensions。更多细节请参见flutter.dev/go/theme-extensions，并查看GitHub上的这个例子。

Ads

我们知道，对于出版商来说，为个性化广告征求同意和处理苹果公司的应用跟踪透明度（ATT）要求是很重要的。

为了支持这些要求，谷歌提供了用户信息平台（UMP）SDK，它取代了以前的开源同意SDK。在即将发布的GMA SDK for Flutter中，我们正在增加对UMP SDK的支持，以使发布者能够获得用户同意。更多细节，请查看pub.dev上的google_mobile_ads页面。

Breaking changes

随着我们不断发展和改进Flutter，我们的目标是将破坏性变化的数量降到最低。随着Flutter 3的发布，我们有以下突破性变化。

• Deprecated API removed after v2.10
• Page transitions replaced by ZoomPageTransitionsBuilder
• Migrate useDeleteButtonTooltip to deleteButtonTooltipMessage of Chips
• ThemeData’s toggleableActiveColor property has been deprecated

具体的迁移过程，可以参考migration guide on Flutter.dev.

Summary

从谷歌的Flutter团队来说，我们要感谢社区所做的出色工作，帮助Flutter保持其作为最受欢迎的跨平台UI工具包的地位，正如Statista和SlashData等分析机构所衡量的那样。我们期待着作为一个社区一起工作，继续提供一个由社区驱动的工具，帮助为开发者和用户创造愉快的体验!

原文链接：https://medium.com/flutter/whats-new-in-flutter-3-8c74a5bc32d0

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

Kotlin在Java的基础上，同样对泛型语法进行了拓展，所以很多Kotlin开发者，看着源码中的一堆in、out和*，感觉非常不知所措。其实，只要了解了Java泛型，那么Kotlin泛型就迎刃而解了。

首先，我们来想想，我们为什么需要泛型。

泛型是面向对象编程的一个非常重要的方面，它的出现，是多态的核心实现，简单的说，就是可以在不同的对象类型之间，使用相同的代码逻辑，从而实现复用。

为了充分了解泛型，以及泛型的实例场景，我们下面来构建一个面向对象的例子。

abstract class Person(open val name: String) {
    abstract fun talk(): String
}

class Parent(override val name: String) : Person(name) {
    override fun talk(): String = name
}

class Son : Person("ryan") {
    override fun talk(): String = "hahaha"
}

fun doTalk(family: MutableList<Person>) {
    family.forEach { println(it.talk()) }
}

这里定义了一个Person类，作为基类，他的子类——Father、Son，就是具体的实例，新建一个方法doTalk，用来输出具体的实现。

fun main() {
    val family = arrayListOf<Person>()
    family.add(Parent("Father"))
    family.add(Son())

    doTalk(family)
}

这样，我们就可以构建一个family的List，指定List的类型为Person，这样Father、Son，这些子类就都可以加入到这个List。

上面就是一个比较简单的泛型的使用实例。

泛型不变性

Father和Son都可以作为子类，加入到Person的List中，这就是泛型，但是让我们再看下下面的代码。

val parents = mutableListOf<Parent>()
parents.add(Parent("Father"))
parents.add(Parent("Mother"))
doTalk(parents)

创建一个类型为Parent的List，再传入doTalk函数，这时候，编译器报错了。

为什么呢？从编译器来看，doTalk需要的是一个List类型的参数，但是传入的是List类型，确实类型不一致，但是，Parent是Person的子类，从语义上来说，doTalk函数也是可以接受Parent类型的List的。

这就是泛型的不变性。即使参数中的类型是父子关系，但是编译器依然不能识别，它只能识别具体的类型。

泛型的型变

正是由于存在泛型的不变性，所以我们在支持某些场景的泛型参数时，就需要通过「泛型的型变」来拓展「泛型的不变性」。

Kotlin，或者说Java的泛型，实际上是一种伪泛型，即泛型只在申明时检查泛型是否有效，在编译时，泛型类型会被擦除，这是因为Java的历史原因所导致的，由于它为了兼容没有泛型的老Java版本，从而做出的妥协。

不管是如何型变，它们的作用都是扩大泛型参数的类型范围。

协变

泛型的协变，是泛型型变的一种方式。

协变的使用很简单，我们给参数加上out前缀即可，代码如下。

fun doTalk(family: MutableList<out Person>) {
    family.forEach { println(it.talk()) }
}

加上out关键字之后，参数类型就变成了「Person类及其子类」，也就是说，只要是Person的子类，都可以作为参数传进来。

那么这样处理之后，上面的方法就可以执行了。但是，协变之后的泛型，就变成可读而不可写类型了。

例如我们在协变泛型参数上进行写操作，代码如下。

fun doTalk(family: MutableList<out Person>) {
    family.add(Son()) // Error
    family.forEach { println(it.talk()) }
}

这样就会报错，因为被out修饰之后，参数失去了写属性，变为只读属性了，这就是协变的副作用。

那么原因是什么呢？

我们来思考下，为什么它是可读的，通过out修饰之后，我们能保证，加入List的数据都是Person的子类，所以，List读取出来的实例类型，不管是哪个子类，都可以转为Person，也就是基类，所以可以通过它来调用基类的函数。

如果把参数写成Java的方式，可能更好理解一些。

void doTalk(List<? extends Person> family) {}

可以发现，泛型的协变，实际上是控制了类型的上限，但返回的具体类型，是不确定的（？代表未知类型），这就是为什么在协变后的参数中，无法执行写指令的原因，因为参数的类型，可能是List，也可能是List，所以无法确定是哪一种类型，自然无法写入。

逆变

逆变是泛型型变的第二种方式，与协变类似，逆变也是将某一个泛型类型，拓展了其父类类型，例如下面这个方法。

fun work(worker: MutableList<Son>) {
    worker.forEach { println(it.talk()) }
}

这个方法接收一个List类型的参数，那么假如我们要传递一个List类型的参数，就会报错，原因跟协变是一样的。

这个时候，就需要使用逆变关键字in，将参数类型拓展为「Son类及其父类」。

fun work(family: MutableList<in Son>) {
    family.forEach { println(it.talk()) }
}


val family = arrayListOf<Person>()
family.add(Parent("Father"))
family.add(Son())
work(family)

这样参数就可以传进去了，但是，逆变的副作用，是会导致泛型参数失去读属性，而只能使用写属性。

fun work(family: MutableList<in Son>) {
    family.add(Son())
    family.forEach { println(it.talk()) } // Error
}

同样的，我们将它转化为Java中的代码，这样更好理解一些。

void work(List<? super Son> family) {}

泛型的逆变，实际上是控制了类型的下限，即Son及其父类。对List进行add操作时，新实例son一定符合条件，但是get时，只会获取到Any或者Object类型，所以，拿到Object类型后，你可以根据业务来进行强转。

星型投影

星型投影，其实就是Java中的「?」通配符，用于在泛型的使用中，去除泛型的依赖，这么说有点抽象，简单的说，就是当你不关心具体的泛型类型时，就可以使用「?」或者「*」来忽略泛型的约束。下面举个例子。

class Push<T> {
    fun pushMsg(msg: String): T {}
}

fun <T> getPush(): Push<T> {}

这是泛型版本的方法，我们可以获取指定泛型的Push，同时，你也可以用out来做泛型协变，让它可以返回子类。

那么这个时候，如果我不关心泛型的类型呢？

fun getPush(): Push<*> {}

fun main() {
    val push = getPush()
    val pushMsg = push.pushMsg("xys")
}

通过「*」，我们就可以不用指定泛型的具体类型，因为我不关心泛型类型，不过要注意的是，星型投影之后返回的类型，就成了「Any?」或者「Object」，因为泛型类型已经没有了。

但是我们依然可以使用协变来限制投影的上限，当我们加上上限后，就可以限制返回数据的上限类型了——out T : CommonPush

实际使用

我们在设计泛型API时，通常会有两种使用方式，一种是将泛型作为参数，另一种是将泛型作为返回值，这两种模式，实际上就对应「生产者-消费者」模型。下面我们就借助这个模型，来完整的演示下。

官方文档中的说法是——Consumer in, Producer out !

生产者

首先，设计一个生产者。

class Producer<T> {
    fun produceSth(): T {
        // TODO
    }
}

fun main() {
    val producer: Producer<Person> = Producer()
    val sth: Person = producer.produceSth()
}

这是我们泛型最基本的使用，创建Person类型的生产者，它生产出来的东西，全是Person类型。

下面，我们来对泛型协变，这样就可以创建Son类型的生产者。

fun main() {
    val producer: Producer<out Person> = Producer<Son>()
    val sth: Person = producer.produceSth()
}

但是协变之后，生产出来的类型，依然是Person类型。

那么在Kotlin中，可以将这种在使用时的协变，变为申明时的协变，代码如下。

class Producer<out T> {
    fun produceSth(): T {
        // TODO
    }
}

fun main() {
    val producer = Producer<Son>()
    val sth: Person = producer.produceSth()
}

在申明时标记协变，这样后续在使用时，就不用再标记了，你可以创建子类的生产者，生产基类的对象。

在Kotlin中，集合类大量使用了协变，如下所示。

public interface List<out E> : Collection<E> {
    // Query Operations

    override val size: Int
    override fun isEmpty(): Boolean
    override fun contains(element: @UnsafeVariance E): Boolean
    override fun iterator(): Iterator<E>

    // Bulk Operations
    override fun containsAll(elements: Collection<@UnsafeVariance E>): Boolean

    // Positional Access Operations
    /**
     * Returns the element at the specified index in the list.
     */
    public operator fun get(index: Int): E

这里泛型就是作为返回值传入。

消费者

同样的，我们创建一个消费者。

class Consumer<T> {
    fun consumeSth(t: T) {
        // TODO
    }
}

fun main() {
    val consumer: Consumer<Son> = Consumer<Person>()
    consumer.consumeSth(Son())
}

同理，创建一个Person类型的消费者，它只能消费Son类型的参数。

我们再给它增加逆变，让它可以接受Son的基类。

fun main() {
    val consumer: Consumer<in Son> = Consumer<Person>()
    consumer.consumeSth(Son())
}

但是逆变之后，同样只能接受Son类型的参数，但是可以创建Person类型的消费者。

类似的，逆变也可以在申明处标记。

fun main() {
    val consumer = Consumer<Person>()
    consumer.consumeSth(Son())
}

class Consumer<in T> {
    fun consumeSth(t: T) {
        // TODO
    }
}

那么逆变，在实际代码中的例子，我们可以参考下Comparable接口的设计。

public interface Comparable<in T> {
    public operator fun compareTo(other: T): Int
}

这里的泛型就是作为参数传递，所以使用了逆变。

泛型的实例化

由于Java会在编译期进行泛型擦除，所以我们无法对泛型来做类型判断，比如下面的代码。

fun <T> test(param: Int) {
    if (param is T) {// Error
    }
}

T是无法进行类型判断的，因为它已经被擦除了，这和在Java中使用instanceof判断是一样的，在Java中，我们通常会再传入一个Class类型的参数来处理这个问题。而在Kotlin中，有更简单的方法来处理，那就是通过inline配合reified关键字来处理。

inline fun <reified T> test(param: Int) {
    if (param is T) {
    }
}

这样T就可以当做正常的类型来处理了，不过这种实例化的方式是有限制的。

• 函数必须是内联函数，因为只有内联函数才会在编译时进行替换
• 加上reified关键字让编译器在该泛型使用时进行实例化

在实战中，我们就可以利用泛型来进一步简化代码，例如：

inline fun <reified T> startActivity(context: Context) {
    context.startActivity(Intent(context, T::class.java))
}

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

Flutter这个东西出来这么久了，到底市场占有率怎么样呢？为了让大家了解这一真实数据，也为了让大家了解当前Flutter在各大App中的使用情况，我今天下载了几百个App，占了手机将近80G空间，就为了得出一个结论——Flutter，到底有没有人用。

首先，我在vivo应用市场中，下载了4月11日软件排行榜中的所有App，总计230个，再加上平时用的比较多的一些App，总共270个App，作为我们的统计基数。

检测方法，我使用LibChecker来查看App是否有使用Flutter相关的so。

https://github.com/zhaobozhen/LibChecker

除了使用LibChecker之外，还有其它方案也可以，例如使用shell指令——zipinfo。

https://github.com/sugood/apkanalyser

Apk本质上也是一种压缩包，所以，通过zipinfo指令并进行grep，就可以很方便的获取了，同时，如果配合一下爬虫来爬取应X宝的Apk下载地址，就可以成为一个全自动化的脚本分析工具，这里没这么强的需求，所以就不详细做了。

App列表

我们来看下，我都下载了多少App。

这些App基本上已经覆盖了应用商店各个排行榜里的Top软件，所以应该还是比较具有代表性和说服力的。

下面我们就用LibChecker来看下，这些App里面到底有多少使用了Flutter。

统计结果

已经使用Flutter的App共52个，占全体样本的19.2%，作为参考，统计了下RN相关的App，共有45个，占全体样本的16.6%，可以说，Flutter已经超过RN成为跨平台方案的首选。

在52个使用Flutter的App中：

• 腾讯系：QQ邮箱、微信、QQ同步助手、蓝盾、腾讯课堂、QQ浏览器、微视、企业微信、腾讯会议
• 百度系：百度网盘、百度输入法
• 阿里系：优酷视频、哈啰出行、淘特、酷狗直播、阿里1688、学习强国、钉钉、淘宝、闲鱼
• 其它大厂：链家、转转、智联招聘、拍拍贷、哔哩哔哩漫画、网易有道词典、爱奇艺、考拉海购、携程旅行、微博、Soul、艺龙旅行、唯品会、飞猪旅行

从上面的数据来看，各大厂都对Flutter有使用，头条系未列出的原因是，目前好像只有头条系大规模使用了Flutter的动态化加载方案，所以原始包内找不到Flutter相关的so，所以未检出（猜测是这样，具体可以请头条系的朋友指出，根据上次头条的分享，内部有90+App在使用Flutter）。

不过这里要注意的 ，这里并不是选取的大家常用的一些APP来做测试的，而是直接选取的排行榜，如果直接用常用APP来测试，那比例可能更高，大概统计了下，估计在60%左右。

不过大厂里面，京东没有使用Flutter我还是比较意外的，看了下京东的几个App，目前还是以RN为主作为跨平台的方案。这跟其它很多大厂一样，它们不仅使用了Flutter，RN也还可以检出，这也从侧面说明了，各个厂商，对跨平台的方案探索，从未停止。

所以，总结一下，目前使用Flutter的团队的几个特定：

• 创业公司：快速试错、快速开发，像Blued、夸克这也的
• 大厂：大厂的话题永远是效率，如何利用跨平台技术来提高开发效率，是它们引入Flutter的根本原因
• 创新型业务：例如B漫、淘特、Soul这类没有太多历史包袱的新业务App，可以利用Flutter进行极为高效的开发

所以，整体在知乎上吵「Flutter被抛弃了」、「Flutter要崛起了」，有什么意义呢？所有的争论都抵不过数据来的真实。

嘴上说着不要，身体倒是很诚实。

希望这份数据能给你一些帮助。

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问

一转眼，困在家里已经一个月了，这次的上海疫情真是出乎所有人的预料，作为一个技术公众号，我们也不去评判任何政治问题，只是作为一个亲身体验者，谈谈自己最近的感受吧。

最早知道疫情扩散时，其实大家都并没有太当回事，毕竟国外的疫情范围，只能用躺平来形容了，所以从在家办公开始，即使知道后面要进行封控，也并没有准备太多的物资，因为那个时候虽然警戒线拉起来了，但是你想出去，保安也不会管你，也就是说，最开始的防疫，实际上是比较形式主义的。

我们小区所在镇并不是疫情的重灾区，所以管理相对来说是比较松散的，直到铁丝网拉起来的那一天，所有人才意识到，这次疫情不是那么简单了，这才开始疯狂采购物资，我也是隔离几天后，才找到附件超市老板的电话，采购了一大批物资，这才让温饱有了最基本的保障，再到后来，小区团购的兴起，才让大家对基本生活，有了一定的保障，不至于饿殍满地。

作为一个经历者，我来聊聊这次疫情的一些感受。

首先是「居委-基层管理者」，面对疫情，除了政府以外，最大的工作承担者，实际上就是这些基层干部，也就是居委会、社区管理者这些人，他们的组织能力和管理能力，直接影响了整个小区的防疫工作，不过很可惜的是，大部分的居委工作人员，组织能力太差，从核酸采集的组织、信息的通报、居民情况的了解这些情况，就可以完全了解一个小区居委的工作能力，不过，没有功劳也有苦劳，小区居委和志愿者们还是很辛苦的，特别是有些居委要分管好几个小区，他们的工作量也是成倍的增长。希望经过这次疫情，居委们能有所警醒，平时就建立起一套完整的管理方案，不仅仅是疫情，因为居委可以说是人民群众和政府之间的桥梁，这个桥梁平时就没建好，怎么能在真正要用的时候承载所需的压力呢？

其次谈谈「物资」，对于我们来说，只要有物资保证，让我在家办公一年也没什么问题。所以，这次疫情反映出来的一个很大的问题，就是物资紧缺，大家的基本生活不能保证，也就让大家对封控产生了很大的抵触情绪，网络上很多流出的xx视频，很大一部分都是因为没有物资而产生的。

不过从客观上来说，如何保障上海近3000万人的基本生活物资，相信这换成其它任何一个城市，都是很大的挑战。但是挑战归挑战，放低数量级之后，也不是没有成功的案例，深圳就是一个，所以这些可能真的和决策层的领导思路有关，咱也不懂，咱也不敢问。就我所见到的，虽然物资紧，但年轻人基本上还是可以从各种渠道，找到采购的方式，不管是团购还是外卖，还是各种抢单抢菜，虽然生活苦一点，还是能活下去，最可怜的是小区内的老人，如果家里没有年轻人，还真是很难得到这些物资保障，这里其实完全靠居委来保障，为这些老人提供帮助，可真的有多少能做到呢？大部分的老人可能都不会使用微信，更不用说什么抢单了，所以说，这次疫情，家里没老人小孩，没生病，就是最大的幸运了。还好大部分的小区在这次疫情中都建了微信群，邻里之间虽然平时交流不多，但是在这种大是大非面前，都是比较照顾的，大家会分一些物资给那些需要帮助的人，有老人需要药或者物资，大家也会帮忙想办法，所以，人性本善。

再来谈谈「躺平 or 清零」。其实，真的，你应该感谢国家愿意无条件的花费巨资来抗击疫情，奥密克戎的致死率虽然不如之前高，但是其传染性和带来的症状，一定也不必其它大型流行性传染病差，所谓的「无症状感染者」，并不是完全没有任何异样，发热、咽痛、肺炎，当躺平的你真的遇到这些问题，再去看看平时没有疫情就已经人山人海的医院，你会感到绝望吗？

中国的人均医疗设施占有率，比起发达国家来说要低很多，人口基数大导致的就医难问题，在没有疫情时，就已经让很多人绝望了，一旦「躺平」，老人小孩的感染风险，会让原本就已经危若累卵的医疗机构更加难以运作，所以，如果你没有得「新冠」，那就不要轻言「躺平」。

但是，「清零」也绝不应该是对除「新冠」之外的其它疾病的无视，这一点在这次疫情中，被无限放大了，有太多的病人，并不是因为「新冠」而绝望，而是本身的疾病无法得到救治，这一点，在新闻中已经被完全解决了，各种患病的人，都可以联系警察、120来获得救治，但是在现实中，依然还是有很多无助、绝望的人，我们只能用「需要救助的人太多了，来不及处理」来麻痹自己，但这事如果真的发生在自己身边，谁又能独善其身呢？

这里最应该感谢的还是全国各地的医务工作者，这三年的抗疫时间，他们应该是最辛苦的人，很多时候，他们没有决策权，但是却服从命令，作出了最大的牺牲。

最后来说说「暴利」。这次疫情以来，可以说是「家蔬抵万金」，各种物资的价格，特别是蔬菜水果，几乎是天价，各种「大礼包」跟充值一样，99、128、299、998、1288，眼花缭乱的大礼包，收到才发现，也就是平时一半不到的价格，正如马克思所说，利润是资本金铤而走险的动力。各种有渠道的「人」，在国难面前大赚一笔，甚至在群里炫耀，这也让很多人不惜感染的风险、甚至已经感染而躲避，来获取高额的利润。其实，在这种灾难面前，物资适当涨价是可以接受的，毕竟运输渠道阻塞，但是，漫天要价，最终必然会接受历史的制裁。

经过这一场疫情，上海可以说是成功的在抗疫史上留下了浓墨重彩的一笔，这是好的一笔，还是差的一笔，只能交给历史来评判了。至此之后，你们小区疫情期间发菜了吗，发了什么菜，发了几次，居委组织得当吗，有人做信息通报吗，志愿者多吗，有多少感染了，可能成为了购房必问的几大问题了。

多年以后，我会夸张的对我孙子说，「想当年，爷爷在中国GDP第一的上海，都差点饿死，你现在居然还不好好吃饭。」

写于在家办公一个月的上海。希望这次疫情早日过去，所有人都能经历风雨，重见彩虹。

上海加油。

向大家推荐下我的网站 https://xuyisheng.top/ 专注 Android-Kotlin-Flutter 欢迎大家访问