মিডলওয়্যার বিক্রেতাদের জন্য পরামর্শ

এনডিকে দিয়ে তৈরি মিডলওয়্যার বিতরণ করা কিছু অতিরিক্ত সমস্যা উত্থাপন করে যা অ্যাপ বিকাশকারীদের চিন্তা করার দরকার নেই। পূর্ব-নির্মিত লাইব্রেরিগুলি তাদের ব্যবহারকারীদের উপর তাদের কিছু বাস্তবায়ন পছন্দ চাপিয়ে দেয়।

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 ব্যবহার করা। এটি কম মজবুত কারণ এটি শুধুমাত্র লাইব্রেরির চিহ্নগুলিকে লুকিয়ে রাখবে যেগুলি স্পষ্টভাবে নামকরণ করা হয়েছে, এবং যে লাইব্রেরিগুলি ব্যবহার করা হয় না সেগুলির জন্য কোনও ডায়াগনস্টিক রিপোর্ট করা হয় না (লাইব্রেরির নামের একটি টাইপো ত্রুটি নয়, এবং এর বোঝা ব্যবহারকারীর উপর বর্তায় লাইব্রেরির তালিকা আপ টু ডেট রাখুন)। এই পদ্ধতিটি আপনার নিজস্ব বাস্তবায়নের বিশদটিও গোপন করে না।

AAR-এ নেটিভ লাইব্রেরি বিতরণ করা

দ্রষ্টব্য: এই বিভাগটি বর্ণনা করে কিভাবে ব্যবহারকারীদের কাছে C/C++ API বিতরণ করতে হয়। যদি আপনার নেটিভ লাইব্রেরিগুলি আপনার Java API-এর বাস্তবায়নের বিবরণ হয়, JNI লাইব্রেরিগুলির সাথে Java মিডলওয়্যার বিভাগটি দেখুন।

অ্যান্ড্রয়েড গ্রেডল প্লাগইন AAR- এ বিতরণ করা নেটিভ নির্ভরতা আমদানি করতে পারে। যদি আপনার ব্যবহারকারীরা অ্যান্ড্রয়েড গ্রেডল প্লাগইন ব্যবহার করে থাকেন, তাহলে এটিই হবে তাদের জন্য আপনার লাইব্রেরি ব্যবহার করার সবচেয়ে সহজ উপায়।

এজিপি দ্বারা নেটিভ লাইব্রেরিগুলিকে একটি AAR-তে প্যাকেজ করা যেতে পারে। আপনার লাইব্রেরি যদি ইতিমধ্যেই externalNativeBuild দ্বারা নির্মিত হয় তবে এটি হবে সবচেয়ে সহজ বিকল্প।

নন-এজিপি বিল্ডগুলি ndkports ব্যবহার করতে পারে, অথবা তাদের AAR-এর prefab/ সাবডিরেক্টরি তৈরি করতে প্রিফ্যাব ডকুমেন্টেশন অনুসরণ করে ম্যানুয়াল প্যাকেজিং করতে পারে।

JNI লাইব্রেরি সহ জাভা মিডলওয়্যার

জাভা লাইব্রেরিগুলি যেগুলি JNI লাইব্রেরিগুলিকে অন্তর্ভুক্ত করে (অন্য কথায়, AARগুলি যাতে jniLibs থাকে) সতর্কতা অবলম্বন করা উচিত যে তারা যে JNI লাইব্রেরিগুলি অন্তর্ভুক্ত করে সেগুলি ব্যবহারকারীর অ্যাপের অন্যান্য লাইব্রেরির সাথে সংঘর্ষে লিপ্ত না হয়৷ উদাহরণস্বরূপ, যদি AAR-এ libc++_shared.so অন্তর্ভুক্ত থাকে, কিন্তু অ্যাপ ব্যবহার করে libc++_shared.so এর একটি ভিন্ন সংস্করণ, শুধুমাত্র একটি APK এ ইনস্টল করা হবে এবং এটি অবিশ্বস্ত আচরণের দিকে নিয়ে যেতে পারে।

সতর্কতা: বাগ 141758241 : অ্যান্ড্রয়েড গ্রেডল প্লাগইনের পুরানো সংস্করণগুলি বর্তমানে এই ত্রুটির অবস্থা নির্ণয় করে না৷ অভিন্নভাবে নামের একটি লাইব্রেরি APK-এ প্যাকেজিংয়ের জন্য নির্বিচারে বেছে নেওয়া হবে।

জাভা লাইব্রেরির জন্য সবচেয়ে নির্ভরযোগ্য সমাধান হল একের বেশি JNI লাইব্রেরি অন্তর্ভুক্ত না করা (এটি অ্যাপগুলির জন্যও ভাল পরামর্শ)। STL সহ সমস্ত নির্ভরতা স্থিরভাবে বাস্তবায়ন লাইব্রেরির সাথে সংযুক্ত করা উচিত এবং ABI পৃষ্ঠকে প্রয়োগ করতে একটি সংস্করণ স্ক্রিপ্ট ব্যবহার করা উচিত। উদাহরণস্বরূপ, একটি জাভা লাইব্রেরি com.example.foo যাতে JNI লাইব্রেরি libfooimpl.so নিম্নলিখিত সংস্করণ স্ক্রিপ্ট ব্যবহার করা উচিত:

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

এই উদাহরণটি JNI টিপসে বর্ণিত হিসাবে JNI_OnLoad মাধ্যমে registerNatives ব্যবহার করে যাতে ন্যূনতম ABI সারফেস উন্মুক্ত হয় এবং লাইব্রেরি লোডের সময় কম হয়।