bettersun

用至今为止前面看到的所有内容，已经可以构建一个完整的功能性应用了。 尽管如此，可能还是会有一些性能考量方面的问题。 本篇文章会提供一些提示和技巧来尽可能地改善代码。

因为应用会越来越复杂，所以同时有多个网络请求在执行是很常见的。 例如，一个用户可能在搜索框里输入时，每敲击一个按键就会触发一个新的请求。 如果用户输入地很快，应用就可能会同时发出去多个请求。

Riverpod 得益于其声明式的属性天生支持下拉刷新。 通常，下拉刷新都很复杂，因其需要解决多个问题： 第一次进入某个画面时，想要表示一个加载中的指示器。但是在刷新时，是想要表示刷新指示器。不应

要确保代码的优良维护性，这有一个使用 Rivderpod 时应该遵循的优秀实践列表。 该列表并不完整，并且还会继续修改。 如果有任何问题，可以直接开issue。 该列表的项目并无特定先后顺序。

这里有一些社区中常被问到的问题： ref.refresh 和 ref.invalidate 有什么区别？为什么在 Ref 和 WidgetRef 之间没有共享接口？为什么要继承 ConsumerWid

Riverpod原生提供了监听 provider 树中发生的所有事件的手段。 这可以用来记录所有事件的日志，或向远程服务报告错误。

Riverpod API 的一个核心部分是独立测试 provider 的能力。 对于一个合适的测试集，需要克服一些挑战： 测试不应共享状态。这意味着新的测试不应当受到前一个测试的影响。 测试应该赋

所有的 provider 默认都是初始化为懒汉式。这意味着 provider 只会在第一次被读取时初始化。这对于只在应用的特定部分使用的 provider 是有用的。

迄今为止，已经看到了如何创建/更新一些状态。但是还没有讨论状态清除时发生的处理。 Riverpod 提供了多种方式和状态清除进行交互。从延迟状态的清除到析构的响应。