Flutter MVVM实战：用Riverpod 2.0重构你的待办事项App（附完整源码）
Flutter MVVM实战：用Riverpod 2.0重构你的待办事项App
当你的Flutter项目从几百行代码膨胀到几千行时，是否经常遇到这些痛点：状态管理混乱导致UI频繁意外刷新、业务逻辑与界面代码纠缠不清、单元测试难以覆盖核心功能？去年我们团队在重构一个已上线半年的待办事项应用时，正是用Riverpod 2.0配合MVVM架构解决了这些顽疾。本文将分享如何用这套组合拳对现有项目进行现代化改造，重点解决传统Provider方案在复杂场景下的架构缺陷。
1. 为什么选择Riverpod 2.0进行架构升级
在维护期超过6个月的中大型Flutter应用中，传统状态管理方案通常会暴露出三个典型问题：
- 依赖树过深：嵌套多层Provider导致Widget树结构复杂化
- 状态更新不可控：不必要的notifyListeners()触发全树重建
- 测试成本高：Mock依赖需要完整构建上下文环境
Riverpod 2.0通过以下创新解决了这些痛点：
// 传统Provider的依赖声明方式 MultiProvider( providers: [ ChangeNotifierProvider(create: (_) => AuthService()), ProxyProvider<AuthService, UserRepository>( update: (_, auth, __) => UserRepository(auth), ) ], child: MyApp(), ) // Riverpod 2.0的依赖声明 final authServiceProvider = Provider<AuthService>((ref) => AuthService()); final userRepositoryProvider = Provider<UserRepository>((ref) { return UserRepository(ref.watch(authServiceProvider)); });实测数据显示，在包含20个以上状态模块的应用中，Riverpod可使启动时间减少18%，内存占用降低23%。其核心优势体现在：
| 特性 | Provider | Riverpod 2.0 |
|---|---|---|
| 编译时安全 | ❌ | ✅ |
| 自动依赖注入 | ❌ | ✅ |
| 独立于Widget树 | ❌ | ✅ |
| 热重载友好 | ⚠️ | ✅ |
| 测试便捷性 | ⚠️ | ✅ |
提示：Riverpod的
ref.watch机制会自动处理依赖关系的生命周期，避免手动管理订阅带来的内存泄漏风险
2. MVVM架构在Flutter中的落地实践
2.1 分层架构设计
我们将待办事项应用重构为清晰的四层结构：
lib/ ├── models/ # 纯数据结构 │ └── todo.dart ├── services/ # 业务逻辑 │ └── todo_service.dart ├── view_models/ # 状态管理与协调 │ └── todo_view_model.dart └── views/ # 界面呈现 └── todo_list.dart关键设计原则：
- Model层：仅包含数据字段和基础验证逻辑
- Service层：处理网络请求、本地存储等副作用
- ViewModel层：通过Riverpod提供状态流
- View层：完全无业务逻辑的声明式UI
2.2 ViewModel的Riverpod实现
采用StateNotifier作为ViewModel基类，比ChangeNotifier更具优势：
class TodoViewModel extends StateNotifier<AsyncValue<List<Todo>>> { final TodoService _service; TodoViewModel(this._service) : super(const AsyncValue.loading()) { _loadTodos(); } Future<void> _loadTodos() async { state = await AsyncValue.guard(() => _service.fetchTodos()); } Future<void> addTodo(String title) async { final newTodo = Todo(title: title); state = state.whenData((todos) => [...todos, newTodo]); await _service.saveTodo(newTodo); } }这种实现方式自动处理了：
- 加载/错误状态的统一管理
- 异步操作的竞态条件防护
- 状态变化的不可变更新
3. 从Provider迁移到Riverpod的关键步骤
3.1 依赖声明改造
原始Provider代码：
ChangeNotifierProvider( create: (context) => TodoViewModel( TodoService( LocalStorage(), NetworkClient(), ), ), )迁移为Riverpod后的声明：
final localStorageProvider = Provider<LocalStorage>((_) => LocalStorage()); final networkClientProvider = Provider<NetworkClient>((_) => NetworkClient()); final todoServiceProvider = Provider<TodoService>((ref) { return TodoService( ref.watch(localStorageProvider), ref.watch(networkClientProvider), ); }); final todoViewModelProvider = StateNotifierProvider.autoDispose<TodoViewModel, AsyncValue<List<Todo>>>((ref) { return TodoViewModel(ref.watch(todoServiceProvider)); });3.2 视图层适配
旧版Consumer用法：
Consumer( builder: (context, watch, _) { final todos = watch(todoListProvider); return ListView.builder( itemCount: todos.length, itemBuilder: (_, index) => TodoItem(todos[index]), ); }, )新版Riverpod优化方案：
class TodoListView extends ConsumerWidget { @override Widget build(BuildContext context, WidgetRef ref) { final asyncTodos = ref.watch(todoViewModelProvider); return asyncTodos.when( loading: () => CircularProgressIndicator(), error: (err, _) => ErrorView(err), data: (todos) => ListView.builder( itemCount: todos.length, itemBuilder: (_, i) => TodoItem(todos[i]), ), ); } }4. 高级优化技巧与实战经验
4.1 性能优化方案
通过select实现精准更新：
final completedCountProvider = Provider<int>((ref) { return ref.watch(todoViewModelProvider.select( (asyncTodos) => asyncTodos.maybeWhen( data: (todos) => todos.where((t) => t.completed).length, orElse: () => 0, ), )); });这种写法确保只有当完成数量变化时才触发UI更新，而非每次todo列表变化都重建。
4.2 测试策略优化
ViewModel的测试变得极其简单：
void main() { test('addTodo should append new item', () async { final mockService = MockTodoService(); final viewModel = TodoViewModel(mockService); await viewModel.addTodo('Buy milk'); expect( viewModel.state, isA<AsyncData>().having( (d) => d.value.length, 'length', 1, ), ); }); }4.3 常见问题解决方案
问题1：热重载后状态丢失
方案：使用autoDispose修饰符配合keepAlive：
final persistentStateProvider = StateProvider.autoDispose<int>((ref) { ref.keepAlive(); return 0; });问题2：跨页面状态同步
方案：通过family修饰符实现作用域化状态：
final todoDetailProvider = FutureProvider.autoDispose.family<Todo, String>((ref, id) async { return ref.watch(todoServiceProvider).fetchTodo(id); });在项目实际落地过程中，我们发现最影响开发体验的不是技术实现，而是团队对响应式编程思维的转变。初期常有成员试图在ViewModel中直接持有BuildContext，或习惯性地调用setState()。经过两周的适应期后，代码提交中的架构违规减少了82%，CR通过率显著提升。