Objective-C

苹果明确不建议在 +load 中放置复杂逻辑，核心原因在于它的调用时机极其特殊，且处于系统启动的“黄金时间”。在 +load 中做太多事，本质上是在跟用户体验和系统稳定性“对着干”。 以下是四个深度原

简单直接的答案是：安全。 +initialize 的安全性是由 Objective-C Runtime 在底层通过**线程锁（Lock）**机制严格保障的。即使有多个线程同时第一次访问某个类，Runt

这两个方法是 Objective-C 类生命周期中最重要的两个钩子，但它们的底层机制、调用时机和对继承的处理完全不同。 以下是它们的本质差异对比： 1. 调用时机：一个是“主动加载”，一个是“懒加载”

Category 的合并过程本质上是一个**“后进先出”的列表插入操作**，它发生在类加载的第三和第四阶段（Realization & Category Attachment）。 我们可以将这个过程拆

在 Objective-C 中，类的加载并不是简单的“一次性到位”，而是一个从磁盘二进制文件到运行时动态对象的深度加工过程。 这个过程主要由 dyld（动态链接器）和 libobjc（Runtime

Objective-C 的“类”在 Runtime 层面的加载是一个严密的流水线作业。它并不是在 main 函数执行时才加载，而是在 App 启动后的 Pre-main 阶段（即 dyld 加载动态库

libobjc.A.dylib 不仅仅是一个动态库，它是 Objective-C 语言的“心脏”。如果没有它，App 里的所有类、方法、内存管理（ARC）以及 Runtime 特性都无法运行。 在 A

这是一个非常经典且复杂的内存拓扑结构。在 iOS 开发中，这五个角色往往交织在一起，形成一个“牵一发而动全身”的引用网络。 为了让你看清它们的真实关系，我们把这张图拆解为两条核心路径：一条是“显性”的

虽然两者都基于自动引用计数（ARC） ，但 Swift 在设计上吸取了 Objective-C 的教训，将内存安全性从“开发者规约”提升到了“语言特性”层面。 它们处理循环引用的核心设计差异可以总结为

在 Swift 中，[weak self] 和 [unowned self] 都是为了打破闭包产生的循环引用，但它们在 Runtime（运行时）安全性和引用计数底层实现上有着本质的区别。 简单来说：w

虽然 Swift 的 Closure（闭包）在很多概念上继承了 Objective-C 的 Block，但在底层捕获语义和编译器优化上，两者有着本质的区别。 最核心的差异可以总结为一句话：Swift

不一致。 虽然 __block 的核心目标（允许 Block 内部修改外部变量）在两个环境下是一样的，但它在内存管理语义上存在一个巨大的、甚至足以导致程序崩溃的差异。 1. 核心差异：是否会触发 Re

Objective-C Block 的变量捕获规则是其最核心的机制。Block 为了保证在未来某个时刻执行时变量依然可用，会根据变量的类型和修饰符，采取截然不同的“打包”策略。 我们可以将其归纳为以下

在 Objective-C 中，Block 本质上是一个封装了函数及其执行上下文（变量捕获）的 OC 对象。根据其内存存储位置的不同，Block 分为三种主要的存储类型。 你可以通过查看 Block

说 NSTimer “必然”导致循环引用其实有些绝对，但在 iOS 10 / macOS 10.12 之前，如果你使用经典的 scheduledTimerWithTimeInterval:target

在 Objective-C 和 Swift 开发中，delegate（代理）属性几乎约定俗成地使用 weak（在 MRC 下用 assign）。这背后的核心原因只有一个：防止循环引用（Retain C

简单直接的答案是：不，ARC 不仅有性能成本，甚至在某些特定情况下比手动管理（MRC）还要高。 虽然 ARC 的初衷是自动化和安全，但“自动化”的代价是由 CPU 的时钟周期和内存开销来支付的。我们可

在 ARC 环境下，循环中内存暴涨的根本原因在于：自动释放对象的“死亡时间”被推迟到了当前 RunLoop 的末尾。 虽然 ARC 帮我们省去了手写 release 的麻烦，但它依然遵循 Object

在 ARC 环境下，@autoreleasepool {} 看起来是一个简单的语法糖，但其底层是一套基于**栈（Stack）**结构的内存管理机制。 当你编写 @autoreleasepool {}

从底层实现来看，__unsafe_unretained 和 __weak 的差异本质上是 “原始指针” 与 “运行时托管指针” 的区别。 虽然它们都不增加引用计数，但处理对象销毁（Deallocati