iOS Runtime: এটি কী, iPhone-এ অ্যাপ্লিকেশন রানটাইম পরিবেশ

iOS Runtime কী?

iOS Runtime হলো সিস্টেম কম্পোনেন্টের একটি সেট যা iOS চালিত Apple ডিভাইসে অ্যাপ্লিকেশন নির্বাহ নিশ্চিত করে। এতে Objective-C Runtime (libobjc.A.dylib লাইব্রেরি), Swift Runtime (libswiftCore.dylib), Core Foundation, Cocoa Touch ফ্রেমওয়ার্ক (UIKit, Foundation), ডায়নামিক লোডার dyld এবং মেমোরি ম্যানেজমেন্ট, থ্রেড এবং আন্তঃপ্রক্রিয়া যোগাযোগের জন্য রানটাইম পরিবেশ অন্তর্ভুক্ত।

স্থাপত্যগতভাবে, iOS Runtime তিনটি স্তরে কাজ করে। সর্বনিম্ন স্তরে — Mach-O বাইনারি ফরম্যাট এবং dyld, যা এক্সিকিউটেবল ফাইল এবং লাইব্রেরি লোড করে। মধ্যম স্তর — Objective-C Runtime এবং Swift Runtime, মেথড ডিসপ্যাচ এবং অবজেক্ট ম্যানেজমেন্টের জন্য দায়ী। উপরের স্তর — Cocoa Touch ফ্রেমওয়ার্ক (UIKit, Foundation, Core Data, Metal), যা ডেভেলপারকে API প্রদান করে।

iOS Runtime বোঝা ডেভেলপারকে জটিল সমস্যা সমাধানে সক্ষম করে: A/B টেস্টিং এবং অ্যানালিটিক্সের জন্য মেথড সুইজলিং (Method Swizzling), ডায়নামিক ক্লাস লোডিং, ARC বোঝার মাধ্যমে মেমোরি অপটিমাইজেশন, retain cycles এবং মেমোরি লিক ডিবাগিং, dyld-এর মাধ্যমে অ্যাপ্লিকেশন লঞ্চ টাইম অপটিমাইজেশন। Runtime জ্ঞান ছাড়া, সিস্টেম স্তরে প্রোফাইলিং এবং অপটিমাইজেশন অসম্ভব।

iOS Runtime কম্পোনেন্ট

Mach-O ফরম্যাট

iOS-এর জন্য অ্যাপ্লিকেশন Mach-O ফরম্যাটে (Mach Object) কম্পাইল করা হয়। Mach-O ফাইলে হেডার, লোড কমান্ড এবং সেগমেন্ট থাকে: __TEXT (কোড, কনস্ট্যান্ট), __DATA (গ্লোবাল ভেরিয়েবল, Objective-C মেটাডেটা), __LINKEDIT (সিম্বল, রিলোকেশন টেবিল)। dyld প্রথম নির্দেশ নির্বাহের আগে Mach-O পার্স করে এবং নির্ভরতা লোড করে।

Objective-C Runtime: Message Passing এবং ডায়নামিক ডিসপ্যাচ

Objective-C Runtime iOS Runtime-এর সবচেয়ে শক্তিশালী অংশ। আর্লি বাইন্ডিং সহ C++-এর বিপরীতে, Objective-C মেসেজ পাসিংয়ের মাধ্যমে লেট বাইন্ডিং ব্যবহার করে। মেথড কল [receiver message] সরাসরি ফাংশন কলে নয়, বরং objc_msgSend(receiver, @selector(message))-এ কম্পাইল করা হয়, যা অবজেক্টের ক্লাসে মেথড ইমপ্লিমেন্টেশন ডায়নামিকভাবে খুঁজে বের করে।

প্রতিটি Objective-C অবজেক্ট তার ক্লাসের জন্য isa পয়েন্টার সংরক্ষণ করে। ক্লাসে মেথড লিস্ট, মেথড ক্যাশ এবং সুপারক্লাসের পয়েন্টার থাকে। objc_msgSend বংশানুক্রমিক শৃঙ্খল ট্রাভার্স করে: ক্লাস ক্যাশ চেক করে, তারপর মেথড লিস্ট, তারপর সুপারক্লাসে যায়। যদি মেথড না পাওয়া যায়, তাহলে ফরওয়ার্ডিং ট্রিগার হয়: resolveInstanceMethod, forwardingTargetForSelector এবং forwardInvocation।

Method Swizzling হলো একটি কৌশল যা runtime-এ IMP (ইমপ্লিমেন্টেশন পয়েন্টার) বিনিময়ের মাধ্যমে মেথড ইমপ্লিমেন্টেশন তাৎক্ষণিকভাবে পরিবর্তন করতে দেয়। এটি A/B টেস্টিং, অ্যানালিটিক্স (স্বয়ংক্রিয় স্ক্রিন ট্র্যাকিং) এবং মনিটরিংয়ের জন্য ব্যবহৃত হয়। চরম প্রয়োজন ছাড়া প্রোডাকশনের জন্য সুপারিশ করা হয় না, কারণ এটি OS আপডেটের সাথে বিরোধ করতে পারে।

উদাহরণ: Objective-C-তে Method Swizzling

// viewDidLoad ট্র্যাকিংয়ের জন্য Method Swizzling
#import 

@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];

        SEL originalSelector = @selector(viewDidLoad);
        SEL swizzledSelector = @selector(swizzled_viewDidLoad);

        Method originalMethod = class_getInstanceMethod(
            class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(
            class, swizzledSelector);

        BOOL didAddMethod = class_addMethod(
            class,
            originalSelector,
            method_getImplementation(swizzledMethod),
            method_getTypeEncoding(swizzledMethod)
        );

        if (didAddMethod) {
            class_replaceMethod(
                class,
                swizzledSelector,
                method_getImplementation(originalMethod),
                method_getTypeEncoding(originalMethod)
            );
        } else {
            method_exchangeImplementations(
                originalMethod, swizzledMethod);
        }
    });
}

- (void)swizzled_viewDidLoad {
    // ইভেন্ট ট্র্যাকিং
    NSLog(@"View Did Load: %@", self.class);
    // মূল ইমপ্লিমেন্টেশন কল করা
    [self swizzled_viewDidLoad];
}

@end

UIViewController (Tracking) ক্যাটাগরি অ্যাপ্লিকেশনের সকল UIViewController-এ viewDidLoad-কে swizzled_viewDidLoad দিয়ে প্রতিস্থাপন করে। dispatch_once একবারের সুইজলিং নিশ্চিত করে। class_addMethod ডাবল সুইজলিং এবং সুপারক্লাসের সাথে বিরোধ প্রতিরোধ করে। এটি কন্ট্রোলার সোর্স কোড পরিবর্তন না করে অ্যানালিটিক্সে স্বয়ংক্রিয় স্ক্রিন ভিউ ট্র্যাকিংয়ের জন্য ব্যবহৃত হয়।

isa পয়েন্টার এবং Tagged Pointers

আধুনিক iOS-এ (arm64), Apple isa পয়েন্টার অপটিমাইজ করেছে: এটি শুধু একটি ক্লাস ঠিকানা নয়, বরং একটি বিট ফিল্ড (non-pointer isa) যাতে মেমোরি ম্যানেজমেন্ট ফ্ল্যাগ এবং ক্লাস তথ্য থাকে। Tagged pointers আরেকটি অপটিমাইজেশন: ছোট NSNumber, NSDate এবং NSString মান হিপে অবজেক্ট হিসেবে নয়, বরং সরাসরি পয়েন্টারে সংরক্ষণ করা হয়, যা malloc এবং retain/release-এর ওভারহেড দূর করে। Tagged pointer isa-এর সর্বনিম্ন গুরুত্বপূর্ণ বিট দ্বারা চিহ্নিত করা হয়।

Swift Runtime: স্ট্যাটিক ডিসপ্যাচ এবং অপটিমাইজেশন

Swift Runtime Objective-C Runtime থেকে মৌলিকভাবে ভিন্ন: Swift ডিফল্টভাবে ক্লাস মেথডের জন্য vtable এবং value types ও এক্সটেনশন মেথডের জন্য direct call-এর মাধ্যমে স্ট্যাটিক ডিসপ্যাচ ব্যবহার করে। ডায়নামিক ডিসপ্যাচ শুধুমাত্র @objc বা dynamic দিয়ে চিহ্নিত মেথডের জন্য ব্যবহৃত হয়। এটি Objective-C-এর তুলনায় 40% পর্যন্ত পারফরম্যান্স উন্নতি প্রদান করে।

Value types (struct, enum) Swift-এ Objective-C থেকে একটি মূল পার্থক্য। এগুলি স্ট্যাকে বা অন্য অবজেক্টের ভিতরে সংরক্ষিত হয়, retain/release ব্যবহার করে না এবং রেফারেন্স কাউন্টিংয়ের জন্য ARC-তে অংশগ্রহণ করে না। Struct-এর isa পয়েন্টার নেই এবং এটি objc_msgSend-এর মাধ্যমে পাঠানো যায় না। Protocol witnesses হলো প্রোটোকলের জন্য vtable-এর একটি অ্যানালগ, যা existential container-এর জন্য ডায়নামিক ডিসপ্যাচ সক্ষম করে।

Swift Runtime-এ রিফিকেশন সহ generics (mangled symbols-এর মাধ্যমে reified generics) এবং string, array, dictionary, set অপটিমাইজ করার জন্য COW (Copy-on-Write) অন্তর্ভুক্ত। একটি কালেকশন কপি করার সময়, প্রকৃত কপি শুধুমাত্র তখনই ঘটে যখন কপিগুলির একটি পরিবর্তন করা হয়। এটি ফাংশনের মধ্যে কালেকশন পাস করার সময় ওভারহেড কমিয়ে দেয়।

Swift বনাম Objective-C ডিসপ্যাচ

import Foundation

// Swift: স্ট্যাটিক ডিসপ্যাচ (ক্লাসের জন্য vtable)
class Animal {
    func makeSound() { print("...") }  // vtable
}

class Dog: Animal {
    override func makeSound() { print("Woof") }  // vtable override
}

// @objc dynamic: Objective-C Runtime ডিসপ্যাচ
class Cat: Animal {
    @objc dynamic override func makeSound() {
        print("Meow")
    }  // objc_msgSend
}

// Struct — কোনো runtime ডিসপ্যাচ নেই
struct Cow {
    func makeSound() { print("Moo") }  // direct call
}

// Protocol with protocol witness
protocol SoundMaker {
    func makeSound()
}

struct Duck: SoundMaker {
    func makeSound() { print("Quack") }
}

// একজিস্টেনশিয়াল কন্টেইনার ব্যবহার
let soundMakers: [SoundMaker] = [Dog(), Cow(), Duck()]
for maker in soundMakers {
    maker.makeSound()  // protocol witness dispatch
}

// পারফরম্যান্স টেস্টিং
func testDispatch() {
    let dog = Dog()
    let cat = Cat()
    var cow = Cow()

    let start = CFAbsoluteTimeGetCurrent()
    for _ in 0..<1000000 {
        dog.makeSound()  // vtable: ~3ns
        cat.makeSound()  // objc_msgSend: ~15ns
        cow.makeSound()  // direct: ~1ns
    }
    let elapsed = CFAbsoluteTimeGetCurrent() - start
    print("Elapsed: (elapsed) sec")
}

উদাহরণটি Swift-এ তিন ধরনের ডিসপ্যাচ প্রদর্শন করে: ক্লাসের (Dog) জন্য vtable, @objc dynamic (Cat)-এর জন্য objc_msgSend এবং struct (Cow)-এর জন্য direct call। একজিস্টেনশিয়াল কন্টেইনার ([SoundMaker])-এ প্রোটোকল উইটনেস ওভারহেড যোগ করে। বাস্তবে, Swift যেখানে সম্ভব স্ট্যাটিক ডিসপ্যাচ বেছে নেয়, যা C-এর কাছাকাছি পারফরম্যান্স প্রদান করে।

Swift Runtime এবং Objective-C ব্রিজ

Swift Runtime Objective-C Runtime-এর সাথে সম্পূর্ণ সামঞ্জস্যের জন্য ডিজাইন করা হয়েছে। NSObject থেকে ইনহেরিট করা যেকোনো Swift ক্লাস স্বয়ংক্রিয়ভাবে Objective-C Runtime-এ রেজিস্টার হয় এবং objc_msgSend-এর মাধ্যমে কল করা যায়। @objc অ্যাট্রিবিউট Swift মেথডকে Objective-C থেকে অ্যাক্সেসযোগ্য করে। স্ট্রিং ব্রিজ: Objective-C API-তে (toll-free bridging) পাস করার সময় Swift String স্বয়ংক্রিয়ভাবে NSString-এ ব্রিজ হয়।

ARC: স্বয়ংক্রিয় রেফারেন্স কাউন্টিং এবং মেমোরি ম্যানেজমেন্ট

ARC (Automatic Reference Counting) iOS-এ একটি মেমোরি ম্যানেজমেন্ট সিস্টেম যা কম্পাইল সময়ে কাজ করে। কম্পাইলার (Clang) অবজেক্ট লাইফটাইম বিশ্লেষণ করে এবং স্বয়ংক্রিয়ভাবে retain/release/autorelease কল সন্নিবেশ করে। ডেভেলপারকে ম্যানুয়ালি সেগুলি কল করার প্রয়োজন নেই — iOS 5-এর আগের Manual Retain-Release (MRR)-এর বিপরীতে। ARC Objective-C এবং Swift অবজেক্টের স্তরে কাজ করে, কিন্তু value types (struct, enum)-এর জন্য নয়।

প্রতিটি Objective-C এবং Swift ক্লাস অবজেক্টের একটি রেফারেন্স কাউন্ট (retain count) আছে, যা non-pointer isa-এর ভিতরে extra_rc ফিল্ডে সংরক্ষিত। যখন একটি অবজেক্ট তৈরি হয়, retain count = 1। retain-এ কাউন্টার বাড়ে, release-এ কমে। যখন কাউন্টার 0-এ পৌঁছায়, অবজেক্টটি dealloc (Objective-C) বা deinit (Swift)-এর মাধ্যমে ডিলোকেট হয়। ARC থ্রেড-সুরক্ষিত: retain/release পারমাণবিক অপারেশন (OSAtomicIncrement32/OSAtomicDecrement32) ব্যবহার করে।

Retain cycles ARC-এর প্রধান সমস্যা। যদি অবজেক্ট A-এর B-তে strong রেফারেন্স থাকে, এবং B-এর A-তে strong রেফারেন্স থাকে, তাহলে উভয় অবজেক্ট কখনই ডিলোকেট হবে না কারণ তাদের রেফারেন্স কাউন্ট কখনই শূন্যে পৌঁছাবে না। সমাধান হলো weak রেফারেন্স (Objective-C-তে __weak, Swift-এ weak) বা unowned রেফারেন্স। Weak রেফারেন্স retain count বাড়ায় না এবং অবজেক্ট ডিলোকেট হলে স্বয়ংক্রিয়ভাবে শূন্য (nil) হয়।

Instruments-এর মাধ্যমে Retain Cycles ডিবাগিং

import Foundation

// Retain cycle উদাহরণ
class Parent {
    var child: Child?
    deinit { print("Parent deallocated") }
}

class Child {
    var parent: Parent?  // strong — retain cycle তৈরি করে!
    deinit { print("Child deallocated") }
}

var parent: Parent? = Parent()
var child: Child? = Child()
parent?.child = child
child?.parent = parent  // চক্র: Parent -> Child -> Parent
parent = nil
child = nil
// deinit কল হয়নি — মেমোরি লিক!

// সমাধান: weak
class WeakChild {
    weak var parent: Parent?  // weak — retain count বাড়ায় না
    deinit { print("WeakChild deallocated") }
}

// সমাধান: unowned (নিশ্চিত লাইফটাইমের জন্য)
class UnownedChild {
    unowned let parent: Parent
    init(parent: Parent) { self.parent = parent }
    deinit { print("UnownedChild deallocated") }
}

// Instruments-এর মাধ্যমে যাচাই
func profileMemory() {
    // 1. Instruments > Leaks চালান
    // 2. অবজেক্ট তৈরি করে এমন কর্ম সম্পাদন করুন
    // 3. লিকের জন্য Leaks পরীক্ষা করুন
    // 4. Allocations-এ dealloc ছাড়া অবজেক্ট খুঁজুন
    for _ in 0..<1000 {
        let p = Parent()
        let c = WeakChild()
        p.child = c as? Child
        // c.parent = p — যোগ করছি না, weak
    }
}

Parent এবং Child-এর মধ্যে retain cycle উদাহরণ: উভয়েই একে অপরের strong রেফারেন্স ধারণ করে, ARC কাউন্টার শূন্য করতে পারে না। সমাধান Child-এ weak parent। Parent ডিলোকেট হলে weak স্বয়ংক্রিয়ভাবে শূন্য হয়। unowned সেই ক্ষেত্রের জন্য যখন parent-এর জীবনকাল child-এর চেয়ে বেশি হওয়ার নিশ্চয়তা আছে (যেমন, viewController এবং view)। Retain cycles তাড়াতাড়ি সনাক্ত করতে Instruments > Leaks ব্যবহার করুন।

Autorelease Pool

Autorelease pool হলো স্পষ্ট মালিকানা ছাড়া তৈরি অবজেক্টের জন্য বিলম্বিত রিলিজ প্রক্রিয়া। Swift এবং Objective-C-তে @autoreleasepool { } একটি পুল তৈরি করে যা ব্লকের শেষে খালি হয়, পুলের প্রতিটি অবজেক্টে release পাঠিয়ে। এটি লুপে (হাজার হাজার অস্থায়ী অবজেক্ট তৈরি) এবং RunLoop ছাড়া ব্যাকগ্রাউন্ড থ্রেডে অত্যন্ত গুরুত্বপূর্ণ। UIKit RunLoop প্রতিটি পুনরাবৃত্তিতে প্রধান autorelease pool স্বয়ংক্রিয়ভাবে খালি করে।

dyld: ডায়নামিক লোডার এবং অ্যাপ্লিকেশন লঞ্চ

dyld (dynamic link editor) হলো সিস্টেম লোডার যা iOS অ্যাপ্লিকেশন লঞ্চ করার সময় Mach-O এক্সিকিউটেবল ফাইল এবং সম্পর্কিত ডায়নামিক লাইব্রেরি (dylib) লোড করার জন্য দায়ী। dyld /usr/lib/dyld-এ অবস্থিত এবং libSystem-এর অংশ। লোডিং প্রক্রিয়ায় বেশ কয়েকটি ধাপ অন্তর্ভুক্ত: Mach-O পার্সিং, নির্ভরতা লোডিং (Library Loader, LC_LOAD_DYLIB), ঠিকানা রিলোকেশন (ASLR), Objective-C Runtime ইনিশিয়ালাইজেশন এবং main() কল করা।

অ্যাপ্লিকেশন লঞ্চ সময় গুরুত্বপূর্ণভাবে dyld-এর উপর নির্ভর করে: যত বেশি ডায়নামিক লাইব্রেরি এবং Objective-C ক্লাস, তত বেশি pre-main time। Apple +load মেথডের সংখ্যা কমানোর সুপারিশ করে (এগুলি main-এর আগে নির্বাহিত হয়), সেগুলিকে +initialize (অলস ইনিশিয়ালাইজেশন) দিয়ে প্রতিস্থাপন করুন। 2020 সাল থেকে, Apple iOS-এ প্রিবিল্ট dyld ক্যাশ ব্যবহার করে: সিস্টেম লাইব্রেরিগুলি একক ক্যাশে প্রি-লিংক করা হয়, যা লোডিং দ্রুত করে।

Pre-main Time মাপা

import Foundation

// DYLD_PRINT_STATISTICS-এর মাধ্যমে লঞ্চ সময় মাপা
// Xcode-এ: Edit Scheme > Run > Arguments > Environment Variables
// DYLD_PRINT_STATISTICS = 1
// DYLD_PRINT_STATISTICS_DETAILS = 1

// Pre-main time-এর প্রোগ্রামেটিক মাপ
@main
struct AppMain {
    static func main() {
        let launchStart = CFAbsoluteTimeGetCurrent()

        // UIApplicationMain এখানে ঘটে
        AppDelegate.main()

        let launchEnd = CFAbsoluteTimeGetCurrent()
        let preMainTime = launchEnd - launchStart
        print("Pre-main time: (preMainTime) sec")
    }
}

// অপটিমাইজেশন: +load-কে +initialize দিয়ে প্রতিস্থাপন
class OptimizedClass {
    // ❌ +load main-এর আগে নির্বাহিত হয়
    // override class func load() { }

    // ✅ +initialize প্রথম অ্যাক্সেসে নির্বাহিত হয়
    static let shared = OptimizedClass()
    private init() {
        // এখানে ইনিশিয়ালাইজেশন
    }
}

// dylib সংখ্যার অপটিমাইজেশন
// স্ট্যাটিক লাইব্রেরি একত্রিত করলে LC_LOAD_DYLIB-এর সংখ্যা কমে
// শুধুমাত্র ব্যবহৃত Objective-C ক্লাস লিংক করতে -ObjC ফ্ল্যাগ ব্যবহার করুন
// Xcode: Build Settings > Mach-O Type > Static Library

pre-main time মাপতে, Xcode স্কিমে DYLD_PRINT_STATISTICS ব্যবহার করুন। আউটপুট মোট সময়, dylib লোডিং সময়, rebase/bind সময়, Objective-C সেটআপ সময় এবং ইনিশিয়ালাইজার সময় দেখায়। লক্ষ্য মান: কোল্ড স্টার্টের জন্য মোট < 400ms, ওয়ার্ম স্টার্টের জন্য < 200ms। অপটিমাইজেশন: লাইব্রেরি মার্জ করা, +load-কে +initialize দিয়ে প্রতিস্থাপন করা, Objective-C ক্লাসের সংখ্যা কমানো (Swift ব্যবহার করুন), ডায়নামিক ফ্রেমওয়ার্কের ন্যূনতম সংখ্যা।

dsc (dyld Shared Cache)

dyld shared cache iOS-এ প্রি-লিংকড সিস্টেম লাইব্রেরির ক্যাশ। সমস্ত সিস্টেম dylib (UIKit, Foundation, CoreGraphics) একটি ফাইলে একত্রিত: /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64। এটি প্রতিটি সিস্টেম লাইব্রেরি আলাদাভাবে লোড করার প্রয়োজন দূর করে — dyld ক্যাশে অ্যাক্সেস করে, যা স্টার্টআপ উল্লেখযোগ্যভাবে দ্রুত করে। 10+ ডায়নামিক ফ্রেমওয়ার্কযুক্ত অ্যাপ্লিকেশনগুলি সবচেয়ে বেশি বিলম্ব অনুভব করে, কারণ কাস্টম dylib dsc-তে অন্তর্ভুক্ত নয়।