ART কনফিগার করা

এই পৃষ্ঠায় Android রানটাইম (ART) ও এর কম্পাইলেশন বিকল্প কীভাবে কনফিগার করতে হয় তা আলোচনা করা হয়েছে। এখানে যেসব বিষয় নিয়ে আলোচনা করা হয়েছে তার মধ্যে রয়েছে সিস্টেম ইমেজের প্রি-কম্পাইলেশন কনফিগারেশন, dex2oat কম্পাইলেশন বিকল্প এবং সিস্টেম পার্টিশন স্পেস, ডেটা পার্টিশন স্পেস ও পারফর্ম্যান্সের মধ্যে কীভাবে ট্রেড-অফ করা যায়।

ART-এর সাথে কাজ করতে ART ও Dalvik এবং Dalvik এক্সিকিউটেবল ফর্ম্যাট দেখুন। আপনার অ্যাপ যাতে ঠিকমতো কাজ করে তা নিশ্চিত করতে, Android Runtime (ART)-এ অ্যাপের আচরণ যাচাই করা দেখুন।

ART কীভাবে কাজ করে

ART আগে-থেকে (AOT) কম্পাইলেশন ব্যবহার করে এবং Android 7 থেকে শুরু করে, এটি AOT কম্পাইলেশন, জাস্ট-ইন-টাইম (JIT) কম্পাইলেশন এবং ইন্টারপ্রিটেশনের একটি হাইব্রিড কম্বিনেশন ব্যবহার করে, এবং AOT কম্পাইলেশন প্রোফাইল-গাইডেড হতে পারে। এইসব এক্সিকিউশন মোডের কম্বিনেশন কনফিগার করা যায় এবং এই বিভাগে তা নিয়ে আলোচনা করা হবে। উদাহরণস্বরূপ, Pixel ডিভাইসগুলি নিম্নলিখিত ফ্লোতে কাজ করার জন্য কনফিগার করা হয়েছে:

  1. কোনও অ্যাপ্লিকেশন প্রাথমিকভাবে Play Store-এর (.dm) মাধ্যমে ডিস্ট্রিবিউট করা dex মেটাডেটা ফাইল দিয়ে ইনস্টল করা হয়, যার মধ্যে ক্লাউড প্রোফাইল থাকে। ART, ক্লাউডে তালিকাভুক্ত পদ্ধতিগুলি AOT-কম্পাইল করে প্রোফাইল করে। অথবা, dex মেটাডেটা ফাইল ছাড়াই অ্যাপ্লিকেশন ইনস্টল করা হলে, কোনও AOT কম্পাইলেশন করা হয় না।
  2. প্রথম কয়েকবার অ্যাপ্লিকেশন রান করার সময়, AOT-কম্পাইল করা হয়নি এমন পদ্ধতি ব্যাখ্যা করা হয়। ইন্টারপ্রেট করা পদ্ধতির মধ্যে যেগুলি ঘন ঘন এক্সিকিউট করা হয়, সেগুলি JIT-কম্পাইল করা হয়। ART এক্সিকিউশনের উপর ভিত্তি করে একটি লোকাল প্রোফাইল তৈরি করে এবং এটি ক্লাউড প্রোফাইলের সাথে একত্রিত করে (যদি কোনও থাকে)।
  3. ডিভাইসটি অলস অবস্থায় থাকলে এবং চার্জ করা হলে, প্রথম কয়েকবার চালানোর সময় তৈরি হওয়া সম্মিলিত প্রোফাইলের উপর ভিত্তি করে অ্যাপ্লিকেশন আবার কম্পাইল করার জন্য একটি কম্পাইলেশন ডেমন রান করে।
  4. অ্যাপ্লিকেশন পরবর্তীকালে রান করার সময়, ART কম্পাইলেশন ডিমনের মাধ্যমে জেনারেট করা আর্টিফ্যাক্ট ব্যবহার করে, যার মধ্যে AOT-কম্পাইল করা কোড বেশি থাকে। এগুলি সেইসব কোডের তুলনায় বেশি থাকে যেগুলি প্রথমবার রান করার সময় জেনারেট করা হয়েছিল। যেসব মেথড AOT-কম্পাইল করা হয় না সেগুলি এখনও ইন্টারপ্রেট করা হয় বা JIT-কম্পাইল করা হয়। ART, এক্সিকিউশনের উপর ভিত্তি করে প্রোফাইল ইনস্টলেশন আপডেট করে এবং তারপরে কম্পাইলেশন ডেমনের পরবর্তী রানগুলি প্রোফাইল পিক-আপ করবে।

ART-এ একটি কম্পাইলার (dex2oat টুল) এবং রানটাইম (libart.so) থাকে যা বুট করার সময় লোড হয়। dex2oat টুলটি একটি APK ফাইল নেয় এবং এক বা একাধিক কম্পাইলেশন আর্টিফ্যাক্ট ফাইল তৈরি করে যা রানটাইম লোড করে। রিলিজ জুড়ে ফাইলের সংখ্যা, তাদের এক্সটেনশন এবং নাম পরিবর্তন হতে পারে, তবে Android 8 রিলিজ অনুযায়ী, এই ফাইলগুলি তৈরি করা হয়:

  • .vdex: যাচাইকরণ দ্রুত করার জন্য কিছু অতিরিক্ত মেটাডেটা থাকে, কখনও কখনও APK-এর আনকমপ্রেসড DEX কোডের সাথে।
  • .odex: APK-এর মধ্যে থাকা পদ্ধতির জন্য AOT-কম্পাইল করা কোড আছে।
  • .art (optional)-এ APK-তে তালিকাভুক্ত কিছু স্ট্রিং ও ক্লাসের ART ইন্টার্নাল রিপ্রেজেন্টেশন থাকে, যা অ্যাপ স্টার্টআপের গতি বাড়াতে ব্যবহার করা হয়।

কম্পাইলেশন বিকল্প

ART-এর জন্য কম্পাইলেশন বিকল্পের দুটি বিভাগ আছে:

  1. সিস্টেম ROM কনফিগারেশন: সিস্টেম ইমেজ তৈরি করার সময় কোন কোড AOT কম্পাইল করা হয়।
  2. রানটাইম কনফিগারেশন: ART কীভাবে কোনও ডিভাইসে অ্যাপ কম্পাইল ও রান করে।

কম্পাইলার ফিল্টার

এই দুটি বিভাগ কনফিগার করার একটি মূল ART বিকল্প হল compiler filters। কম্পাইলার ফিল্টার থেকে বোঝা যায় যে ART কীভাবে DEX কোড কম্পাইল করে এবং এটি dex2oat টুলে পাস করা একটি বিকল্প। Android 8 থেকে শুরু করে, অফিসিয়ালি কাজ করে এমন চারটি ফিল্টার আছে:

  • verify: শুধুমাত্র DEX কোড যাচাইকরণ রান করে (কোনও AOT কম্পাইলেশন নেই)।
  • quicken: (Android 11 বা এর আগের যেকোনও ভার্সন) DEX কোড রান করে এবং আরও ভালো ইন্টারপ্রেটর পারফর্ম্যান্স পেতে কিছু DEX নির্দেশাবলী যাচাই করে অপ্টিমাইজ করে।
  • speed: DEX কোড যাচাইকরণ রান করে এবং সব পদ্ধতি AOT-কম্পাইল করে। কোনও ক্লাসের জন্য ক্লাস লোডিং অপ্টিমাইজ করে না।
  • speed-profile: প্রোফাইলে তালিকাভুক্ত পদ্ধতিগুলির DEX কোড যাচাইকরণ, AOT-কম্পাইল পদ্ধতি রান করে এবং প্রোফাইলে থাকা ক্লাসের জন্য ক্লাস লোড অপ্টিমাইজ করে।

সিস্টেম ROM কনফিগারেশন

সিস্টেম ইমেজ তৈরি করার সময় আগে থেকে ইনস্টল করা লাইব্রেরি ও অ্যাপ AOT-কম্পাইল করা হয়। এই প্রক্রিয়াকে dexpreopt বলা হয়। এই ধরনের কম্পাইল করা ফাইল ততক্ষণ পর্যন্ত ব্যবহারযোগ্য থাকে যতক্ষণ না পর্যন্ত সমস্ত ডিপেন্ডেন্সি অপরিবর্তিত থাকে, বিশেষ করে বুট ক্ল্যাসপাথ।

মনে রাখবেন: ডিভাইসটি সিস্টেম মডিউল আপডেট নিলে, বুট ক্লাসপাথ পরবর্তী আপডেটে পরিবর্তন হওয়ার সম্ভাবনা খুব বেশি থাকে, এর ফলে সব dexpreopt ফাইল পুরনো ও ব্যবহারযোগ্য থাকে না।

dexpreopt কনফিগার করার জন্য অনেক ART বিল্ড বিকল্প উপলভ্য আছে। আপনি কীভাবে এই বিকল্পগুলি কনফিগার করবেন তা সিস্টেম ইমেজের জন্য উপলভ্য স্টোরেজ স্পেস এবং আগে থেকে ইনস্টল করা অ্যাপ্লিকেশনগুলির সংখ্যার উপর নির্ভর করে। সিস্টেম ROM-এ কম্পাইল করা JAR/APK-কে চারটি বিভাগে ভাগ করা যায়:

  • বুট ক্লাসপাথ কোড: ডিফল্ট হিসেবে speed-profile কম্পাইলার ফিল্টারের সাথে কম্পাইল করা হয়েছে।
  • সিস্টেম সার্ভার কোড (এই ডকুমেন্টের পরে PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS দেখুন):
    • (Android 14 এবং তার পরবর্তী ভার্সন) ডিফল্ট হিসেবে speed-profile কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়েছে অথবা প্রোফাইল প্রদান করা না হলে speed কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়েছে।
    • (Android 13 ও এর আগের যেকোনও ভার্সন) ডিফল্ট হিসেবে speed কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়েছে।
    PRODUCT_SYSTEM_SERVER_COMPILER_FILTER-এর মাধ্যমে কনফিগার করা যায় (এই ডকুমেন্টের পরবর্তী অংশে দেখুন)।
  • প্রোডাক্ট-নির্দিষ্ট মূল অ্যাপ (এই ডকুমেন্টে PRODUCT_DEXPREOPT_SPEED_APPS পরে দেখুন): ডিফল্ট হিসেবে speed কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়।
  • অন্যান্য সব অ্যাপ: ডিফল্ট হিসেবে speed-profile কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়, অথবা প্রোফাইল প্রদান করা না থাকলে verify কম্পাইলার ফিল্টার দিয়ে কম্পাইল করা হয়।

    PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER-এর মাধ্যমে কনফিগার করা যায় (এই ডকুমেন্টে পরে দেখুন)।

Makefile সংক্রান্ত বিকল্প

  • WITH_DEXPREOPT

    • সিস্টেম ইমেজে ইনস্টল করা DEX কোডে dex2oat ইনভোক করা হয়েছে কিনা। ডিফল্ট হিসেবে চালু করা থাকে।

  • DONT_DEXPREOPT_PREBUILTS (Android 5 ও তার পরের যেকোনও ভার্সন)

    • DONT_DEXPREOPT_PREBUILTS চালু করলে, প্রি-বিল্টকে dexpreopt করা যাবে না। এইসব অ্যাপের Android.mk-এ include $(BUILD_PREBUILT) নির্দিষ্ট করা আছে। Google Play-এর মাধ্যমে আপডেট করা হতে পারে এমন প্রি-বিল্ট অ্যাপের dexpreopt এড়িয়ে গেলে সিস্টেম ইমেজে জায়গা বাঁচে, তবে প্রথমবার বুট করার সময় বেশি লাগে। মনে রাখবেন, এই বিকল্পটি Android.bp-এ সংজ্ঞায়িত প্রি-বিল্ট অ্যাপের উপর কোনও প্রভাব ফেলে না।

  • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android 9 এবং এর পরের যেকোনও ভার্সন)

    • PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER dexpreopted অ্যাপ্লিকেশনের জন্য ডিফল্ট কম্পাইলার ফিল্টার নির্দিষ্ট করে। এইসব অ্যাপ Android.bp-এ সংজ্ঞায়িত করা আছে অথবা সেগুলির Android.mk-এ include $(BUILD_PREBUILT) নির্দিষ্ট করা আছে। উল্লেখ করা না থাকলে, ডিফল্ট মান হল speed-profile অথবা মান উল্লেখ করা না থাকলে verify এবং কোনও প্রোফাইল প্রদান করা না থাকলে।

  • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (Android 8 MR1 থেকে)

    • WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts চালু করলে শুধুমাত্র বুট ক্লাসপাথ ও সিস্টেম সার্ভার জার ফাইলগুলি অপ্টিমাইজ করা হয়।

  • LOCAL_DEX_PREOPT

    • এছাড়াও, মডিউল ডেফিনিশনে LOCAL_DEX_PREOPT বিকল্প নির্দিষ্ট করে আলাদা আলাদা অ্যাপের জন্য Dexpreopt চালু বা বন্ধ করা যেতে পারে। যেসব অ্যাপ অবিলম্বে Google Play আপডেট পেতে পারে সেগুলির dexpreopt বন্ধ করার জন্য এটি কার্যকর হতে পারে, কারণ আপডেটগুলি সিস্টেম ইমেজে dexpreopt করা কোডকে অপ্রচলিত করে দেবে। এছাড়াও, এটি মেজর ভার্সন আপগ্রেড OTA-তে স্পেস সেভ করার জন্য উপযোগী কারণ ব্যবহারকারীদের কাছে ইতিমধ্যেই ডেটা পার্টিশনে অ্যাপের নতুন ভার্সন থাকতে পারে।

    LOCAL_DEX_PREOPT-এ true বা false ভ্যালু কাজ করে, যা যথাক্রমে dexpreopt চালু বা বন্ধ করে। এছাড়াও, dexpreopt যদি APK বা JAR ফাইল থেকে classes.dex ফাইলটি সরিয়ে না দেয়, তাহলে nostripping নির্দিষ্ট করা যেতে পারে। সাধারণত, dexpreopt-এর পরে এই ফাইলের আর প্রয়োজন হয় না বলে এটি সরিয়ে দেওয়া হয়, তবে থার্ড-পার্টি APK-এর সিগনেচার বৈধ রাখার জন্য এই শেষ বিকল্পটি প্রয়োজন।

  • PRODUCT_DEX_PREOPT_BOOT_FLAGS

    • dex2oat-এ বিকল্প পাস করে, বুট ইমেজ কীভাবে কম্পাইল করা হবে তা নিয়ন্ত্রণ করে। এটি কাস্টমাইজ করা ইমেজ ক্লাস তালিকা, কম্পাইল করা ক্লাস তালিকা এবং কম্পাইলার ফিল্টার নির্দিষ্ট করতে ব্যবহার করা যেতে পারে।

  • PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

    • বুট ইমেজ ছাড়া বাকি সব কিছু কীভাবে কম্পাইল করা হবে তা নিয়ন্ত্রণ করতে dex2oat বিকল্প পাস করে।

  • PRODUCT_DEX_PREOPT_MODULE_CONFIGS

    • নির্দিষ্ট মডিউল ও প্রোডাক্ট কনফিগারেশনের জন্য dex2oat বিকল্প পাস করার সুবিধা দেয়। এটি প্রোডাক্টের device.mk ফাইলে $(call add-product-dex-preopt-module-config,<modules>,<option>) দ্বারা সেট করা হয় যেখানে <modules> হল LOCAL_MODULE-এর তালিকা এবং LOCAL_PACKAGE হল JAR ও APK ফাইলের নাম।

  • PRODUCT_DEXPREOPT_SPEED_APPS (Android 8 থেকে)

    • প্রোডাক্টের জন্য মূল হিসেবে শনাক্ত করা হয়েছে এমন অ্যাপের তালিকা এবং যেগুলি speed কম্পাইলার ফিল্টারের সাথে কম্পাইল করার জন্য উপযুক্ত। যেমন, SystemUI-এর মতো পারসিস্টেন্ট অ্যাপ শুধুমাত্র পরবর্তী রিবুটের সময় প্রোফাইল-গাইডেড কম্পাইলেশন ব্যবহার করার সুযোগ পায়, তাই প্রোডাক্টের জন্য এইসব অ্যাপ সবসময় AOT-কম্পাইল করা থাকলে ভালো হয়।

  • PRODUCT_SYSTEM_SERVER_APPS (Android 8 থেকে)

    • সিস্টেম সার্ভার দ্বারা লোড করা অ্যাপের তালিকা। এইসব অ্যাপ ডিফল্ট হিসেবে speed কম্পাইলার ফিল্টারের মাধ্যমে কম্পাইল করা হয়।

  • PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (Android 8 থেকে)

    • ডিভাইসে ART-এর একটি ডিবাগ ভার্সন অন্তর্ভুক্ত করা হবে কিনা। ডিফল্ট হিসেবে, এটি userdebug ও eng বিল্ডের জন্য চালু করা থাকে। true বা false বিকল্পটি স্পষ্টভাবে সেট করে এই আচরণকে ওভাররাইড করা যেতে পারে।

    ডিফল্ট হিসেবে, ডিভাইসটি নন-ডিবাগ ভার্সন (libart.so) ব্যবহার করে। সুইচ করতে, সিস্টেম প্রপার্টি persist.sys.dalvik.vm.lib.2-কে libartd.so-এ সেট করুন।

  • WITH_DEXPREOPT_PIC (Android 7 পর্যন্ত)

    • Android 5.1.0 থেকে Android 6.0.1 পর্যন্ত, পজিশন-ইনডিপেন্ডেন্ট কোড (PIC) চালু করতে WITH_DEXPREOPT_PIC নির্দিষ্ট করা যেতে পারে। এর ফলে, ছবি থেকে কম্পাইল করা কোডকে /system থেকে /data/dalvik-cache-এ সরাতে হয় না, ফলে ডেটা পার্টিশনে জায়গা বেঁচে যায়। তবে, রানটাইমের উপর সামান্য প্রভাব পড়ে কারণ এটি এমন একটি অপ্টিমাইজেশন বন্ধ করে দেয় যা পজিশন-নির্ভর কোডের সুবিধা নেয়। সাধারণত, /data এ জায়গা বাঁচাতে চাওয়া ডিভাইসগুলিকে PIC কম্পাইলেশন চালু করতে হবে।

    Android 7.0-এ, PIC কম্পাইলেশন ডিফল্ট হিসেবে চালু করা ছিল।

  • WITH_DEXPREOPT_BOOT_IMG_ONLY (Android 7 MR1 পর্যন্ত)

    • এই বিকল্পটি WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY দিয়ে প্রতিস্থাপন করা হয়েছে, এটি সিস্টেম সার্ভার JAR-কেও আগে থেকেই অপ্ট-ইন করে।

  • PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

    • এই বিকল্পটি সিস্টেম সার্ভারের জন্য কম্পাইলার ফিল্টার নির্দিষ্ট করে।

    • (Android 14 ও তার পরবর্তী যেকোনও ভার্সন) উল্লেখ করা না থাকলে, speed-profile কম্পাইলার ফিল্টার ব্যবহার করা হয় অথবা কোনও প্রোফাইল প্রদান করা না হলে speed কম্পাইলার ফিল্টার ব্যবহার করা হয়।
    • (Android 13 ও তার আগের যেকোনও ভার্সন) উল্লেখ করা না থাকলে, speed কম্পাইলার ফিল্টার ব্যবহার করা হয়।
    • speed হিসেবে সেট করা থাকলে, speed কম্পাইলার ফিল্টার ব্যবহার করা হয়।
    • speed-profile-এ সেট করা থাকলে, speed-profile কম্পাইলার ফিল্টার ব্যবহার করা হয়, অথবা কোনও প্রোফাইল প্রদান করা না থাকলে verify কম্পাইলার ফিল্টার ব্যবহার করা হয়।
    • verify হিসেবে সেট করা থাকলে, verify কম্পাইলার ফিল্টার ব্যবহার করা হয়।

  • PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

    • সিস্টেম সার্ভার দ্বারা লোড করা JAR-এর তালিকা নিচে দেওয়া হল। PRODUCT_SYSTEM_SERVER_COMPILER_FILTER-এর নির্দিষ্ট করা কম্পাইলার ফিল্টার দিয়ে JAR কম্পাইল করা হয়

    • (প্রয়োজনীয়) PRODUCT_SYSTEM_SERVER_JARS: প্ল্যাটফর্মে সিস্টেম সার্ভার ক্লাসপাথ JAR-এর তালিকা (অর্থাৎ, SYSTEMSERVERCLASSPATH-এর অংশ হিসেবে)। এই তালিকায় সিস্টেম সার্ভার ক্লাসপাথ JAR যোগ করা প্রয়োজন। তালিকায় সিস্টেম সার্ভার ক্লাসপাথ JAR যোগ করা না গেলে সেইসব JAR লোড করা যায় না।
    • (প্রয়োজনীয়) PRODUCT_APEX_SYSTEM_SERVER_JARS: APEX-এর সাথে ডেলিভার করা সিস্টেম সার্ভার ক্লাসপাথ JAR-এর তালিকা (অর্থাৎ, SYSTEMSERVERCLASSPATH-এর অংশ হিসেবে)। ফর্ম্যাট হল <apex name>:<jar name>। এই তালিকায় APEX সিস্টেম সার্ভার ক্লাসপাথ JAR যোগ করতে হবে। এই তালিকায় APEX সিস্টেম সার্ভার ক্লাসপাথ JAR যোগ করতে না পারলে সেইসব JAR লোড করা যাবে না।
    • (ঐচ্ছিক, Android 13 ও এর আগের যেকোনও ভার্সন) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: সিস্টেম সার্ভার লোড করে এমন JAR-এর তালিকা আলাদা ক্লাসলোডার ব্যবহার করে ডায়নামিক (এর মাধ্যমে SystemServiceManager.startServiceFromJar)। এই তালিকায় স্ট্যান্ডঅ্যালোন সিস্টেম সার্ভার JAR যোগ করার প্রয়োজন নেই তবে এটি খুবই সাজেস্ট করা হয় কারণ এটি JAR-কে কম্পাইল করে এবং তাই ভাল রানটাইম পারফর্ম্যান্স থাকে।
    • (প্রয়োজনীয়, Android 13 থেকে) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: APEX-এর সাথে ডেলিভার করা JAR-এর তালিকা যা সিস্টেম সার্ভার আলাদা ক্লাসলোডার (অর্থাৎ, SystemServiceManager.startServiceFromJar-এর মাধ্যমে অথবা <apex-system-service> হিসেবে ঘোষিত) ব্যবহার করে ডায়নামিকভাবে লোড করে। ফর্ম্যাট হল <apex name>:<jar name>। এই তালিকায় স্ট্যান্ডঅ্যালোন APEX সিস্টেম সার্ভার JAR যোগ করতে হবে। এই তালিকায় স্ট্যান্ডঅ্যালোন APEX সিস্টেম সার্ভার JAR যোগ করতে না পারলে, বুট করা যাবে না।

    বুট ক্লাসপাথ কনফিগারেশন

    প্রি-লোড করা ক্লাসের তালিকা হল এমন ক্লাসের তালিকা যা Zygote স্টার্টআপে শুরু করে। এর ফলে প্রতিটি অ্যাপকে আলাদাভাবে এই ক্লাস ইনিশিয়ালাইজার রান করতে হয় না। এর ফলে অ্যাপগুলি আরও দ্রুত চালু হতে পারে এবং মেমরিতে পৃষ্ঠা শেয়ার করতে পারে। প্রিলোড করা ক্লাস তালিকার ফাইলটি ডিফল্ট হিসেবে frameworks/base/config/preloaded-classes লোকেশন থাকে এবং এতে সাধারণ ফোন ব্যবহারের জন্য টিউন করা একটি তালিকা থাকে। এটি পরিধানযোগ্য ডিভাইস সহ অন্যান্য ডিভাইসের ক্ষেত্রে আলাদা হতে পারে এবং সেই অনুযায়ী টিউন করতে হবে। এটি টিউন করার সময় সতর্ক থাকুন; অনেক বেশি ক্লাস যোগ করলে অব্যবহৃত ক্লাস লোড হওয়ার সময় মেমরি নষ্ট হয়। খুব কম ক্লাস যোগ করলে, প্রতিটি অ্যাপকে নিজের কপি রাখতে হয়, যার ফলে মেমরি নষ্ট হয়।

    ব্যবহারের উদাহরণ (প্রোডাক্টের device.mk-এ):

    PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

    মনে রাখবেন: আপনাকে অবশ্যই এই লাইনটি build/target/product/base.mk থেকে ডিফল্টটি পাওয়া যেকোনও প্রোডাক্ট কনফিগারেশন মেকফাইল ইনহেরিট করার আগে প্লেস করতে হবে।

    রানটাইম কনফিগারেশন

    JIT বিকল্প

    নিচে উল্লেখ করা বিকল্পগুলি শুধুমাত্র সেইসব Android রিলিজকে প্রভাবিত করে যেখানে ART JIT কম্পাইলার উপলভ্য।

    • dalvik.vm.usejit: JIT চালু আছে কিনা।
    • dalvik.vm.jitinitialsize (ডিফল্ট ৬৪K): কোড ক্যাশের প্রাথমিক ক্যাপাসিটি । কোড ক্যাশে নিয়মিত GC করা হবে এবং প্রয়োজন হলে তা বাড়ানো হবে।
    • dalvik.vm.jitmaxsize (ডিফল্ট ৬৪M): কোড ক্যাশের সর্বাধিক ক্যাপাসিটি।
    • dalvik.vm.jitthreshold (ডিফল্ট ১০০০০): কোনও পদ্ধতির "হটনেস" কাউন্টারকে যে থ্রেশহোল্ড অতিক্রম করতে হবে যাতে পদ্ধতিটি JIT-কম্পাইল করা যায়। "hotness" কাউন্টার হল রানটাইমের অভ্যন্তরীণ মেট্রিক। এতে কলের সংখ্যা, ব্যাকওয়ার্ড ব্রাঞ্চ এবং অন্যান্য ফ্যাক্টর অন্তর্ভুক্ত।
    • dalvik.vm.usejitprofiles (Android 13 পর্যন্ত): JIT প্রোফাইল চালু আছে কিনা; dalvik.vm.usejit false হলেও এটি ব্যবহার করা হতে পারে। মনে রাখবেন, এটি মিথ্যা হলে, কম্পাইলার ফিল্টার speed-profile কোনও পদ্ধতি AOT-কম্পাইল করে না এবং verify-এর সমতুল্য হয়। Android 14 থেকে, JIT প্রোফাইল সবসময় চালু থাকে এবং বন্ধ করা যায় না।
    • dalvik.vm.jitprithreadweight (default to dalvik.vm.jitthreshold / ২০): JIT "samples"-এর ওজন (jitthreshold দেখুন) অ্যাপ্লিকেশন UI থ্রেডের জন্য। অ্যাপের সাথে ইন্টার‍্যাক্ট করার সময় ব্যবহারকারীর অভিজ্ঞতাকে সরাসরি প্রভাবিত করে এমন পদ্ধতির কম্পাইলেশন দ্রুত করতে ব্যবহার করা হয়।
    • dalvik.vm.jittransitionweight (সাধারণত dalvik.vm.jitthreshold / ১০): কম্পাইল কোড ও ইন্টারপ্রেটারের মধ্যে ট্রানজিশন করা মেথড ইনভোকেশনের ওয়েট। এটি নিশ্চিত করতে সাহায্য করে যে ট্রানজিশন (যা ব্যয়বহুল) কমানোর জন্য সংশ্লিষ্ট পদ্ধতিগুলি কম্পাইল করা হয়েছে।

    Dex2oat বিকল্প

    এইসব বিকল্প ডিভাইসে কম্পাইলেশনকে (অর্থাৎ, dexopt) প্রভাবিত করে এবং এগুলির মধ্যে কয়েকটি dexpreopt-কেও প্রভাবিত করে, যেখানে উপরে সিস্টেম ROM কনফিগারেশন বিভাগে আলোচনা করা বিকল্পগুলি শুধুমাত্র dexpreopt-কে প্রভাবিত করে।

    রিসোর্স ব্যবহার নিয়ন্ত্রণ করার বিকল্প:

    • dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (Android 11 পর্যন্ত): বুট ইমেজের জন্য ব্যবহার করার থ্রেডের সংখ্যা এবং CPU কোরের সেট (নিচে দেখুন)।
    • dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
      • (Android 11 পর্যন্ত) বুট ইমেজ ছাড়া অন্য সবকিছুর জন্য বুট টাইমে ব্যবহার করার জন্য থ্রেডের সংখ্যা ও CPU কোরের সেট (নিচে দেখুন)।
      • (Android 12 থেকে) বুট ইমেজ সহ সবকিছুর জন্য বুট করার সময় ব্যবহার করার জন্য থ্রেডের সংখ্যা এবং CPU কোরের সেট (নিচে দেখুন)।
        • বিশেষত, Android 14 থেকে, এটি ART পরিষেবার অগ্রাধিকার ক্লাস PRIORITY_BOOT-এর সাথে সম্পর্কিত।
    • dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
      • (Android 11 থেকে Android 13 পর্যন্ত) ক্লাউড ব্যাকআপ থেকে ফিরিয়ে আনার জন্য থ্রেডের সংখ্যা এবং CPU কোরের সেট (নিচে দেখুন) ব্যবহার করা হয়।
      • (Android 14 থেকে) ক্লাউড ব্যাক-আপ থেকে রিস্টোর করা সহ স্বাভাবিকের চেয়ে বেশি লেটেন্সি-সংবেদনশীল সবকিছুর জন্য ব্যবহার করার থ্রেডের সংখ্যা এবং CPU কোরের সেট (নিচে দেখুন)।
        • বিশেষ করে, এটি ART পরিষেবায় প্রায়োরিটি ক্লাস PRIORITY_INTERACTIVE_FAST-এর সাথে সম্পর্কিত।
    • dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (Android 14 থেকে): ব্যাকগ্রাউন্ডে ব্যবহার করার জন্য থ্রেডের সংখ্যা ও CPU কোরের সেট (নিচে দেখুন)।
      • বিশেষত, এটি PRIORITY_BACKGROUND অগ্রাধিকারের ক্লাসের সাথে সম্পর্কিত ART পরিষেবা।
    • dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: অন্যান্য সবকিছুর জন্য ব্যবহার করার থ্রেডের সংখ্যা এবং CPU কোরের সেট।

    CPU কোরের একটি সেটকে CPU আইডির কমা-সেপারেটেড তালিকা হিসেবে নির্দিষ্ট করতে হবে। যেমন, CPU কোর ০-৩-এ dex2oat রান করাতে, এগুলি সেট করুন:

    dalvik.vm.dex2oat-cpu-set=0,1,2,3

    CPU অ্যাফিনিটি প্রপার্টি সেট করার সময়, আমরা সাজেস্ট করি যে dex2oat থ্রেডের সংখ্যার সাথে সংশ্লিষ্ট প্রপার্টি ম্যাচ করান, যাতে অপ্রয়োজনীয় মেমরি ও I/O কনটেনশন এড়ানো যায়: 

    dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

    উপরের সিস্টেম প্রপার্টি ছাড়াও, আপনি dex2oat-এর রিসোর্স ব্যবহার কন্ট্রোল করতে টাস্ক প্রোফাইল ব্যবহার করতে পারবেন (Cgroup অ্যাবস্ট্রাকশন লেয়ার দেখুন)।

    যেসব টাস্ক প্রোফাইল কাজ করে:

    • Dex2OatBackground (Android 14 থেকে) (ডিফল্ট হিসেবে Dex2OatBootComplete ইনহেরিট করে): ব্যাকগ্রাউন্ডে ব্যবহার করার জন্য রিসোর্স কন্ট্রোল করে।
      • বিশেষ করে, এটি ART পরিষেবায় প্রায়োরিটি ক্লাস PRIORITY_BACKGROUND-এর সাথে সম্পর্কিত।
    • Dex2OatBootComplete:
      • (Android 13 পর্যন্ত) বুট করার পরে সবকিছু ব্যবহার করার জন্য রিসোর্স কন্ট্রোল করে।
      • (Android 14 থেকে) বুট করার পরে এবং ব্যাকগ্রাউন্ডে নেই এমন সবকিছুর জন্য ব্যবহার করার রিসোর্স কন্ট্রোল করে।
        • বিশেষত, এটি ART পরিষেবার মধ্যে থাকা PRIORITY_INTERACTIVE_FAST এবং PRIORITY_INTERACTIVE অগ্রাধিকারমূলক ক্লাসের সাথে সম্পর্কিত।

    সিস্টেম প্রপার্টি ও টাস্ক প্রোফাইল, দুটিই নির্দিষ্ট করা থাকলে, দুটিই কার্যকর হয়।

    হিপ সাইজ কন্ট্রোল করার বিকল্প:

    • dalvik.vm.image-dex2oat-Xms: বুট ইমেজের জন্য প্রাথমিক হিপ সাইজ।
    • dalvik.vm.image-dex2oat-Xmx: বুট ইমেজের জন্য হিপের সর্বাধিক সাইজ।
    • dalvik.vm.dex2oat-Xms: অন্য সবকিছুর জন্য প্রাথমিক হিপ সাইজ।
    • dalvik.vm.dex2oat-Xmx: অন্য সবকিছুর জন্য সর্বাধিক হিপ সাইজ।

    dex2oat-এর জন্য প্রাথমিক ও সর্বাধিক হিপ সাইজ কন্ট্রোল করে এমন বিকল্পগুলি কমানো উচিত নয়, কারণ সেগুলি অ্যাপ্লিকেশন কম্পাইল করার ক্ষমতা সীমিত করতে পারে।

    কম্পাইলার ফিল্টার কন্ট্রোল করার বিকল্প:

    • dalvik.vm.image-dex2oat-filter (Android 11 পর্যন্ত): বুট ইমেজের জন্য কম্পাইলার ফিল্টার। Android 12 থেকে, বুট ইমেজের জন্য কম্পাইলার ফিল্টার সবসময় speed-profile থাকে এবং এটি পরিবর্তন করা যায় না।
    • dalvik.vm.systemservercompilerfilter (Android 13 থেকে): সিস্টেম সার্ভারের জন্য কম্পাইলার ফিল্টার। PRODUCT_SYSTEM_SERVER_COMPILER_FILTER দেখুন।
    • dalvik.vm.systemuicompilerfilter (Android 13 থেকে): সিস্টেম UI প্যাকেজের জন্য কম্পাইলার ফিল্টার।
    • dalvik.vm.dex2oat-filter (Android 6 পর্যন্ত): অন্য সবকিছুর জন্য কম্পাইলার ফিল্টার।
    • pm.dexopt.<reason> (Android 7 থেকে): অন্য সবকিছুর জন্য কম্পাইলার ফিল্টার। Android 14 ও এর পরের যেকোনও ভার্সনের জন্য ART পরিষেবা কনফিগারেশন অথবা Android 13 ও এর আগের যেকোনও ভার্সনের জন্য প্যাকেজ ম্যানেজার কনফিগারেশন দেখুন।

    বুট ইমেজ ছাড়া বাকি সব কিছু কম্পাইল করার জন্য কন্ট্রোল করার অন্যান্য বিকল্প:

    • dalvik.vm.dex2oat-very-large (Android 7.1 থেকে): AOT কম্পাইলেশন বন্ধ করতে বাইট হিসেবে ন্যূনতম মোট dex ফাইলের সাইজ।
    • dalvik.vm.dex2oat-swap (Android 7.1 থেকে) (ডিফল্ট: true): dex2oat-এর জন্য সোয়াপ ফাইল ব্যবহার করার অনুমতি দেয়। এটি মেমরি শেষ হয়ে যাওয়ার কারণে ক্র্যাশ হওয়া এড়াতে সাহায্য করতে পারে। মনে রাখবেন, এই বিকল্প চালু করা থাকলেও, dex2oat শুধুমাত্র নির্দিষ্ট কিছু পরিস্থিতিতেই সোয়াপ ফাইল ব্যবহার করবে, যেমন, যখন dex ফাইলের সংখ্যা অনেক বেশি হয় এবং এই পরিস্থিতি পরিবর্তন হতে পারে।
    • dalvik.vm.ps-min-first-save-ms (Android 12 থেকে): রানটাইম প্রথমবার অ্যাপ্লিকেশন লঞ্চ করার আগে অ্যাপ্লিকেশনটির প্রোফাইল তৈরি করার জন্য অপেক্ষা করার ন্যূনতম সময়।
    • dalvik.vm.ps-min-save-period-ms (Android 12 থেকে): অ্যাপ্লিকেশনের প্রোফাইল আপডেট করার আগে অপেক্ষা করার ন্যূনতম সময়।
    • dalvik.vm.dex2oat64.enabled (Android 11 থেকে) (ডিফল্ট: false): dex2oat-এর 64-বিট ভার্সন ব্যবহার করা হবে কিনা।
    • dalvik.vm.bgdexopt.new-classes-percent (Android 12 থেকে) (ডিফল্ট: ২০): আবার কম্পাইল করার প্রসেস ট্রিগার করার জন্য প্রোফাইলে নতুন ক্লাসের ন্যূনতম শতাংশ, যা ০ থেকে ১০০-এর মধ্যে হতে হবে। শুধুমাত্র প্রোফাইল-নির্দেশিত কম্পাইলেশন (speed-profile)-এর ক্ষেত্রে প্রযোজ্য, সাধারণত ব্যাকগ্রাউন্ড dexopt চলাকালীন। মনে রাখবেন, শতাংশের থ্রেশহোল্ড ছাড়াও কমপক্ষে ৫০টি নতুন ক্লাসের থ্রেশহোল্ড রয়েছে এবং এটি কনফিগার করা যায় না।
    • dalvik.vm.bgdexopt.new-methods-percent (Android 12 থেকে) (ডিফল্ট: ২০): আবার কম্পাইলেশন ট্রিগার করার জন্য প্রোফাইলে নতুন পদ্ধতির ন্যূনতম শতাংশ, যা ০ থেকে ১০০-এর মধ্যে হতে হবে। শুধুমাত্র প্রোফাইল-নির্দেশিত কম্পাইলেশন (speed-profile)-এর ক্ষেত্রে প্রযোজ্য, সাধারণত ব্যাকগ্রাউন্ড dexopt চলাকালীন। মনে রাখবেন, শতাংশের থ্রেশহোল্ড ছাড়াও অন্তত ১০০টি নতুন পদ্ধতির একটি থ্রেশহোল্ড রয়েছে এবং এটি কনফিগার করা যায় না।
    • dalvik.vm.dex2oat-max-image-block-size (Android 10 থেকে) (ডিফল্ট: ৫২৪২৮৮) কমপ্রেস করা ছবির জন্য সলিড ব্লকের সর্বাধিক সাইজ। একটি বড় ছবিকে সলিড ব্লকের একটি সেটে ভাগ করা হয় যাতে কোনও ব্লক সর্বাধিক সাইজের চেয়ে বড় না হয়।
    • dalvik.vm.dex2oat-resolve-startup-strings (Android 10 থেকে) (ডিফল্ট: true) true হলে, dex2oat-এর কারণে প্রোফাইলে "startup" হিসেবে চিহ্নিত পদ্ধতি থেকে রেফারেন্স করা সব const-string সমাধান করা হয়।
    • debug.generate-debug-info (ডিফল্ট: false) নেটিভ ডিবাগিংয়ের জন্য ডিবাগ তথ্য জেনারেট করা হবে কিনা, যেমন স্ট্যাক আনওয়াইন্ডিং তথ্য, ELF সিম্বল এবং ডোয়ার্ফ সেকশন।
    • dalvik.vm.dex2oat-minidebuginfo (Android 9 থেকে) (ডিফল্ট: true) ব্যাকট্রেস প্রিন্ট করার জন্য প্রয়োজনীয় LZMA-কম্প্রেস করা ডিবাগিং ইনফরমেশনের ন্যূনতম পরিমাণ জেনারেট করা হবে কিনা।

    ART পরিষেবার বিকল্প

    Android 14 থেকে, অ্যাপের জন্য অন-ডিভাইস AOT কম্পাইলেশন (dexopt নামেও পরিচিত) ART পরিষেবা দ্বারা ম্যানেজ করা হয়। ART পরিষেবা কনফিগার করা সম্পর্কে তথ্য পেতে, ART পরিষেবা কনফিগারেশন দেখুন।

    প্যাকেজ ম্যানেজার সংক্রান্ত বিকল্প

    Android 14-এর আগে, অ্যাপের জন্য অন-ডিভাইস AOT কম্পাইলেশন (a.k.a. dexopt) প্যাকেজ ম্যানেজার দ্বারা ম্যানেজ করা হয়। dexopt-এর জন্য প্যাকেজ ম্যানেজার কনফিগার করা সম্পর্কে তথ্যের জন্য, প্যাকেজ ম্যানেজার কনফিগারেশন দেখুন।

    A/B নির্দিষ্ট কনফিগারেশন

    ROM কনফিগারেশন

    Android 7.0 থেকে শুরু করে, ডিভাইসগুলি A/B সিস্টেম আপডেট চালু করতে দুটি সিস্টেম পার্টিশন ব্যবহার করতে পারে। সিস্টেম পার্টিশনের সাইজ সেভ করতে, আগে থেকে বেছে নেওয়া ফাইলগুলি অব্যবহৃত দ্বিতীয় সিস্টেম পার্টিশনে ইনস্টল করা যেতে পারে। প্রথম বুটের সময় সেগুলি ডেটা পার্টিশনে কপি করা হয়।

    ব্যবহারের উদাহরণ (device-common.mk-এ):

    PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

    এবং ডিভাইসের BoardConfig.mk-এ:

    BOARD_USES_SYSTEM_OTHER_ODEX := true

    মনে রাখবেন, বুট ক্লাসপাথ কোড, সিস্টেম সার্ভার কোড এবং প্রোডাক্ট-নির্দিষ্ট কোর অ্যাপ সবসময় সিস্টেম পার্টিশনে কম্পাইল হয়। ডিফল্ট হিসেবে, অন্যান্য সব অ্যাপ কম্পাইল করে অব্যবহৃত সেকেন্ড সিস্টেম পার্টিশনে রাখা হয়। এটি SYSTEM_OTHER_ODEX_FILTER-এর মাধ্যমে নিয়ন্ত্রণ করা যেতে পারে, যার ডিফল্ট ভ্যালু হল:

    SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

    ব্যাকগ্রাউন্ড OTA dexopt

    A/B চালু থাকা ডিভাইসে, নতুন সিস্টেম ইমেজের সাথে রিবুট করার আগে ব্যাকগ্রাউন্ডে অ্যাপ্লিকেশন কম্পাইল করা যেতে পারে। সিস্টেম ইমেজে কম্পাইলেশন স্ক্রিপ্ট ও বাইনারি ঐচ্ছিকভাবে অন্তর্ভুক্ত করতে ব্যাকগ্রাউন্ডে অ্যাপ কম্পাইলেশন দেখুন। এই সংকলনের জন্য ব্যবহৃত সংকলন ফিল্টারটি এর মাধ্যমে নিয়ন্ত্রণ করা হয়:

    pm.dexopt.ab-ota=speed-profile

    প্রোফাইল নির্দেশিত কম্পাইলেশন থেকে সুবিধা পেতে এবং স্টোরেজ সাশ্রয় করতে আমরা speed-profile ব্যবহার করার সাজেশন দিই।

    JDWP বিকল্প

    userdebug বিল্ডে Java Debug Wire Protocol (JDWP) থ্রেড তৈরি করা persist.debug.dalvik.vm.jdwp.enabled সিস্টেম প্রপার্টির মাধ্যমে নিয়ন্ত্রণ করা হয়। ডিফল্ট হিসেবে, এই প্রপার্টি সেট করা থাকে না এবং JDWP থ্রেড শুধুমাত্র ডিবাগ করা যায় এমন অ্যাপের জন্য তৈরি করা হয়। ডিবাগ করা যায় ও যায় না, উভয় ধরনের অ্যাপের জন্য JDWP থ্রেড চালু করতে, persist.debug.dalvik.vm.jdwp.enabled 1 হিসেবে সেট করুন। প্রপার্টিতে করা পরিবর্তন কার্যকর করার জন্য ডিভাইসটি রিবুট করতে হবে।

    userdebug বিল্ডে ডিবাগ করা যায় না এমন অ্যাপ ডিবাগ করতে, নিম্নলিখিত কমান্ড রান করে JDWP চালু করুন:

      adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
    Android 13 ও এর আগের যেকোনও ভার্সনে চলা ডিভাইসের জন্য, রানটাইম JDWP থ্রেড তৈরি করে যা ইউজারডিবাগ বিল্ডে ডিবাগ করা যায় ও যায় না এমন অ্যাপের জন্য। এর অর্থ হল, userdebug বিল্ডে যেকোনও অ্যাপের প্রোফাইল বা ডিবাগার অ্যাটাচ করা সম্ভব।