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

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

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

weak 表的清理发生在一个对象的 生命终点，确切地说，是在 dealloc 流程执行到 objc_destructInstance 这一步时。 清理过程并不是一蹴而就的，而是一场严密的“定点清除”行

在 Objective-C 的底层实现中，SideTable 是管理内存安全的核心仓库。它并不是一张简单的表，而是一个复杂的 多级嵌套数据结构，专门用来存储引用计数和弱引用信息。 我们可以通过“三层嵌

__weak 变量之所以能在对象释放时自动清空（Zeroing），并不是因为它在不断地“监听”对象，而是因为 Objective-C Runtime 维护了一套高效的**弱引用表（Weak Table

在 ARC 环境下，__strong 是 Objective-C 指针的默认修饰符。它的真实含义可以从所有权语义、生命周期管理以及底层运行时实现三个维度来解剖。 简单来说，__strong 的本质是：

在 ARC（Automatic Reference Counting）模式下，编译器（Clang）并不是简单地替你手写了 retain/release，它实际上进行了一场**“静默的局部最优解计算”*

在 MRC（Manual Reference Counting）环境下，这段代码是安全的，但它代表了一种极度不规范且容易埋坑的写法。 虽然最终内存引用计数是平衡的，但它违反了 Objective-C

在 MRC 下，autorelease 的本质是 “延迟释放” 。它既不是立即销毁对象，也不是增加引用计数，而是将对象的所有权转交给了一个名为 AutoreleasePool（自动释放池） 的管理器。

虽然这五个操作最终都会导致对象的“引用计数（Reference Count）”增加，但从所有权（Ownership）的哲学和内存物理演进来看，它们有着本质的区别。 我们可以把 alloc/new/co

在 MRC（Manual Reference Counting）时代，判定“谁负责释放”并不看心情，而是遵循一套极其严苛的、基于方法名关键字的黄金法则。 这套规则由苹果定义，本质上是把 C 语言对内存

虽然 Objective-C 的消息机制带来了极大的灵活性，但在某些对性能、安全或确定性有极致要求的场景下，开发者会选择“跳过” objc_msgSend，转而使用 C 函数或 C++ 静态方法。 以

从 ABI（应用二进制接口） 的层面来看，Objective-C 的方法调用与 C 函数调用的区别，本质上是**“直接跳转”与“间接分发”**的对立。 在二进制指令级别，这两者的处理方式决定了它们的执

Method Cache（方法缓存） 的作用可以用四个字概括：变慢为快。 如果没有缓存，Objective-C 每一行 [obj message] 都要经历昂贵的方法列表遍历和继承链递归查找。而 Me

Objective-C 的方法调用“看起来慢”，是因为它在底层将函数调用变成了数据库查询。 在传统的 C++ 或 Swift 中，调用方法通常是直接跳转到内存地址（静态派发）或查找偏移量固定的虚函数表

objc_msgSend 是 Objective-C 的灵魂。为了保证极高的执行效率，它的核心逻辑是用汇编语言编写的。其调用流程可以分为三个阶段：消息发送（快速与慢速路径） 、动态方法解析、消息转发。

Swift 的 struct（结构体）和 enum（枚举）无法完整桥接到 Objective-C，本质上是因为 Swift 迈向了“现代静态语言”，而 Objective-C 仍被锁死在“80 年代

Objective-C 之所以能在运行时动态添加方法，是因为它在底层将“类”设计成了一个可变的数据结构，并且拥有一套基于名称查找而非地址偏移的消息分发系统。 这可以从以下三个层面来透彻理解： 1. 类

Objective-C 的继承链方法查找，本质上是围绕 objc_msgSend 函数展开的一场在 objc_class 结构体 之间的递归搜索。 由于 Objective-C 的动态性，它不会在编译