Objective-C

在 KVO 的生命周期管理中，移除观察者的时机和顺序至关重要。如果处理不当，会直接导致程序崩溃或逻辑异常。 1. 移除 Observer 的正确顺序与时机 核心原则：先解绑，后销毁。 最晚时机： 必须

当你在 Objective-C 中调用 addObserver:forKeyPath:options:context: 时，Runtime 并不仅仅是做个登记，而是通过 isa-swizzling 技

在多层继承（Subclassing Hierarchy）下，KVO 的行为之所以会让你感到“出乎意料”，主要源于其底层的 isa-swizzling 机制与 Objective-C 消息转发路径之间的

KVO 的生命周期管理是 Objective-C 开发中最容易出错的环节之一。在 ARC 环境下，虽然内存管理变得简单了，但由于 KVO 内部持有的是观察者的原始指针（unsafe_unretaine

KVO（Key-Value Observing）的实现是 Objective-C Runtime 动态特性的巅峰之作。它的核心机制可以概括为：运行时派生子类、方法重写（Swizzling）以及消息转发

KVC 并不是线程安全的。因为它底层涉及大量的 Runtime 查找、内存偏移计算以及自动装箱/拆箱，在多线程环境下，这些动态特性会带来几种非常隐蔽且致命的风险。 以下是 KVC 在多线程下的典型问题

简单来说：可以，完全没问题。 KVC 的强大之处就在于它打破了“对象”与“非对象”之间的边界，让你能像处理对象一样处理 int、bool 甚至是自定义的 CGRect。 在底层，KVC 靠的是一套严密

KVC 的类型转换并不是简单的强制转换，而是一套基于 Objective-C 类型编码（Type Encoding） 的自动化**装箱（Boxing）与拆箱（Unboxing）**机制。 当你调用 s

当使用 KVC 访问数组属性（NSArray / NSMutableArray）时，为什么会触发mutableArrayValueForKey？这在 Runtime 层面发生了什么？ 这是一个非常精妙

KVC 崩溃（Crash）的根源主要集中在以下四个维度： 1. 找不到指定的 Key (Undefined Key) 这是最常见的崩溃原因。当你尝试访问一个对象中不存在的方法或成员变量时，KVC 找不

KVC（Key-Value Coding）之所以能“突破”访问限制，是因为它本质上是 Objective-C Runtime（运行时） 的一层高级封装。 编译器在编译阶段施加的 private、@pr

KVC（Key-Value Coding）的属性查找逻辑是一个非常严密的“搜索算法”。它不仅查找 Getter/Setter 方法，还会根据特定规则尝试访问成员变量（Ivar）。 查找顺序主要分为 “

答案是：既是语言能力的进化（编译器更聪明），也是 Runtime 管理机制的代差（更先进的元数据管理）。 在 Objective-C 中，如果你不写 weakSelf，循环引用几乎是“必死”的；但在

简单来说，它们在最终目的（打破循环引用）上是等价的，但在执行细节和语法语义上，Swift 的 [weak self] 比 OC 的 __weak 走得更远，也更安全。 我们可以从以下三个维度来拆解它们

虽然 Objective-C 的 Block 和 Swift 的 Closure 在逻辑层面上非常相似，但它们的**捕获语义（Capture Semantics）**有着本质的差异。 最根本的区别在于

在 ARC 环境下，这一行看似简单的赋值，背后其实是一套复杂的弱引用表（Weak Table）管理逻辑。编译器并不会把它当作普通的指针赋值，而是会将其转化为对 Runtime 函数的调用。 具体来说，

在 ARC 环境下，self 被 retain 的时机并不是在 Block 执行的时候，而是在 Block 创建并拷贝到堆上的那一刻。 我们可以把这个过程拆解为以下几个精确的步骤： 1. 核心触发时机

在 Objective-C 中，weakSelf 的存在感之所以这么强，本质上是因为 Objective-C 的闭包（Block）是一等公民，且默认执行的是强引用捕获。 1. 为什么 weakSelf

在 Objective-C 中，Block 捕获 self 的真实语义可以概括为一句话：它在 Block 的结构体内部创建了一个强引用指针，指向了 self 所代表的对象。 这里有三个核心层面的含义，

从底层 C 语言的定义来看，Block 的本质是一个结构体。无论它是哪种类型的 Block，其内存布局的首部都遵循统一的规范（通常被称为 Block_layout）。 以下是 Block 内存布局中最