Jetpack Compose vs React Native cho ngoại tuyến và tính năng thiết bị

Bạn thực sự đang so sánh điều gì

Khi người ta nói “device features”, thường họ ám chỉ những phần liên kết app với chính điện thoại: chụp ảnh bằng camera, GPS, quét Bluetooth, thông báo đẩy, truy cập file (tải về, PDF, tệp đính kèm), và tác vụ nền như đếm bước chân hoặc kiểm tra trạng thái mạng. Câu hỏi thật sự không phải là “có làm được không”, mà là “đường dẫn tới phần cứng có trực tiếp không, và có nhất quán giữa các máy và phiên bản OS không.”

Chế độ ngoại tuyến thay đổi toàn bộ bài toán. Đó không phải là một công tắc nói “hoạt động khi không có Internet.” Bạn cần lưu trữ cục bộ, định nghĩa rõ dữ liệu nào có thể lỗi thời, và quy tắc xử lý khi có xung đột thay đổi (ví dụ, người dùng sửa đơn hàng khi offline trong khi cùng đơn đó đã được cập nhật trên server). Khi thêm đồng bộ, bạn đang thiết kế một hệ thống nhỏ, chứ không chỉ một màn hình.

So sánh Compose và React Native thường được đóng khung là native vs cross-platform, nhưng với công việc ngoại tuyến và truy cập thiết bị, sự khác biệt xuất hiện ở chỗ ghép nối: bạn phụ thuộc vào bao nhiêu cầu nối, plugin và giải pháp tạm, và việc gỡ lỗi khi có sự cố trên một mẫu điện thoại cụ thể dễ hay khó.

“Hiệu năng” cũng cần được định nghĩa bằng trải nghiệm người dùng: thời gian khởi động, cuộn và nhập liệu (đặc biệt trong danh sách dài và biểu mẫu), pin và nhiệt (tác vụ nền âm thầm gây hao pin), và độ ổn định (crash, treo, lỗi giao diện). Bạn có thể phát hành app tốt với cả hai. Sự đánh đổi là bạn muốn sự chắc chắn ở đâu: kiểm soát cấp OS chặt hơn, hay một codebase duy nhất với nhiều mảnh ghép di chuyển ở rìa.

Truy cập tính năng thiết bị: hệ thống khác nhau ra sao

Khác biệt lớn ở đây không phải widget UI. Là cách app của bạn tiếp cận camera, Bluetooth, vị trí, file và dịch vụ nền.

Trên Android, Jetpack Compose là lớp UI. Mã của bạn vẫn dùng Android SDK bình thường và cùng thư viện native như một app Android “cổ điển”. Việc truy cập thiết bị có cảm giác trực tiếp: bạn gọi API Android, xử lý quyền, và tích hợp SDK mà không qua một lớp dịch thuật. Nếu nhà cung cấp đưa thư viện Android cho máy quét hay công cụ MDM, bạn thường có thể thêm và dùng ngay.

React Native chạy JavaScript cho phần lớn logic app, nên truy cập thiết bị phải qua native modules. Một module là đoạn mã Android (Kotlin/Java) hoặc iOS (Swift/Obj-C) để phơi bày tính năng thiết bị cho JavaScript. Nhiều tính năng phổ biến đã có module sẵn, nhưng bạn vẫn phụ thuộc vào cầu nối (hoặc cách tiếp cận JSI/TurboModules mới hơn) để truyền dữ liệu giữa native và JavaScript.

Khi gặp tính năng chưa có sẵn, con đường chia ra. Trong Compose, bạn viết nhiều mã native hơn. Trong React Native, bạn viết một native module tùy chỉnh và phải duy trì nó cho hai nền tảng. Đó là lúc “chúng tôi chọn cross-platform” có thể âm thầm biến thành “bây giờ chúng tôi có ba codebase: JS, Android native, iOS native.”

Một cách thực tế để nghĩ về sự phù hợp của đội khi yêu cầu lớn lên:

• Compose phù hợp hơn nếu bạn đã có năng lực Android mạnh hoặc cần tích hợp sâu vào Android.
• React Native phù hợp nếu đội bạn mạnh về JavaScript và nhu cầu thiết bị là điển hình.
• Dù chọn gì, hãy dự tính công việc native nếu bạn cần dịch vụ nền, phần cứng đặc biệt, hoặc quy tắc ngoại tuyến nghiêm ngặt.

Hiệu năng trong thực tế: nơi người dùng cảm nhận

Sự khác biệt “cảm giác” thực sự xuất hiện ở vài khoảnh khắc: khi mở app, khi chuyển giữa màn hình, và khi UI vẫn đang làm việc trong lúc người dùng còn chạm.

Thời gian khởi động và chuyển màn hình thường dễ giữ nhanh hơn trong Compose vì nó hoàn toàn native và chạy cùng runtime với phần còn lại của app Android. React Native có thể rất nhanh, nhưng cold start thường bao gồm bước thiết lập thêm (nạp JS engine và bundle). Độ trễ nhỏ có khả năng xuất hiện hơn nếu app nặng hoặc build chưa tối ưu.

Độ phản hồi khi tải nặng là vấn đề tiếp theo. Nếu bạn parse một file JSON lớn, lọc danh sách dài, hoặc tính tổng cho một biểu mẫu, app Compose thường đẩy công việc đó sang Kotlin coroutines và giữ main thread rảnh. Trong React Native, bất cứ thứ gì chặn JS thread đều làm cảm giác chạm và animation trở nên “kẹt”, nên bạn thường phải chuyển công việc nặng sang native hoặc lên lịch cẩn thận.

Cuộn là nơi người dùng phàn nàn đầu tiên. Compose cung cấp công cụ danh sách native như LazyColumn để ảo hóa item và tái sử dụng bộ nhớ tốt khi được viết đúng. React Native dựa vào FlatList (và đôi khi các lựa chọn nhanh hơn), và bạn cần chú ý kích thước ảnh, key của item, và re-render để tránh giật.

Pin và công việc nền thường phụ thuộc vào cách bạn thiết kế đồng bộ. Trên Android, app Compose có thể dựa vào công cụ nền của nền tảng như WorkManager để lịch trình đáng tin cậy. Trong React Native, đồng bộ nền phụ thuộc vào native modules và giới hạn OS, nên độ tin cậy dao động hơn theo thiết bị và cấu hình. Polling quá mức đều hao pin trên cả hai.

Nếu hiệu năng là rủi ro lớn, hãy làm một “màn hình vấn đề” trước: danh sách nặng nhất và một biểu mẫu offline với khối lượng dữ liệu thật. Đo trên thiết bị tầm trung, không chỉ flagship.

Nguyên tắc ngoại tuyến cơ bản: lưu trữ dữ liệu và trạng thái

Chế độ ngoại tuyến chủ yếu là vấn đề dữ liệu, không phải giao diện. Dù chọn UI stack nào, phần khó là quyết định lưu gì trên thiết bị, UI hiển thị gì khi offline, và làm thế nào hòa giải thay đổi sau này.

Lưu trữ cục bộ: chọn công cụ phù hợp

Một quy tắc đơn giản: lưu dữ liệu quan trọng do người dùng tạo vào cơ sở dữ liệu thực, không để rải rác trong các trường key-value.

Dùng database cho dữ liệu có cấu trúc bạn cần truy vấn và sắp xếp (đơn hàng, dòng hàng, khách hàng, nháp). Dùng key-value cho cài đặt nhỏ (cờ như “đã xem hướng dẫn”, token, bộ lọc cuối cùng). Dùng file cho blob (ảnh, PDF, export cache, tệp đính kèm lớn).

Trên Android với Compose, các đội thường dùng Room hoặc các lựa chọn dựa trên SQLite kèm một kho key-value nhỏ. Trong React Native, bạn thường thêm thư viện cho SQLite/Realm-style storage và một kho key-value riêng (AsyncStorage/MMKV-like) cho preferences.

Luồng ngoại tuyến-đầu tiên: coi cục bộ là nguồn chân lý

Offline-first nghĩa là tạo/sửa/xóa xảy ra cục bộ trước, rồi đồng bộ sau. Mẫu thực tế: ghi vào DB cục bộ, cập nhật UI từ DB cục bộ, và đẩy thay đổi lên server nền khi có thể. Ví dụ, một nhân viên sales sửa đơn trên máy bay, thấy ngay trong danh sách, và app xếp hàng một task đồng bộ chạy sau.

Xung đột xảy ra khi cùng bản ghi thay đổi trên hai thiết bị. Chiến lược phổ biến: last-write-wins (đơn giản, có thể mất dữ liệu), merge (tốt cho trường cộng dồn như ghi chú), hoặc cho người dùng xem xét (tốt nhất khi độ chính xác quan trọng, như giá cả hoặc số lượng).

Để tránh bug khó chịu, định nghĩa “sự thật” rõ ràng:

• Trạng thái UI là tạm thời (những gì người dùng đang gõ ngay lúc đó).
• Trạng thái lưu là bền vững (những gì bạn có thể load lại sau crash).
• Trạng thái server là chia sẻ (những gì thiết bị khác cuối cùng sẽ thấy).

Giữ ranh giới đó và hành vi ngoại tuyến sẽ dự đoán được ngay cả khi biểu mẫu và danh sách phức tạp.

Độ tin cậy đồng bộ nền: điều gì hỏng và vì sao

Đồng bộ nền thất bại thường vì điện thoại hơn là vì mã của bạn. Cả Android và iOS giới hạn việc app làm gì ở nền để bảo vệ pin, dữ liệu và hiệu năng. Nếu người dùng bật tiết kiệm pin, tắt dữ liệu nền, hoặc kill app, lời hứa “đồng bộ mỗi 5 phút” có thể thành “đồng bộ khi OS cảm thấy phù hợp.”

Trên Android, độ tin cậy phụ thuộc vào cách bạn lên lịch công việc và quy tắc tiết kiệm pin của hãng sản xuất. Đường an toàn là dùng scheduler được OS chấp nhận (như WorkManager với constraints). Dù vậy, các hãng có thể trì hoãn job mạnh khi màn hình tắt hoặc thiết bị idle. Nếu app bạn cần cập nhật gần thời gian thực, bạn sẽ phải thiết kế quanh eventual sync thay vì đồng bộ luôn.

Khác biệt chính giữa Compose và React Native là nơi công việc nền chạy. App Compose thường chạy tác vụ nền trong mã native, nên lịch trình và logic retry gần với OS hơn. React Native vẫn có thể ổn, nhưng tác vụ nền thường phụ thuộc vào thiết lập native thêm và module bên thứ ba. Các lỗi phổ biến: task không đăng ký đúng, headless task bị OS kill, hoặc runtime JS không được đánh thức khi bạn mong muốn.

Để chứng minh sync hoạt động, đối xử nó như một tính năng production và đo lường. Ghi log các thông tin trả lời câu hỏi “nó có chạy không?” và “nó hoàn thành không?” Track khi job được lên lịch, bắt đầu và kết thúc; trạng thái mạng và tiết kiệm pin; các mục trong hàng đợi, đã upload, thất bại và thử lại (kèm mã lỗi); thời gian kể từ đồng bộ thành công gần nhất cho mỗi user/device; và kết quả xung đột.

Test đơn giản: bỏ điện thoại vào túi qua đêm. Nếu sync vẫn thành công vào buổi sáng trên nhiều thiết bị, bạn đang đi đúng hướng.

Biểu mẫu phức tạp: xác thực, nháp và chi tiết UX

Biểu mẫu phức tạp là nơi người dùng cảm nhận sự khác biệt, dù họ không thể gọi tên. Khi biểu mẫu có trường điều kiện, nhiều bước, và nhiều xác thực, độ trễ nhỏ hoặc lỗi focus nhanh chóng khiến người dùng bỏ giữa chừng.

Xác thực dễ chịu hơn khi nó dự đoán được. Hiện lỗi chỉ sau khi trường được chạm, giữ tin nhắn ngắn, và làm luật trùng với workflow thực. Trường điều kiện (ví dụ, “Nếu cần giao hàng, hỏi địa chỉ”) nên xuất hiện mà không làm trang nhảy. Biểu mẫu nhiều bước hoạt động tốt hơn khi mỗi bước có mục tiêu rõ và có cách quay lại mà không mất dữ liệu.

Hành vi bàn phím và focus là điểm mấu chốt thầm lặng. Người dùng mong nút Next di chuyển theo thứ tự hợp lý, màn hình tự cuộn để trường đang nhập luôn thấy được, và thông báo lỗi có thể truy cập bởi screen reader. Test bằng một tay trên điện thoại nhỏ—đó là nơi thứ tự focus lộn xộn và nút bị che khuất lộ ra.

Nháp ngoại tuyến không phải tuỳ chọn cho biểu mẫu dài. Cách thực tế là lưu khi người dùng làm việc và cho họ tiếp tục sau, ngay cả khi app bị kill. Lưu sau thay đổi có ý nghĩa (không phải mọi phím bấm), hiển thị hint “last saved” đơn giản, cho phép dữ liệu một phần, và xử lý tệp đính kèm riêng để ảnh lớn không làm chậm việc lưu nháp.

Ví dụ: một biểu mẫu kiểm tra 40 trường với phần điều kiện (các kiểm tra an toàn chỉ hiện cho thiết bị nhất định). Nếu app validate mọi quy tắc ở mỗi lần gõ, cảm giác gõ sẽ bị kẹt. Nếu chỉ lưu nháp ở cuối, pin cạn hoặc crash sẽ làm mất việc. Trải nghiệm mượt là lưu nhanh cục bộ, tăng dần mức xác thực khi gần gửi, và focus ổn định để bàn phím không che nút hành động.

Danh sách dài: cuộn mượt và sử dụng bộ nhớ

Danh sách dài là nơi người dùng nhận ra vấn đề đầu tiên: cuộn, chạm và lọc nhanh. Cả hai framework đều có thể nhanh, nhưng chậm vì những lý do khác nhau.

Trong Compose, danh sách dài thường xây với LazyColumn (và LazyRow). Nó chỉ render những gì trên màn hình, giúp tiết kiệm bộ nhớ. Bạn vẫn cần giữ mỗi row nhẹ. Công việc nặng trong item composable, hoặc thay đổi state khiến wide recomposition, có thể gây giật.

Trong React Native, FlatList và SectionList cũng thiết kế để ảo hóa, nhưng bạn có thể gặp công việc thêm khi props thay đổi khiến React render lại nhiều hàng. Ảnh, chiều cao động và cập nhật filter thường xuyên có thể gây áp lực lên JS thread, điều này thể hiện bằng frame bị bỏ.

Một vài thói quen tránh hầu hết giật list: giữ key ổn định, tránh tạo object và callback mới cho mỗi hàng ở mỗi render, giữ chiều cao hàng dự đoán được, và phân trang để không chặn cuộn khi tải.

Cách bước để chọn cho ứng dụng của bạn

Bắt đầu bằng viết yêu cầu bằng ngôn ngữ rõ ràng, không bằng thuật ngữ framework. “Quét barcode trong điều kiện thiếu sáng”, “đính kèm 10 ảnh cho mỗi đơn”, “hoạt động 2 ngày không có sóng”, và “đồng bộ im lặng khi máy khóa” làm trade-off rõ ràng.

Tiếp theo, khóa quy tắc dữ liệu và đồng bộ trước khi bạn chăm chút giao diện. Quyết định gì sống cục bộ, gì có thể cache, gì cần mã hóa, và chuyện gì xảy ra khi hai lần sửa trùng nhau. Nếu làm chuyện này sau khi UI đã đẹp, bạn thường phải làm lại nhiều phần app.

Rồi xây cùng một lát nhỏ trên hai lựa chọn và chấm điểm: một biểu mẫu phức tạp với nháp và đính kèm, một danh sách dài với tìm kiếm và cập nhật, một luồng offline cơ bản ở chế độ máy bay, và một lần đồng bộ tiếp tục sau khi app bị kill và mở lại. Cuối cùng, test hành vi nền trên thiết bị thực: bật tiết kiệm pin, giới hạn dữ liệu nền, để máy idle một giờ. Nhiều lỗi “chỉ chạy trên điện thoại tôi” xuất hiện đúng ở bước này.

Đo những gì người dùng thực sự cảm nhận: cold start, mượt khi cuộn, và phiên không crash. Đừng đuổi theo benchmark hoàn hảo. Một baseline đơn giản lặp lại được tốt hơn.

Sai lầm và bẫy thông thường

Nhiều đội bắt đầu tập trung vào màn hình và animation. Phần đau đớn thường xuất hiện sau: hành vi ngoại tuyến, giới hạn công việc nền, và trạng thái không khớp với mong đợi người dùng.

Một bẫy phổ biến là coi đồng bộ nền như sẽ chạy bất cứ khi nào bạn yêu cầu. Android và iOS sẽ tạm dừng hoặc trì hoãn để tiết kiệm pin và dữ liệu. Nếu thiết kế của bạn giả định upload tức thì, bạn sẽ nhận báo cáo “cập nhật thất lạc” thực ra là do OS lập lịch.

Một bẫy khác là làm UI trước và để model dữ liệu chạy theo. Xung đột ngoại tuyến khó sửa sau khi đã ra mắt. Quyết định sớm chuyện gì xảy ra khi cùng record bị sửa hai lần, hoặc khi người dùng xóa thứ chưa bao giờ được upload.

Biểu mẫu có thể âm thầm trở nên lộn xộn nếu bạn không đặt tên và tách trạng thái. Người dùng cần biết họ đang sửa nháp, bản ghi lưu cục bộ, hay thứ đã sync. Không rõ ràng sẽ dẫn tới gửi trùng, mất ghi chú, hoặc xác thực chặn sai thời điểm.

Theo dõi các mẫu sau:

• Giả định công việc nền chạy theo timer thay vì best-effort theo quy tắc OS.
• Xem offline như một toggle, không phải phần lõi của model dữ liệu và xung đột.
• Để một biểu mẫu đại diện cho ba thứ (nháp, lưu, đã sync) mà không có quy tắc rõ ràng.
• Test chỉ trên máy nhanh và Wi‑Fi ổn, rồi ngạc nhiên vì danh sách chậm và upload kẹt.
• Thêm nhiều plugin bên thứ ba, rồi phát hiện một cái không được duy trì hoặc fail ở edge case.

Một kiểm tra thực tế nhanh: một nhân viên tạo đơn trong hầm không có sóng, sửa hai lần rồi đi ra ngoài. Nếu app không giải thích được phiên bản nào sẽ sync, hoặc sync bị chặn bởi tiết kiệm pin, người dùng sẽ đổ lỗi cho app, không phải mạng.

Checklist nhanh trước khi quyết định

Trước khi chọn stack, làm một lát “thực” nhỏ của app và cho điểm. Nếu một mục thất bại, thường nó sẽ biến thành tuần sửa lỗi sau này.

Kiểm tra hoàn thành ngoại tuyến trước: người dùng có hoàn thành ba tác vụ hàng đầu không khi không có mạng, end-to-end, không gặp trạng thái rỗng gây nhầm lẫn hoặc mục trùng? Rồi stress sync: retry và backoff khi Wi‑Fi chập chờn, kill app giữa lúc upload, và trạng thái rõ cho người dùng như “Saved on device” vs “Sent.” Xác thực biểu mẫu với luồng dài, điều kiện: nháp nên mở lại chính xác chỗ người dùng rời đi sau crash hoặc kill. Đẩy danh sách với hàng nghìn hàng, filter và cập nhật tại chỗ, quan sát dropped frames và spike bộ nhớ. Cuối cùng, thử tính năng thiết bị khi quyền bị từ chối và bị giới hạn: quyền “chỉ khi dùng”, bật tiết kiệm pin, dữ liệu nền bị giới hạn, và fallback mềm mại.

Mẹo thực tế: giới hạn thời gian test này 2–3 ngày cho mỗi phương án. Nếu bạn không thể làm phần “offline + sync + danh sách dài + biểu mẫu phức tạp” cảm thấy ổn trong khung đó, hãy chuẩn bị cho đau đầu kéo dài.

Tình huống ví dụ: app bán hàng hiện trường với đơn hàng ngoại tuyến

Hình dung đội bán hàng hiện trường bán cho cửa hàng nhỏ. App cần đơn hàng ngoại tuyến, chụp ảnh (kệ và hoá đơn), catalog lớn, và đồng bộ hàng ngày về HQ.

Sáng: nhân viên mở app ở bãi xe với sóng chập chờn. Họ tìm trong catalog 10.000 mặt hàng, thêm nhanh, và chuyển giữa chi tiết khách hàng và biểu mẫu đơn dài. Đây là nơi ma sát UI lộ ra. Nếu danh sách sản phẩm re-render quá nhiều, cuộn giật. Nếu biểu mẫu mất focus, reset dropdown, hoặc quên nháp khi app vào background để chụp ảnh, nhân viên sẽ cảm nhận ngay.

Giữa ngày: kết nối rớt hàng giờ. Nhân viên tạo năm đơn, mỗi đơn có giảm giá, ghi chú và ảnh. Offline không chỉ là “lưu cục bộ.” Nó còn là quy tắc xung đột (nếu bảng giá thay đổi), trạng thái rõ ràng (Saved, Pending Sync, Synced), và nháp an toàn (biểu mẫu chịu được cuộc gọi, dùng camera, hoặc khởi động lại app).

Tối: nhân viên về vùng có sóng. “Đủ tin cậy” đối với đội này nghĩa là đơn được upload tự động trong vài phút khi mạng trở lại, upload lỗi được thử lại mà không tạo trùng, ảnh được xếp hàng và nén để sync không kẹt, và nhân viên có thể chạm “Sync now” và thấy kết quả.

Thường thì đây là lúc quyết định trở nên rõ ràng: bạn cần bao nhiêu hành vi native dưới áp lực (danh sách dài, camera + backgrounding, và công việc nền do OS quản lý). Prototype phần rủi ro trước: một danh sách sản phẩm khổng lồ, một biểu mẫu đơn phức tạp với nháp, và một hàng đợi offline thử retry upload sau khi mất mạng.

Bước tiếp theo: xác thực lựa chọn với một bản build nhỏ

Nếu bạn vẫn phân vân, làm một spike ngắn, tập trung. Bạn không cố gắng hoàn thành app. Bạn tìm constraint thực sự đầu tiên.

Dùng kế hoạch đơn giản: chọn một tính năng thiết bị không thể bỏ (ví dụ, quét barcode + chụp ảnh), một luồng offline end-to-end (tạo, sửa, lưu nháp, reboot máy, mở lại, gửi), và một job sync (xếp hành động offline, thử lại trên mạng chập chờn, xử lý server reject, và hiển thị lỗi rõ ràng).

Trước khi ra mắt, quyết định cách bạn sẽ bắt lỗi ngoài đời. Ghi log các lần sync với mã lý do (không có mạng, auth hết hạn, xung đột, lỗi server), và thêm một màn hình “Sync status” nhỏ để hỗ trợ có thể chẩn đoán mà không đoán mò.

Nếu bạn cần xây backend và admin UI cùng lúc với mobile, AppMaster (appmaster.io) có thể là baseline hữu ích cho ứng dụng doanh nghiệp: nó sinh backend, web và mã native production-ready, giúp bạn xác thực mô hình dữ liệu và workflows nhanh trước khi cam kết vào một framework mobile cụ thể.