1. Rebuild Optimization – Tối ưu quá trình xây dựng lại giao diện

1.1. Khái niệm Rebuild Optimization

Rebuild Optimization là quá trình tối ưu việc xây dựng lại giao diện trong Flutter nhằm giảm những lần thực thi build() không cần thiết, hạn chế công việc xử lý dư thừa và cải thiện độ mượt của ứng dụng.

Trong Flutter, giao diện được mô tả thông qua các Widget. Khi dữ liệu hoặc trạng thái thay đổi, Flutter có thể gọi lại phương thức build() để cập nhật giao diện theo trạng thái mới. Quá trình này được gọi là rebuild.

Rebuild là một phần bình thường trong cơ chế hoạt động của Flutter. Tuy nhiên, nếu quá nhiều Widget bị rebuild trong khi giao diện thực tế không thay đổi, ứng dụng có thể phải thực hiện nhiều công việc hơn mức cần thiết. Điều này đặc biệt đáng chú ý trong các màn hình có danh sách dài, biểu đồ, animation, nhiều thành phần tương tác hoặc cây Widget phức tạp.

Mục tiêu của Rebuild Optimization không phải là ngăn mọi lần rebuild mà là bảo đảm quá trình rebuild diễn ra đúng phạm vi, đúng thời điểm và với chi phí thấp nhất có thể.

Ví dụ, một màn hình hiển thị thông tin tài khoản gồm tên người dùng, ảnh đại diện, số dư và nút tăng số lượng sản phẩm. Khi người dùng nhấn nút tăng số lượng, chỉ phần giao diện phụ thuộc vào số lượng cần cập nhật. Những thành phần không liên quan như ảnh đại diện hoặc thông tin tài khoản không nên phải thực hiện thêm nhiều công việc không cần thiết.

1.2. Cơ chế rebuild trong Flutter

Khi trạng thái của một StatefulWidget thay đổi thông qua setState(), Flutter đánh dấu phần tử tương ứng trong Element Tree cần được cập nhật. Trong quá trình xử lý khung hình tiếp theo, Flutter gọi lại build() của Widget bị ảnh hưởng và cập nhật cấu trúc giao diện khi cần thiết.

Quá trình này có thể được mô tả như sau:

Cần phân biệt rằng việc gọi lại build() không đồng nghĩa với việc toàn bộ giao diện phải được vẽ lại từ đầu. Flutter sử dụng Element Tree để duy trì các phần tử giao diện hiện có, so sánh cấu trúc mới với cấu trúc hiện tại và chỉ cập nhật những phần cần thiết.

Ví dụ, khi một bộ đếm tăng từ 1 lên 2, Flutter có thể tạo Widget mới cho phần hiển thị số lượng nhưng vẫn giữ lại các Element phù hợp với Widget cũ. Vì vậy, rebuild không mặc nhiên đồng nghĩa với việc tạo lại toàn bộ trạng thái hoặc toàn bộ giao diện.

1.3. Phạm vi rebuild và ảnh hưởng của cây Widget

Phạm vi rebuild phụ thuộc vào vị trí xảy ra thay đổi trạng thái, cách tổ chức cây Widget và các cơ chế quản lý trạng thái được sử dụng.

Nếu setState() được gọi trong một Widget cấp cao, phương thức build() của Widget đó sẽ được gọi lại. Các Widget con được tạo mới bên trong phương thức build() có thể cần được đối chiếu và cập nhật. Điều này không có nghĩa tất cả Widget con đều bị dựng lại hoàn toàn, nhưng vẫn có thể phát sinh công việc xử lý không cần thiết.

Ví dụ chưa tối ưu:

class ProductPage extends StatefulWidget {
  const ProductPage({super.key});

  @override
  State<ProductPage> createState() => _ProductPageState();
}

class _ProductPageState extends State<ProductPage> {
  int quantity = 1;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('Chi tiết sản phẩm'),
      ),
      body: Column(
        children: [
          const FlutterLogo(size: 120),
          const Text('Áo thun nam'),
          Text('Số lượng: $quantity'),
          ElevatedButton(
            onPressed: () {
              setState(() {
                quantity++;
              });
            },
            child: const Text('Tăng số lượng'),
          ),
        ],
      ),
    );
  }
}

Trong ví dụ trên, mỗi lần tăng số lượng, phương thức build() của ProductPage được gọi lại. Các Widget con được khai báo trực tiếp bên trong build() cũng được tạo thành những mô tả Widget mới, ngoại trừ những phần được tái sử dụng thông qua cơ chế const hoặc các tối ưu khác.

Đối với giao diện nhỏ, cách viết này hoàn toàn hợp lý. Tuy nhiên, nếu ProductPage chứa nhiều thành phần phức tạp như danh sách sản phẩm, biểu đồ doanh thu, ảnh có xử lý tùy chỉnh và nhiều vùng tương tác, việc tổ chức lại cây Widget có thể giúp giảm chi phí xử lý.

1.4. Tách Widget thành các thành phần nhỏ

Một phương pháp phổ biến để tối ưu rebuild là tách giao diện lớn thành những Widget nhỏ, có trách nhiệm rõ ràng.

Thay vì để toàn bộ giao diện nằm trong một phương thức build(), lập trình viên có thể tách thành:

• ProductImage: hiển thị hình ảnh sản phẩm.

• ProductInformation: hiển thị tên và mô tả.

• QuantitySelector: quản lý bộ chọn số lượng.

• ProductPrice: hiển thị giá tiền.

• AddToCartButton: xử lý thao tác thêm vào giỏ hàng.

Mỗi thành phần có thể được kiểm soát trạng thái và cập nhật độc lập hơn. Nếu số lượng thay đổi, phần QuantitySelector có thể được thiết kế để tự cập nhật mà không phải đưa trạng thái số lượng lên một Widget cha quá lớn.

Ví dụ:

class QuantitySelector extends StatefulWidget {
  const QuantitySelector({super.key});

  @override
  State<QuantitySelector> createState() =>
      _QuantitySelectorState();
}

class _QuantitySelectorState extends State<QuantitySelector> {
  int quantity = 1;

  @override
  Widget build(BuildContext context) {
    return Row(
      mainAxisSize: MainAxisSize.min,
      children: [
        IconButton(
          onPressed: quantity > 1
              ? () {
                  setState(() {
                    quantity--;
                  });
                }
              : null,
          icon: const Icon(Icons.remove),
        ),
        Text(
          '$quantity',
          style: const TextStyle(fontSize: 18),
        ),
        IconButton(
          onPressed: () {
            setState(() {
              quantity++;
            });
          },
          icon: const Icon(Icons.add),
        ),
      ],
    );
  }
}

Khi quantity thay đổi, trạng thái được quản lý ngay bên trong QuantitySelector. Nhờ vậy, Widget cha không cần gọi setState() chỉ để cập nhật số lượng.

Tuy nhiên, việc tách Widget không tự động bảo đảm hiệu năng tốt hơn trong mọi trường hợp. Một Widget nhỏ vẫn có thể rebuild thường xuyên nếu trạng thái được đặt ở vị trí không phù hợp. Do đó, cần kết hợp việc chia nhỏ giao diện với cách tổ chức trạng thái hợp lý.

1.5. Sử dụng const Widget

Trong Dart, từ khóa const cho phép tạo đối tượng hằng tại thời điểm biên dịch khi các điều kiện tương ứng được đáp ứng. Flutter tận dụng đặc điểm này để tái sử dụng các Widget có cấu hình không thay đổi.

Ví dụ:

const Text(
  'Flutter Widget Fundamentals',
  style: TextStyle(
    fontSize: 20,
    fontWeight: FontWeight.bold,
  ),
)

Nếu Widget không phụ thuộc vào dữ liệu động, sử dụng const giúp hạn chế việc tạo các đối tượng Widget mới không cần thiết.

Một ví dụ khác:

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

  @override
  Widget build(BuildContext context) {
    return const Column(
      children: [
        FlutterLogo(size: 100),
        Text('Sản phẩm nổi bật'),
        Text('Danh mục thời trang'),
      ],
    );
  }
}

Trong trường hợp này, Column và các Widget con đủ điều kiện được khai báo là const.

Một số lưu ý quan trọng:

• Constructor phải hỗ trợ const nếu muốn tạo Widget bằng constructor hằng.

• Các giá trị truyền vào phải đáp ứng điều kiện của biểu thức hằng.

• Dữ liệu động như giá sản phẩm lấy từ API không thể tùy tiện chuyển thành const.

• const không ngăn Widget cha rebuild.

• const không thay thế việc đo đạc hiệu năng bằng công cụ profiling.

Ví dụ, nếu Widget cha rebuild nhưng tiếp tục sử dụng cùng một Widget const, Flutter có thể tận dụng tính ổn định của cấu hình Widget để giảm công việc cập nhật.

1.6. Truyền Widget con thông qua constructor

Một kỹ thuật khác là truyền Widget con vào thông qua constructor, thường bằng thuộc tính child.

Kỹ thuật này đặc biệt hữu ích khi một Widget cha cần quản lý trạng thái nhưng có một vùng giao diện không phụ thuộc vào trạng thái đó.

Ví dụ:

class CounterPanel extends StatefulWidget {
  final Widget child;

  const CounterPanel({
    super.key,
    required this.child,
  });

  @override
  State<CounterPanel> createState() => _CounterPanelState();
}

class _CounterPanelState extends State<CounterPanel> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        widget.child,
        Text('Số lần nhấn: $count'),
        ElevatedButton(
          onPressed: () {
            setState(() {
              count++;
            });
          },
          child: const Text('Tăng'),
        ),
      ],
    );
  }
}

Sử dụng:

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: CounterPanel(
          child: const FlutterLogo(size: 100),
        ),
      ),
    );
  }
}

Trong ví dụ này, FlutterLogo được tạo từ phía gọi CounterPanel và truyền vào thuộc tính child. Khi CounterPanel rebuild do số đếm thay đổi, Widget con không cần được tạo lại trong phương thức build() của CounterPanel.

Flutter vẫn thực hiện các bước cập nhật cần thiết đối với cây giao diện, nhưng cách tổ chức này có thể giảm việc tạo lại các mô tả Widget không liên quan đến trạng thái.

1.7. Các nguyên tắc tối ưu rebuild

Để kiểm soát rebuild hiệu quả, cần áp dụng những nguyên tắc sau:

1. Đặt trạng thái tại vị trí phù hợp, tránh đặt mọi trạng thái ở Widget gốc của màn hình nếu chỉ một vùng nhỏ sử dụng nó.

2. Tách các thành phần giao diện có trạng thái và trách nhiệm riêng biệt.

3. Sử dụng const cho các Widget có cấu hình tĩnh.

4. Truyền Widget con qua constructor khi phù hợp, đặc biệt đối với những vùng giao diện không phụ thuộc trạng thái của Widget cha.

5. Tránh thực hiện công việc tính toán nặng trực tiếp trong build().

6. Không thực hiện gọi API, ghi cơ sở dữ liệu hoặc thao tác có tác dụng phụ trong build().

7. Với ứng dụng sử dụng Provider, Riverpod hoặc BLoC, chỉ đăng ký lắng nghe những trạng thái mà Widget thực sự cần.

8. Sử dụng Flutter DevTools để xác định điểm nghẽn trước khi tối ưu.

9. Không tách Widget quá mức chỉ để tăng số lượng lớp mà không mang lại lợi ích về khả năng bảo trì hoặc hiệu năng.

10. Đo đạc trong chế độ profile trên thiết bị phù hợp thay vì chỉ đánh giá dựa trên cảm giác khi chạy debug.

1.8. Kết luận về Rebuild Optimization

Rebuild Optimization là kỹ thuật quan trọng giúp ứng dụng Flutter duy trì hiệu năng khi giao diện và trạng thái ngày càng phức tạp. Việc hiểu phạm vi rebuild, tách Widget hợp lý, sử dụng const và truyền Widget con thông qua constructor giúp giảm những công việc dư thừa. Tuy nhiên, hiệu năng thực tế còn phụ thuộc vào layout, rendering, xử lý dữ liệu và cách quản lý trạng thái. Vì vậy, tối ưu rebuild cần được kết hợp với profiling và kiểm thử thay vì chỉ dựa trên các quy tắc viết code.

2. ListView.builder và Lazy Building – Xây dựng danh sách theo nhu cầu

2.1. Khái niệm Lazy Building

Lazy Building là cơ chế xây dựng các phần tử giao diện theo nhu cầu sử dụng thay vì tạo toàn bộ phần tử ngay từ đầu.

Trong ứng dụng thực tế, danh sách sản phẩm, lịch sử giao dịch, bài viết, thông báo và danh bạ có thể chứa hàng trăm hoặc hàng nghìn phần tử. Nếu sử dụng cách tạo toàn bộ Widget cùng lúc, ứng dụng có thể phải xử lý nhiều đối tượng không xuất hiện trên màn hình.

ListView.builder là một phương thức phổ biến của Flutter để xây dựng danh sách theo nhu cầu. Nó sử dụng itemBuilder để tạo các phần tử khi hệ thống cần chúng trong quá trình hiển thị và quản lý vùng đệm cuộn.

Lazy Building không có nghĩa chỉ những phần tử đang nhìn thấy mới tồn tại tuyệt đối. Flutter có thể tạo trước một số phần tử nằm ngoài vùng nhìn thấy để hỗ trợ cuộn mượt hơn. Tuy nhiên, nó không yêu cầu phải tạo toàn bộ danh sách ngay từ đầu.

2.2. Cấu trúc cơ bản của ListView.builder

Cú pháp cơ bản:

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, index) {
    final product = products[index];

    return ListTile(
      title: Text(product.name),
      subtitle: Text(product.price),
    );
  },
)

Trong đó:

• itemCount: số lượng phần tử tối đa cần xây dựng.

• itemBuilder: hàm trả về Widget tương ứng với một chỉ số.

• context: BuildContext tại vị trí xây dựng phần tử.

• index: vị trí của phần tử trong danh sách.

• return: Widget đại diện cho phần tử tại vị trí đó.

Khi người dùng cuộn danh sách, Flutter có thể yêu cầu itemBuilder xây dựng thêm các phần tử mới. Các phần tử không còn cần thiết có thể được loại bỏ hoặc tái sử dụng theo cơ chế quản lý của hệ thống giao diện.

2.3. Cơ chế hoạt động của itemBuilder

itemBuilder là thành phần trung tâm của ListView.builder. Đây là một hàm được Flutter gọi khi cần xây dựng Widget cho một chỉ số nhất định.

Ví dụ:

ListView.builder(
  itemCount: 1000,
  itemBuilder: (context, index) {
    return ListTile(
      leading: CircleAvatar(
        child: Text('$index'),
      ),
      title: Text('Sản phẩm $index'),
    );
  },
)

Mặc dù danh sách có 1.000 phần tử, Flutter không cần tạo tất cả 1.000 Widget ngay khi danh sách được hiển thị. Các phần tử được xây dựng theo nhu cầu của viewport và vùng đệm.

Điều này giúp giảm chi phí khởi tạo giao diện ban đầu, đặc biệt với danh sách dài.

Một nguyên tắc quan trọng là itemBuilder nên thực hiện công việc nhẹ và có thể lặp lại. Không nên đặt các thao tác nặng như đọc file lớn, gọi API hoặc truy vấn cơ sở dữ liệu trực tiếp trong hàm này, vì hàm có thể được gọi nhiều lần.

Nếu cần tải dữ liệu, nên sử dụng cơ chế quản lý dữ liệu riêng, chẳng hạn như Repository, Future, Stream hoặc state management. itemBuilder chỉ nên tập trung chuyển đổi dữ liệu đã có thành Widget.

2.4. Vai trò của itemCount

itemCount xác định số phần tử mà danh sách dự kiến cung cấp.

Ví dụ:

ListView.builder(
  itemCount: 20,
  itemBuilder: (context, index) {
    return ListTile(
      title: Text('Phần tử $index'),
    );
  },
)

Danh sách có tối đa 20 phần tử, từ chỉ số 0 đến 19.

Khai báo itemCount chính xác giúp Flutter biết kích thước danh sách và ước lượng vùng cuộn tốt hơn.

Nếu dữ liệu đến từ một danh sách động, nên sử dụng:

itemCount: products.length,

Khi dữ liệu thay đổi, Widget cần được xây dựng lại theo trạng thái mới để cập nhật số lượng phần tử.

Nếu bỏ qua itemCount, danh sách có thể được xem là không xác định trước số lượng phần tử. Trong một số trường hợp, điều này phù hợp với danh sách tải liên tục hoặc dữ liệu vô hạn. Tuy nhiên, nếu số lượng đã biết, khai báo itemCount thường là lựa chọn phù hợp hơn.

2.5. itemExtent và tối ưu kích thước phần tử

itemExtent xác định chiều dài cố định của mỗi phần tử theo trục cuộn.

Ví dụ:

ListView.builder(
  itemCount: 1000,
  itemExtent: 72,
  itemBuilder: (context, index) {
    return ListTile(
      title: Text('Sản phẩm $index'),
    );
  },
)

Với danh sách cuộn dọc, mỗi phần tử có chiều cao 72 logical pixels. Với danh sách cuộn ngang, giá trị này tương ứng với chiều rộng.

Khi biết chính xác kích thước mỗi phần tử, Flutter có thể tính toán vị trí các phần tử hiệu quả hơn mà không cần đo đạc kích thước biến đổi của từng phần tử theo cách thông thường.

itemExtent phù hợp với:

• Danh sách cài đặt.

• Danh sách thông báo có chiều cao cố định.

• Danh sách lựa chọn.

• Danh sách các dòng dữ liệu có bố cục đồng nhất.

Không nên sử dụng itemExtent nếu nội dung có thể xuống nhiều dòng và làm thay đổi chiều cao thực tế của phần tử. Nếu kích thước thực tế không phù hợp với giá trị đã khai báo, giao diện có thể bị cắt hoặc hiển thị không đúng như mong đợi.

2.6. prototypeItem và kích thước mẫu

prototypeItem cho phép cung cấp một Widget mẫu để Flutter đo kích thước phần tử đại diện và sử dụng kích thước đó cho các phần tử trong danh sách.

Ví dụ:

ListView.builder(
  itemCount: 100,
  prototypeItem: const ListTile(
    title: Text('Một sản phẩm mẫu'),
  ),
  itemBuilder: (context, index) {
    return ListTile(
      title: Text('Sản phẩm $index'),
    );
  },
)

Kỹ thuật này hữu ích khi các phần tử có kích thước tương đương nhưng không muốn chỉ định trực tiếp một giá trị itemExtent.

Có thể phân biệt hai thuộc tính:

• itemExtent: chỉ định kích thước theo một giá trị số cụ thể.

• prototypeItem: dùng một Widget mẫu để xác định kích thước.

Không nên đồng thời khai báo itemExtent và prototypeItem cho cùng một ListView, vì chúng là những cách xác định kích thước phần tử thay thế nhau.

2.7. cacheExtent và vùng đệm cuộn

cacheExtent xác định phạm vi vùng đệm ngoài viewport theo trục cuộn. Flutter có thể xây dựng và bố trí các phần tử nằm ngoài vùng đang hiển thị để chuẩn bị cho quá trình cuộn tiếp theo.

Ví dụ:

ListView.builder(
  itemCount: 500,
  cacheExtent: 300,
  itemBuilder: (context, index) {
    return ListTile(
      title: Text('Mục $index'),
    );
  },
)

Giá trị 300 được tính theo logical pixels, không phải số lượng phần tử.

Tăng cacheExtent có thể giúp một số danh sách hiển thị mượt hơn khi cuộn vì các phần tử sắp xuất hiện đã được chuẩn bị. Tuy nhiên, điều này cũng có thể làm tăng số Widget được xây dựng và chi phí bộ nhớ.

Giảm vùng đệm có thể tiết kiệm tài nguyên nhưng cũng có khả năng khiến việc xây dựng phần tử diễn ra sát thời điểm người dùng cuộn đến.

Do đó, không có một giá trị cacheExtent tối ưu cho mọi ứng dụng. Cần thử nghiệm với dữ liệu thực tế, kích thước phần tử và thiết bị mục tiêu.

2.8. So sánh ListView và ListView.builder

Cần lưu ý rằng ListView thông thường vẫn có thể phù hợp với danh sách nhỏ, cố định và dễ đọc. Không nhất thiết phải thay thế mọi ListView bằng ListView.builder.

2.9. Tối ưu danh sách lớn trong ứng dụng thực tế

Đối với một ứng dụng thương mại điện tử có hàng nghìn sản phẩm, ngoài việc sử dụng ListView.builder, cần chú ý các yếu tố sau:

Tối ưu dữ liệu

Không tải toàn bộ dữ liệu lớn chỉ để hiển thị vài sản phẩm đầu tiên. Có thể sử dụng phân trang từ API, tải thêm dữ liệu khi người dùng gần cuối danh sách hoặc áp dụng cơ chế tải theo nhu cầu.

Tối ưu hình ảnh

Hình ảnh có kích thước quá lớn có thể tiêu tốn nhiều bộ nhớ. Nên sử dụng ảnh thu nhỏ phù hợp với kích thước hiển thị, cache ảnh khi phù hợp và hạn chế giải mã ảnh có độ phân giải không cần thiết.

Sử dụng Key hợp lý

Nếu danh sách có thêm, xóa hoặc sắp xếp lại phần tử, nên sử dụng Key ổn định dựa trên định danh của dữ liệu để Flutter đối chiếu đúng phần tử khi cập nhật cây Widget.

Ví dụ:

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, index) {
    final product = products[index];

    return ProductCard(
      key: ValueKey(product.id),
      product: product,
    );
  },
)

Tránh xử lý nặng trong itemBuilder

Không tính toán dữ liệu phức tạp lặp lại mỗi lần Widget được yêu cầu xây dựng. Những dữ liệu có thể tính trước nên được chuẩn bị ở lớp phù hợp.

Quản lý trạng thái phần tử

Đối với danh sách có checkbox, nút yêu thích hoặc bộ đếm riêng, cần tổ chức trạng thái hợp lý để thay đổi một phần tử không làm phát sinh quá nhiều công việc trên toàn bộ danh sách.

Theo dõi hiệu năng

Sử dụng Flutter DevTools để kiểm tra frame time, CPU, bộ nhớ và những phần tử gây ra độ trễ khi cuộn.

2.10. Kết luận về ListView.builder và Lazy Building

ListView.builder là giải pháp quan trọng khi xây dựng các danh sách có số lượng phần tử lớn hoặc thay đổi theo dữ liệu. Cơ chế Lazy Building giúp hạn chế việc tạo Widget không cần thiết ngay từ đầu. Các thuộc tính itemCount, itemExtent, prototypeItem và cacheExtent cho phép kiểm soát số lượng, kích thước và vùng đệm của danh sách. Để đạt hiệu năng tốt, cần kết hợp tối ưu Widget với quản lý dữ liệu, hình ảnh, Key và cơ chế phân trang.

3. RepaintBoundary và Layer – Tối ưu quá trình vẽ giao diện

3.1. Khái niệm repaint và sự khác biệt với rebuild

Trong Flutter, rebuild và repaint là hai quá trình khác nhau.

Rebuild là quá trình xây dựng lại mô tả Widget thông qua phương thức build().

Repaint là quá trình vẽ lại nội dung hình ảnh của một phần giao diện khi hệ thống rendering xác định nội dung đó cần được cập nhật.

Một Widget có thể rebuild mà không nhất thiết phải dẫn đến việc vẽ lại toàn bộ nội dung của nó. Ngược lại, một vùng giao diện có thể cần repaint do thay đổi nội dung vẽ, ngay cả khi không phải mọi Widget trong vùng đó đều rebuild.

Ví dụ, một màn hình có biểu đồ doanh thu và tiêu đề tĩnh. Khi dữ liệu biểu đồ thay đổi, phần biểu đồ có thể cần vẽ lại. Tuy nhiên, tiêu đề không nhất thiết phải vẽ lại nội dung nếu nó không bị ảnh hưởng.

Việc phân biệt rebuild và repaint rất quan trọng khi tối ưu Flutter. Nếu vấn đề nằm ở quá trình tạo Widget, cần xem xét phạm vi rebuild. Nếu vấn đề nằm ở việc vẽ quá nhiều nội dung, cần xem xét rendering, layer và RepaintBoundary.

3.2. Khái niệm RepaintBoundary

RepaintBoundary là một Widget tạo ranh giới repaint trong hệ thống vẽ của Flutter.

Nó giúp cô lập một vùng giao diện để việc vẽ lại trong vùng đó có thể được quản lý độc lập hơn so với những vùng xung quanh.

Ví dụ:

RepaintBoundary(
  child: CustomPaint(
    size: const Size(300, 200),
    painter: RevenueChartPainter(),
  ),
)

Trong ví dụ trên, vùng biểu đồ được đặt trong một RepaintBoundary. Nếu biểu đồ cần repaint thường xuyên, ranh giới này có thể giúp hạn chế việc vẽ lại lan sang các vùng giao diện không liên quan, tùy thuộc vào cách tổ chức layer và thay đổi thực tế.

Tuy nhiên, RepaintBoundary không phải một công cụ tăng tốc tuyệt đối. Việc tạo thêm ranh giới có thể làm tăng số lượng layer và chi phí quản lý bộ nhớ. Vì vậy, cần sử dụng khi có lý do hợp lý và xác minh hiệu quả bằng profiling.

3.3. Cơ chế hoạt động của RepaintBoundary

Flutter sử dụng hệ thống rendering để tổ chức và vẽ nội dung giao diện. Trong quá trình đó, RepaintBoundary có thể tạo ra một ranh giới độc lập trong cây render và dẫn đến việc hình thành layer phù hợp.

Khi một vùng nằm trong ranh giới cần vẽ lại, hệ thống có thể xử lý vùng đó độc lập hơn với những nội dung nằm bên ngoài.

Ví dụ, trong một ứng dụng có bản đồ hoặc biểu đồ động và phần tiêu đề cố định, nếu toàn bộ giao diện được tổ chức không hợp lý, các thay đổi trong vùng động có thể khiến nhiều nội dung khác phải tham gia vào quá trình vẽ.

Khi đặt vùng động trong RepaintBoundary, Flutter có thêm cơ hội giới hạn phạm vi repaint.

Cần hiểu rằng ranh giới repaint không ngăn hoàn toàn mọi hoạt động rendering bên ngoài. Các thay đổi về layout, kích thước, vị trí hoặc cấu trúc cây vẫn có thể gây ra những công việc khác. RepaintBoundary chủ yếu giải quyết vấn đề cô lập quá trình vẽ, không phải công cụ thay thế cho tối ưu layout hoặc rebuild.

3.4. Layer trong hệ thống rendering

Layer là thành phần được sử dụng để tổ chức nội dung hình ảnh trong hệ thống rendering của Flutter.

Có thể hình dung layer như những vùng nội dung được quản lý trong một cấu trúc phân cấp nhằm hỗ trợ tổng hợp hình ảnh, biến đổi, clipping, opacity và những thao tác rendering khác.

Trong quá trình vẽ giao diện, Flutter có thể tạo và sử dụng nhiều loại layer tùy theo cấu trúc Widget cũng như hiệu ứng được áp dụng.

Một số Widget hoặc cơ chế thường liên quan đến layer gồm:

• RepaintBoundary: tạo ranh giới repaint.

• Opacity: điều chỉnh độ trong suốt.

• ClipRect, ClipRRect: cắt nội dung theo vùng hình học.

• Transform: biến đổi vị trí, kích thước hoặc góc xoay.

• Các Widget sử dụng hiệu ứng hình ảnh hoặc animation.

Không phải mọi Widget đều tạo một layer riêng. Một số Widget chỉ tham gia vào cây Widget và RenderObject mà không tạo thêm layer độc lập. Việc tạo layer phụ thuộc vào loại Widget, cấu trúc rendering và các điều kiện thực tế.

3.5. Ví dụ sử dụng RepaintBoundary

Giả sử ứng dụng có một đồng hồ hoặc hiệu ứng đồ họa được cập nhật liên tục. Vùng đồ họa này có thể cần repaint thường xuyên, trong khi phần mô tả bên ngoài ít thay đổi.

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

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        const Text(
          'Tổng quan doanh thu',
          style: TextStyle(
            fontSize: 22,
            fontWeight: FontWeight.bold,
          ),
        ),
        RepaintBoundary(
          child: CustomPaint(
            size: const Size(double.infinity, 200),
            painter: RevenueChartPainter(),
          ),
        ),
        const Text('Dữ liệu doanh thu theo thời gian'),
      ],
    );
  }
}

class RevenueChartPainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint()
      ..color = Colors.blue
      ..strokeWidth = 3
      ..style = PaintingStyle.stroke;

    final path = Path()
      ..moveTo(0, size.height * 0.8)
      ..lineTo(size.width * 0.3, size.height * 0.5)
      ..lineTo(size.width * 0.6, size.height * 0.65)
      ..lineTo(size.width, size.height * 0.2);

    canvas.drawPath(path, paint);
  }

  @override
  bool shouldRepaint(covariant RevenueChartPainter oldDelegate) {
    return false;
  }
}

Ví dụ này minh họa cách cô lập vùng vẽ biểu đồ. Tuy nhiên, shouldRepaint() trả về false vì biểu đồ mẫu không có dữ liệu thay đổi giữa hai delegate. Trong một biểu đồ động, cần lưu dữ liệu trong painter và triển khai shouldRepaint() phù hợp để xác định khi nào nội dung thực sự thay đổi.

Nếu dữ liệu biểu đồ thay đổi nhưng shouldRepaint() luôn trả về false, biểu đồ có thể không hiển thị dữ liệu mới như mong muốn. Ngược lại, trả về true trong mọi trường hợp có thể khiến biểu đồ repaint thường xuyên hơn cần thiết.

3.6. Những trường hợp nên sử dụng RepaintBoundary

RepaintBoundary có thể hữu ích khi:

• Một vùng giao diện vẽ lại thường xuyên nhưng những vùng xung quanh ít thay đổi.

• Một Widget sử dụng CustomPainter có nội dung vẽ tương đối độc lập.

• Có animation hoặc đồ họa động cần được cô lập khỏi các vùng tĩnh.

• Flutter DevTools cho thấy việc repaint lan rộng là một phần của vấn đề hiệu năng.

• Cần tách một vùng hình ảnh để phục vụ những thao tác rendering phù hợp.

Ngược lại, không nên đặt RepaintBoundary quanh mọi Widget theo thói quen. Những vùng giao diện đơn giản như một dòng văn bản tĩnh thường không cần ranh giới riêng nếu không có bằng chứng cho thấy điều đó cải thiện hiệu năng.

3.7. RepaintBoundary không thay thế tối ưu rebuild

Một lỗi thường gặp là cho rằng thêm RepaintBoundary sẽ ngăn Widget rebuild. Điều này không chính xác.

Nếu một Widget gọi setState(), quá trình rebuild vẫn có thể diễn ra. RepaintBoundary chủ yếu giúp tổ chức lại phạm vi vẽ, không ngăn việc tạo Widget mới hay cập nhật cấu hình Widget.

Có thể phân biệt như sau:

3.8. Kết luận về RepaintBoundary và Layer

RepaintBoundary và layer là những thành phần quan trọng trong quá trình tối ưu rendering của Flutter. Chúng giúp tổ chức vùng vẽ và hạn chế công việc repaint không cần thiết trong những trường hợp phù hợp. Tuy nhiên, hiệu quả phụ thuộc vào cấu trúc giao diện, đặc điểm thay đổi nội dung và chi phí quản lý layer. Lập trình viên cần phân biệt rõ rebuild, layout và repaint để chọn đúng giải pháp tối ưu.

4. Debugging Layout và Rendering – Chẩn đoán lỗi bố cục và hiển thị

4.1. Khái niệm debugging layout và rendering

Debugging Layout và Rendering là quá trình kiểm tra, xác định và xử lý các vấn đề xảy ra trong giai đoạn bố trí cũng như vẽ giao diện Flutter.

Một giao diện có thể biên dịch thành công nhưng vẫn hiển thị sai kích thước, tràn nội dung, mất phần tử, chồng lấn hoặc giật khi cuộn. Những vấn đề này thường không thể được giải quyết chỉ bằng cách kiểm tra cú pháp Dart.

Flutter cung cấp nhiều công cụ hỗ trợ chẩn đoán, gồm:

• Flutter Inspector.

• Layout Explorer.

• Performance View.

• Flutter DevTools.

• Các chế độ hiển thị debug.

• Log và thông báo lỗi trong IDE hoặc terminal.

Mục tiêu của debugging là xác định nguyên nhân thực tế thay vì sửa giao diện bằng các giá trị kích thước tùy ý.

4.2. Hệ thống Constraints trong Flutter

Flutter sử dụng cơ chế layout dựa trên constraints. Parent Widget truyền các giới hạn kích thước xuống Child Widget; Child Widget chọn kích thước phù hợp; sau đó parent định vị child trong vùng bố cục.

Có thể tóm tắt quy tắc layout như sau:

1. Constraints đi từ parent xuống child.

2. Kích thước được xác định từ child trở về parent.

3. Parent định vị child trong hệ tọa độ của parent.

Constraints thường bao gồm:

• minWidth: chiều rộng tối thiểu.

• maxWidth: chiều rộng tối đa.

• minHeight: chiều cao tối thiểu.

• maxHeight: chiều cao tối đa.

Nhiều lỗi layout xảy ra khi Widget không nhận được giới hạn kích thước phù hợp với cách nó muốn bố trí nội dung.

Ví dụ, một Column nằm trong vùng không giới hạn chiều cao nhưng chứa một Expanded có thể gây lỗi vì Expanded cần phần không gian còn lại được xác định. Tương tự, một Row chứa nhiều phần tử rộng có thể gây overflow nếu tổng chiều rộng vượt quá không gian cho phép.

4.3. Xử lý lỗi RenderFlex overflow

Một lỗi phổ biến là thông báo A RenderFlex overflowed by ... pixels.

Ví dụ:

Row(
  children: [
    const Icon(Icons.shopping_bag),
    const SizedBox(width: 12),
    Text(
      'Tên sản phẩm rất dài và có thể vượt quá chiều rộng màn hình',
    ),
    const Icon(Icons.arrow_forward),
  ],
)

Nếu tổng chiều rộng của các phần tử vượt quá chiều rộng khả dụng, Row có thể xảy ra overflow.

Một cách khắc phục là sử dụng Expanded hoặc Flexible cho phần nội dung cần co giãn:

Row(
  children: [
    const Icon(Icons.shopping_bag),
    const SizedBox(width: 12),
    const Expanded(
      child: Text(
        'Tên sản phẩm rất dài và có thể vượt quá chiều rộng màn hình',
        maxLines: 2,
        overflow: TextOverflow.ellipsis,
      ),
    ),
    const Icon(Icons.arrow_forward),
  ],
)

Trong ví dụ này, Expanded giúp phần văn bản sử dụng phần chiều rộng còn lại. maxLines và TextOverflow.ellipsis kiểm soát việc hiển thị văn bản khi nội dung quá dài.

Tuy nhiên, không nên thêm Expanded một cách máy móc. Cần kiểm tra constraints của parent, bởi vì Expanded không phù hợp trong mọi môi trường layout.

4.4. Flutter Inspector

Flutter Inspector là công cụ cho phép quan sát cấu trúc Widget đang chạy trong ứng dụng.

Các chức năng thường dùng gồm:

• Xem cây Widget.

• Chọn một Widget trên giao diện.

• Quan sát thuộc tính của Widget.

• Kiểm tra kích thước và vị trí.

• Bật chế độ hiển thị ranh giới layout.

• Xác định Widget gây ra vấn đề về bố cục.

Ví dụ, khi một nút không xuất hiện đúng vị trí, có thể sử dụng Inspector để chọn nút đó, lần ngược lên các Widget cha và kiểm tra xem nó đang nằm trong Column, Row, Stack hay một vùng có giới hạn kích thước cụ thể.

Việc kiểm tra theo cây Widget thường hiệu quả hơn việc liên tục thay đổi padding, margin hoặc height mà chưa xác định nguyên nhân.

4.5. Layout Explorer

Layout Explorer là một phần công cụ hỗ trợ phân tích bố cục trong Flutter DevTools, đặc biệt hữu ích khi làm việc với các Widget như Row, Column và Flex.

Công cụ này giúp quan sát các yếu tố như:

• Hướng bố cục.

• Cách phân phối không gian.

• Main axis và cross axis.

• Cách sử dụng MainAxisAlignment.

• Cách sử dụng CrossAxisAlignment.

• Tỷ lệ không gian của các child có Flexible hoặc Expanded.

Ví dụ, nếu một Row không phân chia khoảng cách như mong muốn, Layout Explorer giúp kiểm tra cách bố trí phần tử và phân phối không gian trước khi chỉnh sửa code.

Layout Explorer đặc biệt có giá trị với những giao diện responsive, biểu mẫu nhiều trường và màn hình có bố cục lồng nhau phức tạp.

4.6. debugPaintSizeEnabled

debugPaintSizeEnabled là một cờ debug được sử dụng để hiển thị trực quan các ranh giới kích thước của Widget trong quá trình phát triển.

Ví dụ:

import 'package:flutter/material.dart';

void main() {
  debugPaintSizeEnabled = true;

  runApp(const MyApp());
}

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

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: Scaffold(
        body: Center(
          child: Padding(
            padding: EdgeInsets.all(24),
            child: Text('Kiểm tra bố cục'),
          ),
        ),
      ),
    );
  }
}

Khi bật chế độ này trong môi trường debug, Flutter hiển thị các đường viền và thông tin trực quan hỗ trợ kiểm tra kích thước Widget.

Công cụ này hữu ích khi:

• Xác định vùng chiếm chỗ của Widget.

• Kiểm tra padding.

• Phát hiện phần tử có kích thước không như mong đợi.

• Quan sát cấu trúc bố cục lồng nhau.

Đây là cờ debug và không nên bật trong bản phát hành production. Ngoài ra, cách sử dụng có thể phụ thuộc phiên bản Flutter và cấu hình dự án.

4.7. Performance View và Flutter DevTools

Flutter DevTools cung cấp những công cụ phân tích hiệu năng trong quá trình chạy ứng dụng.

Performance View hỗ trợ quan sát thời gian xử lý frame và các hoạt động liên quan đến CPU, GPU cũng như rendering.

Trong nhiều ứng dụng Flutter, mục tiêu thường gặp là giữ thời gian xử lý mỗi frame trong giới hạn phù hợp với tần số làm mới màn hình. Ví dụ, màn hình 60 Hz có khoảng 16,67 ms cho mỗi frame; màn hình 120 Hz có khoảng 8,33 ms.

Nếu quá trình xử lý vượt quá ngân sách thời gian cần thiết, người dùng có thể thấy hiện tượng giật, chậm hoặc animation không mượt.

Các bước phân tích cơ bản:

1. Chạy ứng dụng trong profile mode.

2. Mở Flutter DevTools.

3. Truy cập Performance View.

4. Thực hiện thao tác gây ra hiện tượng giật.

5. Quan sát những frame có thời gian xử lý cao.

6. Kiểm tra các tác vụ CPU, layout, paint hoặc công việc đồng bộ liên quan.

7. Thay đổi code và đo lại để xác định hiệu quả.

Không nên kết luận một Widget là nguyên nhân gây chậm chỉ dựa vào việc nó xuất hiện trong cây giao diện. Cần xác định chính xác giai đoạn xử lý gây ra vấn đề.

4.8. Debugging trong debug mode và profile mode

Debug mode ưu tiên hỗ trợ phát triển, cung cấp nhiều kiểm tra và thông tin chẩn đoán. Vì vậy, hiệu năng ở chế độ debug không đại diện chính xác cho hiệu năng phát hành.

Profile mode được thiết kế để đo đạc hiệu năng gần với môi trường thực tế hơn, đồng thời vẫn cung cấp công cụ phân tích cần thiết.

Có thể sử dụng:

• Debug mode: kiểm tra logic, lỗi giao diện và hành vi của Widget.

• Profile mode: phân tích hiệu năng, frame time, CPU và các điểm nghẽn.

• Release mode: đánh giá trải nghiệm ứng dụng đã tối ưu trong điều kiện phát hành.

Khi phát hiện ứng dụng bị giật trong debug mode, nên tái hiện và đo lại bằng profile mode trước khi đưa ra kết luận về hiệu năng production.

4.9. Quy trình chẩn đoán lỗi giao diện

Một quy trình phù hợp gồm các bước:

1. Tái hiện lỗi trên một màn hình hoặc thao tác cụ thể.

2. Đọc thông báo lỗi và stack trace.

3. Sử dụng Inspector để kiểm tra cây Widget.

4. Kiểm tra constraints, kích thước và cách phân phối không gian.

5. Sử dụng chế độ vẽ ranh giới để xác định vùng bố cục.

6. Nếu vấn đề là độ mượt, sử dụng Performance View.

7. Xác định nguyên nhân chính trước khi sửa.

8. Thực hiện một thay đổi có mục tiêu.

9. Kiểm tra lại trên các kích thước màn hình và thiết bị khác nhau.

10. Viết kiểm thử để hạn chế lỗi tái xuất hiện nếu phù hợp.

4.10. Kết luận về Debugging Layout và Rendering

Debugging Layout và Rendering là kỹ năng thiết yếu khi phát triển ứng dụng Flutter. Việc nắm vững constraints, sử dụng Flutter Inspector, Layout Explorer và Performance View giúp xác định chính xác nguyên nhân gây lỗi bố cục hoặc suy giảm hiệu năng. Một quy trình chẩn đoán dựa trên bằng chứng sẽ giúp giảm thời gian sửa lỗi, tránh các giải pháp tạm thời và cải thiện chất lượng giao diện trên nhiều thiết bị.

5. Widget Testing – Kiểm thử giao diện và hành vi Widget

5.1. Khái niệm Widget Testing

Widget Testing là phương pháp kiểm thử các thành phần giao diện Flutter trong một môi trường kiểm thử có khả năng xây dựng Widget, mô phỏng tương tác và xác minh kết quả.

Khác với kiểm thử đơn vị chỉ tập trung vào một hàm hoặc lớp riêng lẻ, Widget Testing cho phép kiểm tra sự kết hợp giữa Widget, trạng thái, hành vi người dùng và nội dung được hiển thị.

Ví dụ, một màn hình đăng nhập có thể cần kiểm tra:

• Tiêu đề đăng nhập xuất hiện đúng.

• Hai trường nhập liệu được hiển thị.

• Nút đăng nhập có thể được tìm thấy.

• Nhấn nút sẽ kích hoạt hành vi dự kiến.

• Thông báo lỗi xuất hiện khi dữ liệu không hợp lệ.

• Giao diện cập nhật đúng khi trạng thái thay đổi.

Widget Testing thường chạy nhanh hơn kiểm thử toàn bộ ứng dụng trên thiết bị thật và phù hợp để tự động hóa việc kiểm tra các thành phần giao diện.

5.2. Tệp kiểm thử và cấu trúc cơ bản

Trong dự án Flutter, các tệp kiểm thử thường được đặt trong thư mục test/.

Ví dụ:

my_app/
├── lib/
│   └── main.dart
├── test/
│   └── counter_test.dart
├── pubspec.yaml
└── analysis_options.yaml

Flutter cung cấp các API kiểm thử thông qua thư viện flutter_test.

Một bài kiểm thử Widget cơ bản:

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

void main() {
  testWidgets('Hiển thị tiêu đề', (WidgetTester tester) async {
    await tester.pumpWidget(
      const MaterialApp(
        home: Scaffold(
          body: Text('Xin chào Flutter'),
        ),
      ),
    );

    expect(
      find.text('Xin chào Flutter'),
      findsOneWidget,
    );
  });
}

Trong ví dụ trên:

• testWidgets() tạo một bài kiểm thử Widget.

• WidgetTester cung cấp các thao tác kiểm thử giao diện.

• pumpWidget() xây dựng Widget cần kiểm tra.

• find.text() tìm văn bản trên giao diện.

• expect() xác minh kết quả mong đợi.

• findsOneWidget xác nhận có đúng một Widget phù hợp.

5.3. testWidgets và WidgetTester

testWidgets() là hàm dùng để định nghĩa bài kiểm thử Widget. Hàm này cung cấp một đối tượng WidgetTester để thao tác với môi trường kiểm thử.

Cấu trúc thường gặp:

testWidgets('Mô tả bài kiểm thử', (
  WidgetTester tester,
) async {
  // Xây dựng Widget.

  // Thực hiện tương tác.

  // Kiểm tra kết quả.
});

WidgetTester hỗ trợ nhiều thao tác quan trọng:

• Xây dựng giao diện.

• Nhấn nút hoặc chạm vào vị trí cụ thể.

• Nhập văn bản.

• Cuộn danh sách.

• Đợi giao diện cập nhật.

• Tìm Widget trong cây giao diện.

• Kiểm tra trạng thái và nội dung hiển thị.

Ví dụ:

await tester.pumpWidget(
  const MaterialApp(
    home: Scaffold(
      body: Text('Trang chủ'),
    ),
  ),
);

expect(find.text('Trang chủ'), findsOneWidget);

Mỗi bài kiểm thử nên có tên rõ ràng, thể hiện hành vi đang được xác minh. Điều này giúp dễ xác định nguyên nhân khi một kiểm thử thất bại.

5.4. pumpWidget()

pumpWidget() dùng để đưa một Widget vào môi trường kiểm thử và khởi tạo hoặc cập nhật cây giao diện tương ứng.

Ví dụ:

await tester.pumpWidget(
  const MaterialApp(
    home: Scaffold(
      body: Center(
        child: Text('Sản phẩm'),
      ),
    ),
  ),
);

Sau thao tác này, bài kiểm thử có thể tìm kiếm và kiểm tra Widget đã được xây dựng.

pumpWidget() phù hợp khi cần khởi tạo giao diện hoặc cung cấp một cây Widget mới để kiểm tra.

Cần lưu ý rằng việc sử dụng pumpWidget() không có nghĩa mọi hoạt động bất đồng bộ trong ứng dụng đều đã hoàn tất. Nếu Widget phụ thuộc vào Future, animation hoặc một cơ chế cập nhật trạng thái, bài kiểm thử có thể cần thêm các lần pump() hoặc sử dụng cách chờ phù hợp.

5.5. pump() và pumpAndSettle()

Hai phương thức này thường được sử dụng để điều khiển việc cập nhật giao diện trong kiểm thử.

pump()

pump() yêu cầu môi trường kiểm thử xử lý một frame. Nó hữu ích khi muốn kiểm tra giao diện sau một thao tác cụ thể hoặc sau một khoảng thời gian được chỉ định.

Ví dụ:

await tester.tap(find.text('Tăng'));
await tester.pump();

expect(find.text('Số lượng: 2'), findsOneWidget);

Trong trường hợp nút gọi setState(), pump() cho phép Flutter xử lý frame cập nhật để bài kiểm thử xác minh nội dung mới.

pumpAndSettle()

pumpAndSettle() tiếp tục xử lý frame cho đến khi không còn frame nào được lên lịch cần xử lý, hoặc cho đến khi đạt giới hạn timeout.

Ví dụ:

await tester.tap(find.text('Mở hộp thoại'));
await tester.pumpAndSettle();

expect(find.text('Xác nhận'), findsOneWidget);

Phương thức này thường hữu ích với animation ngắn, chuyển trạng thái giao diện hoặc hộp thoại.

Tuy nhiên, không nên sử dụng pumpAndSettle() một cách máy móc. Những Widget có animation lặp vô hạn hoặc liên tục lên lịch frame có thể khiến phương thức không bao giờ đạt trạng thái ổn định và gây timeout. Trong trường hợp đó, nên sử dụng pump() với thời gian cụ thể và kiểm tra trạng thái cần thiết.

5.6. find và các phương thức tìm Widget

find là API giúp tìm Widget trong cây giao diện của môi trường kiểm thử.

Các phương thức thường gặp:

Ví dụ:

expect(find.text('Đăng nhập'), findsOneWidget);

expect(find.byType(ElevatedButton), findsOneWidget);

expect(find.byIcon(Icons.add), findsOneWidget);

Một số matcher phổ biến:

• findsOneWidget: có đúng một Widget phù hợp.

• findsNothing: không có Widget phù hợp.

• findsWidgets: có ít nhất một Widget phù hợp.

• findsNWidgets(n): có đúng n Widget phù hợp.

Khi giao diện có nhiều Widget sử dụng cùng một nội dung, nên sử dụng Key hoặc phạm vi tìm kiếm phù hợp để tránh kiểm tra nhầm phần tử.

5.7. expect và xác minh kết quả

expect() dùng để so sánh kết quả thực tế với kết quả mong đợi.

Ví dụ:

expect(
  find.text('Đăng nhập thành công'),
  findsOneWidget,
);

Trong kiểm thử Widget, expect() có thể xác minh:

• Widget có xuất hiện hay không.

• Văn bản có đúng hay không.

• Số lượng phần tử được hiển thị.

• Trạng thái nút có được cập nhật hay không.

• Một thông báo lỗi có xuất hiện sau tương tác hay không.

• Một Widget đã biến mất sau thao tác hay chưa.

Ví dụ, kiểm tra rằng thông báo lỗi không xuất hiện khi mới mở màn hình:

expect(
  find.text('Vui lòng nhập email'),
  findsNothing,
);

Sau khi người dùng nhấn nút với dữ liệu không hợp lệ, bài kiểm thử có thể xác minh thông báo xuất hiện đúng theo yêu cầu.

5.8. Kiểm thử thao tác nhấn nút và cập nhật trạng thái

Giả sử có một Widget đếm số lần nhấn nút.

import 'package:flutter/material.dart';

class CounterWidget extends StatefulWidget {
  const CounterWidget({super.key});

  @override
  State<CounterWidget> createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int count = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      mainAxisSize: MainAxisSize.min,
      children: [
        Text('Số lượng: $count'),
        ElevatedButton(
          onPressed: () {
            setState(() {
              count++;
            });
          },
          child: const Text('Tăng'),
        ),
      ],
    );
  }
}

Bài kiểm thử:

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

void main() {
  testWidgets(
    'Số lượng tăng sau khi nhấn nút',
    (WidgetTester tester) async {
      await tester.pumpWidget(
        const MaterialApp(
          home: Scaffold(
            body: CounterWidget(),
          ),
        ),
      );

      expect(
        find.text('Số lượng: 0'),
        findsOneWidget,
      );

      await tester.tap(find.text('Tăng'));
      await tester.pump();

      expect(
        find.text('Số lượng: 1'),
        findsOneWidget,
      );
    },
  );
}

Bài kiểm thử xác minh toàn bộ chuỗi hành vi: xây dựng Widget, kiểm tra trạng thái ban đầu, mô phỏng thao tác nhấn nút, xử lý frame và xác minh giao diện mới.

Đây là ví dụ tiêu biểu về kiểm thử giao diện có trạng thái.

5.9. Kiểm thử nhập liệu và validation

Đối với biểu mẫu, có thể sử dụng enterText() để mô phỏng người dùng nhập dữ liệu vào trường văn bản.

Ví dụ:

await tester.enterText(
  find.byKey(const Key('emailField')),
  '[email protected]',
);

expect(
  find.text('[email protected]'),
  findsOneWidget,
);

Trong ứng dụng thực tế, nên sử dụng Key ổn định cho các trường nhập liệu quan trọng để việc kiểm thử ít phụ thuộc vào cấu trúc giao diện.

Có thể kiểm tra nhiều tình huống:

• Trường nhập liệu ban đầu trống.

• Email không đúng định dạng.

• Mật khẩu không đáp ứng yêu cầu.

• Nhấn nút gửi biểu mẫu khi dữ liệu chưa hợp lệ.

• Hiển thị thông báo lỗi phù hợp.

• Giao diện chuyển sang trạng thái thành công khi dữ liệu hợp lệ.

Những kiểm thử này giúp giảm lỗi trong các luồng tương tác quan trọng như đăng nhập, đăng ký, thanh toán và cập nhật thông tin cá nhân.

5.10. Chạy kiểm thử và tổ chức bộ kiểm thử

Có thể chạy toàn bộ kiểm thử trong dự án Flutter bằng lệnh:

flutter test

Để chạy một tệp cụ thể:

flutter test test/counter_test.dart

Nên tổ chức kiểm thử theo thành phần hoặc chức năng, chẳng hạn:

test/
├── widgets/
│   ├── product_card_test.dart
│   └── counter_test.dart
├── screens/
│   ├── login_screen_test.dart
│   └── product_screen_test.dart
└── helpers/
    └── test_helpers.dart

Cấu trúc thực tế có thể khác tùy quy mô dự án. Điều quan trọng là mỗi bài kiểm thử có phạm vi rõ ràng và dễ bảo trì.

Nếu Widget phụ thuộc vào API, cơ sở dữ liệu hoặc hệ thống xác thực, nên thay thế những phụ thuộc bên ngoài bằng dữ liệu giả hoặc mock phù hợp. Điều này giúp kiểm thử nhanh, ổn định và không phụ thuộc vào kết nối mạng thực tế.

5.11. Nguyên tắc viết Widget Testing hiệu quả

Một bộ kiểm thử Widget có chất lượng cần tuân thủ các nguyên tắc sau:

1. Kiểm thử hành vi mà người dùng thực sự trải nghiệm.

2. Kiểm tra cả trạng thái ban đầu và trạng thái sau tương tác.

3. Đặt tên bài kiểm thử rõ ràng.

4. Tránh phụ thuộc vào thời gian thực hoặc mạng bên ngoài nếu không cần thiết.

5. Sử dụng Key ổn định cho những phần tử quan trọng.

6. Chọn pump() hoặc pumpAndSettle() theo đúng đặc điểm của giao diện.

7. Kiểm tra cả trường hợp hợp lệ và không hợp lệ.

8. Tách logic nghiệp vụ phức tạp khỏi Widget để dễ kiểm thử.

9. Tránh kiểm thử quá nhiều chi tiết triển khai nội bộ khiến bài kiểm thử dễ hỏng khi refactor.

10. Chạy lại bộ kiểm thử sau khi sửa giao diện hoặc thay đổi trạng thái.

5.12. Kết luận về Widget Testing

Widget Testing giúp xác minh rằng giao diện Flutter hoạt động đúng theo yêu cầu, từ việc hiển thị nội dung đến xử lý tương tác và cập nhật trạng thái. Những API như testWidgets, WidgetTester, pumpWidget(), pump(), pumpAndSettle(), find và expect tạo nền tảng cho việc xây dựng bộ kiểm thử tự động. Khi được tổ chức tốt, Widget Testing giúp phát hiện lỗi sớm, giảm nguy cơ hồi quy và tăng độ tin cậy của ứng dụng.

6. Golden Testing – Kiểm thử giao diện bằng ảnh chuẩn

6.1. Khái niệm Golden Testing

Golden Testing là phương pháp kiểm thử giao diện bằng cách so sánh hình ảnh thực tế được tạo ra từ ứng dụng với một hình ảnh chuẩn đã được xác nhận trước đó.

Hình ảnh chuẩn thường được gọi là golden image. Nó thể hiện trạng thái giao diện được xem là đúng trong một môi trường kiểm thử cụ thể.

Khi chạy kiểm thử, Flutter tạo ảnh từ Widget hiện tại và so sánh với ảnh chuẩn. Nếu có sự khác biệt vượt quá mức cho phép, bài kiểm thử có thể thất bại.

Golden Testing đặc biệt hữu ích khi cần kiểm tra:

• Bố cục của màn hình.

• Màu sắc và kiểu chữ.

• Khoảng cách giữa các Widget.

• Kích thước nút và trường nhập liệu.

• Hình dạng đường viền.

• Trạng thái giao diện ở những kích thước màn hình cụ thể.

• Sự thay đổi giao diện ngoài ý muốn sau khi sửa code.

6.2. Cơ chế hoạt động của Golden Testing

Quy trình Golden Testing thường bao gồm bốn bước chính:

Golden Testing thường được triển khai thông qua matchesGoldenFile() trong thư viện flutter_test.

6.3. Ví dụ Golden Testing cơ bản

Giả sử có Widget sau:

import 'package:flutter/material.dart';

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

  @override
  Widget build(BuildContext context) {
    return const Card(
      child: Padding(
        padding: EdgeInsets.all(24),
        child: Text(
          'Chào mừng bạn',
          style: TextStyle(fontSize: 24),
        ),
      ),
    );
  }
}

Có thể viết bài kiểm thử như sau:

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

void main() {
  testWidgets(
    'WelcomeCard hiển thị đúng thiết kế',
    (WidgetTester tester) async {
      await tester.binding.setSurfaceSize(
        const Size(400, 300),
      );

      await tester.pumpWidget(
        const MaterialApp(
          home: Scaffold(
            body: Center(
              child: WelcomeCard(),
            ),
          ),
        ),
      );

      await expectLater(
        find.byType(WelcomeCard),
        matchesGoldenFile('goldens/welcome_card.png'),
      );

      addTearDown(() async {
        await tester.binding.setSurfaceSize(null);
      });
    },
  );
}

Trong ví dụ này:

• setSurfaceSize() đặt kích thước bề mặt kiểm thử để kết quả có thể tái lập.

• pumpWidget() dựng giao diện.

• find.byType() xác định Widget cần chụp.

• matchesGoldenFile() so sánh ảnh thực tế với ảnh chuẩn.

• addTearDown() khôi phục kích thước sau kiểm thử.

Đường dẫn ảnh chuẩn phải được tạo và quản lý đúng theo cấu hình dự án. Golden Testing không tự động biết rằng mọi ảnh khác biệt đều là lỗi; lập trình viên phải xác minh ảnh chuẩn và cập nhật khi có thay đổi thiết kế được chấp thuận.

6.4. Tạo và cập nhật ảnh chuẩn

Trong Flutter, có thể sử dụng chế độ cập nhật golden file khi chạy kiểm thử để tạo ảnh chuẩn hoặc cập nhật ảnh đã có.

Ví dụ:

flutter test --update-goldens

Lệnh này yêu cầu Flutter cập nhật những golden file liên quan đến các bài kiểm thử được chạy.

Cần sử dụng cẩn thận vì lệnh có thể thay thế ảnh chuẩn hiện có bằng kết quả mới. Nếu giao diện đang có lỗi, việc cập nhật ảnh chuẩn có thể vô tình khiến lỗi trở thành kết quả được chấp nhận.

Quy trình phù hợp:

1. Viết bài kiểm thử và xác định giao diện cần chụp.

2. Tạo golden file ban đầu.

3. Xem xét hình ảnh được tạo ra.

4. Xác nhận hình ảnh đúng theo thiết kế.

5. Lưu ảnh chuẩn cùng mã nguồn hoặc trong hệ thống quản lý kiểm thử phù hợp.

6. Chạy lại kiểm thử khi thay đổi giao diện.

7. Kiểm tra mọi khác biệt trước khi cập nhật ảnh chuẩn.

6.5. Các yếu tố ảnh hưởng đến kết quả Golden Testing

Golden Testing có thể bị ảnh hưởng bởi nhiều yếu tố môi trường.

Font chữ

Font hệ thống hoặc font chưa được tải đúng có thể làm thay đổi chiều rộng ký tự, xuống dòng và chiều cao văn bản. Nên sử dụng font được kiểm soát trong dự án và bảo đảm font đã sẵn sàng trước khi chụp ảnh.

Kích thước màn hình

Giao diện có thể khác nhau giữa các kích thước bề mặt. Vì vậy, cần xác định rõ kích thước màn hình cho từng golden test.

DPI và cấu hình rendering

Các khác biệt về môi trường rendering có thể làm thay đổi kết quả hình ảnh. Cần duy trì môi trường kiểm thử nhất quán.

Animation

Nếu chụp ảnh tại những thời điểm khác nhau trong animation, hình ảnh có thể khác nhau dù code không có lỗi. Nên cố định trạng thái animation hoặc điều khiển thời gian trong bài kiểm thử.

Dữ liệu động

Ngày giờ, ảnh tải từ mạng, dữ liệu ngẫu nhiên hoặc thông tin phụ thuộc môi trường có thể khiến kết quả không ổn định. Nên dùng dữ liệu kiểm thử cố định.

6.6. Golden Testing và Widget Testing thông thường

Hai phương pháp không thay thế nhau. Một Widget có thể hiển thị đúng hình ảnh nhưng xử lý nút sai; ngược lại, một Widget có thể xử lý đúng logic nhưng hiển thị sai màu sắc hoặc khoảng cách.

6.7. Ưu điểm và hạn chế của Golden Testing

Ưu điểm

• Phát hiện những thay đổi trực quan khó nhận ra bằng mắt khi kiểm tra thủ công.

• Giúp duy trì tính nhất quán trong hệ thống thiết kế.

• Hữu ích khi refactor giao diện.

• Hỗ trợ kiểm tra nhiều kích thước màn hình.

• Có thể tích hợp vào quy trình CI/CD để tự động kiểm tra giao diện.

Hạn chế

• Cần quản lý ảnh chuẩn.

• Có thể phát sinh sai khác do môi trường hoặc font chữ.

• Không xác minh đầy đủ hành vi người dùng.

• Những thay đổi giao diện hợp lệ cũng khiến kiểm thử thất bại cho đến khi ảnh chuẩn được cập nhật.

• Bộ golden test quá lớn có thể làm tăng thời gian kiểm thử và chi phí bảo trì.

6.8. Ứng dụng Golden Testing trong dự án thực tế

Đối với một ứng dụng thương mại điện tử, Golden Testing có thể được áp dụng cho:

• Thẻ sản phẩm.

• Trang chi tiết sản phẩm.

• Màn hình giỏ hàng.

• Màn hình thanh toán.

• Biểu mẫu đăng nhập.

• Các trạng thái lỗi và trạng thái rỗng.

• Màn hình quản trị và biểu đồ thống kê.

Ví dụ, một ProductCard có thể được kiểm thử ở các trạng thái còn hàng, hết hàng, giảm giá hoặc có nhãn sản phẩm nổi bật. Những ảnh chuẩn này giúp phát hiện lỗi khi thay đổi theme, font chữ, padding hoặc cấu trúc bố cục.

6.9. Kết luận về Golden Testing

Golden Testing là phương pháp kiểm thử trực quan hiệu quả cho ứng dụng Flutter. Bằng cách so sánh giao diện thực tế với ảnh chuẩn, phương pháp này giúp phát hiện những thay đổi ngoài ý muốn về màu sắc, kích thước, bố cục và font chữ. Để đạt độ tin cậy cao, cần kiểm soát môi trường kiểm thử, quản lý ảnh chuẩn cẩn thận và kết hợp Golden Testing với các bài kiểm thử hành vi.

7. Error Handling trong Widget Tree – Xử lý lỗi trong cây giao diện

7.1. Khái niệm Error Handling trong Widget Tree

Error Handling trong Widget Tree là quá trình phát hiện, ghi nhận và xử lý các lỗi phát sinh trong quá trình xây dựng giao diện, cập nhật trạng thái hoặc thực thi các hành vi liên quan đến Widget.

Trong ứng dụng Flutter, lỗi có thể phát sinh từ nhiều nguồn:

• Phương thức build() gặp lỗi khi xử lý dữ liệu.

• Widget nhận dữ liệu không hợp lệ.

• Callback của nút nhấn phát sinh exception.

• Future hoặc Stream thất bại.

• API trả về dữ liệu sai định dạng.

• Layout gặp constraints không phù hợp.

• Một tác vụ bất đồng bộ phát sinh lỗi nhưng không được xử lý.

Nếu không quản lý lỗi phù hợp, ứng dụng có thể hiển thị giao diện lỗi, mất một phần nội dung, ghi log không đầy đủ hoặc tạo ra trải nghiệm không tốt cho người dùng.

Mục tiêu của Error Handling không chỉ là ngăn ứng dụng gặp sự cố mà còn giúp phân loại lỗi, cung cấp thông tin chẩn đoán và duy trì trạng thái giao diện hợp lý.

7.2. Phân biệt lỗi build và lỗi trong callback

Lỗi trong build() xảy ra khi Flutter thực thi quá trình xây dựng Widget. Ví dụ, code truy cập một phần tử danh sách không tồn tại hoặc thực hiện phép xử lý dữ liệu không hợp lệ.

Ví dụ:

class ProductName extends StatelessWidget {
  final List<String> products;

  const ProductName({
    super.key,
    required this.products,
  });

  @override
  Widget build(BuildContext context) {
    return Text(products[0]);
  }
}

Nếu products là danh sách rỗng, việc truy cập products[0] sẽ phát sinh lỗi RangeError.

Có thể xử lý bằng cách kiểm tra dữ liệu trước khi sử dụng:

class ProductName extends StatelessWidget {
  final List<String> products;

  const ProductName({
    super.key,
    required this.products,
  });

  @override
  Widget build(BuildContext context) {
    if (products.isEmpty) {
      return const Text('Chưa có sản phẩm');
    }

    return Text(products.first);
  }
}

Ngược lại, lỗi trong callback xảy ra khi một hàm xử lý sự kiện được thực thi, chẳng hạn onPressed, onTap hoặc onChanged.

Ví dụ:

ElevatedButton(
  onPressed: () {
    final result = 10 ~/ 0;
    debugPrint('$result');
  },
  child: const Text('Thực hiện'),
)

Trong trường hợp này, lỗi chia số nguyên cho 0 xảy ra khi người dùng nhấn nút, không phải khi Widget được xây dựng ban đầu.

Hai loại lỗi có thời điểm phát sinh và cơ chế truyền lỗi khác nhau. Do đó, cần sử dụng cách xử lý phù hợp với từng tình huống.

7.3. Xử lý lỗi build trong Flutter

Flutter có cơ chế xử lý lỗi phát sinh trong quá trình xây dựng giao diện. Trong môi trường debug, lỗi thường được hiển thị kèm thông tin chẩn đoán để lập trình viên xác định vị trí và nguyên nhân.

ErrorWidget là Widget được sử dụng để đại diện cho một vùng giao diện khi quá trình xây dựng Widget gặp lỗi và lỗi đó được xử lý theo cơ chế tương ứng của Flutter.

Có thể tùy chỉnh Widget này thông qua ErrorWidget.builder.

Ví dụ:

import 'package:flutter/material.dart';

void main() {
  ErrorWidget.builder = (FlutterErrorDetails details) {
    return const Material(
      child: Center(
        child: Text(
          'Đã xảy ra lỗi giao diện',
          style: TextStyle(
            color: Colors.red,
          ),
        ),
      ),
    );
  };

  runApp(const MyApp());
}

Trong ví dụ trên, ErrorWidget.builder được cấu hình để trả về một giao diện thay thế khi Flutter cần tạo ErrorWidget.

Cần lưu ý rằng ErrorWidget.builder không phải cơ chế bắt mọi loại lỗi trong toàn bộ ứng dụng. Nó chủ yếu liên quan đến việc tạo Widget thay thế cho những lỗi xảy ra trong quá trình xây dựng Widget theo cơ chế của Flutter.

Ngoài ra, tùy chỉnh ErrorWidget không giải quyết nguyên nhân gốc của lỗi. Nếu code liên tục truy cập dữ liệu không hợp lệ, việc thay đổi giao diện lỗi chỉ làm thay đổi cách biểu diễn sự cố.

7.4. FlutterError.onError

FlutterError.onError là callback được sử dụng để nhận các lỗi được Flutter framework báo cáo thông qua cơ chế FlutterError.

Callback này thường được cấu hình ở giai đoạn khởi động ứng dụng để ghi log hoặc tích hợp với hệ thống theo dõi lỗi.

Ví dụ:

import 'package:flutter/material.dart';

void main() {
  FlutterError.onError = (FlutterErrorDetails details) {
    FlutterError.presentError(details);

    // Có thể gửi thông tin lỗi đến hệ thống logging.
    debugPrint(
      'Flutter error: ${details.exceptionAsString()}',
    );
  };

  runApp(const MyApp());
}

Trong ví dụ này:

• FlutterError.onError tiếp nhận thông tin lỗi do Flutter framework báo cáo.

• FlutterError.presentError() giữ lại cách trình bày lỗi theo cơ chế mặc định.

• details.exceptionAsString() lấy thông tin mô tả exception để ghi log.

Khi tích hợp hệ thống theo dõi lỗi thực tế, cần chú ý bảo vệ dữ liệu nhạy cảm và tránh gửi thông tin tài khoản, mật khẩu hoặc dữ liệu cá nhân không cần thiết vào log.

Điểm quan trọng là FlutterError.onError không tự động bắt mọi exception trong Dart. Các lỗi từ callback, Future, isolate hoặc những cơ chế khác có thể cần được xử lý riêng tùy theo ngữ cảnh.

7.5. Phân biệt ErrorWidget.builder và FlutterError.onError

Hai cơ chế này có vai trò khác nhau:

Trong một ứng dụng thực tế, có thể sử dụng cả hai cơ chế. ErrorWidget.builder phục vụ cách hiển thị lỗi giao diện, còn FlutterError.onError phục vụ chẩn đoán và theo dõi lỗi framework.

7.6. Xử lý lỗi trong callback

Với những thao tác có thể phát sinh lỗi, cần sử dụng try-catch khi phù hợp.

Ví dụ:

ElevatedButton(
  onPressed: () {
    try {
      final result = 10 ~/ 0;
      debugPrint('$result');
    } catch (error, stackTrace) {
      debugPrint('Lỗi thao tác: $error');
      debugPrintStack(stackTrace: stackTrace);
    }
  },
  child: const Text('Thực hiện'),
)

Trong ví dụ trên, exception được bắt trong callback. Điều này giúp tránh để lỗi của tác vụ đó lan truyền không kiểm soát trong luồng xử lý thông thường.

Tuy nhiên, không nên bắt lỗi rồi bỏ qua hoàn toàn. Nếu thao tác thất bại, ứng dụng có thể cần:

• Hiển thị thông báo cho người dùng.

• Khôi phục trạng thái giao diện.

• Ghi log lỗi.

• Cho phép người dùng thử lại.

• Giữ lại dữ liệu đã nhập.

• Phân loại lỗi để xử lý phù hợp.

7.7. Xử lý lỗi bất đồng bộ trong Widget

Nhiều Widget cần tải dữ liệu từ API hoặc cơ sở dữ liệu. Trong trường hợp này, lỗi có thể xảy ra sau khi phương thức build() đã hoàn tất.

Một cách tiếp cận phổ biến là sử dụng FutureBuilder.

Future<String> loadProductName() async {
  await Future.delayed(
    const Duration(seconds: 1),
  );

  return 'Áo thun nam';
}

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

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: FutureBuilder<String>(
        future: loadProductName(),
        builder: (context, snapshot) {
          if (snapshot.connectionState ==
              ConnectionState.waiting) {
            return const Center(
              child: CircularProgressIndicator(),
            );
          }

          if (snapshot.hasError) {
            return const Center(
              child: Text(
                'Không thể tải dữ liệu sản phẩm',
              ),
            );
          }

          if (!snapshot.hasData) {
            return const Center(
              child: Text('Không có dữ liệu'),
            );
          }

          return Center(
            child: Text(snapshot.data!),
          );
        },
      ),
    );
  }
}

Ví dụ này minh họa ba trạng thái chính:

• Đang tải dữ liệu.

• Tải dữ liệu thất bại.

• Tải dữ liệu thành công.

Trong ứng dụng thực tế, cần tránh tạo lại Future không cần thiết trong mỗi lần build(), vì điều đó có thể khiến tác vụ được khởi chạy lại. Có thể lưu Future trong State, tạo nó trong initState() hoặc sử dụng một cơ chế quản lý trạng thái phù hợp.

7.8. Xử lý lỗi và vòng đời Widget

Một số lỗi phát sinh khi tác vụ bất đồng bộ hoàn tất sau khi Widget đã bị loại khỏi cây giao diện.

Ví dụ, một tác vụ bắt đầu khi màn hình xuất hiện nhưng người dùng rời khỏi màn hình trước khi tác vụ hoàn tất. Nếu callback cố cập nhật trạng thái của một State đã bị dispose, ứng dụng có thể gặp cảnh báo hoặc hành vi không mong muốn.

Trong những trường hợp phù hợp, cần kiểm tra vòng đời của State trước khi gọi setState():

Future<void> loadData() async {
  final result = await fetchData();

  if (!mounted) {
    return;
  }

  setState(() {
    data = result;
  });
}

mounted cho biết State còn được gắn với cây giao diện hay không.

Tuy nhiên, kiểm tra mounted không thay thế việc quản lý vòng đời tác vụ. Nếu tác vụ có thể hủy, nên sử dụng cơ chế hủy tương ứng khi Widget bị loại bỏ, đặc biệt với những tác vụ mạng hoặc xử lý dài.

7.9. Zone và xử lý lỗi ngoài Flutter framework

Một ứng dụng Dart có thể gặp các exception không được xử lý bởi callback của Flutter framework. Với các lỗi thuộc phạm vi zone, runZonedGuarded() có thể hỗ trợ bắt lỗi chưa được xử lý trong zone tương ứng.

Ví dụ minh họa:

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

void main() {
  runZonedGuarded(
    () {
      runApp(const MyApp());
    },
    (error, stackTrace) {
      debugPrint('Uncaught error: $error');
      debugPrintStack(stackTrace: stackTrace);
    },
  );
}

Đây chỉ là một lớp bổ sung trong chiến lược xử lý lỗi. Không nên cho rằng runZonedGuarded() tự động thay thế FlutterError.onError, cơ chế xử lý lỗi của nền tảng hoặc việc xử lý exception trong từng tác vụ bất đồng bộ.

Đối với các ứng dụng cần theo dõi lỗi toàn diện, cần thiết kế rõ các điểm ghi nhận lỗi ở tầng framework, tầng bất đồng bộ và tầng nền tảng.

7.10. Các nguyên tắc xây dựng chiến lược Error Handling

Một chiến lược xử lý lỗi phù hợp cần tuân thủ những nguyên tắc sau:

1. Phân biệt lỗi build, lỗi callback, lỗi bất đồng bộ và lỗi nền tảng.

2. Kiểm tra dữ liệu trước khi sử dụng để tránh lỗi không cần thiết.

3. Không đặt tác vụ có tác dụng phụ trực tiếp trong build().

4. Dùng try-catch tại những ranh giới xử lý có thể phục hồi lỗi.

5. Cung cấp giao diện lỗi dễ hiểu cho người dùng.

6. Ghi log đủ thông tin để chẩn đoán nhưng không làm lộ dữ liệu nhạy cảm.

7. Sử dụng FlutterError.onError để theo dõi những lỗi framework phù hợp.

8. Dùng ErrorWidget.builder cho mục đích hiển thị lỗi build, không xem nó là giải pháp sửa lỗi gốc.

9. Quản lý vòng đời tác vụ bất đồng bộ và tránh cập nhật State sau khi Widget đã bị dispose.

10. Kiểm thử các trạng thái lỗi cùng với trạng thái thành công.

7.11. Kết luận về Error Handling trong Widget Tree

Error Handling trong Widget Tree giúp ứng dụng Flutter xử lý các tình huống lỗi một cách có tổ chức và dễ chẩn đoán hơn. Việc phân biệt lỗi build với lỗi callback, sử dụng ErrorWidget.builder, cấu hình FlutterError.onError và xử lý các tác vụ bất đồng bộ đúng cách giúp nâng cao độ ổn định của ứng dụng. Tuy nhiên, giao diện lỗi và hệ thống ghi log chỉ là một phần của giải pháp; việc kiểm tra dữ liệu, quản lý trạng thái và xử lý nguyên nhân gốc vẫn là yếu tố quan trọng nhất.

Kết luận

Tối ưu hiệu năng và kiểm thử Widget là nhóm kiến thức giúp nâng cao chất lượng ứng dụng Flutter cả về tốc độ, độ ổn định và khả năng bảo trì.

Rebuild Optimization giúp kiểm soát phạm vi cập nhật giao diện. ListView.builder và Lazy Building giúp xử lý danh sách lớn hiệu quả hơn. RepaintBoundary và layer hỗ trợ cô lập những vùng vẽ cần cập nhật độc lập. Flutter Inspector, Layout Explorer và DevTools giúp xác định nguyên nhân gây lỗi bố cục hoặc hiện tượng giật. Widget Testing và Golden Testing tạo nền tảng kiểm thử tự động cho hành vi và hình ảnh giao diện. Cuối cùng, Error Handling giúp ứng dụng phản ứng phù hợp khi gặp lỗi trong quá trình xây dựng Widget hoặc thực thi tác vụ.

Trong một dự án thực tế, các kỹ thuật này cần được áp dụng phối hợp thay vì tách rời. Một giao diện mượt không chỉ phụ thuộc vào số lần rebuild mà còn liên quan đến layout, rendering, dữ liệu, animation và tài nguyên hệ thống. Tương tự, một giao diện hiển thị đẹp chưa đủ để bảo đảm chất lượng nếu các thao tác của người dùng không hoạt động chính xác hoặc ứng dụng không xử lý được tình huống lỗi.

Vì vậy, quy trình phát triển Widget chuyên nghiệp nên kết hợp thiết kế cây giao diện hợp lý, tối ưu theo số liệu đo đạc, kiểm thử tự động và quản lý lỗi có hệ thống. Đây là nền tảng để xây dựng những ứng dụng Flutter có hiệu năng tốt, giao diện nhất quán và dễ mở rộng trong tương lai.