JIT (Just-In-Time) ایک متحرک تالیف ٹیکنالوجی ہے جو بائٹ کوڈ یا پروگرام کی درمیانی نمائندگی کو عملدرآمد کے دوران براہ راست مشینی ہدایات میں تبدیل کرتی ہے۔ Android میں، JIT مرتب پہلی بار ورژن 2.2 Froyo میں Dalvik ورچوئل مشین کے حصے کے طور پر ظاہر ہوا اور ایپلیکیشن کے عملدرآمد کو 2–5 گنا تیز کیا۔ Google, 2024 کے مطابق، ART میں جدید JIT تشریح کو ہاٹ میتھڈز کی پروفائلڈ تالیف کے ساتھ جوڑتا ہے۔
اہم نکات
Just-In-Time (JIT) ایک تالیف کا طریقہ ہے جس میں سورس کوڈ یا بائٹ کوڈ پہلے سے نہیں (جیسا کہ AOT میں)، بلکہ پروگرام کے متعلقہ حصے کی پہلی کال کے وقت مشینی ہدایات میں تبدیل ہوتا ہے۔ اصطلاح “Just-In-Time” کا مطلب ہے کہ تالیف عملدرآمد سے فوراً پہلے “عین وقت پر” ہوتی ہے۔
JIT کا تصور 1960 کی دہائی سے موجود ہے، لیکن 1995 میں Java ورچوئل مشین کی آمد کے ساتھ بڑے پیمانے پر اپنایا گیا۔ JIT بائٹ کوڈ کی پورٹیبلیٹی (ایک بار لکھیں — کہیں بھی چلائیں) کو مقامی کوڈ کے قریب کارکردگی کے ساتھ جوڑنے کی اجازت دیتا ہے۔ Java HotSpot VM میں، JIT مرتب عملدرآمد شدہ کوڈ کا تجزیہ کرتا ہے اور صرف انتہائی اہم حصوں کو مرتب کرتا ہے، وقت اور میموری بچاتا ہے۔
JIT مرتب ان پٹ کے طور پر بائٹ کوڈ وصول کرتا ہے، اس کی تشریح کرتا ہے اور متوازی طور پر اعدادوشمار جمع کرتا ہے۔ جب کوڈ کا کوئی حصہ (میتھڈ، لوپ) کافی بار کال کیا جاتا ہے، JIT اسے مرتب کرنے کا فیصلہ کرتا ہے۔ مرتب کردہ مشینی کوڈ کیش میں محفوظ ہوتا ہے — بعد کی کالوں پر، پہلے سے مرتب کردہ ورژن استعمال ہوتا ہے۔ یہ پورے پروگرام کو مرتب کیے بغیر رفتار فراہم کرتا ہے۔
// مثال: ایک میتھڈ متعدد کالوں کے بعد ہاٹ ہو جاتی ہے
public class HotMethod {
private int compute(int n) {
int sum = 0;
for (int i = 0; i < n; i++) {
sum += i * i;
}
return sum;
}
}
// لوپ میں 500 بار کال کرنا — JIT compute کو مرتب کرے گا
for (int t = 0; t < 500; t++) {
hot.compute(1000);
}
Android میں، JIT تالیف ارتقاء کے تین مراحل سے گزری۔ پہلا مرحلہ — JIT کے بغیر Dalvik (Android 1.0–2.1): DEX بائٹ کوڈ کی خالص تشریح۔ دوسرا مرحلہ — JIT کے ساتھ Dalvik (Android 2.2–4.4): JIT مرتب کا تعارف، جس نے ایپلیکیشنز کو 2–5 گنا تیز کیا۔ تیسرا مرحلہ — ہائبرڈ JIT کے ساتھ ART (Android 7.0+): نئی صلاحیت میں JIT کی واپسی۔
Dalvik میں JIT کو ٹریس پر مبنی مرتب کے طور پر نافذ کیا گیا تھا۔ یہ انفرادی میتھڈز کا نہیں، بلکہ ہدایات کی زنجیروں (ٹریس) کا تجزیہ کرتا تھا جو بار بار ترتیب وار عملدرآمد ہوتی ہیں۔ یہ متعدد میتھڈز سمیت مکمل عملدرآمد کے راستوں کو مرتب کرنے کی اجازت دیتا تھا۔ یہ طریقہ کار چھوٹی ہدایات کیش والے موبائل پروسیسرز کے لیے مؤثر تھا، کیونکہ مرتب کردہ ٹریس L1 کیش میں سماجاتا تھا۔
Android 7.0 Nougat سے شروع ہو کر، ART میتھڈ پر مبنی JIT استعمال کرتا ہے — یہ عملدرآمد پروفائلز کی بنیاد پر انفرادی میتھڈز کو مرتب کرتا ہے۔ یہ JIT Dalvik JIT سے نمایاں طور پر تیز کام کرتا ہے: ایک میتھڈ کے لیے عام تالیف کا وقت 0.5–1 ملی سیکنڈ ہے جبکہ Dalvik میں 3–5 ملی سیکنڈ۔ مرتب کردہ کوڈ ایپلیکیشن ہیپ کے بجائے ایک علیحدہ میموری علاقے (JIT کوڈ کیش) میں محفوظ ہوتا ہے، جو بکھراو کو کم کرتا ہے۔
| پیرامیٹر | Dalvik JIT | ART JIT |
|---|---|---|
| قسم | ٹریس پر مبنی | میتھڈ پر مبنی |
| تالیف کی رفتار | 3–5 ملی سیکنڈ/میتھڈ | 0.5–1 ملی سیکنڈ/میتھڈ |
| تالیف کی حد | ~200 کالز | متحرک |
| کوڈ کیش | ایپلیکیشن ہیپ میں | JIT کوڈ کیش |
| پروفائلنگ | اندرونی | بیرونی .prof فائلیں |
JIT کا مرکزی طریقہ کار ہاٹ میتھڈ کا پتہ لگانا ہے۔ ہر میتھڈ کال ایک اندرونی کاؤنٹر بڑھاتی ہے۔ جب کاؤنٹر حد عبور کرتا ہے، میتھڈ کو “ہاٹ” نشان زد کیا جاتا ہے اور تالیف کے لیے بھیجا جاتا ہے۔ Dalvik میں، حد مقرر تھی (~200 کالز)। ART میں، کاؤنٹر ڈیوائس کے دستیاب وسائل کے مطابق متحرک طور پر ترتیب دیے جاتے ہیں۔
تالیف کے عمل میں کئی مراحل شامل ہیں۔ پہلا — بائٹ کوڈ تجزیہ: JIT ہدایات کے سلسلے کی جانچ کرتا ہے اور ڈیٹا فلو گراف بناتا ہے۔ دوسرا — بهتری: چھوٹی میتھڈز کو ان لائن کرنا، مردہ کوڈ ہٹانا، مستقل فولڈنگ۔ تیسرا — کوڈ جنریشن: بہتر کردہ گراف کو مخصوص CPU آرکیٹیکچر (ARM, ARM64, x86) کے لیے مشینی ہدایات میں تبدیل کرنا۔
// ان لائننگ کا مظاہرہ — JIT میتھڈ باڈی کو ان لائن کرے گا
public int inlineExample() {
return square(5);
}
private int square(int x) {
return x * x;
} // JIT کال کو return 5 * 5; سے بدل دے گا
JIT کی ایک خاص تکنیک — آن اسٹیک تبدیلی (OSR)۔ اگر کسی میتھڈ میں ایک لمبا لوپ ہے جو سینکڑوں تکراروں کے بعد ختم نہیں ہوتا، JIT لوپ کو “چلتے پھرتے” مرتب کر سکتا ہے اور تشریح شدہ ورژن کو عملدرآمد کے دوران ہی مرتب کردہ ورژن سے بدل سکتا ہے۔ OSR خاص طور پر حسابی کاموں کے لیے مؤثر ہے: رینڈرنگ، امیج پروسیسنگ، کرپٹوگرافی۔
JIT اور AOT دو تالیف طریقہ کار ہیں جن میں متضاد سمجھوتے ہیں۔ JIT کمپیکٹ تقسیم سائز اور موافقت کے لیے پہلی لانچ کی رفتار قربان کرتا ہے۔ AOT پہلے سیکنڈ سے زیادہ سے زیادہ کارکردگی کے لیے انسٹالیشن کا وقت اور ڈسک کی جگہ قربان کرتا ہے۔ کوئی بھی طریقہ کار مکمل طور پر بہتر نہیں ہے — انتخاب منظر نامے پر منحصر ہے۔
JIT کا بنیادی فائدہ موافقت پذیر بهتری ہے۔ JIT AOT کے لیے دستیاب نہ ہونے والی پروفائل معلومات استعمال کر سکتا ہے: صحیح آبجیکٹ کی اقسام، حقیقی کال فریکوئنسی، حقیقی برانچنگ پیٹرن۔ یہ جامد تالیف کے ساتھ ناممکن جارحانہ بهتریوں کو لاگو کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، JIT میتھڈ کالز کو ڈی ورچوئلائز کر سکتا ہے اگر عملی طور پر صرف ایک ریسیور قسم پائی جائے۔
| معیار | JIT | AOT |
|---|---|---|
| انسٹالیشن کا وقت | فوری | سائز پر منحصر |
| پہلی لانچ | سست (وارم اپ) | تیز |
| ڈسک کی جگہ | کم سے کم | +15–30% |
| موافقت | اعلی | کم |
| CPU استعمال | تالیف کے دوران چوٹیاں | مستحکم |
JIT تالیف اس وقت افضل ہے جب تیزی سے تعیناتی اور ڈسک کی جگہ کی بچت اہم ہو۔ موبائل ڈویلپمنٹ کے تناظر میں، JIT ان ایپلیکیشنز کے لیے مثالی ہے جو بارہا اپ ڈیٹ ہوتی ہیں (A/B ٹیسٹنگ، ہاٹ فکسز)۔ JIT ڈویلپمنٹ کے دوران بھی آسان ہے، جب کوڈ دن میں درجنوں بار دوبارہ بنایا جاتا ہے — تالیف میں بچایا گیا ہر سیکنڈ فیڈ بیک لوپ کو تیز کرتا ہے۔
JIT ڈویلپرز کو کئی عملی فوائد فراہم کرتا ہے۔ پہلا — چھوٹا APK سائز۔ JIT طریقہ کار کے ساتھ، APK میں صرف بائٹ کوڈ (DEX) پیک ہوتا ہے، جو مرتب کردہ مقامی کوڈ سے 20–30% کم جگہ لیتا ہے۔ محدود اندرونی اسٹوریج والے صارفین کے لیے، یہ ایک اہم فائدہ ہے۔
دوسرا فائدہ ڈیوائس موافقت ہے۔ JIT حقیقی CPU آرکیٹیکچر، RAM کی مقدار اور موجودہ لوڈ کو مدنظر رکھتے ہوئے کوڈ مرتب کرتا ہے۔ مثال کے طور پر، 2 GB RAM والے ڈیوائس پر، JIT میموری بچانے کے لیے کم جارحانہ طور پر مرتب کر سکتا ہے، جبکہ 12 GB والے فلیگ شپ پر تمام ممکنہ بهوریاں لاگو کر سکتا ہے۔ AOT تالیف، دوسری طرف، انسٹالیشن کے وقت فیصلہ مقرر کر دیتی ہے۔
بائٹ کوڈ پلیٹ فارم سے آزاد رہتا ہے، جو ایپلیکیشن کی تقسیم کو آسان بناتا ہے۔ ایک APK ARM، ARM64 اور x86 ڈیوائسز پر کام کرتا ہے، اور JIT ہر آرکیٹیکچر کے لیے مقامی کوڈ تیار کرتا ہے۔ AOT طریقہ کار کے لیے APK میں متعدد مقامی کوڈ ویریئنٹ شامل کرنے (سائز بڑھانے) یا ہر آرکیٹیکچر کے لیے علیحدہ ورژن مرتب کرنے کی ضرورت ہوگی۔
JIT کا بنیادی نقصان وارم اپ تاخیر ہے۔ صارف ایپلیکیشن کے پہلے سیکنڈز میں سستی محسوس کرتا ہے جبکہ JIT ہاٹ میتھڈز کو مرتب کرتا ہے۔ گیمز میں، یہ ابتدائی لیولز میں ہکلانے کے طور پر ظاہر ہوتا ہے۔ اینیمیشن والی ایپلیکیشنز میں — اسکرینوں کے درمیان پہلی منتقلی میں جھٹکے۔
دوسرا نقصان — بجلی کی کھپت۔ تالیف کا عمل CPU پر بھاری بوجھ ڈالتا ہے، وارم اپ کی مدت کے دوران بجلی کی کھپت 10–20% بڑھا دیتا ہے۔ بیٹری سے چلنے والے آلات پر، یہ بیٹری کی زندگی کم کرتا ہے۔ یہ خاص طور پر بار بار ایپلیکیشن ری اسٹارٹ والے مناظر میں نمایاں ہے (محدود میموری کے ساتھ ملٹی ٹاسکنگ، جہاں نظام عمل کو ان لوڈ اور ری لوڈ کرتا ہے)۔
ایک اور مسئلہ — JIT کیش کا بکھراو۔ مرتب کردہ کوڈ ایک مسلسل میموری علاقے میں محفوظ ہوتا ہے۔ جب نئی کلاسز لوڈ ہوتی ہیں اور اضافی میتھڈز مرتب ہوتے ہیں، کیش بکھر جاتا ہے، جس سے میموری کے انتظام کا بوجھ بڑھ جاتا ہے۔ Dalvik میں، یہ مسئلہ وقتاً فوقتاً کیش صاف کرنے سے حل کیا گیا؛ ART میں، JIT کیش ہیپ سے علیحدہ مختص ہوتی ہے اور اپنی ڈیفراگمنٹیشن حکمت عملی استعمال کرتی ہے۔
ART میں جدید طریقہ کار — ہائبرڈ تالیف، JIT اور AOT کی طاقتوں کو یکجا کرتا ہے۔ ایپلیکیشن انسٹالیشن کے دوران، کوئی تالیف نہیں کی جاتی — صرف بائٹ کوڈ کی تصدیق (verify) کی جاتی ہے۔ یہ تیز انسٹالیشن اور کم سے کم جگہ کے استعمال کو یقینی بناتا ہے۔ پہلی لانچز ہاٹ میتھڈز کی JIT تالیف کے ساتھ تشریحی موڈ میں چلتی ہیں — صارف کو لمبے انتظار کے بغیر قابل قبول کارکردگی ملتی ہے۔
متوازی طور پر، ایک پس منظر پروفائلر حقیقی استعمال کے بارے میں ڈیٹا جمع کرتا ہے۔ 2–13 مکمل ایپلیکیشن لانچز کے بعد، پروفائل کافی مکمل ہو جاتا ہے، اور نظام ہاٹ میتھڈز کو مقامی کوڈ میں مرتب کرنے کے لیے dex2oat چلاتا ہے۔ یہ آپریشن پس منظر میں اس وقت کیا جاتا ہے جب ڈیوائس لوڈڈ نہ ہو (چارجنگ، اسکرین بند)۔ پس منظر AOT مکمل ہونے کے بعد، ایپلیکیشن مکمل AOT تالیف کے برابر کارکردگی حاصل کرتی ہے۔
# پس منظر تالیف کا جبری آغاز
adb shell cmd package compile -m speed-profile -f com.example.app
# تالیف کی حالت دیکھیں
adb shell cmd package dump-profiles com.example.app
Google I/O 2017 کے مطابق، ہائبرڈ تالیف نے خالص AOT کے مقابلے میں ایپلیکیشن انسٹالیشن کا وقت 30–50% کم کیا۔ سسٹم پارٹیشن پر قبضہ کردہ ڈسک کی جگہ 20–30% کم ہوئی۔ اسی وقت، پس منظر کی تالیف کے بعد کارکردگی مکمل AOT کی سطح سے مماثل ہے۔ واحد منظر نامہ جہاں ہائبرڈ AOT سے کم تر ہے وہ انسٹالیشن کے فوراً بعد پہلی لانچ ہے: ایپلیکیشن JIT موڈ میں چلتی ہے اور 10–15% سست ہو سکتی ہے۔
اکثر پوچھے گئے سوالات
JIT ایک پروگرام کو تیز کرنے کا طریقہ ہے جہاں کوڈ پہلے سے نہیں، بلکہ چلنے کے دوران حصوں میں مشینی زبان میں ترجمہ ہوتا ہے۔ سب سے زیادہ بار بار آنے والے حصے مرتب اور کیش ہو جاتے ہیں، جبکہ نایاب حصے اپنی اصلی شکل میں رہتے ہیں۔
JIT عملدرآمد کے دوران کوڈ مرتب کرتا ہے، جگہ بچاتا ہے اور انسٹالیشن کو تیز کرتا ہے۔ AOT پہلے سے تمام کوڈ مرتب کرتا ہے — ایپلیکیشن تیزی سے شروع ہوتی ہے لیکن زیادہ ڈسک جگہ اور انسٹالیشن وقت درکار ہوتا ہے۔
JIT ہٹایا نہیں گیا — یہ ترقی پایا۔ Android 5.0 میں، JIT کے ساتھ Dalvik کو خالص AOT کے ساتھ ART سے بدل دیا گیا۔ Android 7.0 میں، JIT ایک ہائبرڈ سسٹم کے حصے کے طور پر ART میں واپس آیا جہاں یہ بہترین کارکردگی کے لیے پس منظر AOT تالیف کے ساتھ مل کر کام کرتا ہے۔
JIT CPU بوجھ کی وجہ سے وارم اپ کی مدت میں بجلی کی کھپت 10–20% بڑھاتا ہے۔ ہاٹ میتھڈ تالیف مکمل ہونے کے بعد، بجلی کی کھپت معمول کی سطح پر واپس آ جاتی ہے۔ ART کا ہائبرڈ موڈ پس منظر کی تالیف کے ذریعے ان چوٹیوں کو کم کرتا ہے۔
ہاں، گہری گنتی والے مناظر میں۔ صارف ایپلیکیشن کے پہلے سیکنڈز میں یا گیم کے شروع میں سستی محسوس کر سکتا ہے۔ Android (8.0+) کے جدید ورژنز میں، ہائبرڈ موڈ پروفائلڈ تالیف کی بدولت اس اثر کو کم کرتا ہے۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں