مشاوره برای فروشندگان میان افزار

توزیع میان‌افزار ساخته شده با 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 هنگام پیوند. این کمتر قوی است زیرا فقط نمادهای موجود در کتابخانه هایی را که صریحاً نامگذاری شده اند مخفی می کند و هیچ تشخیصی برای کتابخانه هایی که مورد استفاده قرار نمی گیرند گزارش نمی شود (یک تایپ در نام کتابخانه خطایی نیست و بار کاربر برای کاربر است لیست کتابخانه را به روز نگه دارید). این رویکرد همچنین جزئیات اجرای خود را پنهان نمی کند.

توزیع کتابخانه های بومی در AARs

The Android Gradle plugin can import native dependencies distributed in AARs . If your users are using the Android Gradle plugin, this will be the easiest way for them to consume your library.

Native libraries can be packaged into an AAR by AGP . This will be the easiest option if your library is already built by externalNativeBuild .

ساختهای غیر AGP می توانند از NDKports استفاده کنند ، یا بسته بندی های دستی را با پیروی از مستندات prefab انجام دهند تا prefab/ subdirectory AAR خود را ایجاد کنند.

میان افزار جاوا با کتابخانه های JNI

کتابخانه های جاوا که شامل کتابخانه های JNI (به عبارت دیگر ، AAR هایی که حاوی jniLibs هستند) باید مراقب باشند که کتابخانه های JNI که شامل می شوند با سایر کتابخانه های برنامه کاربر برخورد نمی کنند. به عنوان مثال ، اگر AAR شامل libc++_shared.so libc++_shared.so به اشتراک گذاشته شود.

The most reliable solution is for Java libraries to include no more than one JNI library (this is good advice for apps too). کلیه وابستگی ها از جمله STL باید به صورت آماری به کتابخانه اجرای پیوند داده شود و از یک اسکریپت نسخه برای اجرای سطح ABI استفاده شود. For example, a Java library com.example.foo that includes the JNI library libfooimpl.so should use the following version script:

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

این مثال از registerNatives از طریق JNI_OnLoad استفاده می کند ، همانطور که در نکات JNI توضیح داده شده است تا اطمینان حاصل شود که حداقل سطح ABI در معرض دید قرار گرفته و زمان بارگذاری کتابخانه به حداقل می رسد.