首页
沸点
课程
数据标注
HOT
AI Coding
更多
直播
活动
APP
插件
直播
活动
APP
插件
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
Objective-C
项阿丑
创建于2026-02-04
订阅专栏
OC相关知识整理
暂无订阅
共188篇文章
创建于2026-02-04
订阅专栏
默认顺序
默认顺序
最早发布
最新发布
5-7.【OC】【Block】__block 变量在 Stack → Heap 的迁移过程中,发生了什么变化?
这是一个非常硬核的内存迁移过程。当 Block 从栈拷贝到堆时,__block 变量并不是简单地“移动”,而是一场坐标转换和关系重定位。 我们可以把这个过程拆解为三个关键动作: 1. 结构体的“克隆”
5-6.【OC】【Block】__block 修饰符的底层原理是什么?
简单来说,__block 修饰符的作用是**“将一个栈上的变量包装成一个对象”**,从而让它能够随着 Block 一起被拷贝到堆上,实现跨作用域的读写访问。 如果不加 __block,Block 捕获
5-5.【OC】【Block】Block_copy / [block copy] 在 ARC 下是否还“真的有用”?
这是一个非常敏锐的问题。在 ARC(自动引用计数) 几乎接管了一切的今天,手动调用 Block_copy 或 [block copy] 的场景确实极度萎缩,但它并没有完全“退役”。 简单直接的回答是:
5-4.【OC】【Block】Block 从 Stack copy 到 Heap 的触发时机有哪些?至少说出 3 种。
在 ARC(自动引用计数)环境下,编译器为了保证程序的安全性,会非常频繁地自动将 Block 从栈(Stack)拷贝到堆(Heap)上。一旦拷贝到堆,Block 的生命周期就不再受限于当前作用域,而是
5-3.【OC】【Block】Stack Block 为什么不能跨作用域使用?它的生命周期是如何结束的?
简单来说,Stack Block(栈上的 Block) 最大的局限性在于它的生命周期是与它所在的函数或作用域(Scope) 强绑定的。 在 Objective-C 中,Block 本质上是一个对象,但
5-2.【OC】【Block】如何通过代码特征快速判断一个 Block 属于哪种类型?
✅「肉眼 + 编译器语义」判断法 这是苹果工程师自己用的方式。 一、先给结论(99% 场景适用) 你只需要看三件事: 🥇 是否捕获任何外部变量? ❌ 没有捕获: 👉 必然是: ✅ Global Blo
5-1.【OC】【Block】OC 中为什么会有 Global / Stack / Heap 三种 Block?它们诞生的历史原因是什么?
这是个**非常底层 + 很“历史包袱感”**的问题 ——Block 之所以看起来怪(Global / Stack / Heap 三种),本质不是设计优雅,而是: 一、最初:Block 不是 OC 发明
4-30.【OC】【锁】在大型工程中,你会如何设计锁粒度与隔离策略?
在大型 iOS 工程中,设计锁粒度与隔离策略的目标是在数据安全性、执行性能与开发维护成本之间找到平衡。锁粒度过粗会导致主线程卡顿(如你提供的 slowlog_0 所示),锁粒度过细则会增加死锁风险。
4-29.【OC】【锁】主线程同步派发到主队列为什么必死锁?
这是一个非常经典且容易在面试中遇到的问题。在 iOS 开发中,执行 dispatch_sync(dispatch_get_main_queue(), ^{ ... }); 会产生立即且永久的死锁。 这
4-28.【OC】【锁】请画出“双锁反序”死锁的 wait-for graph。
“双锁反序”(AB-BA Deadlock)是多线程开发中最经典的死锁模型。当两个线程以相反的顺序请求两把相同的锁时,就会形成环路等待。 1. 场景描述 线程 1:已经持有 锁 A,正在尝试获取 锁
4-27.【OC】【锁】weak 引用表的同步机制是怎样设计的?
weak 引用表的同步机制是 Objective-C Runtime 中设计最精巧的部分之一,它必须在“高频访问”、“内存节省”和“多线程安全”之间取得平衡。 其核心设计可以概括为:多级哈希表结构 +
4-26.【OC】【锁】ARC 的 retain/release 路径中哪些地方涉及锁?
在 ARC(Automatic Reference Counting)环境下,retain 和 release 看起来只是简单的加减计数,但由于它们必须是线程安全的,其实内部逻辑非常复杂,涉及到多层级
4-25.【OC】【锁】atomic property 的实现是否真正线程安全?为什么?
在 Objective-C 中,atomic 属性的实现并不是绝对意义上的“线程安全”。 简单来说,atomic 只能保证属性的 Setter 和 Getter 操作本身是原子的(即读写完整),但无法
4-24.【OC】【锁】Objective-C runtime 内部有哪些关键锁?
Objective-C Runtime(libobjc)作为一个高度动态且线程安全的系统,其内部大量使用了不同类型的锁来保护全局表、方法缓存和类结构。 了解这些内部锁,能帮你理解为什么有些看起来简单的
4-23.【OC】【锁】os_unfair_lock 为什么是“不公平”的?
“不公平”(Unfair)在这里是一个计算机科学术语,主要指该锁不保证“先来后到”的排队顺序(First-In-First-Out, FIFO) 。 在传统的“公平锁”中,如果线程 A、B、C 依次尝
4-22.【OC】【锁】os_unfair_lock 如何避免优先级反转?
os_unfair_lock 是苹果在 iOS 10 中推出的 OSSpinLock 直接替代品。它能够规避优先级反转问题,核心在于它彻底改变了等待机制,并与内核调度器(Mach Kernel)进行了
4-21.【OC】【锁】priority inversion 在自旋锁中是如何产生的?
在自旋锁(Spinlock)中,优先级反转(Priority Inversion) 并非传统意义上的“多个线程竞争”,而是一种由于“忙等”机制导致的死锁状态。 其产生的核心逻辑如下: 1. 产生的前提
4-20.【OC】【锁】OSSpinLock 被废弃的真实原因是什么?
OSSpinLock 被废弃的真实原因在于它在 iOS 的线程调度机制下存在严重的 优先级反转(Priority Inversion) 风险,这会导致应用出现逻辑上的死锁或永久性卡顿。 虽然从代码逻辑
4-19.【OC】【锁】使用 semaphore 容易制造哪类隐蔽死锁?
在使用 dispatch_semaphore(信号量)时,最隐蔽且最常见的死锁类型是**“优先级反转导致的线程饥饿死锁”**,尤其是在 iOS 这种具有复杂优先级调度机制的系统中。 以下是该类死锁的详
4-18.【OC】【锁】semaphore = 1 与 mutex 在语义上有什么本质区别?
本质区别可以总结为:Mutex 是“所有权制”,而 Semaphore 是“信号制”。 1. 所有权 (Ownership):谁领的证,谁能离 这是两者最根本的区别。 Mutex(互斥锁): 具有 O
下一页