React Native มาพร้อมกับข้อดีหลายประการ เช่น การสนับสนุนข้ามแพลตฟอร์ม, การอัปเดต OTA, การรีโหลดแบบสด, ประสิทธิภาพด้านต้นทุน ฯลฯ แต่ปัญหาคอขวดที่ใหญ่ที่สุดในการปรับขนาดแอปพลิเคชันเนทีฟแบบรีแอคทีฟคือประสิทธิภาพเมื่อคุณเพิ่มโมดูล เมื่อแอปพลิเคชันกลายเป็นข้อมูลเข้มข้นหรือเมื่อมีหลายโมดูล ต้องผ่านสะพาน

แต่สถาปัตยกรรมปัจจุบันทำงานอย่างไร?

สถาปัตยกรรม React Native ขึ้นอยู่กับสามเธรด: a) เธรด UI:นี่คือเธรดแอปพลิเคชันหลักที่ใช้สำหรับการแสดงมุมมอง Android และ iOS b) เธรดเงา:เป็นเธรดพื้นหลังชนิดหนึ่งซึ่งคำนวณเค้าโครงขององค์ประกอบ (โดยใช้Yoga ) ก่อนแสดงผลบนแพลตฟอร์มโฮสต์ c) เธรด JS: Bundled JS ซึ่งรับผิดชอบในการจัดการลอจิกทั้งหมดในแอปพลิเคชันเนทีฟตอบสนองของคุณ

การโต้ตอบระหว่างเธรดเหล่านี้ไม่ได้เกิดขึ้นโดยตรง และทุกครั้งที่เธรดหนึ่งต้องการโต้ตอบกับเธรดอื่น เธรดจะต้องผ่านงานหนักของการทำให้เป็นอนุกรมและการดีซีเรียลไลเซชันของข้อมูลไปยัง JSON เพื่อผ่านบริดจ์ ซึ่งส่งผลให้เกิดการคัดลอกข้อมูลที่ไม่จำเป็นและบริดจ์นี้สามารถแออัดได้อย่างง่ายดายเนื่องจากการดำเนินการเป็นแบบอะซิงโครนัสและไม่มีการพิมพ์ที่เข้มงวด

ข้อจำกัดบางประการของสถาปัตยกรรมปัจจุบัน:
1. Javascript และฝั่งดั้งเดิมไม่รู้จักกันและอาศัยข้อความ JSON แบบอะซิงโครนัส
2. โหลดโมดูลทั้งหมดเมื่อเริ่มต้นซึ่งจะเพิ่มเวลาในการโต้ตอบ
3. ไม่จัดลำดับความสำคัญของการกระทำ: การโต้ตอบที่สำคัญของผู้ใช้ไม่สามารถจัดลำดับความสำคัญเหนือการกระทำอื่นๆ ได้
4. การทำให้เป็นอนุกรมของบริดจ์
5. องค์ประกอบ UI ไม่สามารถเข้าถึงได้โดยตรงจากเธรด JS

แนะนำ JSI

JSI นำการเปลี่ยนแปลงครั้งใหญ่ในการโต้ตอบของจาวาสคริปต์และส่วนเนทีฟ ให้การสื่อสารโดยตรงระหว่างสองอาณาจักรด้วยความช่วยเหลือของอินเทอร์เฟซระหว่าง JS และ C ++ การใช้อินเทอร์เฟซ JavaScript ทำให้ JS สามารถอ้างอิงถึงวัตถุโฮสต์และวิธีการเรียกบนวัตถุเหล่านั้น ด้วยความช่วยเหลือของวัตถุโฮสต์ ตอนนี้เราสามารถใช้วัตถุพื้นเมืองในบริบทจาวาสคริปต์ สะพานที่เป็นคอขวดที่ใหญ่ที่สุดถูกแบ่งออกเป็นส่วนต่างๆ:

ผ้า

ระบบการเรนเดอร์ใหม่ที่สร้างโดย Facebook ซึ่งเป็นการปรับสถาปัตยกรรมใหม่ของตัวจัดการ UI ตัวเรนเดอร์นี้ใช้งานใน C ++ และแกนกลางนั้นใช้ร่วมกันระหว่างแพลตฟอร์มต่างๆ ในการสร้างโครงร่างการใช้งานก่อนหน้านี้เกี่ยวข้องกับหลายขั้นตอน เช่น การทำให้เป็นอนุกรมของ JSON และการกระโดดข้ามสะพาน ซึ่งมีปัญหาใหญ่เมื่อสะพานถูกบล็อก เช่น: เฟรมตกขณะเลื่อนผ่านรายการที่ไม่มีที่สิ้นสุด การใช้งานใหม่ช่วยให้ผู้จัดการ UI สามารถสร้าง Shadow Tree ได้โดยตรงใน C++ ซึ่งปรับปรุงประสบการณ์อย่างมากโดยลดจำนวนการกระโดดข้ามขอบเขต การดำเนินการเป็นแบบซิงโครนัสและเธรดที่ปลอดภัยซึ่งถูกเรียกใช้งานจาก React (JavaScript) ไปยังตัวเรนเดอร์ (C++) โดยปกติจะอยู่ในเธรด JavaScript นอกจากนี้ยังเกี่ยวข้องกับการจัดลำดับข้อมูลน้อยลงเนื่องจากสามารถเลือกค่าจาวาสคริปต์ได้โดยตรงจาก JSI การควบคุมโดยตรงนี้ยังช่วยในการจัดลำดับความสำคัญของการกระทำ เรนเดอร์สามารถจัดลำดับความสำคัญของการโต้ตอบบางอย่างของผู้ใช้เพื่อให้แน่ใจว่าพวกเขาได้รับการจัดการอย่างทันท่วงที วิธีนี้จะปรับปรุงประสิทธิภาพอย่างมากในรายการ การนำทาง และการจัดการท่าทาง

โมดูลเทอร์โบ

ในการใช้งานก่อนหน้านี้ เราไม่มีการอ้างอิงถึงโมดูลเนทีฟ ดังนั้นทุกโมดูลจึงถูกโหลดเมื่อเริ่มต้น ซึ่งจะเพิ่ม TTI (เวลาในการโต้ตอบ) แต่ด้วยโมดูลเทอร์โบ เราสามารถโหลดโมดูลแบบสันหลังยาวได้ตามต้องการและเมื่อจำเป็น ซึ่งจะช่วยได้ ในการปรับปรุงเวลาเริ่มต้น ตัวอย่างเช่น: หากคุณมีโมดูลสำหรับพิมพ์เอกสารจากลิงก์ ตอนนี้เราสามารถโหลดโมดูลนี้เมื่อเราเข้าสู่หน้าจอการพิมพ์ ไม่ใช่เมื่อเริ่มต้นแอปพลิเคชันซึ่งดำเนินการในสถาปัตยกรรมก่อนหน้านี้ ความสามารถในการเขียนโมดูลใน C++ ยังเพิ่มความได้เปรียบเนื่องจากช่วยลดการใช้งานที่ซ้ำกันในแพลตฟอร์มต่างๆ

โค้ดเจน

ในการรวมสิ่งนี้เข้าด้วยกันและทำให้ทั้งสองอาณาจักรเข้ากันได้ ทีมงาน React Native ได้สร้างตัวตรวจสอบประเภทเพื่อทำให้ความเข้ากันได้ระหว่าง JS และฝั่ง Native เป็นไปโดยอัตโนมัติ เครื่องมือนี้เรียกว่าCodegen มันใช้วิธีการแบบโมดูลาร์ ซึ่งหมายความว่าภาษา Javascript ที่พิมพ์แบบสแตติกใดๆ สามารถรองรับได้โดยใช้ตัวแยกวิเคราะห์สำหรับระบบนั้น ด้วยการใช้ JavaScript ที่พิมพ์เป็นแหล่งที่มาของความจริง ตัวสร้างนี้สามารถกำหนดไฟล์อินเทอร์เฟซที่ Fabric และ TurboModules ต้องการเพื่อส่งข้อความข้ามอาณาจักรด้วยความมั่นใจ Codegen ยังให้ความปลอดภัยประเภทเวลาในการคอมไพล์ ซึ่งหมายความว่าทั้งสองสภาพแวดล้อมสามารถรันคำสั่งได้โดยไม่ต้องมีการตรวจสอบรันไทม์ ซึ่งหมายถึงขนาดโค้ดที่เล็กลงเพื่อจัดส่งและการดำเนินการที่เร็วขึ้น
เนื่องจากตอนนี้เรามีโค้ด C++ และ C++ นั้นพิมพ์ยาก เราจึงบังคับให้พิมพ์โค้ด JS เพราะเราต้องกำหนดประเภทและไม่สามารถเขียน ที่ ใดก็ได้ในโค้ด โดยพื้นฐานแล้วจะสร้างอินเทอร์เฟซสำหรับคุณและตอนนี้เนื่องจากสร้างขึ้นและอยู่ใน C ++ เราจึงสามารถเชื่อถือข้อมูลที่ถูกส่งโดยพื้นฐานแล้วและเราไม่ต้องตรวจสอบข้อมูลไปมา นอกจากนี้ยังหมายความว่าการใช้การตรวจสอบประเภททำให้เราสามารถระบุปัญหาได้อย่างง่ายดายในระหว่างขั้นตอนการพัฒนา ซึ่งอาจส่งผลให้เกิดข้อขัดข้องร้ายแรงหรือประสบการณ์ของผู้ใช้ที่ไม่ดี

ข้อได้เปรียบที่สำคัญบางประการของ JSI

1. โค้ด Javascript สามารถอ้างอิงถึงองค์ประกอบ Native UI และเรียกใช้เมธอดในนั้น (คล้ายกับการจัดการ DOM ในเว็บ)
2. การเชื่อมโยงที่รวดเร็วและโดยตรงกับโค้ดเนทีฟซึ่งสามารถปรับปรุงประสิทธิภาพได้อย่างมาก เช่นMMKVใช้ JSI ซึ่งเร็วกว่า Asyncstorage ประมาณ 30 เท่า
3. สามารถใช้เอ็นจิ้นอื่นที่ไม่ใช่ JavaScript Core ได้
4. สามารถโหลด Native Modules ได้เมื่อต้องการ
5. การตรวจสอบประเภทคงที่เพื่อให้ JS และ Native code เข้ากันได้

ปัจจุบัน React native JSI อยู่ในช่วงทดลองและเมื่อมีโครงการจำนวนมากขึ้นนำการเปลี่ยนแปลงนี้ไปใช้ เราจะได้ทราบข้อมูลเพิ่มเติมเกี่ยวกับข้อจำกัดและผลกระทบของสถาปัตยกรรมใหม่ แต่สิ่งหนึ่งที่แน่นอนคืออนาคตของการพัฒนาแอปพลิเคชันแบบเนทีฟแบบโต้ตอบและแบบข้ามแพลตฟอร์ม ดูน่าตื่นเต้น