نصائح لمورّدي البرمجيات الوسيطة

يؤدي توزيع البرامج الوسيطة التي تم إنشاؤها باستخدام حزمة NDK إلى ظهور بعض المشاكل الإضافية التي لا داعي للقلق بشأنها من قِبل مطوّري التطبيقات. تفرض المكتبات المُنشأة مسبقًا بعضًا من خيارات التنفيذ على المستخدمين.

اختيار مستويات واجهة برمجة التطبيقات وإصدارات NDK

لا يمكن للمستخدمين استخدام إصدار minSdkVersion أقل من إصدارك. إذا كانت تجربة المستخدمين تطبيقات قيد التشغيل على واجهة برمجة التطبيقات 21، ولا يمكنك إنشاؤها لواجهة برمجة التطبيقات 24. لا بأس بإنشاء مكتبتك لمستوى واجهة برمجة تطبيقات أدنى من مستوى المستخدمين. يمكنك إنشاء واجهة برمجة تطبيقات 16 والحفاظ على التوافق مع مستخدمي واجهة برمجة التطبيقات 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 عند الربط. وهذا الإجراء أقل فعالية لأنّه لن يخفي سوى الرموز في المكتبات التي تم تسميتها صراحةً، ولن يتم تسجيل أي تشخيصات للمكتبات غير المستخدَمة (إنّ الخطأ الإملائي في اسم المكتبة ليس خطأً، ويقع على عاتق المستخدم مسؤولية إبقاء قائمة المكتبات محدّثة). ولا يخفي هذا النهج أيضًا تفاصيل التنفيذ الخاصة بك.

توزيع المكتبات الأصلية في AAR

يمكن للمكوّن الإضافي لنظام Gradle المتوافق مع Android استيراد الملحقات الأصلية الموزّعة في حِزم AAR. إذا كان المستخدمون يستخدمون المكوّن الإضافي لنظام Gradle المتوافق مع Android، سيكون هذا هو أسهل طريقة لهم للاطّلاع على مكتبتك.

يمكن حزم المكتبات الأصلية في ملفات AAR من خلال AGP. سيكون هذا الخيار الأسهل إذا كان قد تم إنشاء مكتبتك باستخدام externalNativeBuild.

يمكن للإصدارات التي لا تستخدم AGP استخدام ndkports أو تنفيذ حزمة يدويًا من خلال اتّباع وثائق Prefab لإنشاء الدليل الفرعي prefab/ في AAR.

برنامج Java الوسيط مع مكتبات JNI

مكتبات Java التي تتضمن مكتبات JNI (بمعنى آخر، ملفات AAR التي تحتوي على jniLibs) إلى توخي الحذر من عدم تضمين مكتبات JNI التي تتضمنها تتداخل مع المكتبات الأخرى في تطبيق المستخدم. على سبيل المثال، إذا كانت ميزة "التطبيق التلقائي للاقتراحات" تتضمّن libc++_shared.so، ولكن إصدار libc++_shared.so مختلف عن التطبيق سيتم تثبيت تطبيق واحد فقط على حزمة APK، ما قد يؤدي إلى مخاطر السلوك.

إنّ الحل الأكثر موثوقية هو أن تتضمّن مكتبات Java مكتبة واحدة فقط من مكتبات JNI (هذه نصيحة جيدة للتطبيقات أيضًا). تُعد جميع التبعيات بما في ذلك يجب ربط STL بشكلٍ ثابت بمكتبة التنفيذ، النص البرمجي لفرض واجهة ABI. على سبيل المثال، يجب أن تستخدم مكتبة Java com.example.foo التي تتضمّن مكتبة JNIlibfooimpl.so ملف برمجة النص البرمجي التالي للإصدار:

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

يستخدم هذا المثال registerNatives من خلال JNI_OnLoad كما هو موضّح في نصائح JNI لضمان عرض الحد الأدنى من مساحة ABI والحد الأدنى من وقت تحميل المكتبة .