Chúng tôi đã chuyển đổi thành công hai ứng dụng lớn nhất của mình. Shopify Di động và Shopify Hệ thống bán hàng (POS) tích hợp với React Native. Kiến trúc mới đồng thời duy trì việc phát hành hàng tuần và phục vụ hàng triệu thương nhân.

Quá trình chuyển đổi này liên quan đến một cơ sở mã phức tạp với hàng trăm màn hình và mô-đun gốc, các thành phần tùy chỉnh mở rộng và sự tích hợp sâu rộng với các thư viện của bên thứ nhất như... Danh sách Flash.

Kết quả chính:

• Duy trì tốc độ phát triển trong suốt quá trình chuyển đổi.
• Không có sự gián đoạn nào trong quá trình phát triển tính năng.
• Đã xác định và giải quyết các vấn đề di chuyển dữ liệu phổ biến trên quy mô lớn.

Bài viết này chia sẻ phương pháp di chuyển hệ thống của chúng tôi, các quyết định quan trọng mà chúng tôi đã đưa ra và những bài học kinh nghiệm để các nhóm khác có thể hưởng lợi từ kinh nghiệm của chúng tôi. Chúng tôi sẽ đề cập đến các chiến lược thực tiễn mà chúng tôi đã sử dụng để di chuyển hệ thống thành công. Shopify Ứng dụng di động đồng thời duy trì tốc độ phát triển và tính ổn định của ứng dụng.

Chiến lược di cư: Giữ cho con tàu luôn chuyển động

Các Nguyên Tắc Chỉ Đạo

Chiến lược di cư của chúng tôi được xây dựng dựa trên ba nguyên tắc cốt lõi:

1. Ưu tiên giảm thiểu thay đổi mã trước, sau đó mới tái cấu trúc sau.Chỉ thực hiện những thay đổi mã tối thiểu cần thiết để kích hoạt Kiến trúc mới. Việc tối ưu hóa và tái cấu trúc có thể được thực hiện sau đó. Việc chuyển đổi càng nhanh càng tốt là rất quan trọng để tránh việc đưa thêm mã mới có thể làm hỏng quy trình xây dựng trên kiến ​​trúc mới.
2. Đảm bảo tính tương thích kiến ​​trúc kép trong suốt quá trình phát triển.Hỗ trợ cả kiến ​​trúc cũ và mới trong suốt quá trình chuyển đổi để cho phép kiểm thử liên tục và ngăn ngừa lỗi hồi quy. Loại bỏ hỗ trợ kiến ​​trúc cũ sau khi triển khai.
3. Duy trì sự tương đồng về hiệu năng và độ ổn định.Đảm bảo kiến ​​trúc mới đạt hiệu suất và độ ổn định tương đương hoặc cao hơn kiến ​​trúc cũ, đặc biệt là về các chỉ số TTI (thời gian tương tác) và các phiên hoạt động không bị lỗi trước khi đưa vào sản xuất.

Duy trì tốc độ phát triển

Tại Shopify, chúng tôi phát hành các bản cập nhật ứng dụng hàng tuần.Điều này khiến việc phát triển tính năng liên tục trở nên cực kỳ quan trọng trong quá trình chuyển đổi. Đối với các ứng dụng lớn, việc tạm dừng phát triển tiềm ẩn rủi ro—các sự cố kỹ thuật có thể làm chậm trễ việc bổ sung các tính năng thiết yếu hoặc sửa lỗi.

Cách tiếp cận của chúng tôi cân bằng giữa tiến độ chuyển đổi và nhu cầu của người bán:

• Kiểm tra kiến ​​trúc kép: Tận dụng mũ đội đầuChúng tôi đã tạo các bản dựng cho cả hai kiến ​​trúc trên mỗi yêu cầu kéo (PR), cho phép dễ dàng kiểm thử mà không cần biên dịch lại cục bộ và ngăn chặn việc hợp nhất các thay đổi gây lỗi kiến ​​trúc mới.

• Chức năng có điều kiệnĐối với các thư viện bên thứ ba không hỗ trợ đồng thời cả hai kiến ​​trúc trên cùng một phiên bản, chúng tôi đã sử dụng các cờ tính năng để vô hiệu hóa chức năng một cách có điều kiện ở chế độ phát triển trên kiến ​​trúc mới.

Thông tin quan trọng dành cho người quản lý thư viện: Cung cấp một phiên bản hỗ trợ cả hai kiến ​​trúc. Quản lý phiên bản có điều kiện không phải là điều đơn giản — hỗ trợ kép giúp giảm đáng kể gánh nặng chuyển đổi. Đó là lý do tại sao chúng tôi duy trì cả hai kiến ​​trúc trong FlashList v2 Phiên bản alpha.

Kỹ thuật sâu sắc

Quá trình di chuyển

• Chiến lược mô-đun gốcChúng tôi không chuyển đổi bất kỳ mô-đun nào sang TurboModules trong quá trình chuyển đổi. Thay vào đó, chúng tôi chỉ thực hiện các thay đổi đối với các mô-đun không hoạt động trên kiến ​​trúc mới (chủ yếu là các mô-đun liên quan đến UIManager). Chúng tôi đã sử dụng cờ tính năng để phân nhánh triển khai, đảm bảo khả năng tương thích với cả hai kiến ​​trúc. Mặc dù TurboModules đại diện cho một bước tiến, nhưng chúng chưa bắt buộc (hiện tại), và với hơn 40 mô-đun trong ứng dụng Shopify, chúng tôi quyết định đánh giá lại chúng sau khi chuyển đổi. Điều này cho phép chúng tôi xác định mô-đun nào vẫn hữu ích và cách chúng tôi có thể cải thiện API của chúng bằng cách tận dụng các khả năng mới của TurboModules.

• Quản lý phụ thuộcChúng tôi đã cập nhật các thư viện phụ thuộc không tương thích lên các phiên bản hỗ trợ kiến ​​trúc kép. Chúng tôi cũng đã vá lỗi hoặc loại bỏ các thư viện không còn được bảo trì. Điều này đã tạo cơ hội để giảm thiểu số lượng thư viện phụ thuộc.

• Nâng cấp lên phiên bản React Native mới nhất: Kiến trúc mới đang được phát triển mạnh mẽ với việc liên tục sửa lỗi và cải thiện hiệu năng. Chúng tôi ưu tiên nâng cấp lên phiên bản React Native mới nhất hiện có và đảm bảo nó hoạt động ổn định trước khi bắt đầu các tối ưu hóa dành riêng cho ứng dụng. Cách tiếp cận này đảm bảo chúng tôi được hưởng lợi từ những cải tiến từ nguồn gốc thay vì khắc phục các vấn đề có thể đã được giải quyết. Hầu hết các lỗi chúng tôi gặp phải đều được khắc phục bằng các bản nâng cấp phiên bản. Do đó, chúng tôi khuyên bạn nên cập nhật lên phiên bản mới nhất có thể trước khi bắt đầu quá trình chuyển đổi.

• Thay đổi mã ứng dụng: Chúng tôi đã thực hiện những thay đổi tối thiểu để đảm bảo mã tính năng hoạt động trên cả hai kiến ​​trúc. Chúng tôi cũng đã thêm cảnh báo lỗi thời vào các đường dẫn mã tạm thời để dọn dẹp sau khi di chuyển.

Các vấn đề thường gặp khi di cư

Quá trình chuyển đổi đòi hỏi phải thích ứng với mô hình kết xuất đồng bộ của kiến ​​trúc mới và các giao diện mô-đun gốc được cập nhật, điều này đã ảnh hưởng đến cách thức hoạt động của các thành phần hiện có và các tích hợp gốc của chúng tôi.

Dưới đây là những vấn đề phổ biến nhất mà chúng tôi gặp phải và giải pháp của chúng:

Thay đổi thao tác cây bóng
Việc thao tác các view React Native từ UIManager gốc có thể dẫn đến các vấn đề nghiêm trọng về giao diện người dùng, chẳng hạn như cử chỉ chạm không hoạt động do sự không đồng bộ giữa những gì React Native cho rằng hệ thống phân cấp view trông như thế nào và thực tế ra sao. Đây là điều mà chúng tôi đã gặp phải. Chế độ xem di động của Cầu Di động.

Các mô-đun gốc cũ trên luồng chính
Chúng tôi gặp một vài sự cố "Ứng dụng bị treo" trên iOS trong quá trình khởi chạy ứng dụng do các mô-đun gốc cũ được tải trong luồng chính trong khi hoạt ảnh đang diễn ra. Điều này gây ra tình trạng bế tắc và dẫn đến sự cố sập ứng dụng. Vấn đề này không dễ tái hiện trong môi trường phát triển và thường yêu cầu phải đóng và khởi chạy lại ứng dụng nhiều lần trong vài phút. Tuy nhiên, chúng tôi đã thấy rất nhiều sự cố sập ứng dụng trong môi trường sản xuất.

Giải pháp: Nếu bạn vẫn còn các mô-đun gốc cũ, hãy đảm bảo thiết lập requiresMainQueueSetup Nên giữ nguyên giá trị là false trừ khi thực sự cần thiết. Trong hầu hết các trường hợp, điều đó là không cần thiết.

Các vấn đề liên quan đến hiệu suất hoạt hình

Ứng dụng Shopify sử dụng phục hồi Chúng tôi đã dành nhiều thời gian cho hoạt ảnh điều hướng. Chúng tôi gặp phải tình trạng giảm tốc độ khung hình nghiêm trọng trên cả hai nền tảng — những vấn đề đặc thù do quy mô và độ phức tạp của hoạt ảnh mà chúng tôi thực hiện.

Những thách thức này đã làm nổi bật thực tế của việc áp dụng sớm trong một dự án lớn. Tuy nhiên, phản hồi từ cả Software Mansion (đơn vị bảo trì Reanimated) và Meta đều rất tích cực. Cả hai nhóm đã hợp tác chặt chẽ với chúng tôi để xác định và giải quyết các vấn đề về hiệu năng mà có thể đã không được chú ý trong các ứng dụng nhỏ hơn hoặc ít phức tạp hơn.

Software Mansion đã cung cấp quyền truy cập sớm vào các bản vá lỗi giải quyết hầu hết các vấn đề về hiệu năng. Hiện tại, chúng tôi đang hợp tác với cả Meta và Software Mansion để tích hợp các bản sửa lỗi này vào Reanimated và React Native, đảm bảo cộng đồng rộng lớn hơn được hưởng lợi từ những cải tiến được phát hiện thông qua quá trình thử nghiệm quy mô lớn của chúng tôi. Những cải tiến về hiệu năng và sửa lỗi từ sự hợp tác này sẽ mang lại lợi ích cho tất cả các nhóm sử dụng Reanimated với kiến ​​trúc mới.

Khuyến nghịĐối với phần lớn các ứng dụng, chúng tôi vẫn khuyên bạn nên sử dụng Reanimated. Những vấn đề về hiệu năng này dường như chủ yếu dễ nhận thấy với các hoạt ảnh phức tạp ở quy mô lớn, và tùy thuộc vào nơi chúng được áp dụng, có thể không ảnh hưởng đáng kể đến người dùng.

Phương pháp triển khai

Vì đây không phải là tính năng có thể triển khai từ xa, chúng tôi đã sử dụng chiến lược triển khai từng bước cẩn thận để theo dõi độ ổn định và hiệu năng.

Điều quan trọng là phải xem xét sự khác biệt về cơ chế kiểm soát triển khai giữa App Store và Play Store.

Google Play Store cung cấp khả năng kiểm soát triển khai chi tiết với khả năng thiết lập tỷ lệ phần trăm cụ thể và dừng cài đặt mới bất cứ lúc nào. Ngược lại, App Store sử dụng lịch trình triển khai dần dần đã được xác định trước. Khi tạm dừng, người dùng có thể... vẫn còn Việc cập nhật thủ công lên phiên bản mới là cần thiết. Thêm vào đó, quá trình phê duyệt các ứng dụng mới được gửi lên App Store có thể mất đến 24 giờ, khiến việc vá lỗi khẩn cấp trở nên chậm hơn và tiềm ẩn nhiều rủi ro hơn.

Vì lý do đó, chúng tôi đã lập một lịch trình bắt đầu với Android, sau đó dần dần mở rộng sang các hệ điều hành khác. iOS được triển khai một ngày sau đó, khi chúng tôi đã tự tin hơn về tính ổn định của bản phát hành.

Lịch trình triển khai:

• Ngày 1 – Android 8% và iOS 0%Mục tiêu là thu thập tín hiệu sớm từ Android vì hệ điều hành này có thể bị dừng hoàn toàn bất cứ lúc nào.
• Ngày 2 – Android 30%, iOS 1%Tỷ lệ triển khai Android tăng đáng kể, đồng thời duy trì tỷ lệ sử dụng thấp trên iOS để có thời gian phản ứng.
• Ngày 3 – cả hai nền tảng đều hoàn thành 100%: Hiện tại, chúng tôi rất tự tin rằng không phát hiện ra vấn đề lớn nào. Vì không thể tăng tỷ lệ người dùng iOS lên một mức cụ thể, chúng tôi quyết định triển khai đầy đủ trên cả hai nền tảng để có dữ liệu quy mô lớn phục vụ cho việc phân tích.

Kế hoạch ứng phó khẩn cấp:

Mục tiêu về độ ổn định (phiên hoạt động không bị lỗi) của ứng dụng Shopify là 99.95%. Đối với bản phát hành này, chúng tôi đã thiết lập ba cấp độ phản hồi dựa trên ngưỡng ổn định:

1. Độ ổn định trên 99.80%: Lỗi này sẽ được khắc phục trong bản phát hành hàng tuần tiếp theo.
2. Độ ổn định nằm trong khoảng từ 99.00% đến 99.80%, hoặc luồng xử lý quan trọng bị gián đoạn nhưng đã có cách khắc phục: Tạm dừng triển khai và sửa lỗi khẩn cấp
3. Độ ổn định dưới 99.00% hoặc luồng xử lý quan trọng bị gián đoạn mà không có giải pháp khắc phục nhanh chóng: rollback

Việc hoàn tác được xem là biện pháp cuối cùng vì nó sẽ gây ra hậu quả nghiêm trọng cho tiến độ chuyển đổi của chúng tôi. Chúng tôi cần dữ liệu mà chỉ có được ở quy mô lớn khi phát hành ứng dụng cho người dùng. Việc hoàn tác không chỉ gây tốn kém về mặt vận hành mà còn làm chậm đáng kể tiến độ chuyển đổi của chúng tôi. Nếu có thể tạm dừng việc triển khai sớm và giải quyết các vấn đề ổn định thay vì vậy, chúng tôi sẽ ưu tiên phương án đó.

Điều gì đã diễn ra tốt đẹp

Quá trình chuyển đổi cuối cùng đã thành công với sự gián đoạn tối thiểu đối với quy trình phát triển của chúng tôi. Chúng tôi duy trì chu kỳ phát hành hàng tuần trong suốt toàn bộ thời gian chuyển đổi, cung cấp các tính năng mới cho người bán mà không bị gián đoạn.

Mặc dù trọng tâm là thực hiện quá trình chuyển đổi đó, nhưng việc chuyển sang sử dụng Fabric đã mang lại một vài lợi ích tức thì:

• Thời gian khởi chạy ứng dụng đã được cải thiện khoảng 10% trên Android và 3% trên iOS.
• Chúng tôi đã đơn giản hóa quá trình hiển thị màn hình bằng cách tận dụng kỹ thuật đo trước khi vẽ (measure before paint), giúp màn hình tải mượt mà và nhanh hơn. Bạn có thể tìm hiểu thêm về điều này trên trang web của chúng tôi. Bài đăng trên blog FlashList v2.
• Chế độ xử lý theo lô mới đã giảm thiểu việc hiển thị lại không cần thiết, giúp các thao tác như chuyển đổi tab trở nên nhanh hơn.

Nhìn chung, chuyên môn của nhóm chúng tôi về kiến ​​trúc mới đã được nâng cao đáng kể trong suốt quá trình. Từ sự thiếu quen thuộc ban đầu, chúng tôi đã có được sự hiểu biết sâu sắc, tạo nền tảng vững chắc cho các bản cập nhật và tối ưu hóa React Native trong tương lai.

Hệ sinh thái React Native rộng lớn hơn cũng được hưởng lợi từ những bài học kinh nghiệm của chúng tôi. Chúng tôi đã xây dựng lại FlashList từ đầu, cung cấp các ví dụ mã thực tế về cách tối ưu hóa hiệu suất hiển thị trên Kiến trúc mới. Chúng tôi cũng đã hợp tác chặt chẽ với Meta và Software Mansion để khám phá, sữa lỗi và các vấn đề về hiệu năng hiện đang được giải quyết ở khâu trước đó.

Hi vọng bài đăng trên blog này có thể giúp các nhóm khác vượt qua những thách thức tương tự, tạo ra giá trị lâu dài vượt ra ngoài sản phẩm của chính chúng ta.

Những điều không suôn sẻ

Mặc dù chúng tôi đã đo lường hiệu năng một cách kỹ lưỡng và thực hiện các tối ưu hóa trước khi triển khai, chúng tôi vẫn gặp phải một số thách thức chỉ bộc lộ rõ ​​khi đưa vào sản xuất quy mô lớn. Bất chấp sự cẩn trọng trong quá trình thử nghiệm nội bộ, tác động thực tế lại nghiêm trọng hơn dự kiến.

Suy giảm hiệu suấtMột số màn hình cần được tinh chỉnh hiệu năng sau khi phát hành, vì những thay đổi trong đường dẫn hiển thị đã phá vỡ một số giả định được đưa ra khi chúng tôi tạo ra các thành phần này. Chúng tôi nhận thấy thời gian tải tăng lên tới 20% trên một số thành phần phức tạp. Điều này không phải do bản thân Kiến trúc mới gây ra. Nó chỉ làm lộ ra những điểm yếu trong thiết kế của một số thành phần mà trước đây không thể nhìn thấy.

Thách thức về tính ổn địnhĐộ ổn định phiên (phiên không bị lỗi) đã giảm từ mục tiêu ban đầu là 99.95%, nhưng đã phục hồi sau vài tuần sửa lỗi. Chúng tôi vẫn thấy một số lỗi xảy ra ở mức độ thấp trong mã nguồn của React Native hoặc thư viện bên thứ ba, nhưng không gây ảnh hưởng đáng kể. Chúng tôi đang làm việc với Meta và những người bảo trì thư viện để tìm giải pháp.

Đột biến ANRLỗi "Ứng dụng không phản hồi" (Application Not Responding) gia tăng trên cả hai nền tảng, một phần do các bản vá tùy chỉnh Reanimated/React Native của chúng tôi đã khắc phục các sự cố hiệu năng khác. Một số hiện tượng tắc nghẽn cũng xuất hiện do một số mô-đun gốc được khởi tạo trên luồng chính. Điều này không gây ra sự cố trên kiến ​​trúc cũ, nhưng trong một số trường hợp hiếm hoi, nó đã làm sập ứng dụng trên kiến ​​trúc mới.

Vì đây là một thay đổi cơ bản đối với khung nền quan trọng nhất của chúng tôi, nên mọi chuyện có thể tồi tệ hơn nhiều. Chúng tôi vẫn lạc quan về tương lai của React Native và tin rằng kiến ​​trúc mới sẽ cung cấp nền tảng tốt hơn để giải quyết những vấn đề về hiệu năng này.

Đề xuất dành cho các đội khác

Việc chuyển đổi sang kiến ​​trúc mới của React Native đầy thách thức nhưng hoàn toàn có thể thực hiện được nếu có kế hoạch đúng đắn.

Những khuyến nghị này dựa trên kinh nghiệm của chúng tôi trong việc di chuyển một ứng dụng sản xuất quy mô lớn phục vụ hàng triệu người dùng. Tùy thuộc vào quy mô và độ phức tạp của dự án, bạn có thể cần điều chỉnh các phương pháp này, nhưng chúng cung cấp một nền tảng vững chắc để lập kế hoạch di chuyển của bạn.

1. Kiểm toán sớm các mối phụ thuộc – Xác định các vấn đề tương thích trước khi bắt đầu quá trình chuyển đổi.
2. Hãy nâng cấp lên phiên bản React Native mới nhất trước khi chỉnh sửa bất kỳ đoạn mã nào. – Tránh lãng phí thời gian vào những vấn đề đã được khắc phục ở phiên bản trước. Phát hành bản nâng cấp trước khi bắt đầu quá trình chuyển đổi để giảm thiểu phạm vi ảnh hưởng của các thay đổi.
3. Hãy bắt đầu thôi – Tập trung vào việc tích hợp Fabric vào quá trình phát triển càng sớm càng tốt. Việc này sẽ cung cấp cho nhóm của bạn những tín hiệu quý giá về những khu vực nào trong ứng dụng cần được chú ý. Duy trì khả năng tương thích với kiến ​​trúc cũ.
4. Tận dụng cộng đồng – Nhiều vấn đề bạn sẽ gặp phải đã được thảo luận trong phần trước. Các vấn đề trên GitHub trong kho lưu trữ React Native hoặc ở các khu vực khác của cộng đồngHãy tìm kiếm các vấn đề và thảo luận hiện có trước khi cố gắng giải quyết vấn đề từ đầu.
5. Giảm thiểu thay đổi ban đầu – Ưu tiên sửa lỗi và thực hiện các tối ưu hóa có mục tiêu trước khi phát hành.
6. Mô-đun gốc chiến lược – Chỉ nên di chuyển những mô-đun mang lại lợi ích rõ ràng trước tiên.
7. Lên kế hoạch cho sự ổn định và suy giảm hiệu năng khi triển khai theo từng giai đoạn. – Chấp nhận việc giảm độ ổn định tạm thời và tận dụng các tính năng triển khai dần dần trên cửa hàng ứng dụng để giảm thiểu rủi ro.
8. Sửa lỗi về phía trước khi có thể. – Tránh việc hoàn tác để duy trì đà phát triển.

Cái gì tiếp theo

Với nền tảng kiến ​​trúc mới, trọng tâm của chúng tôi chuyển từ khả năng tương thích sang tối ưu hóa. Giờ đây, chúng tôi có thể tận dụng những khả năng trước đây không thể thực hiện được, giải quyết những thách thức về hiệu năng hiện tại đồng thời xây dựng trải nghiệm người dùng tốt hơn.

Các ưu tiên tiếp theo của chúng tôi bao gồm:

• Di chuyển TurboModule chiến lượcChuyển đổi các mô-đun tần số cao (tùy chọn người dùng, cờ tính năng) và các đường dẫn quan trọng về hiệu năng để loại bỏ chi phí tuần tự hóa.
• Áp dụng bố cục đồng bộXây dựng các thành phần tốt hơn bằng cách tận dụng bố cục đồng bộ để loại bỏ hiện tượng giật hình và cải thiện hiệu suất trên các bố cục phức tạp.
• Tối ưu hóa hiệu suấtSử dụng tính năng tải TurboModule lười biếng và tối ưu hóa hiển thị để giải quyết các thách thức về thời gian phản hồi (TTI) và thời gian khởi chạy ứng dụng.

Cuối cùng, chúng tôi xin gửi lời cảm ơn đặc biệt đến Meta và Software Mansion vì đã là những đối tác tuyệt vời, hỗ trợ chúng tôi trong mọi bước đi. Chúng tôi cũng xin cảm ơn cộng đồng React Native. Công việc này sẽ không thể thực hiện được nếu không có những kinh nghiệm được chia sẻ trên các diễn đàn GitHub, bài đăng trên blog và các dự án mã nguồn mở.

Kiến trúc mới này đại diện cho tương lai của React Native. Mặc dù việc chuyển đổi đòi hỏi nhiều nỗ lực, nhưng lợi ích lâu dài sẽ khiến nó trở nên xứng đáng. Chúng tôi rất hào hứng với những gì sắp tới. Với bố cục đồng bộ giúp loại bỏ hiện tượng giật lag giao diện người dùng và TurboModules cung cấp khả năng tương tác native cực nhanh, chúng tôi có thể tiếp tục tạo ra những trải nghiệm tuyệt vời và mượt mà mà các nhà bán lẻ mong đợi. Tương lai của React Native trông tươi sáng hơn bao giờ hết, và Shopify đang đầu tư mạnh mẽ vào sự thành công liên tục của nó.