ProGuard — یہ کیا ہے، خصوصیات اور مبہم سازی کی ترتیب

ProGuard کیا ہے؟

ProGuard ایک آزادانہ طور پر تقسیم کردہ ٹول ہے جو Java بائٹ کوڈ پروسیس کرتا ہے، جسے Guardsquare نے تیار کیا ہے۔ یہ Android SDK میں شامل ہے اور تین اہم کام انجام دیتا ہے: کوڈ سکڑاؤ، اصلاح اور مبہم سازی۔ ProGuard ایپلی کیشن اور اس کے انحصار کے تمام بائٹ کوڈ کا تجزیہ کرتا ہے، غیر استعمال شدہ کلاسز اور طریقوں کی نشاندہی کرتا ہے، انہیں ہٹاتا ہے، اور پھر باقی کوڈ کو مبہم کرتا ہے۔

تاریخ اور مقام

ProGuard کو 2000 میں Eric Lafortune نے Java ایپلی کیشن آپٹیمائزیشن ٹول کے طور پر بنایا تھا۔ 2008 میں Android کی آمد کے ساتھ، ProGuard Android SDK میں ضم ہو گیا اور ایپلی کیشن کے تحفظ کے لیے معیاری ٹول بن گیا۔ Guardsquare کے اعدادوشمار (2024) کے مطابق، ProGuard Google Play پر 80% سے زیادہ ایپلی کیشنز میں استعمال ہوتا ہے، جس میں بڑے بینکوں اور ٹیکنالوجی کمپنیوں کی ایپس شامل ہیں۔

ProGuard کوڈ کیسے پروسیس کرتا ہے

ProGuard چار مراحل میں پروسیسنگ کرتا ہے۔ پہلے مرحلے (سکڑاؤ) میں، ٹول ایپلی کیشن میں داخلے کے نکات کا تجزیہ کرتا ہے اور تعین کرتا ہے کہ عملدرآمد کے دوران کون سی کلاسز، طریقے اور فیلڈز قابل رسائی ہیں۔ دوسرے مرحلے (اصلاح) میں، ProGuard کارکردگی بہتر بنانے کے لیے بائٹ کوڈ کو تبدیل کرتا ہے۔ تیسرا مرحلہ (مبہم سازی) شناخت کنندگان کا نام تبدیل کرتا ہے۔ آخری مرحلے میں، preverify ورچوئل مشین پر بائٹ کوڈ کی تصدیق کے لیے ضروری میٹا ڈیٹا شامل کرتا ہے۔

ProGuard کی اہم خصوصیات

آئیے ProGuard کے تین اہم کاموں میں سے ہر ایک کا تفصیل سے جائزہ لیں: سکڑاؤ، اصلاح اور مبہم سازی۔ ہر میکانزم کو سمجھنا ٹول کو بہترین طریقے سے ترتیب دینے میں مدد دے گا۔

کوڈ سکڑاؤ

ProGuard داخلے کے نکات (main طریقہ، Activity، BroadcastReceiver) سے کال گراف کا تجزیہ کرتا ہے اور غیر استعمال شدہ کوڈ کو ہٹاتا ہے۔ Retrofit، OkHttp اور Gson جیسی لائبریریوں والے ایک عام Android پروجیکٹ میں، سکڑاؤ 40% تک بائٹ کوڈ ہٹا سکتا ہے، جس میں غیر استعمال شدہ لائبریری طریقے، ڈیبگ کوڈ اور ٹیسٹ کلاسز شامل ہیں۔ یہ براہ راست APK کا سائز کم کرتا ہے اور ایپلی کیشن لوڈنگ کے وقت کو مختصر کرتا ہے۔

اصلاح

اصلاح کے مرحلے میں، ProGuard بائٹ کوڈ کی 20 سے زیادہ مختلف تبدیلیاں کرتا ہے: چھوٹے طریقوں کو ان لائن کرنا، غیر استعمال شدہ پیرامیٹرز کو ہٹانا، منطقی اظہار کو آسان بنانا، ایک جیسے کوڈ بلاکس کو ضم کرنا۔ مثال کے طور پر، چھوٹے گیٹر اور سیٹر کو براہ راست فیلڈ تک رسائی سے تبدیل کیا جا سکتا ہے۔ اصلاح ایپلی کیشن کی ساخت کے لحاظ سے کوڈ کے عملدرآمد کو 5-15% تک تیز کر سکتی ہے۔

مبہم سازی

مبہم سازی ProGuard میں کلاسز، طریقوں اور فیلڈز کو چھوٹے حروف کی ترتیب میں دوبارہ نام دے کر کام کرتی ہے: a، b، c، a.a، a.b وغیرہ۔ نام تبدیل شدہ عناصر کے تمام حوالہ جات پورے کوڈ میں خود بخود اپ ڈیٹ ہو جاتے ہیں۔ یہ نوٹ کرنا ضروری ہے کہ مبہم سازی پروگرام کے رویے کو نہیں بدلتی، یہ صرف ڈی کمپائل شدہ کوڈ کو سمجھنا مشکل بناتی ہے۔ لائبریریوں اور عوامی API کو keep اصولوں کے ذریعے مبہم سازی سے خارج کر دینا چاہیے۔

// ProGuard مبہم سازی سے پہلے
public class LoginManager {
    public User authenticateUser(String username, String password) {
        // توثیق کی منطق
    }
}

// ProGuard مبہم سازی کے بعد
public class a {
    public Object a(String b, String c) {
        // دوبارہ نامزد کردہ شناخت کنندگان کے ساتھ وہی منطق
    }
}

Android پروجیکٹ میں ProGuard ترتیب

ProGuard ترتیب Android ایپلی کیشن بلڈ سیٹ اپ میں ایک اہم مرحلہ ہے۔ غلط اصول ضروری کلاسز کو ہٹانے اور اس کے نتیجے میں ریلیز ورژن میں کریش کا سبب بن سکتے ہیں۔

build.gradle میں بنیادی سیٹ اپ

Android پروجیکٹ میں ProGuard کو فعال کرنے میں ریلیز بلڈ کی قسم کے لیے minifyEnabled فلیگ کو true پر سیٹ کرنا شامل ہے۔ معیاری ProGuard اصول proguard-android-optimize.txt فائل میں Android SDK کے ساتھ شامل ہیں۔ حسب ضرورت اصول ایک علیحدہ proguard-rules.pro فائل میں شامل کیے جاتے ہیں۔ بلڈ کے دوران، ProGuard پہلے معیاری اصول لاگو کرتا ہے، پھر حسب ضرورت، جو بنیادی ترتیب کو اوور رائڈ کرنے کی اجازت دیتا ہے۔

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt'
            ), 'proguard-rules.pro'
        }
    }
}

proguard-rules.pro فائل

حسب ضرورت اصول فائل میں مخصوص پروجیکٹ کے لیے ہدایات ہوتی ہیں۔ عام اصولوں میں عکاسی کے ذریعے استعمال ہونے والی کلاسز، Gson/Moshi سیریلائزیشن کے لیے ڈیٹا ماڈل، لائبریری کال بیک انٹرفیس، اور مخصوص تشریحات سے تشریح شدہ کلاسز کو محفوظ رکھنا شامل ہے۔ ہر ہدایت -keep، -dontwarn یا -keepclassmembers کلیدی لفظ سے شروع ہوتی ہے اور کلاس کے پیٹرن کی وضاحت کرتی ہے جسے ProGuard کو تبدیل نہیں کرنا چاہیے۔

# Gson کے لیے ڈیٹا ماڈل محفوظ کریں
-keep class com.example.data.model.** { *; }

# عکاسی کے ذریعے استعمال ہونے والی کلاسز محفوظ کریں
-keep class * implements com.google.gson.TypeAdapterFactory

# لائبریری انتباہات کو نظر انداز کریں
-dontwarn okhttp3.internal.**
-dontwarn retrofit2.**

# اینام محفوظ کریں (ProGuard خصوصیت)
-keep class * extends java.lang.Enum { *; }

ProGuard کے اصول: keep، dontwarn اور دیگر

ProGuard ترتیب کے قواعد میں ہدایات کی کئی اقسام شامل ہیں، ہر ایک پروسیسنگ کے ایک مخصوص پہلو کا انتظام کرتی ہے۔ آئیے درست ترتیب کے لیے ضروری اہم ہدایات دیکھتے ہیں۔

عکاسی اور متحرک لوڈنگ

ProGuard عکاسی (Class.forName())، ServiceLoader یا متحرک DEX فائل لوڈنگ کے ذریعے لوڈ کردہ کوڈ کا جامد طور پر تجزیہ نہیں کر سکتا۔ اگر کوئی کلاس اپنے سٹرنگ نام سے بنائی جاتی ہے، تو ProGuard کو اس کے وجود کے بارے میں معلوم نہیں ہوتا اور وہ اسے غیر استعمال شدہ سمجھ کر ہٹا سکتا ہے۔ ایسی تمام کلاسز کو -keep کے ذریعے واضح طور پر محفوظ کرنا چاہیے۔ ProGuard کو فعال کرنے کے بعد ریلیز بلڈز میں کریش کی یہ سب سے عام وجہ ہے۔

لائبریریاں اور AAR انحصار

لائبریریاں اکثر اپنے ProGuard اصول شامل کرتی ہیں، جو AAR فائل میں شامل consumer-rules.pro کے ذریعے خود بخود بلڈ میں شامل ہو جاتے ہیں۔ Android Gradle Plugin بلڈ کے دوران ان اصولوں کو خود بخود لاگو کرتا ہے۔ ڈویلپر کو صرف اس بات کو یقینی بنانے کی ضرورت ہے کہ تمام استعمال شدہ لائبریریاں درست اصول فراہم کریں، اور اگر ضروری ہو تو پروجیکٹ میں انہیں مکمل کریں۔

ProGuard مسائل کی ڈیبگنگ

ProGuard کو فعال کرنے کے بعد جب خرابیاں آتی ہیں، تو اسٹیک ٹریس کو ڈی ابہام کرنے کے لیے میپنگ فائل استعمال کریں۔ تشخیص کے لیے، -whyareyoukeeping کلید استعمال کریں، جو آؤٹ پٹ بلڈ میں کلاس کے محفوظ رہنے کی وجہ دکھاتی ہے۔ عارضی طور پر -optimizationpasses اور -obfuscation کو غیر فعال کرنے سے مسئلہ کو مقامی بنانے میں مدد ملتی ہے۔ Guardsquare کے مطابق، 80% ProGuard مسائل عکاسی کلاسز کے لیے -keep اصول شامل کرنے سے حل ہوتے ہیں۔

ProGuard بمقابلہ R8: موازنہ اور منتقلی

Android Gradle Plugin 3.4 (2019) کی ریلیز کے ساتھ، Google نے R8 متعارف کرایا — ProGuard کا جانشین، جو براہ راست D8/R8 کمپائلر میں ضم ہے۔ 2023 تک، R8 نے AGP 8.0 میں ProGuard کو مکمل طور پر تبدیل کر دیا، لیکن پروجیکٹ کی منتقلی کے لیے آرکیٹیکچرل فرق کو سمجھنا اہم ہے۔

آرکیٹیکچرل فرق

ProGuard DEX میں تبدیلی سے پہلے Java بائٹ کوڈ (.class فائلیں) پروسیس کرنے والے ایک علیحدہ ٹول کے طور پر کام کرتا ہے۔ R8 DEX کمپائلر میں ضم ہے اور کوڈ کو نچلی سطح پر پروسیس کرتا ہے، جو ProGuard میں دستیاب نہ ہونے والی اصلاح کی اجازت دیتا ہے۔ R8 ڈی شوگرنگ بھی سپورٹ کرتا ہے — Java 8+ نحوی شکر کو پرانے Android API لیولز کے لیے پسماندہ مطابقت رکھنے والے کوڈ میں تبدیل کرنا۔

R8 کے فوائد

Google Android Performance Team (2025) کے مطابق، R8 یکساں اصولوں کے ساتھ ProGuard کے مقابلے میں 10-15% بہتر کوڈ سکڑاؤ فراہم کرتا ہے۔ R8 تیز تر ہے — بلڈ کا وقت 20-30% کم ہوتا ہے۔ مزید برآں، R8 کلاس فائل کی سطح کے بجائے DEX کی سطح پر تجزیہ کی بدولت زیادہ مردہ کوڈ ہٹاتا ہے۔ R8 ProGuard کے اصولوں کی نحوی ساخت کے ساتھ مکمل طور پر مطابقت رکھتا ہے، جو ڈویلپر کے لیے منتقلی کو شفاف بناتا ہے۔

منتقلی کا عمل

ProGuard سے R8 پر سوئچ کرنا آسان ہے: AGP 8.0+ میں، R8 بطور ڈیفالٹ استعمال ہوتا ہے۔ پرانے پروجیکٹس کے لیے، آپ کو classpath سے ProGuard ہٹانا ہوگا اور gradle.properties کو اپ ڈیٹ کرنا ہوگا: android.enableR8=true۔ ProGuard کے اصول زیادہ تر معاملات میں بغیر تبدیلی کے R8 کے ساتھ مطابقت رکھتے ہیں۔ سوئچ کرنے کے بعد تمام ہدف آلات پر ریلیز بلڈ کی جانچ کرنے کی سفارش کی جاتی ہے، کیونکہ R8 اس کوڈ کو ہٹا سکتا ہے جسے ProGuard رکھتا تھا۔