【教程】Flutter 高性能项目架构创建指南:从入门到高性能架构

Flutter 新项目权威指南:从入门到高性能架构

第 1 部分:现代 Flutter 架构的基石

1.1 引言 - 超越"能用就行":为何需要高性能架构

欢迎来到 Flutter 开发的世界!对于许多初学者来说,让应用"跑起来"似乎是首要目标。然而,随着项目功能的增加和复杂度的提升,一个没有经过深思熟虑的架构很快就会变成所谓的"意大利面条式代码"------杂乱无章,难以维护,每次增加新功能或修复 bug 都如同在雷区排雷 1。这不仅会拖慢开发进度,还会严重影响应用的性能和稳定性。

本教程的目标,就是引导你从第一天开始,就构建一个专业、可扩展且高性能的 Flutter 应用。我们将摒弃那些临时抱佛脚的编码方式,直接采用业界验证的最佳实践。这不仅能让你写出更健壮的代码,更能为你未来的职业生涯打下坚实的架构思维基础。

为了实现这一目标,我们将采用一套精心挑选的、现代化的技术栈。这套组合拳代表了当前 Flutter 生态在"结构化"与"开发效率"之间取得的完美平衡:

  • 架构模式:功能优先 (Feature-First) 的整洁架构 (Clean Architecture)

    • 是什么? 想象一下,整洁架构就像是把你的代码分成几个逻辑清晰的"部门":UI 部门(展示层)、业务逻辑部门(领域层)和数据处理部门(数据层)2。而"功能优先"则是在此基础上,将整个项目按功能模块(如"登录"、"个人中心"、"商品列表")进行组织,每个模块内部都拥有自己独立的"三部门"结构 3。
    • 为什么选它? 这种结构确保了各部分职责单一、高度解耦,使得应用极易测试、维护和扩展 2。当团队协作时,不同成员可以并行开发不同功能模块,互不干扰 5。虽然传统的整洁架构因其"模板代码"较多而令人生畏 1,但我们将通过代码生成工具来解决这一痛点,让你享受其带来的结构优势,而无需承受繁琐的编码负担。
  • 状态管理与依赖注入:Riverpod

    • 是什么? Riverpod 是一个现代、强大且灵活的 Flutter 框架,它同时解决了"状态管理"和"依赖注入"两大核心问题 6。
    • 为什么选它? 相比于一些早期的解决方案,Riverpod 提供了编译时安全检查,减少了运行时错误,并且其 API 设计更加直观和现代化 8。我们选择它,意味着可以用一套统一的工具和理念来处理应用内的数据流和服务获取,从而简化技术栈。
  • 路由管理:Go_Router

    • 是什么? 一个功能强大、基于 URL 的声明式路由库 10。
    • 为什么选它? 它是 Flutter 官方团队推荐的路由解决方案 12。它能轻松处理复杂的导航逻辑、深层链接(Deep Linking)以及页面间的数据传递,让你的应用导航结构一目了然。
  • 数据层工具集:Dio、Freezed 与 Repository 模式

    • 是什么? 这是我们"数据处理部门"的三大利器。Dio 是一个强大的 HTTP 网络请求库;Freezed 是一个代码生成工具,可以自动为我们创建不可变的数据模型类,省去大量重复的手写代码 13;

      Repository(仓库)模式 则是一种设计模式,它提供了一个清晰、可测试的接口来访问数据 15。

    • 为什么选它们? 这套组合拳让我们的数据层变得极其稳固和高效。Dio 提供了丰富的功能(如拦截器、取消请求),Freezed 保证了数据模型的不可变性(这是构建可预测状态应用的关键),而 Repository 模式则将数据来源(是来自网络 API 还是本地数据库)的细节完全隐藏起来,使得业务逻辑无需关心数据到底从何而来。

本教程的核心价值,不仅仅是介绍这些工具的用法,更是展示如何将它们协同组合,构建一个真正意义上的现代化、高性能 Flutter 应用架构。让我们从最基础的编程原则开始,为这座摩天大楼打下坚实的地基。

1.2 黄金法则:通俗易懂的 SOLID 原则

在动手编码之前,理解一些软件设计的"黄金法则"至关重要。SOLID 原则是五个面向对象编程的基本原则,它们是构建清晰、可维护、可扩展软件的基石 17。我们将用最简单的比喻和 Flutter 代码示例来解释它们,你会发现,这些原则正是我们后续架构设计的理论依据。

  • S - 单一职责原则 (Single Responsibility Principle, SRP)

    • 比喻: 一把瑞士军刀 vs. 一个工具箱。瑞士军刀功能繁多,但每个功能都很基础。而一个专业的工具箱里,锤子只负责敲,螺丝刀只负责拧。一个类也应该像工具箱里的工具,只做好一件事 19。

    • 原则: 一个类应该只有一个引起它变化的原因 20。

    • 示例:

      • 错误示范 ❌: 一个 User 类既存储用户信息,又负责将自己保存到数据库。

        Dart

        javascript 复制代码
        // 违反 SRP:User 类承担了数据模型和数据持久化两个职责
        class User {
          String name;
          String email;
        
          User(this.name, this.email);
        
          void saveToDatabase() {
            // 连接数据库、执行 SQL...
          }
        }
      • 正确示范 ✅: 将职责分离到不同的类中。

        Dart

        arduino 复制代码
        // 职责一:数据模型
        class User {
          final String name;
          final String email;
        
          User(this.name, this.email);
        }
        
        // 职责二:数据持久化
        class UserRepository {
          void save(User user) {
            // 连接数据库、执行 SQL...
          }
        }

        这正是我们稍后将要实践的 Repository 模式的核心思想。

  • O - 开放/封闭原则 (Open/Closed Principle, OCP)

    • 比喻: 一部带 Type-C 接口的手机。这个接口对接入新设备(如充电器、耳机、U盘)是"开放"的,但接口本身的设计(物理形状、协议)是"封闭"的,你不能去修改它 18。

    • 原则: 软件实体(类、模块、函数等)应该对扩展开放,对修改封闭。

    • 示例:

      • 错误示范 ❌: 一个计算不同形状面积的函数,每次增加新形状都要修改函数内部。

        Dart

        kotlin 复制代码
        class AreaCalculator {
          double calculate(Object shape) {
            if (shape is Square) {
              return shape.side * shape.side;
            } else if (shape is Circle) {
              return 3.14 * shape.radius * shape.radius;
            }
            // 每增加一个新形状,都必须修改这里!
            return 0;
          }
        }
      • 正确示范 ✅: 使用抽象来允许扩展。

        Dart

        dart 复制代码
        abstract class Shape {
          double get area;
        }
        
        class Square implements Shape {
          final double side;
          Square(this.side);
          @override
          double get area => side * side;
        }
        
        class Circle implements Shape {
          final double radius;
          Circle(this.radius);
          @override
          double get area => 3.14 * radius * radius;
        }
        
        // AreaCalculator 现在无需修改即可支持新形状
        class AreaCalculator {
          double calculate(Shape shape) {
            return shape.area;
          }
        }

        这正是我们为 Repository 和 DataSource 定义抽象接口的原因。

  • L - 里氏替换原则 (Liskov Substitution Principle, LSP)

    • 比喻: 如果你的程序需要一只"鸟",那么给它一只麻雀或者鸽子都应该能正常工作。但如果给它一只企鹅(它不会飞),程序可能会因为调用 fly() 方法而出错。子类应该能够替换其父类,并且程序的行为不会出错 17。

    • 原则: 子类型必须能够替换掉它们的基类型。

    • 示例: 在 Flutter 中,这通常意味着子 Widget 应该遵循其父 Widget 的契约。一个更经典的例子是:

      Dart

      scala 复制代码
      class Bird {
        void fly() {
          print('Flying...');
        }
      }
      
      class Ostrich extends Bird {
        @override
        void fly() {
          // 鸵鸟不会飞,重写这个方法会破坏原有逻辑
          throw Exception("Ostriches can't fly!");
        }
      }

      在 Widget 树中,如果你期望一个能响应点击的 Button,那么用一个自定义的 FancyButton 替换它时,FancyButton 也必须能正确处理点击事件。

  • I - 接口隔离原则 (Interface Segregation Principle, ISP)

    • 比喻: 你不应该为了买一个锤子而被迫购买一整个工具箱。应该提供小而专的"工具包"(接口)17。

    • 原则: 客户端不应该被强迫依赖于它们不使用的方法。

    • 示例:

      • 错误示范 ❌: 一个庞大的 Worker 接口,包含了所有可能的工作。

        Dart

        less 复制代码
        abstract class IWorker {
          void work();
          void eat();
        }
        
        class Human implements IWorker {
          @override
          void work() {/*... */}
          @override
          void eat() {/*... */}
        }
        
        // 机器人不需要吃饭,但被迫实现 eat 方法
        class Robot implements IWorker {
          @override
          void work() {/*... */}
          @override
          void eat() {
            // 这个方法是多余的
          }
        }
      • 正确示范 ✅: 将大接口拆分成小接口。

        Dart

        typescript 复制代码
        abstract class IWorkable {
          void work();
        }
        
        abstract class IEatable {
          void eat();
        }
        
        class Human implements IWorkable, IEatable {
          @override
          void work() {/*... */}
          @override
          void eat() {/*... */}
        }
        
        class Robot implements IWorkable {
          @override
          void work() {/*... */}
        }
  • D - 依赖倒置原则 (Dependency Inversion Principle, DIP)

    • 比喻: 你家里的台灯并不依赖于某个特定品牌的灯泡。它依赖于一个标准的"灯泡接口"(比如 E27 螺口)。只要灯泡符合这个标准,无论是飞利浦还是欧司朗的,都能拧上去用 18。

    • 原则: 高层模块不应该依赖于低层模块。两者都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。

    • 示例:

      • 错误示范 ❌: 业务逻辑层直接依赖于一个具体的数据获取实现。

        Dart

        csharp 复制代码
        class ApiService {
          Future<String> fetchData() async => "Data from API";
        }
        
        // 业务逻辑直接创建并依赖 ApiService 的实例
        class BusinessLogic {
          final ApiService _apiService = ApiService();
        
          void processData() async {
            final data = await _apiService.fetchData();
            //...
          }
        }
      • 正确示范 ✅: 依赖于抽象(接口)。

        Dart

        dart 复制代码
        // 抽象层
        abstract class IDataSource {
          Future<String> fetchData();
        }
        
        // 低层模块(细节)
        class ApiService implements IDataSource {
          @override
          Future<String> fetchData() async => "Data from API";
        }
        
        // 高层模块(业务逻辑)
        class BusinessLogic {
          final IDataSource _dataSource;
        
          // 依赖通过构造函数"注入"
          BusinessLogic(this._dataSource);
        
          void processData() async {
            final data = await _dataSource.fetchData();
            //...
          }
        }

        这正是"依赖注入"(Dependency Injection, DI)的核心思想,也是 Riverpod 将要为我们解决的问题。

理解这些原则后,你会发现我们接下来构建的整个架构,都是这些思想的具体体现。它们将指导我们做出正确的决策,构建一个优雅而强大的 Flutter 应用。

1.3 搭建你的专业工作空间

现在,理论基础已经牢固,让我们开始动手实践。一个专业的项目始于一个专业的开发环境。

  1. 创建 Flutter 项目

    打开你的终端(Terminal),导航到你希望存放项目的目录,然后运行以下命令:

    Bash

    lua 复制代码
    flutter create your_awesome_app

    Flutter 会为你生成一个包含示例代码的标准项目。用 Visual Studio Code 或 Android Studio 打开这个新创建的 your_awesome_app 文件夹。

  2. 理解项目结构

    你会看到一个文件和文件夹列表。对于初学者,最关键的是 lib 文件夹,这里将存放我们所有的 Dart 代码。pubspec.yaml 文件是项目的"身份证",它定义了项目名称、依赖的第三方库(我们称之为 package)等信息。

  3. 配置代码规范检查器 (Linter)

    Linter 是一个自动化的代码审查工具,它会根据预设的规则检查你的代码,帮助你发现潜在的错误并保持统一的编码风格 12。这对于个人开发和团队协作都至关重要。Flutter 官方提供了一个优秀的 linter 配置包:

    flutter_lints

    打开 pubspec.yaml 文件,确保 dev_dependencies 部分包含了 flutter_lints

    YAML

    yaml 复制代码
    dev_dependencies:
      flutter_test:
        sdk: flutter
      flutter_lints: ^3.0.0 # 确保版本是最新的

    接着,在项目的根目录下找到 analysis_options.yaml 文件。这是 linter 的配置文件。我们将采用比默认更严格一些的规则,以培养良好的编码习惯。用以下内容替换该文件的全部内容:

    YAML

    yaml 复制代码
    include: package:flutter_lints/flutter.yaml
    
    linter:
      rules:
        # 风格建议
        - prefer_const_constructors
        - prefer_const_declarations
        - prefer_final_locals
        - prefer_final_fields
        - always_use_package_imports
        - avoid_relative_lib_imports
        - require_trailing_commas
    
        # 性能与错误预防
        - avoid_empty_else
        - avoid_print # 在生产代码中避免使用 print
        - cancel_subscriptions
        - close_sinks
        - no_logic_in_create_state
        - use_key_in_widget_constructors

    这些规则会鼓励你使用 const 来优化性能,使用 final 来保证不可变性,并避免一些常见的编码陷阱。

  4. 安装必备的 IDE 扩展

    为了提升开发效率,强烈建议安装以下适用于 VS Code 或 Android Studio 的扩展/插件:

    • Dart: 官方 Dart 语言支持。
    • Flutter: 官方 Flutter 框架支持。
    • Awesome Flutter Snippets: 提供常用的 Flutter 代码片段,减少模板代码的编写。
    • Riverpod Snippets: 专门为我们即将使用的 Riverpod 提供代码片段,极大提高效率。

至此,你的工作空间已经配置完毕。这是一个干净、规范且高效的起点,为我们接下来构建坚实的架构打下了基础。

第 2 部分:构建架构骨架

在添加任何具体的功能之前,我们需要先搭建起整个应用的"骨架"。这个骨架定义了代码的组织方式、模块间的通信规则以及数据的流动方向。一个好的骨架能让应用在不断"长肉"的过程中保持"体形",而不是变得臃肿和混乱。

2.1 功能优先 (Feature-First) 的项目结构

组织代码的方式主要有两种:层优先(Layer-First)和功能优先(Feature-First)4。

  • 层优先: 将代码按照技术类型分组,比如 screensprovidersrepositories 文件夹。这种方式在项目初期很简单直观,但随着功能增多,你会发现为了修改一个功能,你需要在多个文件夹之间来回跳转,非常低效。
  • 功能优先: 将代码按照业务功能模块分组,比如 auth(认证)、products(商品)、profile(个人中心)。每个功能模块内部再按层(如 datadomainpresentation)组织。

我们选择功能优先的结构,因为它具有明显的优势:

  • 高内聚,低耦合: 与单一功能相关的所有代码都集中在一起,便于理解和维护 21。
  • 模块化: 每个功能模块就像一个独立的"微型应用",可以独立开发、测试,甚至在未来复用到其他项目中 5。
  • 团队协作友好: 不同的开发者可以同时负责不同的功能模块,代码冲突的概率大大降低 5。

现在,让我们在 lib 文件夹下创建我们应用的骨架。删除 lib/main.dart 里的所有示例代码,然后创建以下目录结构:

bash 复制代码
your_awesome_app/
└── lib/
    ├── main.dart             # 应用入口
    └── src/
        ├── core/             # 核心/通用服务
        │   ├── di/           # 依赖注入配置
        │   └── routing/      # 路由配置
        ├── features/         # 所有功能模块
        │   └── (example_feature)/ # 例如:products 模块
        │       ├── data/
        │       │   ├── datasources/
        │       │   ├── models/
        │       │   └── repositories/
        │       ├── domain/
        │       │   ├── entities/
        │       │   ├── repositories/
        │       │   └── usecases/
        │       └── presentation/
        │           ├── notifiers/
        │           ├── screens/
        │           └── widgets/
        ├── shared/           # 跨功能共享的代码
        │   ├── theme/
        │   └── widgets/
        └── utils/            # 通用工具类

为了让你更清晰地理解每个文件夹的职责,这里提供一个详细的蓝图表格。

路径 职责 关键内容示例
lib/main.dart 应用的唯一入口。负责初始化依赖注入、路由,并启动应用。 ProviderScope, MaterialApp.router
lib/src/core/ 应用的核心逻辑,与任何具体业务功能无关,是应用的"基础设施"。 依赖注入容器配置、路由图定义、全局 API 客户端封装。
lib/src/features/ 所有业务功能模块的父目录,是应用的主体。 auth/, products/, profile/ 等功能文件夹。
lib/src/features/[feature_name]/data 数据层: 负责获取和存储特定功能的数据。 product_model.dart, product_remote_datasource.dart, product_repository_impl.dart
lib/src/features/[feature_name]/domain 领域层: 包含特定功能的纯业务逻辑和规则,不依赖任何框架。 product_entity.dart, product_repository.dart (抽象接口), fetch_products_usecase.dart
lib/src/features/[feature_name]/presentation 表现层: 负责特定功能的 UI 展示和用户交互。 products_screen.dart, product_card.dart, products_notifier.dart (状态管理)
lib/src/shared/ 共享层: 存放被多个功能模块共同使用的代码,以避免重复。 可复用的 UI 组件 (PrimaryButton)、应用主题 (app_theme.dart)、全局常量。
lib/src/utils/ 工具层: 存放通用的、与业务无关的辅助函数或扩展。 date_formatter.dart, string_extensions.dart, logger.dart

这个结构初看起来可能有些复杂,但它的逻辑非常清晰。一旦你习惯了它,你会发现开发新功能就像"填空"一样,每个文件都各司其职,整个项目井然有序。

2.2 使用 Riverpod 实现统一的依赖注入

依赖注入 (Dependency Injection, DI) 是一个听起来很高级但原理很简单的概念。

比喻: 想象一个厨师(比如一个 Widget)需要一把刀(比如一个网络请求服务)。他有两种方式获得刀:

  1. 自己制造: 每次做饭都现场打一把刀。这显然很低效,而且每把刀质量可能都不同。
  2. 从工具架上取: 厨房里有一个统一的工具架(DI 容器),上面放着一把标准化的、高质量的厨刀。厨师需要时直接去拿就行。

依赖注入就是第二种方式。我们不让 Widget 自己创建它所依赖的服务,而是通过一个外部容器来"注入"这些服务 22。这样做的好处是:

  • 解耦: Widget 不再关心服务的具体实现,只关心它需要一个符合某种"接口"的服务。
  • 易于测试: 在测试时,我们可以轻松地给 Widget 注入一个"模拟的"假服务,从而独立地测试 Widget 的行为 15。

既然我们已经决定使用 Riverpod 进行状态管理,那么用它来做依赖注入是自然而然的选择。这避免了引入额外的 DI 库(如 get_it),让我们的技术栈更精简 7。Riverpod 的

Provider 本质上就是一个强大的 DI 容器。

第一步:添加依赖

在 pubspec.yaml 文件中添加 riverpod 和 dio(我们的网络请求库):

YAML

yaml 复制代码
dependencies:
  flutter:
    sdk: flutter
  flutter_riverpod: ^2.5.1 # 使用最新版本
  dio: ^5.4.3+1 # 使用最新版本

然后在终端运行 flutter pub get

第二步:配置 ProviderScope

为了让整个应用都能访问到 Provider,我们需要在应用的根部用 ProviderScope 包裹起来。修改 lib/main.dart:

Dart

scala 复制代码
import 'package.flutter/material.dart';
import 'package.flutter_riverpod/flutter_riverpod.dart';

void main() {
  runApp(
    // ProviderScope 是存放所有 provider 状态的容器
    const ProviderScope(
      child: MyApp(),
    ),
  );
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: Text('Hello, Awesome App!'),
        ),
      ),
    );
  }
}

第三步:提供一个全局服务

让我们来提供一个将在整个应用中使用的 Dio 实例。在 lib/src/core/di/ 目录下创建一个 dio_provider.dart 文件:

Dart

ini 复制代码
import 'package.dio/dio.dart';
import 'package.flutter_riverpod/flutter_riverpod.dart';

/// 提供一个全局的 Dio 实例
final dioProvider = Provider<Dio>((ref) {
  final dio = Dio();
  // 在这里可以添加全局配置,比如 base URL、拦截器等
  // dio.options.baseUrl = 'https://api.example.com';
  return dio;
});

现在,应用中的任何地方(只要能访问到 ref 对象),都可以通过 ref.read(dioProvider) 来获取这个唯一的 Dio 实例。我们的 DI 骨架已经搭建完成。

2.3 使用 Go_Router 实现声明式路由

Flutter 默认的 Navigator.push 是一种命令式路由,代码分散在各个角落,难以管理,并且不利于处理深层链接等高级场景。go_router 采用声明式路由,你将所有的路由规则集中定义在一个地方,就像一张应用的"导航地图"10。

第一步:添加依赖

在 pubspec.yaml 中添加 go_router:

YAML

yaml 复制代码
dependencies:
  #... 其他依赖
  go_router: ^14.1.0 # 使用最新版本

运行 flutter pub get

第二步:配置路由

在 lib/src/core/routing/ 目录下创建 app_router.dart 文件。这里我们将定义所有的路由和导航逻辑。

Dart

scala 复制代码
import 'package:flutter/material.dart';
import 'package:go_router/go_router.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

// 这是一个(目前假的)认证状态 provider
final authStateProvider = StateProvider<bool>((ref) => false);

final goRouterProvider = Provider<GoRouter>((ref) {
  final authState = ref.watch(authStateProvider);

  return GoRouter(
    initialLocation: '/splash',
    routes:,
    redirect: (BuildContext context, GoRouterState state) {
      final isLoggedIn = authState;
      final isLoggingIn = state.matchedLocation == '/login';

      // 如果用户未登录且不在登录页,则重定向到登录页
      if (!isLoggedIn &&!isLoggingIn) {
        return '/login';
      }
      // 如果用户已登录且在登录页,则重定向到首页
      if (isLoggedIn && isLoggingIn) {
        return '/home';
      }
      // 其他情况不重定向
      return null;
    },
  );
});

// 为了让示例能跑起来,我们先创建几个临时的空页面
class SplashScreen extends StatelessWidget {
  const SplashScreen({super.key});
  @override
  Widget build(BuildContext context) => const Scaffold(body: Center(child: Text('Splash')));
}

class LoginScreen extends StatelessWidget {
  const LoginScreen({super.key});
  @override
  Widget build(BuildContext context) => const Scaffold(body: Center(child: Text('Login')));
}

class HomeScreen extends StatelessWidget {
  const HomeScreen({super.key});
  @override
  Widget build(BuildContext context) => const Scaffold(body: Center(child: Text('Home')));
}

这段代码做了几件非常重要的事情:

  1. 创建了一个 goRouterProvider,它会返回一个 GoRouter 实例。

  2. 定义了三个基本路由:/splash/login/home 11。

  3. 实现了一个强大的认证守卫 redirect 24。这个函数会在每次导航前被调用。它会检查当前的认证状态(我们用一个简单的

    authStateProvider 模拟)和目标路径,然后决定是否需要重定向。这是处理需要登录才能访问的页面的最佳实践。

第三步:集成到应用

最后,我们需要将这个 router 集成到我们的 MyApp widget 中。修改 lib/main.dart:

Dart

scala 复制代码
import 'package.flutter/material.dart';
import 'package.flutter_riverpod/flutter_riverpod.dart';
import 'src/core/routing/app_router.dart'; // 导入我们的路由配置

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

// MyApp 现在是一个 ConsumerWidget,以便访问 provider
class MyApp extends ConsumerWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // 监听 goRouterProvider
    final router = ref.watch(goRouterProvider);

    // 使用 MaterialApp.router 构造函数
    return MaterialApp.router(
      routerConfig: router,
      title: 'Awesome App',
      //... 其他配置,比如主题
    );
  }
}

现在,我们的应用已经拥有了一个集中管理、带认证逻辑的现代化路由系统。骨架搭建完成,接下来,让我们开始为它添加第一个功能模块。

第 3 部分:实现第一个功能:"商品列表"深度实践

现在,我们将通过构建一个完整的"商品列表"功能,来将前面讨论的架构理论付诸实践。我们将从最底层的数据获取开始,一步步向上构建,直到最终在 UI 上展示出来。这个过程将清晰地展示各层之间是如何协作的。

我们将使用一个公开的假数据 API https://fakestoreapi.com/products 来获取商品列表。

3.1 数据层:真相的基石

数据层是所有应用数据的来源,它的职责是获取、缓存和管理数据。一个设计良好的数据层应该对上层(领域层和表现层)隐藏其实现细节。

第 1 步:使用 Freezed 定义数据模型

首先,我们需要定义一个 Dart 类来表示从 API 返回的商品数据。手动编写这样的类非常繁琐,需要处理 copyWithtoString== 操作符、hashCode 以及 fromJson/toJson 等模板代码 14。

freezed 包可以为我们自动生成这一切。

添加依赖:

在 pubspec.yaml 中添加 freezed 相关的包:

YAML

yaml 复制代码
dependencies:
  #...
  freezed_annotation: ^2.4.1

dev_dependencies:
  #...
  build_runner: ^2.4.9
  freezed: ^2.5.2
  json_serializable: ^6.8.0

运行 flutter pub get

创建模型文件:

在 lib/src/features/products/data/models/ 目录下创建 product_model.dart 文件:

Dart

dart 复制代码
import 'package:freezed_annotation/freezed_annotation.dart';

part 'product_model.freezed.dart';
part 'product_model.g.dart';

@freezed
class ProductModel with _$ProductModel {
  const factory ProductModel({
    required int id,
    required String title,
    required double price,
    required String description,
    required String category,
    required String image,
    required RatingModel rating,
  }) = _ProductModel;

  factory ProductModel.fromJson(Map<String, dynamic> json) =>
      _$ProductModelFromJson(json);
}

@freezed
class RatingModel with _$RatingModel {
  const factory RatingModel({
    required double rate,
    required int count,
  }) = _RatingModel;

  factory RatingModel.fromJson(Map<String, dynamic> json) =>
      _$RatingModelFromJson(json);
}
  • @freezed 注解告诉 freezed 为这个类生成代码。
  • part 指令链接到即将被生成的文件。
  • with _$ProductModel 是一个 mixin,它将把生成的方法混入到我们的类中。
  • factory 构造函数定义了类的属性。freezed 将确保它们是不可变的。
  • fromJson 工厂构造函数则与 json_serializable 集成,用于解析 JSON 14。

生成代码:

在终端运行以下命令:

Bash

arduino 复制代码
flutter pub run build_runner build --delete-conflicting-outputs

build_runner 会扫描你的项目,找到带有注解的类,并生成对应的 .freezed.dart.g.dart 文件。现在,你的 ProductModel 就拥有了所有必要的方法,并且是类型安全的。

第 2 步:使用 Dio 创建 API 服务 (DataSource)

DataSource 是直接与外部数据源(如 REST API、数据库)交互的组件。它负责执行最原始的数据操作。

lib/src/features/products/data/datasources/ 目录下创建 product_remote_datasource.dart

Dart

kotlin 复制代码
import 'package:dio/dio.dart';
import '../models/product_model.dart';

// 1. 定义抽象接口 (遵循 DIP)
abstract class IProductRemoteDataSource {
  Future<List<ProductModel>> fetchProducts();
}

// 2. 实现具体的数据源
class ProductRemoteDataSource implements IProductRemoteDataSource {
  final Dio _dio;

  ProductRemoteDataSource(this._dio);

  @override
  Future<List<ProductModel>> fetchProducts() async {
    try {
      final response = await _dio.get('https://fakestoreapi.com/products');

      if (response.statusCode == 200) {
        final List<dynamic> data = response.data;
        return data.map((json) => ProductModel.fromJson(json)).toList();
      } else {
        throw Exception('Failed to load products');
      }
    } catch (e) {
      // 实际项目中应进行更精细的错误处理
      throw Exception('Error fetching products: $e');
    }
  }
}

这个实现清晰地展示了如何使用 Dio 发起网络请求,并将返回的 JSON 列表通过我们用 freezed 生成的 fromJson 方法转换成 ProductModel 对象列表。

第 3 步:实现 Repository 模式

Repository 是数据层对外的唯一窗口。它封装了所有数据操作的逻辑,决定是从网络获取数据、从本地缓存读取,还是两者结合 15。

定义抽象 Repository:

在 lib/src/features/products/domain/repositories/ 目录下创建 product_repository.dart。注意,它位于 domain 层,因为它定义的是业务契约,而不是实现细节。

Dart

java 复制代码
import '../entities/product.dart'; // 注意:这里我们可能会使用领域实体

// 为了简单起见,我们暂时让 Entity 和 Model 结构相同
// 在复杂项目中,Entity 可能只包含业务需要的字段
typedef Product = ProductModel; 

abstract class IProductRepository {
  Future<List<Product>> fetchProducts();
}

实现具体 Repository:

在 lib/src/features/products/data/repositories/ 目录下创建 product_repository_impl.dart。

Dart

kotlin 复制代码
import '../../domain/repositories/product_repository.dart';
import '../datasources/product_remote_datasource.dart';
import '../../domain/entities/product.dart';

class ProductRepositoryImpl implements IProductRepository {
  final IProductRemoteDataSource _remoteDataSource;

  ProductRepositoryImpl(this._remoteDataSource);

  @override
  Future<List<Product>> fetchProducts() async {
    // 在这里可以添加缓存逻辑、数据转换等
    // 例如:先检查本地数据库,如果没有再去网络请求
    return await _remoteDataSource.fetchProducts();
  }
}

这个实现非常简单,它只是直接调用了 remote data source。但在真实项目中,Repository 是实现缓存策略、数据聚合等复杂逻辑的最佳位置。

第 4 步:使用 Riverpod 提供数据层服务

最后,我们需要将 DataSource 和 Repository 注册到 Riverpod 的 DI 容器中,以便上层可以访问它们。

lib/src/features/products/presentation/notifiers/ 目录下创建 product_providers.dart

Dart

kotlin 复制代码
import 'package:flutter_riverpod/flutter_riverpod.dart';
import '../../../../core/di/dio_provider.dart';
import '../../data/datasources/product_remote_datasource.dart';
import '../../data/repositories/product_repository_impl.dart';
import '../../domain/repositories/product_repository.dart';

// 1. 提供 ProductRemoteDataSource
final productRemoteDataSourceProvider = Provider<IProductRemoteDataSource>((ref) {
  // 依赖于全局的 dioProvider
  final dio = ref.watch(dioProvider);
  return ProductRemoteDataSource(dio);
});

// 2. 提供 ProductRepository
final productRepositoryProvider = Provider<IProductRepository>((ref) {
  // 依赖于 productRemoteDataSourceProvider
  final remoteDataSource = ref.watch(productRemoteDataSourceProvider);
  return ProductRepositoryImpl(remoteDataSource);
});

这里清晰地展示了 Riverpod 的依赖关系链:productRepositoryProvider 依赖 productRemoteDataSourceProvider,而后者又依赖于我们在 core 中定义的全局 dioProvider 7。

3.2 领域层:封装业务逻辑

领域层是应用的核心,它包含了纯粹的业务规则和逻辑,完全独立于 UI 和数据源 1。

在我们的商品列表功能中,业务逻辑非常简单:就是"获取商品列表"。对于这种简单的 CRUD(增删改查)操作,引入一个额外的"Use Case"(用例)层可能会显得过度设计,增加不必要的模板代码 12。

因此,我们做出一个务实的决定:对于这个功能,我们将直接在表现层的 Notifier 中调用 Repository 的方法。

但是,理解 Use Case 的概念仍然非常重要。一个 Use Case 封装了一个单一的、具体的业务操作。它在以下情况中会变得非常有价值:

  • 复杂的业务规则: 当获取商品前需要检查用户权限、会员等级等。
  • 数据聚合: 当需要从 ProductRepositoryUserRepository 两个地方获取数据,然后组合成一个新的视图模型时。

为了让你理解它的样子,这里是一个可选的 FetchProductsUseCase 示例(我们不会在当前项目中实际使用它,但你可以了解其结构):

Dart

kotlin 复制代码
// 位于 lib/src/features/products/domain/usecases/fetch_products_usecase.dart

import '../entities/product.dart';
import '../repositories/product_repository.dart';

class FetchProductsUseCase {
  final IProductRepository _repository;

  FetchProductsUseCase(this._repository);

  Future<List<Product>> call() async {
    // 在这里可以执行复杂的业务逻辑
    return await _repository.fetchProducts();
  }
}

3.3 表现层:状态、UI 与交互

表现层负责将数据显示给用户,并处理用户的交互。它应该尽可能地"笨",只负责展示,而将所有逻辑委托给状态管理层(Notifier)。

第 1 步:使用 AsyncNotifierProvider 管理状态

Riverpod 的 AsyncNotifier 是处理异步操作(如网络请求)状态的完美工具。它会自动为我们管理加载(loading)、数据(data)和错误(error)三种状态 9。

product_providers.dart 文件中,添加我们的状态 Notifier:

Dart

dart 复制代码
import 'package:flutter_riverpod/flutter_riverpod.dart';
import '../../domain/entities/product.dart';
import 'product_providers.dart'; // 导入 repository provider

// 使用 Riverpod Generator 可以简化这个过程,但手动编写有助于理解
final productsNotifierProvider =
    AsyncNotifierProvider<ProductsNotifier, List<Product>>(
  () => ProductsNotifier(),
);

class ProductsNotifier extends AsyncNotifier<List<Product>> {
  // `build` 方法用于提供初始状态
  @override
  Future<List<Product>> build() async {
    // 第一次构建时,获取商品列表
    return _fetchProducts();
  }

  // 一个私有方法,用于调用 repository
  Future<List<Product>> _fetchProducts() async {
    final repository = ref.read(productRepositoryProvider);
    return await repository.fetchProducts();
  }

  // 公开一个方法用于下拉刷新
  Future<void> refreshProducts() async {
    // 将状态设置为 loading
    state = const AsyncValue.loading();
    // 重新获取数据并更新状态
    state = await AsyncValue.guard(() => _fetchProducts());
  }
}
  • AsyncNotifierProvider 定义了一个提供异步状态的 Notifier。
  • ProductsNotifier 继承自 AsyncNotifier
  • build 方法在 Provider 第一次被读取时调用,它的返回值将成为 Provider 的初始状态。这里我们直接调用了获取数据的方法。
  • ref.read(productRepositoryProvider) 从 DI 容器中获取了我们之前定义的 Repository 实例。
  • refreshProducts 方法演示了如何手动触发数据的重新加载,并通过 AsyncValue.guard 优雅地处理可能出现的错误。
第 2 步:构建响应式 UI

现在,万事俱备,只欠东风。让我们来创建 UI 界面,消费(consume)并展示由 ProductsNotifier 管理的状态。

lib/src/features/products/presentation/screens/ 目录下创建 products_screen.dart

Dart

less 复制代码
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import '../notifiers/product_providers.dart';

// 继承自 ConsumerWidget 以便访问 ref
class ProductsScreen extends ConsumerWidget {
  const ProductsScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // 监听 productsNotifierProvider 的状态
    final productsState = ref.watch(productsNotifierProvider);

    return Scaffold(
      appBar: AppBar(
        title: const Text('商品列表'),
        actions:,
      ),
      // 使用 AsyncValue 的 when 方法来根据不同状态构建不同 UI
      body: productsState.when(
        data: (products) {
          // 数据成功加载
          return ListView.builder(
            itemCount: products.length,
            itemBuilder: (context, index) {
              final product = products[index];
              return ListTile(
                leading: Image.network(product.image, width: 50, height: 50),
                title: Text(product.title),
                subtitle: Text('$${product.price.toStringAsFixed(2)}'),
              );
            },
          );
        },
        loading: () {
          // 加载中状态
          return const Center(child: CircularProgressIndicator());
        },
        error: (error, stackTrace) {
          // 错误状态
          return Center(
            child: Column(
              mainAxisAlignment: MainAxisAlignment.center,
              children:,
            ),
          );
        },
      ),
    );
  }
}

这段 UI 代码是现代 Flutter 开发的典范:

  • ConsumerWidget 让我们可以在 build 方法中访问 WidgetRef
  • ref.watch(productsNotifierProvider) 订阅了状态的变化。当 productsState 改变时(例如,从 loading 变为 data),这个 Widget 会自动重建。
  • productsState.when(...)AsyncValue 最强大的功能。它强迫你处理所有可能的状态:dataloadingerror,确保了 UI 的健壮性,避免了空指针等常见错误 27。

最后,为了能看到这个页面,我们需要在 lib/src/core/routing/app_router.dart 中添加一个到 /products 的路由,并修改 initialLocation 或认证逻辑,使其能够导航到这个新页面。

至此,我们已经完整地构建了一个功能模块,从数据获取到 UI 展示,每一步都遵循了整洁架构和最佳实践。

第 4 部分:打造高质量的用户界面

一个强大的后端架构需要一个精致、一致且易用的用户界面来相匹配。在这一部分,我们将从架构师的视角转向 UI/UX 设计师和前端工程师的视角,专注于如何构建可复用、主题化和响应式的 UI。

4.1 设计可复用的组件

在上一节的 ProductsScreen 中,我们直接在 ListView.builder 里写了 ListTile 来展示商品。这种做法对于简单的列表是可行的,但如果这个商品卡片的样式需要在应用的其他地方(比如"猜你喜欢"、"我的收藏")复用,复制代码将是一场灾难 28。任何微小的样式修改都意味着要去多个地方同步更新。

遵循DRY (Don't Repeat Yourself) 原则,我们应该将重复的 UI 元素提取为独立的、可复用的组件 29。

重构 ProductCard:

让我们将 ListTile 重构为一个独立的 ProductCard widget。在 lib/src/shared/widgets/ 目录下创建 product_card.dart。我们把它放在 shared 目录下,因为它很可能被多个功能模块(如 products, cart, wishlist)使用。

Dart

scala 复制代码
import 'package:flutter/material.dart';
import '../../features/products/domain/entities/product.dart'; // 导入我们的实体

class ProductCard extends StatelessWidget {
  final Product product;
  final VoidCallback? onTap; // 用于处理点击事件的回调

  const ProductCard({
    super.key,
    required this.product,
    this.onTap,
  });

  @override
  Widget build(BuildContext context) {
    return Card(
      margin: const EdgeInsets.symmetric(horizontal: 16, vertical: 8),
      child: InkWell(
        onTap: onTap,
        child: Padding(
          padding: const EdgeInsets.all(12.0),
          child: Row(
            children:,
                ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

现在,我们可以回到 products_screen.dart 并使用这个新组件:

Dart

php 复制代码
//... 在 ListView.builder 中
itemBuilder: (context, index) {
  final product = products[index];
  return ProductCard(
    product: product,
    onTap: () {
      // 处理点击事件,例如导航到商品详情页
      // context.go('/products/${product.id}');
    },
  );
},

这次重构带来了巨大的好处:

  • 可复用性: 任何需要展示商品卡片的地方,只需一行 ProductCard(product:...) 即可。
  • 可维护性: 如果需要修改卡片样式(比如增加一个"收藏"按钮),只需修改 ProductCard 文件一处即可。
  • 代码清晰度: ProductsScreen 的代码变得更加简洁,专注于布局和状态管理,而不是 UI 细节。

创建优秀可复用组件的清单:

  • 默认是无状态的 (StatelessWidget): 尽可能让组件无状态,通过构造函数接收所有需要的数据和回调 30。
  • 通过构造函数接收数据: 组件不应该自己去获取数据,它只负责展示传入的数据 31。
  • 使用回调处理交互: 对于按钮点击等事件,使用 VoidCallbackValueChanged<T> 类型的参数,将处理逻辑交由父组件决定 32。
  • 无外部依赖: 一个好的可复用组件不应该依赖任何特定的 Provider 或 Notifier。它应该是纯粹的 UI 单元。

4.2 使用 ThemeData 和 Riverpod 实现一致的主题

在应用中硬编码颜色、字体大小和边距是一种常见的反模式 33。它会导致 UI 不一致,并且在需要进行全局设计变更(比如品牌升级或增加暗黑模式)时,变成一场噩梦。

Flutter 强大的 ThemeData 系统允许我们集中定义应用的视觉风格。结合 Riverpod,我们可以轻松实现动态的主题切换。

第一步:定义主题

在 lib/src/shared/theme/ 目录下创建 app_theme.dart。我们将使用 Material 3 的 ColorScheme.fromSeed 方法,它能根据一个"种子颜色"生成一整套和谐、美观且符合无障碍标准的颜色方案 34。

Dart

less 复制代码
import 'package:flutter/material.dart';

class AppTheme {
  static final ThemeData lightTheme = ThemeData(
    colorScheme: ColorScheme.fromSeed(
      seedColor: Colors.deepPurple,
      brightness: Brightness.light,
    ),
    useMaterial3: true,
    cardTheme: CardTheme(
      elevation: 1,
      shape: RoundedRectangleBorder(
        borderRadius: BorderRadius.circular(12),
      ),
    ),
    elevatedButtonTheme: ElevatedButtonThemeData(
      style: ElevatedButton.styleFrom(
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(8),
        ),
      ),
    ),
  );

  static final ThemeData darkTheme = ThemeData(
    colorScheme: ColorScheme.fromSeed(
      seedColor: Colors.deepPurple,
      brightness: Brightness.dark,
    ),
    useMaterial3: true,
    cardTheme: CardTheme(
      elevation: 1,
      shape: RoundedRectangleBorder(
        borderRadius: BorderRadius.circular(12),
      ),
    ),
    elevatedButtonTheme: ElevatedButtonThemeData(
      style: ElevatedButton.styleFrom(
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(8),
        ),
      ),
    ),
  );
}

第二步:创建主题 Notifier

在 lib/src/shared/theme/ 目录下创建 theme_notifier.dart 来管理当前的主题模式。

Dart

scala 复制代码
import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

final themeNotifierProvider =
    NotifierProvider<ThemeNotifier, ThemeMode>(() => ThemeNotifier());

class ThemeNotifier extends Notifier<ThemeMode> {
  @override
  ThemeMode build() {
    // 默认使用系统设置
    return ThemeMode.system;
  }

  void setThemeMode(ThemeMode mode) {
    state = mode;
  }
}

第三步:集成到 MaterialApp

回到 lib/main.dart,让我们的 MaterialApp 使用这些主题和 Notifier。

Dart

less 复制代码
//... in MyApp's build method
final themeMode = ref.watch(themeNotifierProvider);

return MaterialApp.router(
  routerConfig: router,
  title: 'Awesome App',
  theme: AppTheme.lightTheme, // 设置亮色主题
  darkTheme: AppTheme.darkTheme, // 设置暗色主题
  themeMode: themeMode, // 由 Notifier 控制当前模式
);

第四步:添加切换 UI

现在,我们可以在应用的任何地方添加一个开关来改变主题。例如,在 ProductsScreen 的 AppBar 中:

Dart

vbnet 复制代码
//... in ProductsScreen's AppBar
actions:

现在,点击这个按钮,整个应用的主题就会在亮色和暗色之间平滑切换!我们所有的组件,如 CardElevatedButton 等,都会自动适应新的主题颜色和样式,因为我们在 ProductCard 中使用了 Theme.of(context) 来获取样式,而不是硬编码。

4.3 构建响应式和自适应 UI

在当今多设备的环境下,应用必须能够适应不同尺寸的屏幕。Flutter 为此提供了强大的工具。

  • 响应式 (Responsive): 布局根据可用空间进行调整(例如,在宽屏上显示更多列)。
  • 自适应 (Adaptive): UI 元素根据平台(iOS/Android)或设备类型(手机/平板)改变其外观或行为。

关键实践:

  1. 绝对不要锁定屏幕方向: 强制应用只能竖屏是一种过时的做法,它会破坏在平板电脑和可折叠设备上的用户体验 30。
  2. 使用 LayoutBuilder LayoutBuilder 是实现响应式布局的首选工具。它提供了一个 constraints 对象,让你知道父组件允许的最大和最小宽高,从而可以动态地调整布局。

示例:ListView vs GridView

让我们修改 ProductsScreen,使其在屏幕较宽时显示网格布局,在较窄时显示列表布局。

Dart

php 复制代码
//... in ProductsScreen's body
body: productsState.when(
  data: (products) {
    return LayoutBuilder(
      builder: (context, constraints) {
        // 设置一个断点,例如 600 逻辑像素
        if (constraints.maxWidth > 600) {
          // 宽屏:使用 GridView
          return GridView.builder(
            gridDelegate: const SliverGridDelegateWithFixedCrossAxisCount(
              crossAxisCount: 2, // 或 3,取决于宽度
              childAspectRatio: 3 / 2,
              crossAxisSpacing: 10,
              mainAxisSpacing: 10,
            ),
            itemCount: products.length,
            itemBuilder: (context, index) {
              return ProductCard(product: products[index]);
            },
          );
        } else {
          // 窄屏:使用 ListView
          return ListView.builder(
            itemCount: products.length,
            itemBuilder: (context, index) {
              return ProductCard(product: products[index]);
            },
          );
        }
      },
    );
  },
  //... loading and error states
),

通过 LayoutBuilder,我们的 UI 现在能够智能地适应不同的屏幕尺寸,提供了更优化的用户体验。

第 5 部分:性能、测试与最终打磨

一个项目的功能完成只是第一步。要成为一个专业的、可交付的应用,我们还必须关注性能、可测试性和其他质量保障措施。

5.1 初学者的性能优化清单

性能优化是一个广阔的领域,但对于初学者来说,掌握几个关键点就能带来巨大的提升。

  • const 的力量: 这是 Flutter 中最简单、最有效的性能优化手段。当一个 widget 被声明为 const 时,Flutter 在重建(rebuild)时会跳过它,因为它知道这个 widget 永远不会改变 35。你的 linter 已经配置为提示你添加

    const,请务必遵循它的建议。

    Dart

    vbnet 复制代码
    // 好: const 使这个 Text widget 不会不必要地重建
    const Text('这是一个常量标题')
  • 懒加载列表 (ListView.builder): 我们已经实践了这一点。对于长列表,永远使用 .builder 构造函数。它只构建屏幕上可见的列表项,极大地节省了内存和 CPU 资源 36。

  • 图片优化: 图片是性能的主要消耗者。

    • 调整尺寸: 不要在一个需要 100x100 像素的视图里加载一张 4000x3000 像素的原图。在上传图片到服务器时,最好就生成不同尺寸的缩略图 38。
    • 使用缓存: 对于网络图片,使用像 cached_network_image 这样的包可以缓存图片,避免重复下载 39。
    • 选择合适的格式: 使用 WebP 格式通常比 PNG 或 JPG 体积更小,质量相近。
  • 最小化重建范围: 我们的 Riverpod 架构在这方面有天然优势。ref.watch 会精确地只重建需要更新的 widget。如果你在使用 StatefulWidget,请确保 setState() 在尽可能深的子 widget 中被调用,以避免重建整个屏幕。

  • 使用 Flutter DevTools: Flutter DevTools 是你的性能诊断"显微镜"。其中的"Performance"和"Inspector"视图可以帮助你直观地看到哪些 widget 在频繁重建(打开"Highlight Repaints"),以及每一帧的渲染耗时 37。

5.2 实用的测试入门

测试是保证应用质量和未来迭代安全性的关键。对于初学者,测试可能看起来很复杂,但我们可以从三个最基本的测试类型开始。

  • 单元测试 (Unit Test): 测试单个函数或类的逻辑,不涉及 UI。
  • 组件测试 (Widget Test): 测试单个 Widget 的渲染和交互,不涉及整个应用。
  • 集成测试 (Integration Test): 测试整个应用或一个完整的功能流程。

我们将为我们的 products 功能编写单元测试和组件测试。

添加测试依赖:

在 pubspec.yaml 的 dev_dependencies 中添加 mocktail 用于模拟依赖:

YAML

yaml 复制代码
dev_dependencies:
  #...
  mocktail: ^1.0.3

单元测试 ProductsNotifier:

在 test/features/products/ 目录下创建 products_notifier_test.dart。

Dart

dart 复制代码
import 'package:flutter_test/flutter_test.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:mocktail/mocktail.dart';
import 'package:your_awesome_app/src/features/products/domain/entities/product.dart';
import 'package:your_awesome_app/src/features/products/domain/repositories/product_repository.dart';
import 'package:your_awesome_app/src/features/products/presentation/notifiers/product_providers.dart';

// 1. 创建一个 Mock Repository
class MockProductRepository extends Mock implements IProductRepository {}

void main() {
  late MockProductRepository mockRepository;
  late ProviderContainer container;
  final testProducts = [Product(/*...假数据...*/)];

  setUp(() {
    mockRepository = MockProductRepository();
    // 2. 创建一个 ProviderContainer 用于测试
    container = ProviderContainer(
      overrides:,
    );
  });

  test('Notifier 应该在初始化时成功获取商品', () async {
    // 安排 (Arrange): 当 fetchProducts 被调用时,返回成功结果
    when(() => mockRepository.fetchProducts()).thenAnswer((_) async => testProducts);

    // 监听 Notifier 的状态
    final listener = container.listen(productsNotifierProvider, (_, __) {});

    // 等待初始状态
    await container.read(productsNotifierProvider.future);

    // 断言 (Assert): 验证状态是否为 data,并且数据正确
    expect(listener.read(), isA<AsyncData>().having((s) => s.value, 'value', testProducts));
  });

  test('Notifier 在获取商品失败时应该处理错误', () async {
    final exception = Exception('网络错误');
    // 安排: 当 fetchProducts 被调用时,抛出异常
    when(() => mockRepository.fetchProducts()).thenThrow(exception);
    
    // 监听
    final listener = container.listen(productsNotifierProvider, (_, __) {});

    // 等待
    await container.read(productsNotifierProvider.future).catchError((_) => {});

    // 断言: 验证状态是否为 error
    expect(listener.read(), isA<AsyncError>());
  });
}

这个测试展示了如何模拟(mock)Repository 依赖,并验证 Notifier 在成功和失败两种情况下的状态是否正确 1。

组件测试 ProductsScreen:

在 test/features/products/ 目录下创建 products_screen_test.dart。

Dart

arduino 复制代码
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:your_awesome_app/src/features/products/domain/entities/product.dart';
import 'package:your_awesome_app/src/features/products/presentation/notifiers/product_providers.dart';
import 'package:your_awesome_app/src/features/products/presentation/screens/products_screen.dart';

void main() {
  final testProducts = [Product(/*...假数据...*/)];

  testWidgets('当加载时,应该显示加载指示器', (tester) async {
    await tester.pumpWidget(
      ProviderScope(
        overrides:,
        child: const MaterialApp(home: ProductsScreen()),
      ),
    );

    // 验证 CircularProgressIndicator 是否存在
    expect(find.byType(CircularProgressIndicator), findsOneWidget);
  });

  testWidgets('当数据加载成功时,应该显示商品列表', (tester) async {
    await tester.pumpWidget(
      ProviderScope(
        overrides:,
        child: const MaterialApp(home: ProductsScreen()),
      ),
    );

    // 验证 ListView 是否存在
    expect(find.byType(ListView), findsOneWidget);
    // 验证商品标题是否显示
    expect(find.text(testProducts.first.title), findsOneWidget);
  });
}

这个测试展示了如何为 Widget 测试覆盖 Provider 的状态,并验证 UI 是否根据不同的状态正确渲染 12。

5.3 结论与后续步骤

恭喜你!你已经从零开始,构建了一个拥有现代化、高性能架构的 Flutter 应用。你不仅学会了如何使用一系列强大的工具,更重要的是,你理解了这些工具背后的架构思想。

核心回顾:

  • 分层与解耦: 通过整洁架构,我们将 UI、业务逻辑和数据获取清晰地分离开来,实现了高内聚、低耦合。
  • 依赖注入: 通过 Riverpod,我们实现了依赖的集中管理和注入,使得代码更加模块化和可测试。
  • 单向数据流: 数据从数据层流向表现层,UI 事件触发状态更新,整个流程清晰可预测。
  • 声明式思维: 无论是用 Go_Router 定义路由,还是用 Riverpod 的 when 方法构建 UI,我们都在用声明式的方式描述"我们想要什么",而不是"我们该如何一步步做"。

这只是你专业 Flutter 开发之旅的开始。基于当前坚实的架构,你可以继续探索更多高级主题:

  • 构建环境区分 (Flavors): 为开发、测试和生产环境配置不同的 API 地址、应用图标等。
  • CI/CD (持续集成/持续部署): 自动化测试和应用打包发布流程。
  • 高级动画: 学习 Flutter 强大的动画系统,创造更生动的用户体验。
  • 代码混淆: 保护你的应用代码,防止被轻易逆向工程 41。

推荐资源:

  • Flutter 官方文档: 永远是最新、最权威的信息来源。
  • Riverpod 官方文档: 深入学习 Riverpod 的各种 Provider 和高级用法。
  • Code with Andrea、Reso Coder 等博客和 YouTube 频道: 这些是 Flutter 社区公认的高质量学习资源。

从一个坚实的架构开始,你未来的开发之路将更加平坦和高效。你所构建的不仅仅是一个应用,更是一个易于维护、易于扩展、能够经受时间考验的健壮系统。祝你编码愉快!

相关推荐
踢球的打工仔13 小时前
PHP面向对象(7)
android·开发语言·php
安卓理事人13 小时前
安卓socket
android
安卓理事人19 小时前
安卓LinkedBlockingQueue消息队列
android
万能的小裴同学21 小时前
Android M3U8视频播放器
android·音视频
q***577421 小时前
MySql的慢查询(慢日志)
android·mysql·adb
JavaNoober21 小时前
Android 前台服务 "Bad Notification" 崩溃机制分析文档
android
王六岁1 天前
UIAutomatorViewer 安装指南 (macOS m3pro 芯片)
android studio
城东米粉儿1 天前
关于ObjectAnimator
android
zhangphil1 天前
Android渲染线程Render Thread的RenderNode与DisplayList,引用Bitmap及Open GL纹理上传GPU
android
火柴就是我1 天前
从头写一个自己的app
android·前端·flutter