iOS核心知识点解析atomic和nonatomic区别,以及作用? atomic与nonatomic的主要区别在于系统

一、属性修饰符与内存管理

atomic和nonatomic区别及作用

atomic与nonatomic的主要区别在于系统自动生成的getter/setter方法实现不同：

atomic：系统自动生成的getter/setter方法会进行加锁操作，保证读写操作的原子性
nonatomic：系统自动生成的getter/setter方法不会进行加锁操作，性能更高

atomic的局限性与线程安全：

系统生成的getter/setter方法会进行加锁操作，但仅保证单个getter或setter操作的原子性
不能防止对象在getter/setter调用时被其他线程释放，不提供对象生命周期的保障
真正的线程安全需要依靠ARC、信号量、串行队列等机制实现

实际开发建议：

大多数情况下使用nonatomic，因为性能更好
即使使用atomic也不能保证线程安全，仍需额外的同步机制
在需要高性能的场景下，优先考虑nonatomic配合其他线程安全方案

weak 和 assign 的区别

核心差异：

weak策略在属性所指的对象遭到摧毁时，系统会自动将指针设置为nil，防止野指针
assign策略在对象摧毁后，指针仍指向原内存地址，产生野指针，容易导致崩溃

使用场景：

weak必须用于OC对象，主要用于解决循环引用问题
assign可用于修饰基本数据类型（int、float等）和非OC对象
weak通常用于delegate、block等可能引起循环引用的场景

属性关键字默认值

ARC环境下默认关键字：

基本数据类型：atomic, readwrite, assign
普通的OC对象：atomic, readwrite, strong

开发建议：

显式声明属性关键字，提高代码可读性
根据实际需求选择合适的修饰符，不要依赖默认值

copy关键字的使用

使用场景：

NSString、NSArray、NSDictionary等不可变对象
- 防止可变对象在不知情情况下被修改
- 保护封装性，确保属性值不会无意间变动
Block的使用
- MRC下：block默认在栈区，使用copy可以放到堆区
- ARC下：编译器会自动将作为属性被strong或copy修饰的block从栈拷贝到堆
- 编码惯例：虽然ARC下strong和copy效果相同，但Apple仍推荐使用copy

iOS字符串修饰推荐copy的原因

1. 防止可变字符串被意外修改

// 危险情况：使用strong
@property (nonatomic, strong) NSString *strongString;
@property (nonatomic, copy) NSString *copyString;

NSMutableString *mutableString = [NSMutableString stringWithString:@"Hello"];
self.strongString = mutableString;  // 只是指针赋值
self.copyString = mutableString;    // 创建不可变副本

[mutableString appendString:@" World"];

NSLog(@"strongString: %@", self.strongString);  // 输出: "Hello World" - 被修改了！
NSLog(@"copyString: %@", self.copyString);      // 输出: "Hello" - 保持原值

2. 保证字符串的不可变性

// 确保属性值不会被外部改变
@interface User : NSObject
@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy) NSString *email;
@end

// 使用时的安全性
NSMutableString *mutableName = [NSMutableString stringWithString:@"张三"];
User *user = [[User alloc] init];
user.name = mutableName;  // 自动创建不可变副本

[mutableName appendString:@"改了"];  // 不影响user.name
NSLog(@"用户名: %@", user.name);  // 仍然是"张三"

3. 线程安全性考虑

// 多线程环境下更安全
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    NSMutableString *mutableStr = [NSMutableString stringWithString:@"Thread1"];
    self.copyProperty = mutableStr;  // 创建副本，线程安全
});

dispatch_async(dispatch_get_global_queue(0, 0), ^{
    [mutableStr appendString:@"Modified"];  // 不影响copyProperty的值
});

不同修饰符的对比

strong vs copy 行为差异：

@property (nonatomic, strong) NSString *strongStr;  // 直接引用，可能被修改
@property (nonatomic, copy) NSString *copyStr;      // 创建副本，保持稳定

NSMutableString *mutable = [NSMutableString stringWithString:@"初始值"];

// 赋值时的不同行为
_strongStr = mutable;        // 直接指向mutable的内存地址  
_copyStr = [mutable copy];   // 创建新的不可变字符串副本

NSMutableString应该用strong

1. 使用copy的错误示例

// 错误：用copy修饰NSMutableString
@property (nonatomic, copy) NSMutableString *mutableString;

// 使用时会出现问题
NSMutableString *tempString = [NSMutableString stringWithString:@"Hello"];
self.mutableString = tempString;  // 实际上得到的是NSString，不是NSMutableString

// 编译通过，但运行时会崩溃！
[self.mutableString appendString:@" World"];  // ❌ 崩溃：unrecognized selector

2. 正确的strong修饰

// 正确：用strong修饰NSMutableString
@property (nonatomic, strong) NSMutableString *mutableString;

// 正常使用
NSMutableString *tempString = [NSMutableString stringWithString:@"Hello"];
self.mutableString = tempString;  // 保持可变性

[self.mutableString appendString:@" World"];  // ✅ 正常工作
NSLog(@"%@", self.mutableString);  // 输出："Hello World"

不同类型字符串的修饰符选择

属性类型	推荐修饰符	原因
`NSString`	`copy`	防止被意外修改，保证不可变性
`NSMutableString`	`strong`	保持可变性，避免类型错误

特殊情况处理

需要可变副本的情况

@property (nonatomic, copy) NSString *originalString;

// 如果需要基于不可变字符串创建可变字符串
- (void)processString {
    NSMutableString *mutableCopy = [self.originalString mutableCopy];
    [mutableCopy appendString:@" processed"];
    
    // 或者直接创建新的可变字符串
    NSMutableString *newMutable = [NSMutableString stringWithString:self.originalString];
    [newMutable appendString:@" new content"];
}

防御性编程

// 如果外部可能传入NSString或NSMutableString
@property (nonatomic, strong) NSMutableString *mutableProperty;

- (void)setMutableProperty:(NSMutableString *)mutableProperty {
    // 确保传入的是可变字符串
    if ([mutableProperty isKindOfClass:[NSMutableString class]]) {
        _mutableProperty = [mutableProperty mutableCopy];  // 创建新的可变副本
    } else {
        _mutableProperty = [mutableProperty mutableCopy];  // 从NSString创建可变副本
    }
}

面试回答要点

核心原则：

NSString → 用copy（保证不可变性）
NSMutableString → 用strong（保持可变性）

原因分析：

对NSMutableString使用copy会得到NSString，失去可变方法
这会导致运行时崩溃（unrecognized selector）
strong保持对象的原始类型和功能

最佳实践：

根据属性的设计用途选择修饰符
如果属性需要可变操作，必须用strong
如果属性应该是不可变的，用copy并声明为NSString类型

一句话总结： 需要可变用strong，需要不可变用copy。

特殊情况说明

1. 性能考虑

// 对于确定不可变的NSString，copy不会产生额外开销
NSString *immutableString = @"固定的字符串";
self.copyProperty = immutableString;  // 不会真正拷贝，只是引用计数+1

2. 例外情况

// 以下情况可能不需要copy：
@property (nonatomic, strong) NSMutableString *mutableString;  // 本身就是可变的
@property (nonatomic, strong) NSString *internalTempString;    // 内部临时使用

面试回答要点

核心原因：

防止可变字符串被外部修改，保证数据一致性
确保属性值的不可变性和线程安全
符合NSString的设计哲学（不可变类）

实际效果：

传入NSString时：copy与strong行为相同，无性能损失
传入NSMutableString时：copy创建安全副本，strong可能被意外修改

最佳实践：

所有NSString属性都应该用copy修饰
只有明确需要可变时才使用NSMutableString
这是iOS开发中的通用约定和最佳实践

深拷贝与浅拷贝：

// 浅拷贝 - 只拷贝指针
NSArray *shallowCopy = [originalArray copy];

// 深拷贝 - 拷贝内容
NSArray *deepCopy = [originalArray mutableCopy];

二、面向对象特性

面向对象三大特性

1. 封装

隐藏对象的属性和实现细节，仅对外提供公共访问方式
将变化隔离，便于使用，提高复用性和安全性
通过访问控制修饰符（@public、@protected、@private）实现

2. 继承

提高代码复用性，建立类之间的关系
子类拥有父类的所有成员变量和方法
继承是多态的前提，OC不支持多继承

3. 多态

核心定义： 同一接口有多种不同的实现方式，不同对象对同一消息的不同响应方式

实现方式：

子类通过重写父类方法改变实现
通过父类类型指针指向子类对象
运行时根据对象实际类型调用正确方法

多态的优势：

提高程序扩展性和可维护性
接口与实现分离，降低耦合度
支持运行时动态绑定

OC的动态特性

为什么OC是动态语言：

动态语言：程序在运行时可以改变其结构
动态类型语言：类型检查在运行时进行

OC动态特性的三个方面：

1. 动态类型

// 运行时确定类型
id object = someObject;
if ([object isKindOfClass:[NSString class]]) {
    // 运行时类型检查
}

2. 动态绑定

将调用方法的确定推迟到运行时
编译时方法调用不与代码绑定，消息发送后才确定被调用代码
通过动态类型和绑定实现真正的运行时多态

3. 动态加载

在运行期间加载需要的资源或可执行代码
支持插件化架构和热更新

多继承的实现方式

OC不支持直接多继承，但可通过以下方式模拟：

消息转发机制

- (id)forwardingTargetForSelector:(SEL)aSelector {
    if ([alternateObject respondsToSelector:aSelector]) {
        return alternateObject;
    }
    return [super forwardingTargetForSelector:aSelector];
}

协议（Protocol）
- 实现"多接口"而非真正的多继承
- 一个类可以遵循多个协议
组合模式
- 持有多个其他类的实例
- 通过方法转发复用功能
类别（Category）
- 为已有类添加方法
- 无法添加实例变量，不是真正的继承

三、Runtime与消息机制

Runtime基础概念

Runtime是什么：

OC的运行时库，为OC的动态特性提供支持
OC代码在运行时转为Runtime API调用
允许程序在运行时改变结构、添加函数等

Runtime核心功能：

对象模型和类结构管理
消息传递和方法调用机制
方法交换和动态解析
类型编码和内存管理

消息机制详解

消息发送三大阶段：

1. 消息发送流程

objc_msgSend(receiver, selector, arg1, arg2, ...)

具体流程：

通过isa指针找到类对象
在类的方法缓存中快速查找
在当前类的方法列表中查找
通过superClass指针在父类链中查找
优化机制：方法缓存、方法排序提高查找效率

2. 动态方法解析

// 实例方法解析
+ (BOOL)resolveInstanceMethod:(SEL)sel {
    if (sel == @selector(dynamicMethod)) {
        class_addMethod(self, sel, (IMP)dynamicMethodImplementation, "v@:");
        return YES;
    }
    return [super resolveInstanceMethod:sel];
}

// 类方法解析
+ (BOOL)resolveClassMethod:(SEL)sel {
    if (sel == @selector(dynamicClassMethod)) {
        class_addMethod(object_getClass(self), sel, (IMP)dynamicClassMethodImplementation, "v@:");
        return YES;
    }
    return [super resolveClassMethod:sel];
}

3. 消息转发机制

第一步：快速转发

- (id)forwardingTargetForSelector:(SEL)aSelector {
    if (aSelector == @selector(missingMethod)) {
        return [BackupObject new]; // 指定备用接收者
    }
    return [super forwardingTargetForSelector:aSelector];
}

第二步：完整转发

// 返回方法签名
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector {
    if (aSelector == @selector(missingMethod)) {
        return [NSMethodSignature signatureWithObjCTypes:"v@:"];
    }
    return [super methodSignatureForSelector:aSelector];
}

// 处理转发
- (void)forwardInvocation:(NSInvocation *)anInvocation {
    if ([backupObject respondsToSelector:anInvocation.selector]) {
        [anInvocation invokeWithTarget:backupObject];
    } else {
        [super forwardInvocation:anInvocation];
    }
}

Runtime实际应用

关联对象

objc_setAssociatedObject(object, key, value, policy)

方法交换

method_exchangeImplementations(method1, method2)

动态创建类

Class newClass = objc_allocateClassPair([NSObject class], "NewClass", 0);
objc_registerClassPair(newClass);

属性遍历

unsigned int count;
objc_property_t *properties = class_copyPropertyList([class class], &count);

四、Category与扩展

Category的使用与原理

使用场合：

为现有类添加实例方法或类方法
为类添加协议实现
通过Runtime关联对象的方式添加属性
分解庞大的类文件，按功能模块分离
方法交换，实现AOP编程

实现原理：

编译结构：struct category_t存储方法、属性、协议信息
运行时合并：Runtime将Category数据合并到类信息中
方法覆盖：后编译的Category方法会"覆盖"先前的方法（实际是顺序查找）

Category与Extension的区别

特性	Class Extension	Category
编译时机	编译时包含在类信息中	运行时合并到类信息中
成员变量	可以声明	不能添加
主要用途	封装私有接口	扩展类功能
可见性	通常写在.m文件中	公开接口

load与initialize方法

load方法：

调用时机：Runtime加载类、分类时调用，main函数之前
调用顺序：父类 → 子类 → 分类（同级别按编译顺序）
可以继承，但不应该主动调用

initialize方法：

调用时机：类第一次收到消息时调用
调用顺序：分类 → 子类 → 父类（同级别按编译顺序）
线程安全：Runtime确保initialize方法线程安全

对比总结：

特性	load方法	initialize方法
调用时机	main函数前	类第一次收到消息时
调用顺序	父类→子类→分类	分类→子类→父类
显式调用	不应调用	可通过消息机制触发
线程安全	安全	Runtime保证安全
使用场景	方法交换、注册	类级别初始化

load和initialize调用时机对比

1. load方法 - main函数之前调用

调用时机：

在main函数执行之前，程序启动时自动调用
在Runtime加载类、分类时立即调用

调用顺序：

父类的load → 子类的load → 分类的load
类之间的调用顺序与编译顺序有关

// 示例
@implementation ParentClass
+ (void)load {
    NSLog(@"ParentClass load");  // 最先调用
}
@end

@implementation ChildClass  
+ (void)load {
    NSLog(@"ChildClass load");   // 其次调用
}
@end

@implementation ChildClass (Category)
+ (void)load {
    NSLog(@"ChildClass Category load");  // 最后调用
}
@end

// 输出顺序：
// ParentClass load
// ChildClass load  
// ChildClass Category load

2. initialize方法 - 第一次使用时调用

调用时机：

在类第一次收到消息时调用（懒加载）
在main函数执行之后，实际使用时才调用

调用顺序：

分类的initialize → 子类的initialize → 父类的initialize
如果子类没实现，会调用父类的initialize

// 示例
@implementation ParentClass
+ (void)initialize {
    NSLog(@"ParentClass initialize");
}
@end

@implementation ChildClass
// 不实现initialize方法
@end

// 使用时：
ChildClass *obj = [[ChildClass alloc] init];  // 第一次使用
// 输出：ParentClass initialize（子类没实现，调用父类的）

底层原理分析

load方法的调用机制

// Runtime源码中的调用逻辑
void load_images(const char *path __unused, const struct mach_header *mh) {
    // 1. 准备load方法列表
    prepare_load_methods((const headerType *)mh);
    
    // 2. 按顺序调用load方法
    call_load_methods();
}

static void call_load_methods(void) {
    // 先调用所有类的load方法
    call_class_loads();
    
    // 再调用所有分类的load方法  
    call_category_loads();
}

initialize方法的调用机制

// 消息发送时的调用
id objc_msgSend(id self, SEL op, ...) {
    // 如果类还没有初始化
    if (!cls->isInitialized()) {
        // 调用initialize方法
        class_initialize(cls);
    }
    // 继续消息发送
}

实际应用场景

load方法的典型用途

// 1. 方法交换（Method Swizzling）
@implementation UIViewController (Tracking)
+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Method originalMethod = class_getInstanceMethod(self, @selector(viewDidLoad));
        Method swizzledMethod = class_getInstanceMethod(self, @selector(swizzled_viewDidLoad));
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}
@end

// 2. 注册类或组件
@implementation MyManager
+ (void)load {
    [ModuleManager registerClass:self];
}
@end

initialize方法的典型用途

// 1. 初始化静态变量
@implementation MyClass
static NSDictionary *config;

+ (void)initialize {
    if (self == [MyClass class]) {
        config = @{@"key": @"value"};  // 初始化配置
    }
}

// 2. 设置默认值
@implementation MyView
+ (void)initialize {
    if (self == [MyView class]) {
        // 设置默认样式
        [[self appearance] setBackgroundColor:[UIColor whiteColor]];
    }
}
@end

重要区别总结

特性	load方法	initialize方法
调用时机	main函数之前	类第一次使用时
调用次数	仅1次	每个类1次（可能因子类多次）
调用顺序	父类→子类→分类	分类→子类→父类
自动调用	是	是（通过消息机制）
线程安全	安全（单线程）	Runtime保证安全
使用场景	方法交换、注册	初始化配置、设置默认值

面试回答要点

load方法在main之前的原因：

Runtime需要在程序正式运行前完成类的准备工作
保证所有类在main函数执行前都已完成基础配置
为方法交换、组件注册等提供时机

initialize方法在之后的原因：

采用懒加载机制，提高启动性能
只有真正用到的类才需要初始化
避免加载大量不使用的类

关键记忆点：

load：程序启动时，自动调用，用于基础配置
initialize：第一次使用时，懒加载，用于类级别初始化
两者都是线程安全的，但使用场景完全不同

Category添加成员变量

不能直接添加成员变量，但可通过关联对象模拟：

#import <objc/runtime.h>

static void *kAssociatedObjectKey = &kAssociatedObjectKey;

@implementation UIView (Custom)
- (void)setCustomProperty:(id)value {
    objc_setAssociatedObject(self, kAssociatedObjectKey, value, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}

- (id)customProperty {
    return objc_getAssociatedObject(self, kAssociatedObjectKey);
}
@end

五、Block编程

Block原理与本质

Block本质：

OC对象，内部封装函数调用及调用环境
底层结构：struct __block_impl包含isa指针、函数指针、描述信息、捕获变量

内存位置：

全局Block：存储在数据区，不捕获外部变量
栈Block：存储在栈上，作用域结束可能被销毁
堆Block：存储在堆上，需要手动管理内存（MRC）或自动管理（ARC）

__block修饰符

作用：

允许在Block内部修改外部局部变量的值
将变量内存管理从栈转移到堆，确保Block执行时变量有效

原理：

__block修饰的变量被编译为结构体对象
结构体内部持有变量的实际值
Block通过指针访问和修改这个结构体

使用注意：

避免循环引用，结合__weak使用
注意MRC环境下的内存管理

Block属性修饰符

copy原因：

将Block从栈复制到堆，确保Block的生命周期
栈Block在作用域结束后会被销毁

ARC环境说明：

编译器会自动将作为属性被strong或copy修饰的block从栈拷贝到堆
编码惯例仍推荐使用copy

使用注意事项：

循环引用：使用__weak打破强引用环
内存管理：MRC环境下需要手动copy/release
变量捕获：理解自动变量、__block变量的区别
线程安全：多线程环境中使用Block要注意同步

Block修改变量规则

不需要__block的情况：

NSMutableArray *array = [NSMutableArray array];
void (^block)(void) = ^{
    [array addObject:@"object"]; // 修改数组内容，不需要__block
};

需要__block的情况：

__block NSMutableArray *array = [NSMutableArray array];
void (^block)(void) = ^{
    array = [NSMutableArray new]; // 重新赋值，需要__block
};

总结： 修改指针指向对象内容不需要__block，改变指针本身的值需要__block

六、KVO与KVC机制

KVO实现原理

实现机制：

动态子类：Runtime动态生成NSKVONotifying_前缀的子类
ISA指向：instance对象的isa指向新子类
方法重写：重写setter方法，调用_NSSetXXXValueAndNotify
通知流程：
- willChangeValueForKey:
- 调用父类原始setter
- didChangeValueForKey:
触发监听：调用观察者的observeValueForKeyPath:ofObject:change:context:

手动触发KVO

- (void)viewDidLoad {
    [super viewDidLoad];
    Person *person = [[Person alloc] init];
    [person addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:nil];
    
    [person willChangeValueForKey:@"name"];
    person.name = @"NewName"; // 实际改变属性值
    [person didChangeValueForKey:@"name"];
}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    NSLog(@"被观测对象：%@, 被观测的属性：%@, 值的改变: %@, 携带信息:%@", object, keyPath, change, context);
}

核心原理：

动态子类：Runtime创建NSKVONotifying_XXX子类
ISA指针：修改被观察对象的isa指针指向新子类
方法重写：重写setter方法，插入通知逻辑
通知流程：willChange → 原始setter → didChange

关键特点：

基于Runtime的动态特性
使用ISA-Swizzling技术
只有通过setter方法修改才会触发
直接修改成员变量不会触发

常见问题：

为什么KVO有时不触发？→ 检查是否使用了setter方法
KVO性能如何？→ 动态创建有开销，适合低频变化
如何手动触发？→ 成对调用willChange/didChange

一句话总结： KVO通过Runtime动态创建子类并重写setter方法，在属性变化时自动发送通知。

KVC原理与过程

赋值过程（setValue:forKey:）：

查找setter方法：set<Key>: → _set<Key>
找到方法则调用并传递参数
未找到且accessInstanceVariablesDirectly返回YES，查找成员变量：_<key> → _is<Key> → <key> → is<Key>
找到成员变量则直接赋值
都未找到则调用setValue:forUndefinedKey:，默认抛出异常

取值过程类似，按getter方法、成员变量顺序查找。

七、内存管理与调试

对象内存结构

OC对象内存占用：

系统为NSObject对象分配16字节（malloc_size获取）
NSObject对象内部使用8字节（64位环境，class_getInstanceSize获取）
内存对齐：系统分配内存按16字节对齐

类信息存储：

对象方法、属性、成员变量、协议信息：类对象中
类方法：元类对象中
成员变量具体值：实例对象中
类定义信息：编译后的二进制数据段中

指针与对象关系

isa指针指向：

实例对象的isa → 类对象
类对象的isa → 元类对象
元类对象的isa → 基类的元类对象
形成闭环：基类的元类对象的isa → 基类的类对象

nil对象消息发送：

不会崩溃：objc_msgSend判断receiver为nil时直接返回
返回值：对象类型返回nil，基础数据类型返回0，结构体返回zero-filled结构体
注意：向[NSNull null]发送消息会崩溃

BAD_ACCESS错误调试

错误原因： 内存访问错误，访问野指针或已释放对象

调试方法：

全局断点：快速定位问题代码行
僵尸对象诊断：检测对已释放对象的访问
Analyze静态分析：检测潜在内存问题
Address Sanitizer：Xcode内置内存错误检测工具
重写respondsToSelector：记录崩溃前访问的最后一个对象

八、RunLoop机制

RunLoop基础概念

RunLoop是什么：

运行循环，管理线程的事件和消息
保持线程存活：没有事件时休眠，有事件时唤醒
主线程RunLoop自动创建并运行，子线程需手动启动

主要作用：

保持线程存活，避免空转消耗CPU
处理输入源、定时器、界面刷新等事件
在特定模式下处理特定事件，提高效率

RunLoop与线程关系

一对一关系：

每条线程有唯一对应的RunLoop对象
RunLoop保存在全局Dictionary，线程指针为key
主线程RunLoop自动创建，子线程第一次获取时创建
线程结束时RunLoop销毁

RunLoop Mode机制

Mode的作用：

隔离不同来源的事件，提高处理效率
避免不相关事件的干扰

主要Mode：

kCFRunLoopDefaultMode：默认模式，处理大多数常规事件
UITrackingRunLoopMode：界面跟踪模式，保证滑动流畅性
kCFRunLoopCommonModes：占位模式，包含Default和Tracking模式

Timer与RunLoop

正确使用方式：

NSTimer *timer = [NSTimer timerWithTimeInterval:1 target:self selector:@selector(timerFired) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

解决TableView滑动时Timer不响应：

NSTimer *timer = [NSTimer timerWithTimeInterval:3 repeats:YES block:^(NSTimer * _Nonnull timer) {
    // 定时任务
}];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

RunLoop内部实现

do {
    // 1. 通知Observers：即将处理Timers
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
    
    // 2. 通知Observers：即将处理Sources
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
    
    // 3. 处理Blocks
    __CFRunLoopDoBlocks(runloop, currentMode);
    
    // 4. 处理Sources0
    __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
    
    // 5. 处理Sources1（基于Port的线程间通信）
    if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer))) {
        goto handle_msg;
    }
    
    // 6. 通知Observers：即将休眠
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
    
    // 7. 进入休眠，等待消息
    __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer));
    
    // 8. 通知Observers：结束休眠
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
    
handle_msg:
    // 处理接收到的消息
} while (!stopped);

RunLoop性能监控

卡顿监控原理：

创建监控线程观察主线程RunLoop状态
重点关注时间段：
- kCFRunLoopBeforeSources → kCFRunLoopBeforeWaiting
- kCFRunLoopAfterWaiting → 后续状态
计算耗时，超过阈值（如16ms）判定为卡顿
记录堆栈信息进行分析

实现示例：

CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
    switch (activity) {
        case kCFRunLoopAfterWaiting:
            // 记录开始时间
            break;
        case kCFRunLoopBeforeWaiting:
            // 计算耗时，判断是否卡顿
            break;
    }
});
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);

九、其他重要知识点

符号表与调试

符号表作用：

内存地址、函数名、文件名和行号的映射
将Crash的二进制堆栈信息还原为源代码信息
格式：<起始地址> <结束地址> <函数> [<文件名:行号>]

生成时机： 编译源代码、处理资源后生成DSYM文件

容错处理策略

容错注意事项：

数据校验：服务器返回数据、用户输入严格校验
类型安全：使用合适数据类型，避免类型转换错误
边界检查：数组、字典等集合操作进行边界检查
异常处理：合理使用@try-catch处理异常
防御式编程：对可能为nil的对象、可能失败的操作预判

崩溃预防策略：

方法交换：Runtime交换系统方法，添加容错逻辑
分类扩展：为常用类添加安全的操作方法
数据验证：外部输入和网络数据多层验证
日志监控：建立崩溃日志收集分析系统

iOS App启动过程

核心回答框架（30秒版本）

iOS App启动分为4个主要阶段：

dyld加载 - 加载可执行文件和动态库
Runtime初始化 - 注册类、执行+load方法
main函数执行 - UIApplicationMain启动
UI初始化 - 创建Application Delegate和Root VC

详细回答（2-3分钟完整版）

阶段1：dyld动态链接器加载

// 系统级别加载过程
1. 内核加载App → 创建进程空间
2. dyld加载Mach-O可执行文件
3. 递归加载所有依赖的动态库
4. 进行符号绑定和重定位
5. 调用libSystem_init进行系统初始化

关键点：

dyld是Apple的动态链接器
加载主程序和各动态库到内存
处理符号解析和地址绑定

阶段2：Runtime运行时初始化

// Objective-C运行时准备
1. 调用各镜像的初始化函数
2. 调用所有类的+load方法（调用顺序：父类→子类→分类）
3. 初始化C++静态对象
4. 执行__attribute__((constructor))标记的函数

关键点：

+load方法在main函数之前调用
Runtime完成类注册、方法注册
此时App的Objective-C环境已就绪

阶段3：main函数执行

// main.m文件
int main(int argc, char * argv[]) {
    @autoreleasepool {
        // UIApplicationMain是App的入口点
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

UIApplicationMain的作用：

创建UIApplication单例对象
创建AppDelegate对象并设置为Application的delegate
启动主运行循环（Main RunLoop）
调用AppDelegate的application:didFinishLaunchingWithOptions:

阶段4：UI初始化阶段

// AppDelegate.m
- (BOOL)application:(UIApplication *)application 
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    
    // 1. 创建UIWindow
    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    
    // 2. 创建根视图控制器
    UIViewController *rootVC = [[ViewController alloc] init];
    self.window.rootViewController = rootVC;
    
    // 3. 显示窗口
    [self.window makeKeyAndVisible];
    
    return YES;
}

启动时间优化相关

1. 启动时间分类

// 冷启动时间 = pre-main时间 + main之后时间

// pre-main时间（可测量）
// 在Xcode设置环境变量：DYLD_PRINT_STATISTICS = 1
// 输出示例：
Total pre-main time: 1.3 seconds
    dylib loading time: 0.8s
    rebase/binding time: 0.2s  
    ObjC setup time: 0.1s
    initializer time: 0.2s

2. 优化建议

pre-main优化：

减少动态库数量（合并或使用静态库）
减少ObjC类数量（清理无用代码）
减少+load方法，改用+initialize
控制C++全局变量数量

main之后优化：

延迟初始化非必要组件
异步执行耗时操作
使用启动图缓存UI状态

面试扩展知识点

1. 启动状态区分

// 冷启动：App完全重新启动
// 热启动：App从后台恢复到前台
// 温启动：系统保留了部分资源，但需要重新创建UI

2. 启动过程中的关键方法调用顺序

1. +load (所有类和分类)
2. main()
3. UIApplicationMain()
4. application:didFinishLaunchingWithOptions:
5. applicationDidBecomeActive:
6. viewDidLoad (根控制器)
7. viewWillAppear:
8. viewDidAppear:

3. Swift App的启动差异

// Swift App没有main.m文件
// 使用 @main 标记AppDelegate
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    // Swift的启动流程与OC基本相同
}

简洁版回答（1分钟）

"iOS App启动主要经历4个阶段：首先dyld加载可执行文件和动态库到内存；然后Runtime初始化，调用+load方法注册所有类；接着进入main函数，UIApplicationMain创建应用实例；最后进入UI初始化阶段，创建window和根视图控制器并显示界面。"

进阶问题准备

可能追问：

+load和+initialize的区别？
- +load在main前调用，+initialize在类第一次使用时调用
如何优化启动时间？
- 减少动态库、控制+load使用、延迟初始化
dyld的作用是什么？
- 动态链接器，负责加载程序和库，解析符号
为什么要有UIApplicationMain？
- 创建应用单例，启动主运行循环，管理应用生命周期

加分项：

提到冷启动/热启动概念
知道如何测量pre-main时间
了解Swift和OC启动的差异
能结合实际优化经验

动态库的数量对启动时间的影响远大于单个动态库的代码内容多少，因为每个动态库都需要独立的文件IO、代码签名验证、内存映射和符号解析等固定开销，这些与库大小无关的系统级操作成本远高于代码内容加载的边际成本。

静态库对启动速度的影响主要体现在 链接期 和 主二进制文件大小 上，而不是运行时。

一、静态库 vs 动态库的影响对比

核心差异：

class StaticVsDynamicImpact {
    // 影响时间点对比
    let impactTiming = [
        "动态库": "运行时影响 (dyld加载阶段)",
        "静态库": "编译时影响 (链接阶段)"
    ]
    
    // 影响机制对比
    let impactMechanism = [
        "动态库": "每个库的固定开销 × 库数量",
        "静态库": "主二进制大小 × 加载系数"
    ]
}

二、静态库如何影响启动速度

1. 主二进制文件大小增长

class MainBinaryImpact {
    func analyzeSizeImpact() {
        // 静态库代码被复制到主可执行文件中
        let mainBinarySize = calculateMainBinarySize()
        
        // 影响因素：
        let factors = [
            "📏 文件IO时间": "读取更大的二进制文件",
            "🔄 Rebase成本": "更多的指针需要重定位", 
            "📝 Page Fault": "更多的代码页需要加载",
            "🔗 Binding开销": "更多的符号需要绑定"
        ]
    }
    
    func calculateLoadTimeIncrease() -> TimeInterval {
        // 大致估算：每增加1MB，启动时间增加0.5-1ms
        let sizeIncreaseMB = 10.0
        return sizeIncreaseMB * 0.75 // ≈ 7.5ms
    }
}

2. 链接期优化限制

class LinkTimeIssues {
    // 静态库在链接期的问题
    let linkTimeProblems = [
        "❌ 死代码消除困难": "链接器难以跨静态库边界优化",
        "❌ 符号重复": "多个静态库可能包含相同符号",
        "❌ 启动代码重复": "每个静态库可能有自己的初始化代码"
    ]
    
    func deadCodeElimination() {
        // 动态库: 可以整体移除未使用的库
        // 静态库: 即使只使用一个函数，也可能链接整个库
    }
}

三、实际影响程度分析

性能测试数据：

场景	配置	冷启动时间	影响因素
动态库方案	8个动态库，主二进制2MB	420ms	dyld加载开销
静态库方案	0个动态库，主二进制12MB	380ms	✅ 通常更快
混合方案	3个动态库，主二进制8MB	400ms	平衡方案

量化分析：

struct QuantitativeAnalysis {
    // 静态库的启动时间影响公式
    func calculateStaticLibraryImpact() -> TimeInterval {
        let baseStartupTime: TimeInterval = 350.0 // ms
        let sizePenaltyPerMB: TimeInterval = 0.8  // ms/MB
        let mainBinarySizeMB = 15.0
        
        return baseStartupTime + (mainBinarySizeMB * sizePenaltyPerMB)
    }
    
    // 动态库的启动时间影响公式  
    func calculateDynamicLibraryImpact() -> TimeInterval {
        let baseStartupTime: TimeInterval = 350.0 // ms
        let penaltyPerLibrary: TimeInterval = 3.0 // ms/库
        let libraryCount = 8
        
        return baseStartupTime + (Double(libraryCount) * penaltyPerLibrary)
    }
}

四、静态库的优势

为什么静态库通常更快：

class StaticLibraryAdvantages {
    let advantages = [
        "✅ 零动态库加载开销": "避免dyld的固定成本",
        "✅ 更好的编译器优化": "链接时优化(LTO)可以跨库边界",
        "✅ 减少Page Fault": "代码在主二进制中更紧凑",
        "✅ 简化依赖管理": "没有运行时库查找和验证"
    ]
    
    func optimizationBenefits() {
        // 链接时优化可以：
        let ltoBenefits = [
            "跨库内联函数",
            "消除未使用的代码",
            "更好的指令缓存局部性"
        ]
    }
}

五、静态库的劣势

潜在问题：

class StaticLibraryDrawbacks {
    let drawbacks = [
        "📱 应用大小增长": "相同代码在不同App中重复",
        "🔗 符号冲突风险": "多个静态库可能导出相同符号",
        "🔄 更新困难": "需要重新编译整个App",
        "📊 内存使用": "无法在进程间共享代码页"
    ]
    
    func memoryImpact() {
        // 如果多个App使用相同的动态库，系统可以共享内存
        // 静态库会导致每个App都有独立的代码副本
    }
}

六、实际建议

选择策略：

class SelectionStrategy {
    func shouldUseStaticLibrary() -> Bool {
        let conditions = [
            "库代码专用于当前App": true,
            "不需要进程间共享": true, 
            "库大小适中": true,
            "启动性能是关键指标": true
        ]
        
        return conditions.allSatisfy { $0.value }
    }
    
    func shouldUseDynamicLibrary() -> Bool {
        let conditions = [
            "多个App共享该库": true,
            "需要热更新能力": true,
            "库非常大": true,
            "作为插件系统": true
        ]
        
        return conditions.allSatisfy { $0.value }
    }
}

最佳实践：

struct BestPractices {
    let recommendations = [
        "🎯 核心业务代码": "使用静态库，优化启动速度",
        "🔧 共享基础组件": "考虑动态库，减少内存占用",
        "📊 第三方SDK": "优先静态库，避免dyld开销",
        "🧩 插件系统": "必须使用动态库"
    ]
}

总结

静态库会影响启动速度，但通常是正向影响：

✅ 多数情况下：静态库比动态库启动更快，因为避免了dyld的固定开销
⚠️ 影响因素：主二进制文件大小增长会带来轻微负面影响
🎯 最佳实践：对启动性能敏感的场景优先使用静态库

一句话回答：静态库通过消除dyld加载开销通常能提升启动速度，但过大的主二进制文件会轻微抵消这部分收益。

好的，这是一个非常核心的iOS开发问题。我将从概念、启动顺序到实际选型为你完整解析。

一、静态库 vs 动态库的根本区别

核心概念对比：

// 静态库 - 编译时链接
class StaticLibraryExample {
    // 代码在编译时被"复制"到主程序中
    // 就像把书页撕下来装订到你的书里
}

// 动态库 - 运行时链接  
class DynamicLibraryExample {
    // 代码在运行时被"引用"
    // 就像从图书馆借书来读
}

技术维度对比：

特性	静态库 (.a / .framework)	动态库 (.dylib / .framework)
链接时机	编译时	运行时
文件位置	嵌入主程序内部	独立文件，系统共享
内存使用	每个进程独立副本	多个进程可共享同一内存代码
代码签名	主程序统一签名	每个库独立签名验证
更新方式	重新编译整个App	可独立更新（系统库）
加载开销	无额外加载成本	每个库都有固定加载开销

二、App启动过程中的加载顺序

启动时间线：

func appLaunchTimeline() {
    // 1. 📦 内核加载主程序二进制
    loadMainExecutable()
    
    // 2. 🔗 dyld加载所有动态库
    //   按照依赖顺序：系统库 → 第三方动态库
    loadDynamicLibraries()
    
    // 3. 📝 Rebase & Binding
    //   修正所有指针地址（动态库+主程序）
    performRebasingAndBinding()
    
    // 4. 🚀 执行main()函数
    //   此时静态库代码已随主程序加载完毕
    executeMainFunction()
}

关键结论：

静态库代码随主程序二进制一起首先被加载，动态库由dyld在之后按依赖顺序加载。

三、实际开发中的选型策略

选择静态库的场景： 🎯

class StaticLibraryUseCases {
    let scenarios = [
        "🚀 对启动性能要求极高的功能": "如首页核心业务模块",
        "📱 App专属的业务组件": "不会被其他App共享的代码",
        "🔒 需要强代码保护的SDK": "避免被逆向分析实现",
        "📦 小型第三方依赖": "如网络库、工具类库",
        "⚡ 需要链接时优化(LTO)": "追求极致性能"
    ]
    
    // 实际示例
    func realWorldExamples() {
        let staticLibraries = [
            "Alamofire": "网络库 - 每个App独立使用",
            "SnapKit": "布局库 - 编译时优化效果好", 
            "R.swift": "资源安全访问 - 编译期检查",
            "App核心业务模块": "如电商商品模块、社交聊天模块"
        ]
    }
}

选择动态库的场景： 🔄

class DynamicLibraryUseCases {
    let scenarios = [
        "🏢 系统级框架": "UIKit, Foundation, CoreData等",
        "📚 多个App共享的组件": "公司内部基础组件库",
        "🧩 插件化架构": "需要运行时加载的模块",
        "🔧 App Extension": "Today Widget、Share Extension等",
        "📊 大型资源库": "包含大量图片、资源的组件",
        "🔄 需要热修复的模块": "通过更新动态库修复线上问题"
    ]
    
    // 实际示例  
    func realWorldExamples() {
        let dynamicLibraries = [
            "SwiftUI": "系统框架，多个Extension共享",
            "公司基础UI库": "所有产品线统一设计规范",
            "音视频处理库": "资源庞大，独立更新",
            "AB测试SDK": "需要动态配置和更新"
        ]
    }
}

四、实战决策框架

决策流程图：

func shouldUseStaticOrDynamic(library: Library) -> LibraryType {
    // 1. 检查系统要求
    if library.isSystemFramework {
        return .dynamic // 系统库必须是动态的
    }
    
    // 2. 检查共享需求
    if library.willBeSharedByMultipleApps {
        return .dynamic // 跨App共享选动态
    }
    
    // 3. 检查App Extension依赖
    if library.usedByAppExtensions {
        return .dynamic // Extension依赖必须是动态的
    }
    
    // 4. 检查启动性能需求
    if library.isCriticalForLaunchPerformance {
        return .static // 启动关键路径选静态
    }
    
    // 5. 默认推荐静态库
    return .static
}

性能权衡矩阵：

考量维度	静态库优势	动态库优势
启动速度	🥇 更快	🥈 稍慢
内存效率	🥈 进程独立	🥇 进程共享
更新灵活性	🥈 需重装App	🥇 可独立更新
开发体验	🥇 编译期检查	🥈 运行时发现错误
包大小	🥈 可能重复	🥇 系统共享

五、现代iOS开发的最佳实践

Swift Package Manager的默认行为：

class SPMPractice {
    // SPM默认将包编译为静态库，但可配置
    let packageConfig = """
    // Package.swift
    let package = Package(
        name: "MyPackage",
        products: [
            .library(
                name: "MyLibrary",
                type: .static, // 默认静态
                targets: ["MyLibrary"]
            ),
            .library(
                name: "MyDynamicLibrary", 
                type: .dynamic, // 显式声明动态
                targets: ["MyLibrary"]
            )
        ]
    )
    """
}

实际项目推荐配置：

struct ProjectConfiguration {
    let recommendedSetup = [
        "📱 主工程": "静态链接所有第三方库",
        "🔧 App Extension": "动态链接共享组件", 
        "🏗️ 模块化架构": "核心业务静态，共享组件动态",
        "🚀 性能敏感模块": "绝对静态（如首页、登录）"
    ]
    
    func modernApproach() {
        // 现代做法：大部分情况用静态，特殊情况用动态
        let defaultChoice = "静态库"
        let exceptionalCases = [
            "系统框架",
            "App Extension共享代码", 
            "超大型资源组件",
            "插件化系统"
        ]
    }
}

六、常见误区澄清

错误观念：

class CommonMisconceptions {
    let myths = [
        "❌ 静态库一定比动态库快": "只有启动阶段有优势，运行时一样",
        "❌ 动态库可以随便更新": "App Store禁止任意动态库更新",
        "❌ 静态库会让App更大": "合理的链接器优化可以消除未使用代码",
        "❌ 动态库更"现代"": "选择基于需求，不是新旧程度"
    ]
}

总结

一句话指南：默认选择静态库优化启动性能，仅在需要进程共享、App Extension依赖或系统要求时使用动态库。

快速决策清单：

✅ 选静态库：启动性能关键、单App使用、无Extension依赖
🔄 选动态库：多App共享、有App Extension、系统框架、插件架构

在现代iOS开发中，由于App启动性能的重要性，静态库已成为默认推荐选择，Swift Package Manager也反映了这一趋势。

一、iOS中"两个进程共享一个动态库"的场景

实际上，在标准的iOS App中，这种情况几乎不存在，但有几个特例：

class SharedLibraryScenarios {
    let exceptionalCases = [
        "🏢 系统框架": "UIKit, Foundation等被所有App共享",
        "🔧 App Extension": "主App与Extension共享动态库",
        "🧩 特殊系统进程": "后台守护进程间的系统库共享"
    ]
    
    // ❌ 普通开发者无法实现的场景
    let impossibleForDevelopers = [
        "两个独立App共享自定义动态库",
        "同一公司不同App共享业务动态库", 
        "用户安装的任意App间共享第三方动态库"
    ]
}

二、同一个App的多个进程场景

iOS App的进程模型：

class iOSProcessModel {
    func standardAppStructure() {
        // 📱 绝大多数iOS App：单进程模型
        let typicalApp = AppProcess(
            name: "YourApp",
            processCount: 1, // 只有一个主进程
            threads: ["Main", "Background", "Network"] // 多线程，但同进程
        )
    }
    
    func exceptionalCases() {
        // 🎯 唯一的例外：App Extension
        let appWithExtensions = AppProcess(
            name: "MainApp",
            processes: [
                "MainAppProcess",           // 主App进程
                "TodayWidgetProcess",       // 今日小组件进程  
                "ShareExtensionProcess",    // 分享扩展进程
                "NotificationServiceProcess" // 通知服务进程
            ]
        )
    }
}

三、App Extension：真正的多进程共享

架构示意图：

iOS 进程关系图：
┌─────────────────────────────────────────┐
│             你的主 App (进程A)             │
│  ┌─────────────────────────────────────┐ │
│  │       主程序二进制 + 动态库副本A        │ │
│  └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│          今日小组件 (进程B)               │
│  ┌─────────────────────────────────────┐ │
│  │       小组件二进制 + 动态库副本B        │ │
│  └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

┌─────────────────────────────────────────┐
│           分享扩展 (进程C)                │
│  ┌─────────────────────────────────────┐ │
│  │       扩展二进制 + 动态库副本C         │ │
│  └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

🔍 关键：每个Extension都是独立进程，但有相同动态库的独立副本

为什么iOS设计成这样

安全架构决策：

class iOSSecurityDesign {
    let designPrinciples = [
        "🔒 最小权限原则": "每个进程只有完成自身功能所需的最低权限",
        "🛡️ 故障隔离": "一个Extension崩溃不会影响主App",
        "📱 资源控制": "系统可以单独管理每个进程的资源使用",
        "⚡ 性能优化": "不活跃的Extension进程可以被系统冻结"
    ]
    
    func explainIsolationBenefits() {
        // 示例：今日小组件崩溃时
        let todayWidgetCrash = CrashScenario(
            affectedProcess: "TodayWidget",
            impact: "仅小组件无法使用",
            mainApp: "完全正常",
            otherExtensions: "完全正常"
        )
    }
}

对开发者的实际影响

动态库在Extension中的配置：

// 在Xcode项目中的配置
class ProjectConfiguration {
    let dynamicLibrarySetup = """
    📁 你的项目结构：
    MyApp.xcodeproj/
    ├── MyApp (主Target)
    ├── TodayWidget (Extension Target) 
    ├── ShareExtension (Extension Target)
    └── Frameworks/
        └── SharedFramework.framework (动态库)
    
    ⚙️ 每个Target都要：
    - 链接 SharedFramework.framework
    - 嵌入动态库副本
    - 独立代码签名
    """
    
    func buildResult() {
        // 构建产物：
        let buildProducts = [
            "MyApp.app/ Frameworks/ SharedFramework.framework": "副本A",
            "TodayWidget.appex/ Frameworks/ SharedFramework.framework": "副本B", 
            "ShareExtension.appex/ Frameworks/ SharedFramework.framework": "副本C"
        ]
    }
}

实际开发建议

应对多进程动态库的策略：

class DevelopmentStrategies {
    let recommendations = [
        "📦 优先使用静态库": "如果没有Extension需求，用静态库避免重复",
        "🎯 精简动态库内容": "移除Extension不需要的代码",
        "🔧 共享配置分离": "动态库代码共享，但每进程独立配置",
        "📱 考虑包大小影响": "多个Extension时评估存储成本"
    ]
    
    func decisionFramework() {
        let decisionTree = """
        是否需要App Extension?
        ├── 否 → 🎯 使用静态库 (启动更快，包更小)
        └── 是 → 🔧 使用动态库 + 优化资源占用
        """
    }
}

总结

核心答案：

❌ 两个独立App无法共享动态库 - iOS安全沙箱禁止
✅ 同一个App的多个Extension是独立进程 - 这是iOS中唯一的"多进程"场景
🔍 每个Extension有动态库的独立副本 - 不是真正的内存共享
🏢 只有系统框架能真共享 - 第三方开发者无法实现

iOS核心知识点解析

一、属性修饰符与内存管理

atomic和nonatomic区别及作用

weak 和 assign 的区别

属性关键字默认值

copy关键字的使用

iOS字符串修饰推荐copy的原因

1. 防止可变字符串被意外修改

2. 保证字符串的不可变性

3. 线程安全性考虑

不同修饰符的对比

strong vs copy 行为差异：

NSMutableString应该用strong

1. 使用copy的错误示例

2. 正确的strong修饰

不同类型字符串的修饰符选择

推荐方案：

特殊情况处理

需要可变副本的情况

防御性编程

面试回答要点

特殊情况说明

1. 性能考虑

2. 例外情况

面试回答要点

二、面向对象特性

面向对象三大特性

1. 封装

2. 继承

3. 多态

OC的动态特性

1. 动态类型

2. 动态绑定

3. 动态加载

多继承的实现方式

三、Runtime与消息机制

Runtime基础概念

消息机制详解

1. 消息发送流程

2. 动态方法解析

3. 消息转发机制

Runtime实际应用

四、Category与扩展

Category的使用与原理

Category与Extension的区别

load与initialize方法

load和initialize调用时机对比

1. load方法 - main函数之前调用

2. initialize方法 - 第一次使用时调用

底层原理分析

load方法的调用机制

initialize方法的调用机制

实际应用场景

load方法的典型用途

initialize方法的典型用途

重要区别总结

面试回答要点

Category添加成员变量

五、Block编程

Block原理与本质

__block修饰符

Block属性修饰符

Block修改变量规则

六、KVO与KVC机制

KVO实现原理

手动触发KVO

KVC原理与过程

七、内存管理与调试

对象内存结构

指针与对象关系

BAD_ACCESS错误调试

八、RunLoop机制

RunLoop基础概念

RunLoop与线程关系

RunLoop Mode机制

Timer与RunLoop

RunLoop内部实现

RunLoop性能监控

九、其他重要知识点

符号表与调试