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

การแจกจ่ายมิดเดิลแวร์ที่สร้างด้วย 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 อย่างชัดเจนด้วยสคริปต์เวอร์ชัน (ซึ่งยังช่วยให้ใช้งาน รายละเอียดการติดตั้งใช้งานของคุณเป็นแบบส่วนตัว) ตัวอย่างเช่น ไลบรารีเลขคณิตง่ายๆ อาจมีสคริปต์เวอร์ชันต่อไปนี้

LIBMYMATH {
global:
    add;
    sub;
    mul;
    div;
    # C++ symbols in an extern block will be mangled automatically. See
    # https://stackoverflow.com/a/21845178/632035 for more examples.
    extern "C++" {
        "pow(int, int)";
    }
local:
    *;
};

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

อีกตัวเลือกหนึ่งที่มีประสิทธิภาพน้อยกว่าคือการใช้ -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 เวอร์ชันต่างจากแอป แต่จะมีการติดตั้งเพียงไฟล์เดียวใน APK และอาจทำให้เกิดความไม่น่าเชื่อถือ พฤติกรรมของคุณ

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

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

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