DEX: এটি কী, বাইটকোডের গঠন এবং কার্যনীতি

DEX কী এবং কেন এটি প্রয়োজন

DEX (Dalvik Executable) একটি বাইটকোড ফরম্যাট যা বিশেষভাবে Android মোবাইল ডিভাইসের জন্য ডিজাইন করা হয়েছে। স্ট্যান্ডার্ড Java বাইটকোড (.class ফাইল) থেকে ভিন্ন, DEX সীমিত সম্পদের জন্য অপ্টিমাইজ করা: কম মেমোরি, ছোট আকার এবং দ্রুত ক্লাস লোডিং।

Java থেকে DEX-এ

Java বা Kotlin-এর সোর্স কোড javac/kotlinc দ্বারা স্ট্যান্ডার্ড .class ফাইলে (Java বাইটকোড) কম্পাইল করা হয়। তারপর d8 টুল (বা আগে dx) .class-কে এক বা একাধিক DEX ফাইলে রূপান্তর করে। এই রূপান্তর শুধু রিপ্যাকেজিং নয় — d8 অপ্টিমাইজেশন করে: কনস্ট্যান্ট পুল মার্জ করা, নির্দেশনাগুলিকে রেজিস্টার আর্কিটেকচারে পুনরায় লেখা এবং ডুপ্লিকেট ডেটা সরানো।

আর্কিটেকচারাল বৈশিষ্ট্য

DEX রেজিস্টার-ভিত্তিক আর্কিটেকচার ব্যবহার করে (স্ট্যাক-ভিত্তিক JVM-এর বিপরীতে)। প্রতিটি মেথডের একটি নির্দিষ্ট সংখ্যক রেজিস্টার থাকে (65536 পর্যন্ত)। DEX নির্দেশনা ছোট — গড়ে 2 বাইট বনাম JVM-এ 1–4 বাইট। এটি আরও কম্প্যাক্ট কোড তৈরি করে: একটি সাধারণ অ্যাপ্লিকেশন 10–15 MB .class থেকে কমে 4–6 MB .dex হয়।

DEX ফাইলের গঠন: বিভাগ এবং হেডার

একটি DEX ফাইলের কঠোরভাবে নির্ধারিত বাইনারি গঠন রয়েছে। প্রতিটি ফাইল একটি হেডার দিয়ে শুরু হয় এবং বেশ কয়েকটি বিভাগ ধারণ করে যা অফসেটের মাধ্যমে একে অপরকে উল্লেখ করে।

DEX হেডার

DEX-এর ম্যাজিক নম্বর হল `dex\n035\0` (ভার্সন 035)। অন্যান্য ভার্সন: 036, 037, 038 (Android 8.0+ এর জন্য)। হেডারটি 0x70 বাইট সাইজের এবং এতে SHA-1 চেকসাম এবং সমস্ত বিভাগের অফসেট থাকে। ভার্চুয়াল মেশিন দ্বারা DEX লোড করার সময় হেডার ভ্যালিডেশন প্রথম ধাপ।

কনস্ট্যান্ট পুল

string_ids, type_ids, proto_ids, field_ids, method_ids — এগুলি ইনডেক্সড টেবিল। মেথড কোডে সম্পূর্ণ নাম সংরক্ষণ করার পরিবর্তে, একটি 4-বাইট ইনডেক্স ব্যবহার করা হয়। এটি একটি মূল অপ্টিমাইজেশন: যদি একটি ক্লাস 100 বার উল্লেখ করা হয়, তার নাম string_ids-এ একবার সংরক্ষিত হয়। dex2oat ART কম্পাইলেশনের সময় এই টেবিলগুলি আরও অপ্টিমাইজ করে।

Java এবং Kotlin থেকে DEX-এ কম্পাইল করার প্রক্রিয়া

সোর্স কোডকে DEX-এ রূপান্তরের প্রক্রিয়া বেশ কয়েকটি ধাপ নিয়ে গঠিত। আধুনিক টুলচেইন D8 কম্পাইলার ব্যবহার করে, যা 2018 সালে Android Gradle Plugin 3.2-এর সাথে DX-কে প্রতিস্থাপন করে।

ধাপ 1: .class-এ কম্পাইলেশন

javac (Java-র জন্য) বা kotlinc (Kotlin-এর জন্য) সোর্স কোডকে .class ফাইলে কম্পাইল করে। প্রতিটি ক্লাস Java বাইটকোডে একটি পৃথক .class ফাইল। এই ধাপে, টাইপ পরীক্ষা, ব্রিজ মেথড জেনারেশন এবং কনস্ট্যান্ট ইনলাইনিং করা হয়।

ধাপ 2: D8 কম্পাইলেশন

D8 সমস্ত .class ফাইল নেয় এবং সেগুলিকে DEX বাইটকোডে রূপান্তর করে। D8 বেশ কয়েকটি অপ্টিমাইজেশন করে: অব্যবহৃত মেথড আর্গুমেন্ট সরানো, বিভিন্ন .class ফাইল থেকে কনস্ট্যান্ট পুল একক গ্লোবাল DEX পুলে মার্জ করা এবং JVM স্ট্যাক নির্দেশনাকে Dalvik রেজিস্টার নির্দেশনায় রূপান্তর করা।

// Kotlin সোর্স কোড
data class User(
    val name: String,
    val email: String
)

fun greet(user: User): String {
    return "Hello, ${user.name}!"
}

D8 কম্পাইলেশনের পর, এই কোড কম্প্যাক্ট DEX নির্দেশনায় রূপান্তরিত হয়: স্ট্রিং লোড করার জন্য const-string, অবজেক্ট ফিল্ড অ্যাক্সেস করার জন্য iget-object, StringBuilder.append কল করার জন্য invoke-virtual।

D8 বনাম DX

D8 DX-এর তুলনায় 2–3 গুণ দ্রুত, আরও কম্প্যাক্ট DEX তৈরি করে (5–10% ছোট), এবং Kotlin-নির্দিষ্ট কনস্ট্রাক্ট (ইনলাইন ফাংশন, ল্যাম্বডা) ভালোভাবে অপ্টিমাইজ করে। DX 2018 সালে অবচিত ঘোষণা করা হয়েছিল এবং Android Gradle Plugin 8.0 থেকে সরিয়ে দেওয়া হয়েছে।

Dalvik বনাম ART: DEX নির্বাহ কীভাবে পরিবর্তিত হয়েছে

Android-এ DEX কোডের নির্বাহ দুটি ধাপের মধ্য দিয়ে গেছে: মূল Dalvik ভার্চুয়াল মেশিন (Android 2.2–4.4) এবং Android Runtime ART (Android 5.0+)। কম্পাইলেশন পদ্ধতির পার্থক্য মৌলিক।

Dalvik VM: JIT কম্পাইলেশন

Dalvik Just-In-Time (JIT) কম্পাইলেশন ব্যবহার করত: DEX বাইটকোড ব্যাখ্যা করা হত, এবং ঘন ঘন কল করা মেথডগুলি চলাকালীন নেটিভ কোডে কম্পাইল করা হত। সুবিধা — দ্রুত ইনস্টলেশন। অসুবিধা — ধীর স্টার্টআপ এবং JIT-এর জন্য ধ্রুবক CPU খরচ।

ART: AOT কম্পাইলেশন

ART (Android Runtime) dex2oat-এর মাধ্যমে অ্যাপ্লিকেশন ইনস্টলেশনের সময় DEX-কে নেটিভ কোডে কম্পাইল করে। এটি একটি Ahead-Of-Time (AOT) পদ্ধতি: ইনস্টলেশন বেশি সময় নেয়, কিন্তু স্টার্টআপ দ্রুত এবং শক্তি খরচ কম। Android 7.0 থেকে, ART একটি হাইব্রিড পদ্ধতি ব্যবহার করে — AOT + JIT + Profile Guided Optimization।

dex2oat: ইনস্টলেশনের সময় রূপান্তর

dex2oat টুল অ্যাপ্লিকেশন ইনস্টল বা আপডেট করার সময় চলে। এটি DEX-কে ডিভাইস আর্কিটেকচারের জন্য নেটিভ কোড সহ ELF ফাইলে কম্পাইল করে। ফলাফল — /data/dalvik-cache/ ডিরেক্টরিতে .oat এবং .art ফাইল। Google ক্রমাগত dex2oat উন্নত করছে: Android 14-এ ফোল্ডেবল ডিভাইসের জন্য অপ্টিমাইজেশন যোগ করা হয়েছে।

Multidex: 64K মেথডের সীমা অতিক্রম করা

প্রতি DEX ফাইলে 65536 মেথডের সীমা Dalvik আর্কিটেকচারের উত্তরাধিকার। DEX হেডারের method_ids ফিল্ড 4 বাইট নেয়, যা সর্বোচ্চ 2^16 = 65536 ইউনিক রেফারেন্স দেয়। Google Play Services, Firebase এবং অন্যান্য SDK-সহ আধুনিক অ্যাপ্লিকেশন সহজেই এই সীমা অতিক্রম করে।

Multidex প্রক্রিয়া

Multidex কোডকে একাধিক DEX ফাইলে বিভক্ত করার একটি প্রক্রিয়া। প্রধান classes.dex-এ এন্ট্রি পয়েন্ট (Application ক্লাস, প্রধান Activity) থাকে, বাকিগুলি classes2.dex, classes3.dex ইত্যাদি। স্টার্টআপে, অতিরিক্ত DEX থেকে ক্লাস DexClassLoader-এর মাধ্যমে লোড করা হয়।

// build.gradle.kts — multidex সক্ষম করা
android {
    defaultConfig {
        multiDexEnabled = true
    }
}

// Multidex সমর্থন সহ Application ক্লাস
class MyApp : Application() {
    override fun attachBaseContext(base: Context) {
        super.attachBaseContext(base)
        MultiDex.install(this)
    }
}

Multidex সমস্যা

অ্যাপ্লিকেশন স্টার্টআপের সময় অতিরিক্ত DEX-এর লোডিং Android 5.0-এর আগের ডিভাইসগুলিতে ANR (Application Not Responding) সৃষ্টি করতে পারে। সুপারিশ — শুধুমাত্র প্রয়োজন হলে multidex ব্যবহার করুন এবং সীমা অতিক্রম না করার জন্য নির্ভরতা কমিয়ে দিন।

DEX অপ্টিমাইজেশন: ProGuard, R8 এবং অবফাসকেশন

DEX-এর অপ্টিমাইজেশন রিলিজ Android অ্যাপ্লিকেশন তৈরির একটি মানক ধাপ। R8 এবং ProGuard টুল DEX আকার কমায়, কোড অবফাসকেট করে এবং অব্যবহৃত ক্লাস সরিয়ে দেয়।

R8 বনাম ProGuard

R8 ProGuard-এর উত্তরসূরি, 2019 থেকে Android Gradle Plugin-এ নির্মিত। R8 একক পাসে মিনিফিকেশন, অবফাসকেশন এবং অপ্টিমাইজেশন করে, যখন ProGuard-এর দুটি ধাপ প্রয়োজন ছিল: ProGuard → D8। ProGuard এখনও সমর্থিত, তবে Google নতুন প্রকল্পের জন্য R8 সুপারিশ করে।

R8 অব্যবহৃত ক্লাস, মেথড এবং ফিল্ড সরিয়ে দেয়, সেগুলিকে ছোট নামে (a, b, c) নামকরণ করে, ইনলাইন ফাংশন অন্তর্ভুক্ত করে এবং ডেড কোড সরিয়ে দেয়। ফলাফল — কার্যকারিতা না হারিয়ে DEX 20–40% কমে যায়।

R8 নিয়ম

R8 কনফিগারেশন proguard-rules.pro ফাইলে নির্দিষ্ট করা হয়। ডেভেলপার নির্দিষ্ট করতে পারে কোন ক্লাসের নাম পরিবর্তন করা যাবে না (উদাহরণস্বরূপ, রিফ্লেকশন বা Gson সিরিয়ালাইজেশনের জন্য)। Firebase এবং অন্যান্য SDK তাদের নির্ভরতায় নিজস্ব নিয়ম প্রদান করে।

DEX ডিকম্পাইলেশন: টুল এবং সুরক্ষা

DEX-কে পুনরায় Java কোডে ডিকম্পাইল করা যেতে পারে। এটি Android অ্যাপ্লিকেশনের জন্য একটি গুরুত্বপূর্ণ সুরক্ষা প্রশ্ন: অবফাসকেশন ছাড়া, কোড মূলের কাছাকাছি স্তরে পুনরুদ্ধার হয়।

ডিকম্পাইলেশন টুল

JADX সবচেয়ে জনপ্রিয় DEX থেকে Java ডিকম্পাইলার। এটি ক্লাসের নাম, মেথড, ফিল্ড এবং বেশিরভাগ লজিক পুনরুদ্ধার করে। apktool DEX-কে smali কোডে (Dalvik অ্যাসেম্বলার) ডিকম্পাইল করে — মূল নির্দেশনার কাছাকাছি একটি নিম্ন-স্তরের উপস্থাপনা। Bytecode Viewer একটি ইন্টারফেসে একাধিক ডিকম্পাইলারকে একত্রিত করে।

সুরক্ষা পদ্ধতি

R8/ProGuard এর সাথে অবফাসকেশন প্রতিরক্ষার প্রথম লাইন: ক্লাস এবং মেথডের নাম অপঠনযোগ্য হয়ে যায়। DexGuard অতিরিক্ত পদ্ধতি সহ একটি বাণিজ্যিক টুল: স্ট্রিং এনক্রিপশন, অখণ্ডতা পরীক্ষা, অ্যান্টি-ট্যাম্পার। কন্ট্রোল ফ্লো অবফাসকেশন (O-LLVM) কার্যকারিতা বজায় রেখে কোড গঠন পরিবর্তন করে, বিশ্লেষণকে আরও কঠিন করে তোলে।