React Native có thật sự là native ?
Câu trả lời là có. Những gì chúng ra nhận được ở đầu cuối (nhìn thấy và tương tác trên mobile) chính là các thành phần native chứ ko phải cái HTLM5 + CSS3 nào ở đây hết. Có điều là cái cơ chế để làm được điều này nó không native như nhìu người lầm tưởng. Hồi đó mình cũng nghĩ là nó dùng JS compile ra code binary chạy, nhưng mà em nó khẳng định "em là chính em anh ơi".
Native nhưng không native là sao ?!?
Đầu tiên là chúng ta dev với Javascript (JS) và khi build vào mobile thì chúng được đóng gói kèm theo mấy đống đồ chơi node_modules vào thiết bị. Lúc này sẽ xuất hiện 2 lãnh thổ trong thiết bị: Native của dân cư bản địa (iOS/Android) và dân ngoại lai (JS hay còn gọi là JSCore/JS Engine). Bọn bản địa không cho dân ở ngoài du nhập vào mà chỉ cho giao thương thông qua những cây cầu (bridge). Từ đây mọi thứ được 2 bên thống nhất và trao đổi qua các cây cầu này, đa số là các biến dữ liệu (variable).
JSCore đương nhiên có các nhà máy chạy song song không ngừng nghỉ (JS Threads) để làm các logic business mà chúng ta viết trong JS. Dân bản địa thì có 2 loại nhà máy mà ai cũng biết là Main Thread và Dispatch Queue (RN định danh nó là Shadow Queue). Main Thread thì chỉ có 1 mà thôi, shadow queue vì nó là queue nên nó chạy thread pool, công việc chính của queue này là tính toán layout cho các component (dựa trên Flexbox). Tính xong rồi thì chuyển qua main thread cho hiện lên và chúng ta có được cái ta cần.
=> Các tiến trình này hầu hết là tự động nên mọi người không cần phải lo lắng quá.
=> Từ đó không native có nghĩa là ở bên địa hạt của JSCore. Còn native thì của bên iOS (ObjC/Swift) và Android (Java/Kotlin).
=> Dung lượng cài app của RN thấp là do nó chỉ là dung lượng của gói JS đẩy vào sau khi đã được minify. Một số thủ thuật có thể khiến gói build nhỏ hơn được nữa với phương pháp nén và rút ruột công trình (loại x86 ra khỏi gói build).JS Core trong Native Mobile
Câu này ai cũng hỏi nhưng đa số trả lời kiểu nó native mà ... ò thật ra là tại họ lười trả lời chi tiết thôi. Nếu bạn đã đọc từ đầu thì bạn đã có câu trả lời là "KHÔNG" rồi. Nhưng chênh lệch này không đáng quan ngại theo kiẻu Web App và app native nên các bạn đừng lo, nó vẫn chạy vi vu.
Cái chính ở đây là chúng ta đi giải mã tại sao nó chậm hơn, đó là "chi phí" cho sự giao tiếp giữa 2 bên khá tốn kém. Những cây cầu chính là là nguyên nhân dẫn tới bottle neck. Vì thế để tối ưu nó, các nhà phát triển RN phải tìm cách giảm thiểu tối đa việc sử dụng các cây cầu này (giống đi cầu có trạm thu phí vậy đó).
=> Đây là nguyên nhân các lib hiện tại sử dụng setNativeProps hoặc uỷ thác hẳn cho native chứ không viết hết trên JS nữa.
=> Lib đạt tối ưu max hiệu năng thì phải cần native, nghĩa là phải viết 2 nền rồi tạo bridge ra JS... Tới đây nhìu người băn khoăn kêu khóc RN vớ vẩn nếu thế dev native cho rồi. Haizz cái gì cũng có cái giá của nó mà. Tới đây bạn nào viết native được 2 nền native sẽ là GOD, tha hồ dev lib. Việc dùng RN giúp chúng ta thống nhất UX trên 2 nền mà chỉ hy sinh 1 ít hiệu năng, vấn đề này vẫn đã và đang được cải thiện lên rất nhiều.
Vậy nó nên học RN và làm app với nó không ??
Những bạn đang có ý định học RN để làm app thôi thì cứ yên tâm mà học, nó dễ lắm, rất dễ. Mấy cái mình nói trên kia chỉ là để hiểu thêm cơ chế và sau này các bạn có thể đánh giá được lib nào tệ lib nào tốt, cái thế giới của node module nó tạp nham lắm ...
Những ai đang làm cty, điều hành nhóm dev mobile thì cứ thử đổi qua làm thử 1 2 apps để trải nghiệm sự khác biệt, đôi khi lại không muốn code native nữa đó chứ ... à thật ra là lúc đó team native đổi qua viết lib, custom animation nhìu hơn.
xem thêm : học iot ở đâu
Hi. I’m Designer of Blog Magic. I’m CEO/Founder of ThemeXpose. I’m Creative Art Director, Web Designer, UI/UX Designer, Interaction Designer, Industrial Designer, Web Developer, Business Enthusiast, StartUp Enthusiast, Speaker, Writer and Photographer. Inspired to make things looks better.
0 nhận xét:
Đăng nhận xét