คำแนะนำสำหรับผู้ให้บริการมิดเดิลแวร์

การเผยแพร่มิดเดิลแวร์ที่สร้างขึ้นด้วย NDK จะทำให้เกิดปัญหาเพิ่มเติมบางอย่างที่นักพัฒนาแอปไม่จําเป็นต้องกังวล ไลบรารีที่สร้างไว้ล่วงหน้าจะกำหนดตัวเลือกการติดตั้งใช้งานบางอย่างให้กับผู้ใช้

การเลือกระดับ API และเวอร์ชัน NDK

ผู้ใช้จะใช้ minSdkVersion ที่ต่ำกว่าของคุณไม่ได้ หากแอปของผู้ใช้ต้องทำงานบน API 21 คุณจะสร้างสำหรับ API 24 ไม่ได้ เราสามารถสร้าง ไลบรารีสำหรับระดับ API ต่ำกว่าผู้ใช้ คุณสามารถสร้างแอปสําหรับ API 16 และยังคงใช้งานร่วมกับผู้ใช้ API 21 ได้

เวอร์ชัน NDK ส่วนใหญ่เข้ากันได้ แต่บางครั้งก็อาจมีการเปลี่ยนแปลงที่ทำให้ใช้งานร่วมกันไม่ได้ หากคุณทราบว่าผู้ใช้ทั้งหมดของคุณกำลังใช้ NDK เวอร์ชันเดียวกัน จะดีที่สุดที่จะใช้เวอร์ชันเดียวกับที่พวกเขามี หรือไม่เช่นนั้น ให้ใช้เวอร์ชันล่าสุด

การใช้ STL

หากคุณเขียน C++ และใช้ STL คุณต้องเลือก libc++_shared กับ libc++_static จะมีผลกับผู้ใช้หากคุณเผยแพร่ไลบรารีที่ใช้ร่วมกัน หากคุณเผยแพร่ไลบรารีที่ใช้ร่วมกัน คุณต้องเลือกใช้ libc++_shared หรือตรวจสอบว่าไลบรารีของคุณไม่ได้เปิดเผยสัญลักษณ์ของ libc++ วิธีที่ดีที่สุดคือประกาศแพลตฟอร์ม ABI อย่างชัดเจนด้วยสคริปต์เวอร์ชัน

อีกตัวเลือกหนึ่งที่มีประสิทธิภาพน้อยกว่าคือการใช้ -Wl,--exclude-libs,libc++_static.a -Wl,--exclude-libs,libc++abi.a เมื่อลิงก์ วิธีนี้มีประสิทธิภาพน้อยกว่าเนื่องจาก จะซ่อนเฉพาะสัญลักษณ์ในไลบรารีที่มีชื่อชัดเจน มีการรายงานการวินิจฉัยสำหรับไลบรารีที่ไม่มีการใช้งาน (มีการพิมพ์ผิดในไลบรารี name ไม่ถือว่าเป็นข้อผิดพลาด และผู้ใช้ต้องรับภาระในการเก็บรักษารายการไลบรารีต่อไป ปัจจุบัน) และวิธีการนี้ก็ไม่ได้ซ่อนรายละเอียดการใช้งานของคุณเองเช่นกัน

การเผยแพร่ไลบรารีเนทีฟใน AAR

ปลั๊กอิน Android Gradle สามารถนําเข้าทรัพยากร Dependency เนทีฟที่เผยแพร่ใน AAR หากผู้ใช้ใช้ปลั๊กอิน Android Gradle ปลั๊กอินนี้จะเป็น วิธีที่ง่ายที่สุดที่จะช่วยให้ผู้ชม ดูวิดีโอจากคลังของคุณได้

คุณสามารถแพ็กเกจไลบรารีแบบเนทีฟเป็น AAR โดย AGP นี่จะเป็น ตัวเลือกที่ง่ายที่สุดหากไลบรารีของคุณสร้างขึ้นโดย externalNativeBuild อยู่แล้ว

บิลด์ที่ไม่ใช่ AGP สามารถใช้ ndkports หรือทำการแพ็กเกจด้วยตนเองโดยทำตามเอกสารประกอบของ Prefab เพื่อสร้างไดเรกทอรีย่อย prefab/ ของ AAR

มิดเดิลแวร์ Java ที่มีไลบรารี JNI

ไลบรารี Java ที่มีไลบรารี JNI (หรือที่เรียกว่า AAR ที่มี jniLibs) ต้องระมัดระวังว่าไลบรารี JNI ที่รวมไว้จะไม่ทับซ้อนกับไลบรารีอื่นๆ ในแอปของผู้ใช้ เช่น หาก AAR มี libc++_shared.so แต่ libc++_shared.so นั้นเป็นเวอร์ชันอื่นที่แตกต่างจากที่แอปใช้ ระบบจะติดตั้ง libc++_shared.so เพียงเวอร์ชันเดียวลงใน APK และอาจทําให้แอปทํางานอย่างไม่เสถียร

โซลูชันที่เชื่อถือได้มากที่สุดคือให้ไลบรารี Java ใส่ไว้ไม่เกิน 1 ประเภท ไลบรารี JNI (เป็นคำแนะนำที่ดีสำหรับแอปด้วย) ไลบรารี Dependency ทั้งหมด รวมถึง STL ควรลิงก์แบบคงที่กับไลบรารีการใช้งาน และควรใช้สคริปต์เวอร์ชันเพื่อบังคับใช้แพลตฟอร์ม ABI ตัวอย่างเช่น ไลบรารี Java com.example.foo ที่มีไลบรารี JNI libfooimpl.so ควรใช้สคริปต์เวอร์ชันต่อไปนี้

LIBFOOIMPL {
global:
    JNI_OnLoad;
local:
    *;
};

ตัวอย่างนี้ใช้ registerNatives ผ่าน JNI_OnLoad ตามที่อธิบายไว้ในเคล็ดลับ JNI เพื่อให้แน่ใจว่ามีการแสดง ABI ขั้นต่ำและเวลาในการโหลดไลบรารีจะลดลง