iOS Runtime: τι είναι, περιβάλλον εκτέλεσης εφαρμογών στο iPhone

Τι είναι το iOS Runtime;

iOS Runtime — η συλλογή στοιχείων συστήματος που εξασφαλίζουν την εκτέλεση εφαρμογών σε συσκευές Apple υπό iOS. Περιλαμβάνει το 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 επιτρέπει στον προγραμματιστή να λύνει πολύπλοκες εργασίες: swizzling μεθόδων (Method Swizzling) για δοκιμές A/B και αναλυτική, δυναμική φόρτωση κλάσεων, βελτιστοποίηση μνήμης μέσω κατανόησης του ARC, εντοπισμό σφαλμάτων retain cycles και διαρροών μνήμης, βελτιστοποίηση χρόνου εκκίνησης εφαρμογής μέσω dyld. Χωρίς γνώση του runtime, η προφιλοποίηση και βελτιστοποίηση σε επίπεδο συστήματος είναι αδύνατες.

Στοιχεία του iOS Runtime

Μορφή Mach-O

Οι εφαρμογές για iOS μεταγλωττίζονται σε μορφή Mach-O (Mach Object). Το αρχείο Mach-O περιέχει κεφαλίδα (header), εντολές φόρτωσης (load commands) και τμήματα (segments): __TEXT (κώδικας, σταθερές), __DATA (καθολικές μεταβλητές, μεταδεδομένα Objective-C), __LINKEDIT (σύμβολα, πίνακες μετατόπισης). Το dyld αναλύει το Mach-O και φορτώνει τις εξαρτήσεις πριν από την εκτέλεση της πρώτης εντολής.

Objective-C Runtime: message passing και δυναμική αποστολή

Objective-C Runtime — το πιο ισχυρό μέρος του iOS Runtime. Σε αντίθεση με τη C++ με πρώιμη σύνδεση (early binding), η Objective-C χρησιμοποιεί όψιμη σύνδεση (late binding) μέσω message passing. Η κλήση μεθόδου [receiver message] μεταγλωττίζεται όχι ως άμεση κλήση συνάρτησης, αλλά ως objc_msgSend(receiver, @selector(message)), που βρίσκει δυναμικά την υλοποίηση της μεθόδου στην κλάση του αντικειμένου.

Κάθε αντικείμενο Objective-C αποθηκεύει έναν δείκτη isa στην κλάση του. Η κλάση περιέχει λίστα μεθόδων (method list), κρυφή μνήμη μεθόδων (method cache) και δείκτη στην υπερκλάση. Το objc_msgSend διατρέχει την αλυσίδα κληρονομικότητας: ελέγχει την κρυφή μνήμη της κλάσης, στη συνέχεια τη method list, έπειτα πηγαίνει στην υπερκλάση. Εάν η μέθοδος δεν βρεθεί, ενεργοποιείται το forward: resolveInstanceMethod, forwardingTargetForSelector και forwardInvocation.

Method Swizzling — τεχνική αντικατάστασης της υλοποίησης μεθόδου επί τόπου μέσω ανταλλαγής IMP (implementation pointer) στο runtime. Χρησιμοποιείται για δοκιμές A/B, αναλυτική (αυτόματη παρακολούθηση οθονών) και παρακολούθηση. Δεν συνιστάται σε παραγωγή χωρίς απόλυτη ανάγκη, καθώς μπορεί να έρχεται σε σύγκρουση με ενημερώσεις του λειτουργικού συστήματος.

Παράδειγμα: Method Swizzling σε Objective-C

// Method Swizzling για παρακολούθηση viewDidLoad
#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) αντικαθιστά το viewDidLoad με swizzled_viewDidLoad σε όλα τα UIViewController στην εφαρμογή. Το dispatch_once εγγυάται μοναδικό swizzling. Το class_addMethod αποτρέπει διπλό swizzling και συγκρούσεις με υπερκλάσεις. Χρησιμοποιείται για αυτόματη παρακολούθηση εμφάνισης οθονών στην αναλυτική χωρίς αλλαγή του πηγαίου κώδικα των ελεγκτών.

Δείκτης isa και tagged pointers

Στα σύγχρονα iOS (arm64), η Apple βελτιστοποίησε τον δείκτη isa: δεν είναι απλώς μια διεύθυνση κλάσης, αλλά ένα πεδίο bit (non-pointer isa) που περιέχει σημαίες διαχείρισης μνήμης και πληροφορίες για την κλάση. Tagged pointers — μια άλλη βελτιστοποίηση: οι μικρές τιμές NSNumber, NSDate και NSString αποθηκεύονται όχι ως αντικείμενα στο heap, αλλά απευθείας στον δείκτη, εξαλείφοντας την επιβάρυνση malloc και retain/release. Το tagged pointer αναγνωρίζεται από το λιγότερο σημαντικό bit του isa.

Swift Runtime: στατική αποστολή και βελτιστοποίηση

Swift Runtime διαφέρει ριζικά από το Objective-C Runtime: η Swift χρησιμοποιεί προεπιλεγμένα στατική αποστολή (static dispatch) μέσω vtable για μεθόδους κλάσης και direct call για value types και extension methods. Η δυναμική αποστολή (dynamic dispatch) χρησιμοποιείται μόνο για μεθόδους που επισημαίνονται με @objc ή dynamic. Αυτό δίνει αύξηση απόδοσης έως 40% σε σύγκριση με την Objective-C.

Value types (struct, enum) στη Swift — η βασική διαφορά από την Objective-C. Αποθηκεύονται στη στοίβα (stack) ή μέσα σε άλλο αντικείμενο, δεν χρησιμοποιούν retain/release και δεν συμμετέχουν στο ARC για τον μετρητή αναφορών. Το Struct δεν έχει δείκτη isa και δεν μπορεί να σταλεί μέσω objc_msgSend. Protocol witnesses — το ανάλογο του vtable για πρωτόκολλα, που επιτρέπει δυναμική αποστολή για το existential container.

Το Swift Runtime περιλαμβάνει επίσης generics με εκ νέου υλοποίηση (reified generics μέσω mangled symbols) και COW (Copy-on-Write) για βελτιστοποίηση των string, array, dictionary, set. Κατά την αντιγραφή συλλογής, η πραγματική αντιγραφή συμβαίνει μόνο όταν τροποποιείται ένα από τα αντίγραφα. Αυτό ελαχιστοποιεί την επιβάρυνση κατά τη μεταβίβαση συλλογών μεταξύ συναρτήσεων.

Swift vs Objective-C αποστολή

import Foundation

// Swift: στατική αποστολή (vtable για class)
class Animal {
    func makeSound() { print("...") }  // vtable
}

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

// @objc dynamic: Objective-C Runtime dispatch
class Cat: Animal {
    @objc dynamic override func makeSound() {
        print("Meow")
    }  // objc_msgSend
}

// Struct — no runtime dispatch
struct Cow {
    func makeSound() { print("Moo") }  // direct call
}

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

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

// Χρήση existential container
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: vtable για class (Dog), objc_msgSend για @objc dynamic (Cat) και direct call για struct (Cow). Τα protocol witnesses στο existential container ([SoundMaker]) προσθέτουν επιβάρυνση. Στην πράξη, η Swift επιλέγει στατική αποστολή όπου είναι δυνατό, παρέχοντας απόδοση κοντά στη C.

Swift Runtime και γέφυρα Objective-C

Swift Runtime έχει σχεδιαστεί για πλήρη συμβατότητα με το Objective-C Runtime. Κάθε κλάση Swift που κληρονομεί το NSObject καταγράφεται αυτόματα στο Objective-C Runtime και μπορεί να κληθεί μέσω objc_msgSend. Το χαρακτηριστικό @objc καθιστά τη μέθοδο Swift προσβάσιμη από Objective-C. Γέφυρα String: το Swift String γεφυρώνεται αυτόματα σε NSString κατά τη μεταβίβαση σε Objective-C API (toll-free bridging).

ARC: Automatic Reference Counting και διαχείριση μνήμης

ARC (Automatic Reference Counting) — σύστημα διαχείρισης μνήμης στο iOS, που λειτουργεί στο στάδιο μεταγλώττισης. Ο μεταγλωττιστής (Clang) αναλύει τον κύκλο ζωής των αντικειμένων και εισάγει αυτόματα κλήσεις retain/release/autorelease. Ο προγραμματιστής δεν χρειάζεται να τις καλεί χειροκίνητα — σε αντίθεση με το Manual Retain-Release (MRR) πριν από το iOS 5. Το ARC λειτουργεί σε επίπεδο αντικειμένων Objective-C και Swift class, αλλά όχι για value types (struct, enum).

Κάθε αντικείμενο Objective-C και Swift class έχει έναν μετρητή αναφορών (retain count), που αποθηκεύεται στο πεδίο extra_rc εντός του non-pointer isa. Κατά τη δημιουργία αντικειμένου, retain count = 1. Κατά το retain, ο μετρητής αυξάνεται· κατά το release, μειώνεται. Όταν ο μετρητής φτάσει στο 0, το αντικείμενο αποδεσμεύεται μέσω dealloc (Objective-C) ή deinit (Swift). Το ARC είναι thread-safe: το retain/release χρησιμοποιεί ατομικές λειτουργίες (OSAtomicIncrement32/OSAtomicDecrement32).

Retain cycles — το κύριο πρόβλημα του ARC. Εάν το αντικείμενο A αποθηκεύει μια strong αναφορά στο B, και το B — μια strong αναφορά στο A, κανένα αντικείμενο δεν θα αποδεσμευτεί ποτέ, επειδή οι μετρητές αναφορών τους δεν θα μηδενιστούν. Λύση — αδύναμες αναφορές (__weak σε Objective-C, weak σε Swift) ή unowned. Οι αδύναμες αναφορές δεν αυξάνουν το retain count και μηδενίζονται αυτόματα (nil) κατά την αποδέσμευση του αντικειμένου.

Εντοπισμός retain cycles μέσω Instruments

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
    }
}

Παράδειγμα retain cycle μεταξύ Parent και Child: και τα δύο διατηρούν strong αναφορές το ένα στο άλλο, το ARC δεν μπορεί να μηδενίσει τους μετρητές. Διόρθωση — weak parent στο Child. Το weak μηδενίζεται αυτόματα κατά την αποδέσμευση του parent. unowned — για περιπτώσεις όπου η διάρκεια ζωής του parent είναι εγγυημένα μεγαλύτερη από του child (π.χ. viewController και view). Χρησιμοποιήστε το Instruments > Leaks για τον εντοπισμό retain cycles σε πρώιμο στάδιο.

Autorelease pool

Autorelease pool — μηχανισμός καθυστερημένης αποδέσμευσης για αντικείμενα που δημιουργήθηκαν χωρίς ρητή ιδιοκτησία. Το @autoreleasepool { } σε Swift και Objective-C δημιουργεί μια δεξαμενή που αδειάζει στο τέλος του μπλοκ, στέλνοντας release σε κάθε αντικείμενο στη δεξαμενή. Κρίσιμο σε βρόχους (δημιουργία χιλιάδων προσωρινών αντικειμένων) και σε νήματα παρασκηνίου χωρίς RunLoop. Το UIKit RunLoop αδειάζει αυτόματα την κύρια δεξαμενή autorelease σε κάθε επανάληψη.

dyld: δυναμικός φορτωτής και εκκίνηση εφαρμογής

dyld (dynamic link editor) — φορτωτής συστήματος υπεύθυνος για τη φόρτωση εκτελέσιμων αρχείων Mach-O και σχετικών δυναμικών βιβλιοθηκών (dylib) κατά την εκκίνηση εφαρμογής iOS. Το dyld βρίσκεται στη διαδρομή /usr/lib/dyld και είναι μέρος του libSystem. Η διαδικασία φόρτωσης περιλαμβάνει διάφορα στάδια: ανάλυση του Mach-O, φόρτωση εξαρτήσεων (Library Loader, LC_LOAD_DYLIB), μετατόπιση διευθύνσεων (ASLR), αρχικοποίηση του Objective-C Runtime και κλήση της main().

Ο χρόνος εκκίνησης εφαρμογής (launch time) εξαρτάται κρίσιμα από το dyld: όσο περισσότερες δυναμικές βιβλιοθήκες και κλάσεις Objective-C, τόσο μεγαλύτερος είναι ο pre-main time. Η Apple συνιστά την ελαχιστοποίηση του αριθμού μεθόδων +load (εκτελούνται πριν από τη main), αντικαθιστώντας τις με +initialize (τεμπέλικη αρχικοποίηση). Από το 2020, η Apple χρησιμοποιεί προκατασκευασμένη dyld cache στο iOS: οι βιβλιοθήκες συστήματος είναι προ-συνδεδεμένες σε μια ενιαία κρυφή μνήμη, επιταχύνοντας τη φόρτωση.

Μέτρηση 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
// Χρησιμοποιήστε τη σημαία -ObjC για σύνδεση μόνο χρησιμοποιούμενων κλάσεων Objective-C
// Xcode: Build Settings > Mach-O Type > Static Library

Για τη μέτρηση του pre-main time χρησιμοποιήστε το DYLD_PRINT_STATISTICS στο σχήμα Xcode. Η έξοδος θα δείξει total time, dylib loading time, rebase/bind time, Objective-C setup time και initializer time. Στόχοι: total < 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.