ART: এটি কী, রানটাইম এবং এটি কীভাবে কাজ করে

ART কী?

Android Runtime (ART) হলো একটি অ্যাপ্লিকেশন রানটাইম পরিবেশ যা এক্সিকিউশনের আগে DEX বাইটকোডকে নেটিভ মেশিন কোডে কম্পাইল করে। Dalvik-এর বিপরীতে, যা রানটাইমের সময় Just-In-Time কম্পাইলেশন ব্যবহার করত, ART APK ইনস্টলেশনের সময় Ahead-Of-Time (AOT) কম্পাইলেশন করে। এই মৌলিক আর্কিটেকচারাল পরিবর্তনের ফলে অ্যাপ্লিকেশনের গতি উল্লেখযোগ্যভাবে বেড়েছে এবং পাওয়ার খরচ কমেছে।

ART প্রথম Android 4.4 KitKat-এ একটি পরীক্ষামূলক বিকল্প হিসেবে আবির্ভূত হয়েছিল। ডেভেলপাররা ডেভেলপার সেটিংসে এটি সক্রিয় করতে পারতেন এবং তাদের অ্যাপ্লিকেশন পরীক্ষা করতে পারতেন। Android 5.0 Lollipop-এ, ART ডিফল্ট রানটাইম হয়ে ওঠে এবং Dalvik সম্পূর্ণরূপে প্ল্যাটফর্ম থেকে সরিয়ে দেওয়া হয়েছিল। Android 7.0 Nougat প্রকাশের সময়, ART একটি হাইব্রিড কম্পাইলেশন মোড পেয়েছিল।

উন্নয়নের ইতিহাস

Dalvik-কে ART দিয়ে প্রতিস্থাপনের সিদ্ধান্ত হঠাৎ ছিল না। নতুন রানটাইমের কাজ 2012 সালে শুরু হয়েছিল যখন Google JIT পদ্ধতির সীমাবদ্ধতাগুলি উপলব্ধি করেছিল। প্রধান লক্ষ্যগুলি: অ্যাপ লঞ্চ ত্বরান্বিত করা, CPU লোড কমানো এবং পাওয়ার খরচ কমানো। উন্নয়নের নেতৃত্বে ছিল Android Runtime Group, যা আগে Dalvik অপ্টিমাইজেশনে কাজ করছিল।

আর্কিটেকচারাল পরিবর্তন

ART একই রেজিস্টার-ভিত্তিক আর্কিটেকচার ব্যবহার করে যেমন Dalvik, কিন্তু সম্পূর্ণ পুনঃডিজাইন করা কম্পাইলারের সাথে। ইন্টারপ্রেটার এবং JIT কম্পাইলারের পরিবর্তে, ART-তে dex2oat AOT কম্পাইলার অন্তর্ভুক্ত রয়েছে, যা ইনস্টলেশনের সময় DEX ফাইলগুলিকে ELF বাইনারিতে রূপান্তর করে। ফলস্বরূপ, ART-তে অ্যাপ্লিকেশনগুলি ওয়ার্ম-আপ পর্যায় ছাড়াই তাত্ক্ষণিকভাবে নেটিভ কর্মক্ষমতা সহ শুরু হয়।

ART আর্কিটেকচার: Dalvik থেকে নতুন রানটাইম পর্যন্ত

ART Dalvik-এর মূল নীতিগুলি বজায় রেখেছে: পৃথক প্রক্রিয়ার মাধ্যমে অ্যাপ্লিকেশন বিচ্ছিন্নতা, রেজিস্টার-ভিত্তিক আর্কিটেকচার এবং DEX ফরম্যাট সমর্থন। তবে, অভ্যন্তরীণ বাস্তবায়ন সম্পূর্ণরূপে পুনঃলিখিত হয়েছে। Dalvik ইন্টারপ্রেটারের পরিবর্তে, ART-তে তিনটি এক্সিকিউশন মোড অন্তর্ভুক্ত: ইন্টারপ্রেটার, JIT কম্পাইলার এবং dex2oat AOT কম্পাইলার। মোড নির্বাচন অ্যাপ্লিকেশনের জীবনচক্র পর্যায়ের উপর নির্ভর করে।

ART-এর মূল উপাদান হলো dex2oat (dalvik executable to optimized android translator)। এই ইউটিলিটি অ্যাপ্লিকেশন ইনস্টলেশনের সময় চলে (Android 7.0 থেকে — ব্যাকগ্রাউন্ড অপ্টিমাইজেশনের সময়ও)। dex2oat APK থেকে DEX ফাইল পড়ে, বাইটকোড অপ্টিমাইজ করে এবং একটি OAT ফাইল — নেটিভ কোড সহ ELF বাইনারি — জেনারেট করে। OAT ফাইলগুলি /data/dalvik-cache/ ডিরেক্টরিতে সংরক্ষিত হয়।

# ডিভাইসে OAT ফাইল পরীক্ষা করা
adb shell ls -la /data/dalvik-cache/arm64/

# অ্যাপ্লিকেশনের বাধ্যতামূলক পুনঃকম্পাইলেশন
adb shell cmd package compile -m speed com.example.app

ART উপাদান

ART সিস্টেম বেশ কয়েকটি আন্তঃসংযুক্ত মডিউল নিয়ে গঠিত। dex2oat কম্পাইলার নেটিভ কোড জেনারেশনের জন্য দায়ী। গার্বেজ কালেক্টর (GC) মেমরি ডিলোকেশন পরিচালনা করে। ইন্টারপ্রেটার কম্পাইলেশন ছাড়াই কদাচিৎ কল করা কোড এক্সিকিউট করে। প্রোফাইলার হাইব্রিড কম্পাইলেশনের জন্য হট মেথডগুলি ট্র্যাক করে। প্রতিটি মডিউল স্বাধীনভাবে কাজ করতে পারে, যা ART-কে নমনীয় এবং স্কেলেবল করে তোলে।

হাইব্রিড কম্পাইলেশন: JIT + AOT + প্রোফাইলিং

Android 7.0 Nougat থেকে শুরু করে, ART কম্পাইলেশনের জন্য একটি হাইব্রিড পদ্ধতি ব্যবহার করে, যা JIT এবং AOT-এর সুবিধাগুলিকে একত্রিত করে। অ্যাপ্লিকেশন ইনস্টলেশনের সময়, ART আর সম্পূর্ণ AOT কম্পাইলেশন করে না — পরিবর্তে, অ্যাপটি হট মেথডগুলির JIT কম্পাইলেশন সহ ইন্টারপ্রেটেড মোডে চলে। এটি ইনস্টলেশন সময় এবং স্টোরেজ স্পেস হ্রাস করে।

একটি ব্যাকগ্রাউন্ড প্রোফাইলার সমান্তরালে কাজ করে। এটি এক্সিকিউশন পরিসংখ্যান সংগ্রহ করে: কোন মেথডগুলি সবচেয়ে বেশি কল করা হয়, কোডের কোন শাখাগুলি এক্সিকিউট হয়, কোন ক্লাস লোড হয়। পর্যাপ্ত ডেটা জমা হওয়ার পর (সাধারণত 2–3 অ্যাপ লঞ্চের পরে), ART ব্যাকগ্রাউন্ডে dex2oat চালায় এবং শুধুমাত্র প্রোফাইল করা হট মেথডগুলি নেটিভ কোডে কম্পাইল করে।

কম্পাইলেশন মোড

ART system_server-এর মাধ্যমে পরিচালিত বেশ কয়েকটি কম্পাইলেশন মোড সমর্থন করে। “speed” মোড সমস্ত মেথড AOT-তে কম্পাইল করে (সর্বোচ্চ কর্মক্ষমতা, ধীর ইনস্টলেশন)। “speed-profile” মোড শুধুমাত্র প্রোফাইল করা হট মেথডগুলি কম্পাইল করে (গতি এবং আকারের ভারসাম্য)। “verify” মোড কম্পাইলেশন ছাড়াই শুধুমাত্র বাইটকোড যাচাই করে (সর্বনিম্ন স্থান, ইন্টারপ্রিটেশন)। ডিফল্টরূপে, speed-profile ব্যবহার করা হয় — বেশিরভাগ অ্যাপ্লিকেশনের জন্য সর্বোত্তম।

ART প্রোফাইলার

প্রোফাইলার বিশেষ .prof ফাইলে এক্সিকিউশন ডেটা সংগ্রহ করে। প্রতিটি অ্যাপ্লিকেশন তার প্রোফাইল /data/misc/profiles/-এ সংরক্ষণ করে। যখন থ্রেশহোল্ড পৌঁছে যায় (সাধারণত 1000 স্যাম্পল), প্রোফাইলার চিহ্নিত হট মেথডগুলি কম্পাইল করতে dex2oat চালু করে। অ্যাপ্লিকেশন আপডেটের মধ্যেও প্রোফাইলগুলি সংরক্ষিত থাকে, যা OTA সিস্টেম আপডেটের পরে পুনরায় অপ্টিমাইজেশন দ্রুত করে।

ART-তে গার্বেজ কালেকশন

ART-তে গার্বেজ কালেকশন Dalvik-এর তুলনায় নাটকীয়ভাবে উন্নত হয়েছে। একক-থ্রেডেড Concurrent Mark and Sweep (CMS)-এর পরিবর্তে, ART বেশ কয়েকটি অপ্টিমাইজেশন সহ জেনারেশনাল কালেক্টর ব্যবহার করে: মুভিং কালেক্টর (হিপ কমপ্যাকশন), লার্জ অবজেক্ট স্পেস (বড় অবজেক্টের জন্য আলাদা স্টোরেজ) এবং কনকারেন্ট কমপ্যাকশন (সমান্তরাল কমপ্যাকশন)।

ART-তে একটি সাধারণ GC পজ 2–3 ms, যেখানে Dalvik-এ 5–10 ms ছিল। এটি বেশ কয়েকটি প্রক্রিয়ার মাধ্যমে সম্ভব হয়েছে। প্রথমত, ART কনকারেন্ট ফেজগুলির জন্য stop-the-world-এর পরিবর্তে read-barrier ব্যবহার করে। দ্বিতীয়ত, জেনারেশনাল কালেক্টর বেশিরভাগ চক্রে শুধুমাত্র তরুণ প্রজন্মের অবজেক্টগুলি প্রক্রিয়া করে, পুরো হিপ স্পর্শ না করে। তৃতীয়ত, লার্জ অবজেক্ট স্পেস (LOS) আলাদাভাবে বরাদ্দ করা হয় এবং নিয়মিত GC চক্রে অংশগ্রহণ করে না।

// ডিবাগিংয়ের জন্য GC লগ সক্রিয় করা
System.logV("ART", "GC trigger: allocation failed");

// বাধ্যতামূলক GC কল (প্রোডাকশনে সুপারিশ করা হয় না)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    Debug.getRuntimeIStats();
}

ART যুগে মেমরি লিক

উন্নত GC সত্ত্বেও, মেমরি লিক একটি প্রাসঙ্গিক সমস্যা থেকে যায়। একটি ART-নির্দিষ্ট কারণ হলো সঠিক ডিলোকেশন ছাড়া JNI-এর মাধ্যমে নেটিভ লাইব্রেরি লোড করা। যদি নেটিভ কোড malloc-এর মাধ্যমে মেমরি বরাদ্দ করে কিন্তু free কল না করে, তবে ART এই মেমরি মুক্ত করতে পারে না — এটি পরিচালিত হিপের বাইরে থাকে। Android NDK-তে AddressSanitizer টুল এই ধরনের লিক সনাক্ত করতে সাহায্য করে।

ART বনাম Dalvik: তুলনামূলক বিশ্লেষণ

ART এবং Dalvik একই কাজের দুটি মৌলিকভাবে ভিন্ন বাস্তবায়ন: Android অ্যাপ্লিকেশন এক্সিকিউট করা। পার্থক্যগুলি সমস্ত স্তরকে প্রভাবিত করে: কম্পাইলেশন থেকে মেমরি পরিচালনা পর্যন্ত। নীচে মূল কর্মক্ষমতা এবং সামঞ্জস্য প্যারামিটারের তুলনা দেওয়া হল।

ART-এর প্রধান সুবিধা হলো JIT ওয়ার্ম-আপ দূর করা। Dalvik-এ, JIT হট মেথডগুলি কম্পাইল করার সময় একটি অ্যাপ প্রথম 3–10 সেকেন্ডের জন্য ধীর হতে পারে। ART-তে, সমস্ত মেথড ইতিমধ্যেই নেটিভ কোডে কম্পাইল করা হয় (অথবা ব্যাকগ্রাউন্ডে কম্পাইল হবে)। এটি বিশেষ করে গেম এবং ভারী UI সহ অ্যাপগুলিতে লক্ষণীয়: fps পার্থক্য ART-এর পক্ষে 15–20% পর্যন্ত পৌঁছাতে পারে।

সামঞ্জস্য

Dalvik-এর জন্য লেখা সমস্ত অ্যাপ্লিকেশন পরিবর্তন ছাড়াই ART-এ কাজ করে। Google DEX বাইটকোড স্তরে সম্পূর্ণ ব্যাকওয়ার্ড সামঞ্জস্যের গ্যারান্টি দেয়। ব্যতিক্রম হলো রিফ্লেকশনের মাধ্যমে Dalvik-নির্দিষ্ট অভ্যন্তরীণ API ব্যবহার করা কোড: Android SDK-তে @hide দিয়ে চিহ্নিত dalvik.system.DexFile ক্লাসের সদস্য। এই জাতীয় কোড পাবলিক API ব্যবহার করার জন্য আপডেট করা উচিত।

Java 8 সমর্থন এবং ডিসুগারিং

ART নেটিভ Java 8 বৈশিষ্ট্য সমর্থন সহ প্রথম Android রানটাইম হয়ে ওঠে। Android 7.0 থেকে শুরু করে, ART-তে ডিসুগারিং অন্তর্ভুক্ত — Java 8 কনস্ট্রাক্ট (ল্যাম্বডা, মেথড রেফারেন্স, Stream API) সমতুল্য Java 7 কোডে রূপান্তর করার প্রক্রিয়া। এটি পুরানো ডিভাইসগুলির সাথে সামঞ্জস্য না হারিয়ে আধুনিক সিনট্যাক্স ব্যবহার করতে দেয়।

ডিসুগারিং D8 কম্পাইলার দ্বারা সম্পাদিত হয় এবং নিম্নরূপ কাজ করে। ল্যাম্বডা সহ সোর্স কোড একই ক্লাসের মধ্যে একটি সিন্থেটিক মেথডে রূপান্তরিত হয় এবং ল্যাম্বডাটি একটি invoke-custom কল দ্বারা প্রতিস্থাপিত হয়। ART-এর রানটাইমে বিশেষভাবে Java 8-এর জন্য যুক্ত করা invoke-custom নির্দেশের সমর্থন অন্তর্ভুক্ত। Android 6.0 এবং নীচের ডিভাইসগুলিতে, ল্যাম্বডাগুলি অজ্ঞাত ক্লাসে ডিসুগার করা হয়।

// Java 8 ল্যাম্বডা — ART-তে ডিসুগারিং
button.setOnClickListener(v -> handleClick(v));

// ডিসুগারিংয়ের পরে (Java 7 সমতুল্য)
button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        handleClick(v);
    }
});

ডিসুগারিং-এর সীমাবদ্ধতা

সমস্ত Java 8 বৈশিষ্ট্য ডিসুগারিং দ্বারা সমর্থিত নয়। java.time API (তারিখ এবং সময়) শুধুমাত্র desugar_jdk_libs — build.gradle-এ যুক্ত একটি অতিরিক্ত লাইব্রেরি — এর মাধ্যমে উপলব্ধ। Stream API-ও desugar_jdk_libs প্রয়োজন। java.util.function এবং Optional অতিরিক্ত নির্ভরতা ছাড়াই কাজ করে। সম্পূর্ণ Java 8 সমর্থন ডিসুগারিং ছাড়াই Android 8.0 এবং তার উপরের ডিভাইসগুলিতে উপলব্ধ।

ART-র জন্য অ্যাপ্লিকেশন অপ্টিমাইজেশন

যদিও ART ব্যাকওয়ার্ড সামঞ্জস্যপূর্ণ, কিছু অপ্টিমাইজেশন অনুশীলন বিশেষ করে এই রানটাইমে কর্মক্ষমতা উন্নত করে। প্রধান সুপারিশ হলো রিফ্লেকশন কমানো। ART কম্পাইল সময়ে দৃশ্যমান মেথডগুলিকে সরাসরি মেশিন কোড কলগুলিতে কম্পাইল করে। রিফ্লেকশন ART-কে অতিরিক্ত stubs জেনারেট করতে বাধ্য করে, যা এক্সিকিউশন 10–15% ধীর করে দেয়।

Android 9.0 থেকে শুরু করে, ART App Startup Optimization-এর জন্য সমর্থন চালু করেছে। ডেভেলপার ম্যানিফেস্টে <initialization>-এর মাধ্যমে ইনিশিয়ালাইজেশন ক্লাস চিহ্নিত করতে পারেন এবং ART অ্যাপ স্টার্টআপে সেগুলি প্রিলোড করবে। এটি অনেক প্লাগইন বা লাইব্রেরি সহ অ্যাপ্লিকেশনগুলির জন্য লঞ্চ সময় 5–15% হ্রাস করে।

<!-- AndroidManifest.xml-এ App Startup Optimization -->
<application>
    <profileable
        android:shell="true"
        android:enable="true" />
</application>

কর্মক্ষমতা পরীক্ষা

ART-এ কর্মক্ষমতা পরিমাপ করতে, systrace এবং perfetto ব্যবহার করুন। Systrace dex2oat কম্পাইলেশন সময়, GC ফ্রিকোয়েন্সি এবং ফ্রেম রেন্ডারিং গতি দেখায়। Perfetto আরও বিস্তারিত তথ্য প্রদান করে: থ্রেড বিতরণ, JNI ট্রানজিশন সময়, নেটিভ লাইব্রেরি লোডিং। লঞ্চ: adb shell perfetto -o /data/misc/perfetto-traces/trace.perfetto -t 10s sched freq idle am wm।