Flutter - free resource mobile app, desktop, web

WebAssembly là canh bạc lớn nhất trong lộ trình Flutter 2026, và 3.47 đẩy nó tiến thêm một bước với deferred loading thử nghiệm. Khảo sát Q2 2026 chấm Web ở mức 72% hài lòng — điểm nền tảng thấp thứ nhì — và hiệu năng tải là một phần lớn của lý do. Wasm là phương án sửa được nhắm tới.

Nhưng ship Wasm hôm nay không phải là bật một cái cờ. Đó là một cuộc migrate, một ma trận hỗ trợ trình duyệt với một lỗ hổng lớn, và hai HTTP header mà phần lớn mọi người quên.

Các lệnh build

# Phát triển
flutter run -d chrome --wasm

# Production
flutter build web --wasm

# Production, kèm symbolication cho giám sát lỗi
flutter build web --wasm --source-maps

# Staging/QA — stack trace đọc được, binary lớn hơn ~47%
flutter build web --wasm --no-strip-wasm

Dùng --source-maps cho bất cứ thứ gì bạn trỏ Sentry hay dịch vụ tương tự vào; nó sinh main.dart.wasm.map. Chỉ dùng --no-strip-wasm ở staging — chi phí dung lượng là thật.

Flutter 3.47 cũng thêm deferred loading thử nghiệm:

flutter build web --release --wasm --enable-wasm-deferred-loading

Ở tầng Dart, đây cùng là năng lực đã ra mắt dạng preview trong Dart 3.13 (dart compile wasm -O2 --enable-deferred-loading), được ghi nhận cho cải thiện đáng kể thời gian tải trang lần đầu so với dart2js với ứng dụng lớn. Với app lớn, đây là ranh giới giữa việc Wasm nhanh hơn trên lý thuyết và nhanh hơn thật ở chỉ số người dùng cảm nhận.

Ma trận trình duyệt, và vấn đề iOS

Đầu ra Wasm của Flutter cần WasmGC. Hỗ trợ hiện tại:

Hãy đọc lại dòng cuối. Không phải “Safari trên iOS”; là mọi trình duyệt trên iOS, vì Apple bắt buộc dùng WebKit. Nếu lưu lượng web của bạn nghiêng về di động, một phần đáng kể người dùng sẽ không chạy bản Wasm của bạn chút nào.

Chính vì thế fallback rất quan trọng: ngay cả với --wasm, Flutter vẫn biên dịch ra JavaScript. Nếu không phát hiện WasmGC lúc chạy, bản JS sẽ chạy. Bạn đang ship cả hai, và trình duyệt chọn. Điều đó tốt cho tính đúng đắn và tệ cho ai hy vọng Wasm giảm dung lượng triển khai.

Để xác nhận một phiên chạy theo đường nào:

const isRunningWithWasm = bool.fromEnvironment('dart.tool.dart2wasm');

Hãy log nó. Nếu không, bạn sẽ tối ưu một nhánh code mà phần lớn người dùng chẳng bao giờ chạm tới.

Cuộc migrate thật sự: thoát khỏi dart:html

Đây mới là phần việc. Wasm sẽ không biên dịch nếu app của bạn import thư viện web không được hỗ trợ.

Flutter cho bạn cảnh báo sớm mà không cần build Wasm — chạy flutter build web thường sẽ thực hiện một lượt Wasm dry run:

Wasm dry run failed:
Found incompatibilities with WebAssembly.

package:my_app/main.dart 1:1 - dart:html unsupported (0)

Hãy chạy nó ngay hôm nay, kể cả khi bạn chưa có kế hoạch Wasm. Đó là một lượt kiểm toán miễn phí cho cây dependency của bạn.

Khi biên dịch đầy đủ thất bại, hãy bỏ qua stack trace và tìm Context tree — nó nêu tên chuỗi package đã kéo thư viện không tương thích vào:

Context: The unavailable library 'dart:html' is imported through these packages:
    main.dart => package:my_app => dart:html

Thường đó là một dependency gián tiếp, không phải code của bạn. Để migrate dần, conditional import cho phép hai thế giới cùng tồn tại:

import 'fallback.dart'
  if (dart.library.js) 'legacy_web_interop.dart'
  if (dart.library.js_interop) 'wasm_web_interop.dart';

Hai cái header ai cũng quên

App Flutter Wasm có thể render trên nhiều luồng — nhưng chỉ khi server của bạn gửi đúng header cross-origin:

Thiếu một trong hai, đa luồng lặng lẽ không xảy ra. App vẫn chạy; chỉ là chậm hơn con số benchmark bạn đọc được. Hãy kiểm tra chúng trong cấu hình CDN hoặc reverse proxy, không chỉ ở môi trường dev — đây là cái bẫy kinh điển “nhanh trên localhost, chậm trên production”.

Lưu ý require-corp sẽ làm hỏng các tài nguyên bên thứ ba nhúng vào mà không khai báo header CORP. Nếu bạn nhúng nhiều nội dung ngoài, credentialless thường là lựa chọn thực dụng.

Khác biệt lúc chạy đáng biết

package:web và dart:js_interop dưới Wasm không giống hệt backend JS:

• Kiểm tra is / as hành xử khác trên các kiểu JS interop
• Zone lan truyền trong callback khác đi

Không cái nào làm hỏng một app thông thường, nhưng cả hai sẽ cắn đoạn code làm những trò thông minh với kiểm tra kiểu qua ranh giới interop. Hãy test riêng lớp interop thay vì cho rằng chúng ngang bằng.

Kế hoạch triển khai của bạn

1. Chạy flutter build web ngay hôm nay và đọc kết quả Wasm dry run. Đó là backlog migrate của bạn.
2. Cập nhật web/index.html theo phần khởi tạo Flutter hiện hành, hoặc sinh lại bằng flutter create . --platforms web.
3. Migrate code của chính bạn từ dart:html sang package:web và từ dart:js sang dart:js_interop.
4. Truy các thủ phạm gián tiếp được nêu trong Context tree. Mở issue cho những dependency còn import dart:html.
5. Cấu hình header COOP và COEP ở tầng phục vụ production, rồi kiểm chứng bằng tab network.
6. Build với --wasm --source-maps và nối file map vào hệ thống giám sát lỗi.
7. Log dart.tool.dart2wasm và đo xem bao nhiêu phần trăm phiên thật sự đi đường Wasm.
8. Thử --enable-wasm-deferred-loading nếu bundle của bạn lớn, và đo thời gian tải trang lần đầu thay vì tổng dung lượng.

Kết luận

Wasm nhanh hơn thật, và lộ trình chỉ tới việc nó thành mặc định. Nhưng hôm nay nó là một bản build cộng thêm, không phải thay thế: bạn vẫn ship JS, người dùng iOS vẫn nhận đường JS bất kể thế nào, và phần thắng hiệu năng phụ thuộc hai cái header mà phần lớn nhóm chưa đặt. Việc giá trị nhất bạn có thể làm tuần này chẳng tốn gì — chạy flutter build web và đọc kết quả dry run. Dù bạn có ship Wasm quý này hay không, danh sách dependency dính dart:html đó là món nợ sớm muộn cũng phải trả.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Impeller đã là renderer duy nhất trên iOS nhiều năm và mặc định trên Android API 29+ được một thời gian. Flutter 3.47 hoàn tất công việc: Impeller giờ là mặc định trên macOS, Windows và Linux. Chỉ còn Flutter Web chạy trên Skia.

Nếu bạn ship app desktop, đây là thay đổi trong 3.47 dễ làm app của bạn nhìn và cảm nhận khác nhất — và cũng dễ làm lộ ra một lỗi render bạn chưa từng thấy nhất.

Vấn đề Impeller sinh ra để giải

Skia biên dịch shader lúc chạy, theo yêu cầu, ngay lần đầu một thao tác vẽ cụ thể xuất hiện. Đó là lý do một app Flutter có thể giật ở lần đầu bạn mở một màn hình, chạy một animation, hay áp một hiệu ứng blur cụ thể — rồi sau đó chạy mượt mãi mãi. Không phải do code của bạn. Là do renderer biên dịch một chương trình ngay giữa khung hình.

Impeller biên dịch một tập shader nhỏ hơn, đơn giản hơn, ngoại tuyến, lúc build engine. Các pipeline state object được dựng trước thay vì dựng theo từng khung hình. Cache là tường minh và do engine kiểm soát thay vì ngầm định. Kết quả không nhất thiết là frame rate đỉnh cao hơn — mà là nhịp khung hình dự đoán được, thứ mà người dùng thực sự cảm nhận là mượt.

Các mục tiêu thiết kế đáng gọi tên vì chúng giải thích những đánh đổi:

• Hiệu năng dự đoán được — mọi thứ biên dịch ngoại tuyến
• Đo đạc được — tài nguyên đồ hoạ được gắn nhãn, và animation có thể được ghi lại, lưu trữ mà không làm nhiễu thời gian khung hình
• Khả chuyển — shader viết một lần, chuyển đổi theo từng backend
• API hiện đại — dùng tính năng của Metal và Vulkan mà không bắt buộc phải có
• Đồng thời — công việc của một khung hình được trải ra nhiều luồng

Backend nào chạy ở đâu

Vulkan trên Windows và Linux là dòng đáng đọc hai lần. Tình trạng driver của người dùng giờ là một phần trong stack render của bạn theo cách trước đây không phải, và chính sự biến thiên đó là lý do bạn nên test trên phần cứng thật thay vì một máy dev duy nhất.

Wide gamut color trên macOS

Song song với việc đổi renderer, wide gamut color bật mặc định trên macOS. Trên màn hình P3, các màu bão hoà sẽ render bão hoà hơn so với mặc định trước đây. Đây là hành vi đúng, nhưng là thay đổi nhìn thấy được: nếu màu thương hiệu của bạn từng được canh bằng mắt trên bản render bị kẹp về sRGB, chúng sẽ trông khác. Hãy đối chiếu bảng màu với design trước khi kết luận đó là lỗi.

Cách tắt, theo từng nền tảng

Các lối thoát vẫn tồn tại, và release notes nói rõ rằng các phương án fallback sẽ bị gỡ trong một bản phát hành tương lai. Hãy dùng chúng để gỡ kẹt một mốc phát hành và để báo lỗi — không phải làm cấu hình dài hạn.

Để debug trên mọi nền tảng desktop:

flutter run --no-enable-impeller

Bản release, macOS — trong Info.plist, dưới <dict> cấp cao nhất:

<key>FLTEnableImpeller</key>
<false />

Bản release, Linux — trong linux/runner/my_application.cc:

g_autoptr(FlDartProject) project = fl_dart_project_new();
fl_dart_project_set_enable_impeller(project, FALSE);

Bản release, Windows — trong windows\runner\main.cpp:

flutter::DartProject project(L"data");
project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);

Trên Android tương đương là một mục trong manifest (io.flutter.embedding.android.EnableImpeller đặt false). Trên iOS thì không có lối tắt nào cả — và đó là bản xem trước của nơi desktop đang đi tới.

Nên test lại những gì

Đổi renderer thường làm lộ vấn đề ở một nhóm chỗ có thể đoán trước. Ưu tiên:

• Blur và đổ bóng — BackdropFilter, ImageFilter.blur, bóng theo elevation. Trong lịch sử đây là vùng lệch nhiều nhất giữa các renderer.
• Custom painter và shader — mọi thứ dùng CustomPainter, FragmentProgram, hoặc blend mode ngoài srcOver.
• Render chữ ở cỡ nhỏ — định vị subpixel và hinting khác nhau.
• Màu trên màn hình P3 — xem phần wide gamut ở trên.
• Cạnh clip và khử răng cưa — nhất là clip lồng nhau với góc bo.
• Khởi động trên GPU yếu — đường Vulkan trên Windows và Linux là biến số mới.

Khảo sát Q2 2026 đặt mức hài lòng Windows ở 74% và Linux ở 73% — hai điểm nền tảng thấp nhất sau Cupertino. Desktop là nơi Flutter còn phải bù nhiều nhất, và điều đó có hai mặt: bản phát hành này là một khoản đầu tư thật cho các nền tảng đó, đồng thời cũng là vùng có nền tảng kiểm thử mỏng nhất trước đây.

Báo lỗi cho hữu ích

Nếu bạn tìm thấy hồi quy, đội Flutter cần một bộ dữ liệu cụ thể, và các báo cáo thiếu nó thường bị đứng:

1. Thêm tiền tố [Impeller] vào tiêu đề issue.
2. Ghi cấu hình thiết bị, gồm cả chip chính xác và phiên bản driver GPU.
3. Đính kèm ảnh chụp màn hình hoặc video, lý tưởng là đặt cạnh bản --no-enable-impeller.
4. Đính kèm bản export performance trace đã nén.
5. Nêu phiên bản và channel Flutter từ flutter --version.

Bản so sánh cạnh nhau là thứ giá trị nhất. Nó biến “cái này trông sai” thành một khác biệt render tái hiện được.

Checklist nâng cấp của bạn

1. Build các target desktop trên 3.47 trước khi động vào bất cứ thứ gì khác.
2. Chạy bộ visual regression, hoặc nếu chưa có, đi tay qua năm màn hình phức tạp nhất.
3. So với --no-enable-impeller cho bất cứ chỗ nào trông lạ, để biết renderer có thực sự là nguyên nhân không.
4. Test trên ít nhất một GPU Windows yếu và một bản phân phối Linux bạn không dùng để phát triển.
5. Kiểm tra lại màu thương hiệu trên màn hình P3 nếu bạn ship trên macOS.
6. Mở issue có tiền tố [Impeller] ngay bây giờ, khi fallback còn tồn tại.
7. Đừng ship bản tắt Impeller vĩnh viễn. Hãy ghi nó là nợ kỹ thuật kèm ngày gỡ.

Kết luận

Impeller trên desktop là thay đổi đúng và hơi rủi ro. Mặt lợi mang tính cấu trúc: giật do shader thôi là một loại bug bạn phải săn, và nhịp khung hình trở nên dự đoán được. Cái giá là một lượt kiểm chứng lại toàn bộ lớp hiển thị, cộng thêm một phụ thuộc mới vào chất lượng driver Vulkan trên Windows và Linux. Hãy làm lượt đó ngay bây giờ, khi --no-enable-impeller còn tồn tại để cho bạn biết renderer có phải thủ phạm hay không — vì nó sẽ không tồn tại mãi.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.