货拉拉iOS笔试真题解析：内存管理、Runtime与多线程核心考点

作为一份跨年份流传的面试题，货拉拉2018秋招iOS工程师笔试题卷二（B）到现在依然值得翻出来看看。原因很简单：题目考察的不是某个框架的API背诵，而是iOS开发里最核心的内存管理、Runtime、多线程、界面布局这些底层功底。哪怕你只是准备面试，花两个小时过一遍这些题目，也比刷十套“xx题库”更有收获。这篇文章我按照当年的题型分布，把考察点、解题思路、涉及的知识盲区全部拆开讲一遍，顺便补充一些我在实际开发里踩过的坑。

1. 笔试题整体设计与考察意图拆解

1.1 从卷二（B）的题型分布看货拉拉的用人标准

2018年这个时间点很有意思：Swift 4刚稳定不久，iOS 11全面普及，货拉拉这类O2O业务正处于高速扩张期。App承载的是地图、定位、订单流转、司机端接单这些强交互场景，线上问题直接影响用户体验和平台运力调度。所以笔试题的取舍很明确——不考偏题怪题，专考“线上环境出问题能不能快速定位”的能力。

卷二（B）整体分为几大板块：Objective-C语言基础与Runtime机制、内存管理与Block、多线程与并发控制、UIKit与Auto Layout、网络层与数据持久化。这几块几乎就是当时一线iOS工程师的日常主战场。货拉拉想要的人，不是“会用AFNetworking调接口”的，而是能说清楚“AFNetworking底层为什么用NSURLSession”“SDWebImage缓存策略是怎么设计的”这类问题的人。

笔试题里没有简答题之外的纯背诵填空，更多是给一段代码让你说输出、给一个场景让你谈方案。这背后的潜台词是：面试官不需要一个背书机器，而是需要一个能接手现有工程、能独立排查Crash、能对性能瓶颈提出优化方案的工程师。所以如果你打算拿这套题练手，千万别只看答案，重点是想清楚“为什么”。

1.2 为什么这些考点至今没有过时

可能有同学觉得2018年的题太老了，SwiftUI都出了，还看Objective-C干什么。但仔细观察招聘市场你会发现，直到现在，很多大厂的iOS核心模块依然是Objective-C写的，或者说OC与Swift混编。货拉拉客户端在2018年已经是纯OC为主，笔试题考察OC是当时最务实的选择。

更深层的原因在于，iOS的底层运行机制没变：ARC底层还是retain/release，Runtime的消息转发机制依然是Objective-C的根基，RunLoop依然是控制线程生命周期的最佳工具。这些内容不像UIKit那样隔几年改一次API，属于“十年不过时”的硬知识。哪怕你今天用Swift开发，理解了Runtime和内存管理，排查循环引用、优化启动时间的时候照样受用。

另外，2018年恰好是移动端从“能用”向“好用”转变的节点。流量红利见顶，App开始拼性能、拼稳定、拼体验。货拉拉的业务非常依赖App在弱网环境下的表现，所以卷二（B）里网络层和并发控制的题目占比不低，目的就是考察你在非理想环境下的兜底方案设计能力。

2. 核心考点逐题拆解：内存管理、Runtime与Block

2.1 内存管理题：ARC下还有没有必要知道retain/release

卷二（B）里关于内存管理的题目，通常不会让你直接写retain/release，而是给你一个MRC时代遗留的代码片段，问你有没有问题。我见到过的版本有：

- (void)configureWithModel:(Model *)model { _model = [model retain]; }

这道题在ARC环境下等价于：

- (void)configureWithModel:(Model *)model { _model = model; }

如果_model是strong属性，那么这里没啥问题；如果是weak或者assign，分分钟就搞出野指针。更常见的坑藏在Block里：

@property (nonatomic, copy) void (^myBlock)(void); - (void)setup { __weak typeof(self) weakSelf = self; self.myBlock = ^{ __strong typeof(weakSelf) strongSelf = weakSelf; [strongSelf doSomething]; }; }

这里面的细节值得说道说道。__weak是为了打破循环引用，这个大家都知道。但为什么在Block内部要转一次__strong？因为weakSelf在Block执行期间有可能被释放，一旦释放，strongSelf就变成nil，后续所有消息发送都会静默失效。加一个__strong typeof(weakSelf) strongSelf = weakSelf，能保证Block执行期间self不会被提前释放，这是一个非常实用的防御性写法。

还有一道经典的“循环引用找茬题”：

[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(tick) userInfo:nil repeats:YES];

NSTimer在repeats为YES时，会强持有target，也就是self。如果self又强持有timer，那谁也释放不了谁。这里我给两个解法：一是iOS 10以后用block版本的timer方法：

__weak typeof(self) weakSelf = self; self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 repeats:YES block:^(NSTimer * _Nonnull timer) { __strong typeof(weakSelf) strongSelf = weakSelf; [strongSelf tick]; }];

二是实在要用target/selector方式，务必在viewWillDisappear或dealloc里把timer invalidate掉。但这里有个坑，如果你把invalidate放在dealloc里，而timer又持有self，那dealloc根本不会走，你会陷入“等死”的状态。正确的做法是放在viewDidDisappear或者一个专门的teardown方法里，配合页面生命周期管理。

2.2 Runtime题目：不只是背消息转发，还要会举一反三

Runtime的题在卷二（B）里属于压轴级别，通常以“这段代码输出什么”的形式出现。比如：

@implementation Father - (void)sayHello { NSLog(@"Father"); } @end @implementation Son : Father - (void)sayHello { NSLog(@"Son"); } @end

如果只是问输出，那太基础了，面试官会在后面加一句：“如果我在Son里没实现sayHello，但接了一个消息转发，会走到哪一步？”这就谈到消息转发的三个流程：

1. 动态方法解析：调用resolveInstanceMethod，看能不能动态添加方法。
2. 快速转发：看forwardingTargetForSelector能不能把消息转发给别的对象。
3. 完整消息转发：走methodSignatureForSelector和forwardInvocation。

实际开发中用到Runtime最多的场景是Method Swizzling。我见过很多面试者能把原理背得滚瓜烂熟，但一写代码就翻车。这里直接给出一个相对安全的实现：

+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class class = [self class]; SEL originalSelector = @selector(viewWillAppear:); SEL swizzledSelector = @selector(xxx_viewWillAppear:); Method originalMethod = class_getInstanceMethod(class, originalSelector); Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector); BOOL didAddMethod = class_addMethod(class, originalSelector, method_getImplementation(swizzledMethod), method_getTypeEncoding(swizzledMethod)); if (didAddMethod) { class_replaceMethod(class, swizzledSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod)); } else { method_exchangeImplementations(originalMethod, swizzledMethod); } }); }

为什么要先class_addMethod再交换？因为如果当前类没实现originalSelector，而是继承自父类，直接method_exchangeImplementations会把父类的方法也一起换掉，影响全局。先addMethod确保当前类有一个自己的实现，再replaceMethod把swizzledSelector指向原来的实现，这样就能避免误伤父类。这个细节是区分“背过”和“真懂”的分水岭。

2.3 Block底层原理：为什么用copy修饰属性

Block相关的题，卷二（B）一般会从“属性修饰词为什么用copy”切入。很多人回答“因为要拷贝到堆上”，但没说到本质。

Block有三种类型：全局Block（_NSConcreteGlobalBlock）、栈Block（_NSConcreteStackBlock）、堆Block（_NSConcreteMallocBlock）。栈Block的作用域在函数内，函数返回后就失效了。如果属性用strong，编译器可能会在赋值时做一次copy（在ARC下strong对Block也有拷贝效果），但这不是规范做法。用copy修饰，语义最清晰：赋值后这个Block一定在堆上，生命周期由属性持有。

这里有个比较容易混淆的点：ARC下用strong声明Block属性，编译器实际上也会帮你copy，所以在绝大多数情况下你在ARC环境根本看不出strong和copy的区别。但为了代码可读性，以及防止以后有人把工程切到MRC（虽然概率极低），依然建议写copy。这在面试里直接答“copy语义明确，且在ARC下与strong效果一致”，会显得你既懂原理又理解工程规范。

3. 多线程与并发控制：GCD、NSOperation与锁的实战选择

3.1 同步、异步、串行、并发的排列组合

卷二（B）里有一类必考题：给你一张表，问在不同队列执行同步/异步任务会怎样。我直接把这个表格整理出来，面试前过一遍：

这里最经典的死锁题就是：

dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"死锁"); });

我遇到过不止一个面试者跟我说“这段代码不会死锁，因为主队列是串行队列，同步任务会等待之前任务执行完，而之前任务就是当前正在执行的这段代码”。这个解释基本对了，但还有更具体的原因：主队列的任务在runloop中被取出执行，当前正在执行的任务（即dispatch_sync这行代码所在的任务）还没结束，主队列不会取下一个任务，而dispatch_sync又在等下一个任务执行完，互相等待，就死锁了。

如果你答到这里，面试官可能会追问：“那如果我在一个并发队列里调用dispatch_sync(dispatch_get_main_queue(), ^{})会死锁吗？”答案是会，因为主队列是串行的，同一时刻只能执行一个任务，无论调用者是什么队列，只要主队列有空且当前主队列没有正在执行的任务，就会有死锁风险。这种追问是考察你把“串行队列+同步任务”的组合吃没吃透。

3.2 线程安全问题：atomic真的安全吗

卷二（B）对线程安全的题目很执着，其中有个高频问法：“atomic修饰的属性是否线程安全？”答案是否定的。atomic只能保证属性的getter/setter是原子的，也就是赋值和取值不会崩，但无法保证多线程下“先读后写”这个整体操作的线程安全。比如两个线程同时执行self.count += 1，atomic只保证setter内部原子性，但+=这个复合操作本身是三条指令：读值、加一、写回，中间完全可能被另一个线程打断，最后count的增量小于2。

实际开发中，我推荐用GCD的barrier来安全处理多读单写场景：

- (void)setCache:(id)cache forKey:(NSString *)key { dispatch_barrier_async(self.concurrentQueue, ^{ [self.cacheDict setObject:cache forKey:key]; }); } - (id)cacheForKey:(NSString *)key { __block id result; dispatch_sync(self.concurrentQueue, ^{ result = self.cacheDict[key]; }); return result; }

这里有几个细节值得注意。dispatch_barrier_async在执行时，会等待它之前所有任务完成，然后单独执行barrier任务，执行完后再让之后的任务继续。这样就保证了读取可以并发，而写入是独占的，性能比单纯的@synchronized或NSLock好很多。另外，这里的concurrentQueue必须是自己通过dispatch_queue_create创建的并发队列，不能直接用全局并发队列，因为全局队列的barrier行为是未定义的。

顺带提一句iOS 10之后的新方案：用os_unfair_lock替代NSLock。os_unfair_lock是低优先级不等待锁的改进版，性能比NSLock高一个量级，但它不是递归锁，所以不能在同一线程连续加锁两次，否则会死锁。这也是面试加分点，说明你关注系统版本演进带来的最佳实践变化。

3.3 NSOperation与GCD怎么选

卷二（B）里有时会出开放题：“给你一个下载然后解压然后刷新UI的三步任务，你会怎么设计？”其实没有标准答案，但更完善的做法是用NSOperationQueue。

NSOperation相比GCD的显著优势是：可以设置依赖关系、支持取消操作、可以设置最大并发数。比如三个任务A、B、C，C依赖A和B都完成，代码是这样的：

NSOperationQueue *queue = [[NSOperationQueue alloc] init]; queue.maxConcurrentOperationCount = 2; NSBlockOperation *operationA = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"执行A"); }]; NSBlockOperation *operationB = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"执行B"); }]; NSBlockOperation *operationC = [NSBlockOperation blockOperationWithBlock:^{ NSLog(@"执行C"); }]; [operationC addDependency:operationA]; [operationC addDependency:operationB]; [queue addOperations:@[operationA, operationB, operationC] waitUntilFinished:NO];

需要注意的是，依赖关系是跨队列生效的，也就是说operationA即便在另一个queue里执行，operationC也会等待它完成。这个特性在做多模块并行加载时很实用。另外，取消操作需要你手动在Block里检查operation.isCancelled，否则就算调了cancel，任务照样会执行完。这个点很多人不知道，实际项目里取消下载任务时最容易踩到。

4. UIKit、Auto Layout与自适应布局实战

4.1 Auto Layout与Frame之争：从一道计算题说起

卷二（B）里有一道老掉牙的题：有一个View，宽高150，居中显示，问这个View的frame是什么。拿到这道题先别急着算，面试官真正想考察是你对Auto Layout和Frame之间关系的理解：只要有约束，系统会在layout pass阶段计算并设置frame，而在此之前，frame可能是上一次布局的残留值，甚至是零。

如果你在viewDidLoad里打印self.view的frame，通常会得到一个基于storyboard的最终值，但如果你在viewDidLoad里打印一个通过约束布局的子view的frame，大概率是CGRectZero。原因是约束还没生效，要到viewDidLayoutSubviews之后frame才是最终值。这个坑在纯代码布局里特别常见，很多人习惯在viewDidLoad里设置圆角，结果因为frame是CGRectZero，圆角半径被设成了0，整个View看起来就是个方方正正的矩形。

正确的做法是：

- (void)viewDidLayoutSubviews { [super viewDidLayoutSubviews]; self.avatarImageView.layer.cornerRadius = self.avatarImageView.frame.size.width / 2; }

注意viewDidLayoutSubviews会被调用多次，所以圆角设置要写成幂等的，千万别在里面做createView这种操作，不然会造成视图反复创建，内存暴涨。

4.2 使用Auto Layout的几条实战原则

2018年的货拉拉笔试里，Auto Layout的题目以“如何实现一个自适应高度的Cell”为典型。到现在，这个需求依然是UITableView优化里绕不开的话题。

实现方式是在Cell的contentView上把上下左右的约束拉满，然后让UILabel的numberOfLines设为0。这里有个关键坑：UILabel的preferredMaxLayoutWidth需要设置，或者是用systemLayoutSizeFittingSize来让系统自动计算。我的经验是，用约束布局的UILabel在系统中会自动处理preferredMaxLayoutWidth，但如果你在比较老的Base SDK上编译，最好手动设置。

另外，关于UITableView的预估行高，iOS 11以后系统会自动使用estimatedRowHeight，这对滚动性能是有帮助的，但如果你的Cell里有高度动态的WebView或者地图，预估行高会频繁触发布局计算，反而卡顿。这种情况下建议把estimatedRowHeight设为0，强制使用真实高度缓存。

4.3 分屏与多任务适配：2018年的新考点

热搜词里有“ios分屏”，正好对应iOS 11开始全面支持的Drag and Drop和Split View。货拉拉这类工具型App，用户可能会一边看地图一边聊天，分屏适配是必须的。

这里考察点主要是Size Classes。一个成熟的App应该在Regular宽度下显示完整UI，在Compact宽度下收起次要信息。实现方法很简单：

- (void)traitCollectionDidChange:(UITraitCollection *)previousTraitCollection { if (self.traitCollection.horizontalSizeClass != previousTraitCollection.horizontalSizeClass) { // 根据新的SizeClass调整UI } }

但更麻烦的是iPad分屏下的布局变化。iPad全屏时是Regular宽度，分屏一半时依然是Regular宽度，但实际可用宽度缩小了。Size Classes解决不了这种“同SizeClass不同宽度”的场景，需要配合viewWillTransitionToSize来手动调整。一个比较稳妥的方案是使用registerForTraitChanges或通过约束的优先级来处理，让关键UI元素在宽度不足时自动换行或隐藏。

5. 网络层、数据存储与项目实战经验

5.1 网络层设计：不只是AFNetworking封装

卷二（B）的网络题往往不直接考AFNetworking，而是问“如果让你设计一个网络层，你会考虑哪些方面”。这题几乎没有标准答案，但我总结的答题框架是：请求管理、缓存策略、错误处理、弱网优化、日志监控。

请求管理方面，我一般推荐用NSURLSession的taskDelegate来统一处理HTTPS证书校验和缓存策略，而不是直接依赖AFNetworking。AFNetworking的每个manager默认都带有一套URLCache策略，但如果你所有请求都走同一个Session，那么可以设置URLCache的diskCapacity和memoryCapacity，避免每个接口都在读磁盘缓存。

缓存策略方面，HTTP的Cache-Control优先级高于App代码里的NSURLRequestUseProtocolCachePolicy。比如接口返回了Cache-Control: no-store，那就算你在代码里设置了NSURLRequestReturnCacheDataElseLoad，也会被网络层忽略。这一点很容易被忽略，接口联调时发现数据不刷新，排查了半天发现是后端缓存头没配好。

弱网优化是货拉拉这类业务的重中之重。司机端网络不稳定，请求超时时间不能照搬传统App的默认设置。我实测下来的建议是：POST请求超时时间15-20秒，GET请求10秒，上传图片的请求单独设置60秒以上。超时后要做指数退避重试，第一次重试等待2秒，第二次4秒，第三次8秒，最多重试3次。同时配合网络状态监听，在WiFi和4G切换时自动断掉当前所有请求并重新发起。

5.2 数据持久化：本地缓存怎么选

数据存储这块，卷二（B）一般会问SQLite、CoreData和UserDefaults的使用场景。我个人的选型经验是：

• UserDefaults只放用户偏好设置、开关状态等小数据，千万别把大型数组或字典往里塞。我从一个线上项目里看到过，团队把一整套订单列表塞进UserDefaults，结果启动时读取耗时超过3秒，且每次修改都会全量写入，体感非常卡。
• CoreData适合实体关系复杂的场景，比如消息记录、通讯录增量同步。但CoreData的多线程处理比较麻烦，要用childContext和performBlock来安全写库。
• SQLite适合数据量大且查询频繁的场景，但需要自己维护迁移脚本。

如果只是做一个简单的本地缓存，我会走一个轻量方案：把模型转成JSON字符串写入沙盒Library/Caches目录，加上过期时间判断。这个方案在数据量不大的时候足够用，且不会带来ORM框架的学习成本。但注意，Library/Caches目录在系统空间不足时可能会被系统清掉，所以只放可再生的缓存数据，不放用户关键数据。

5.3 自动化打包与证书管理：给新手的提醒

热搜词里出现了“ios开发者app证书更新”、“ios上架”、“ios自动化”，这些确实是iOS工程师的日常烦恼。笔试不会让你写打包脚本，但面试官会问“你了解持续集成吗”，如果你的回答停留在“用Xcode点Archive再上传App Store Connect”，那在二面技术细节上会比较吃亏。

我的建议是至少要了解fastlane的常用命令。fastlane是一个自动化工具，它把证书下载、编译、打包、上传、提交TestFlight审核这些步骤都串起来。核心配置文件是Fastfile，你可以通过lane关键字定义流程：

首先需要配置match管理证书和描述文件。match会把证书和描述文件加密存到Git仓库或Google Cloud Storage里，团队协作时只需拉取一次。使用match update可以在证书过期时自动重新生成。

其次，注意导出IPA时使用的导出方法。App Store分发要用app-store方式导出，真机调试和测试用development方式，企业内部分发用enterprise方式。选错导出方式，装到手机上就会提示“未受信任的企业级开发者”。

最后，上传IPA时如果用了API Key方式，需要在App Store Connect后台创建App Store Connect API密钥，生成密钥ID和Issuer ID，配合.p8文件使用。不要再用Apple ID和专用密码登录上传了，官方已经逐步淘汰这种方式。如果你在2024年之后还需要频繁上架，务必用API Key方式。

6. 常见错误、排查思路与做题技巧

6.1 笔试题里的“隐藏陷阱”清单

我在帮人批改这套题时，整理了高频出错的几个点，分享出来：

• 审题不仔细：问的是输出还是崩溃？很多Runtime题问“输出什么”，但代码执行到一半就崩了。这时候你需要先判断是否崩溃，再回答输出。
• Block捕获变量：默认捕获的是局部变量的副本，不是引用。如果你想修改外部可变对象，需要加__block修饰；如果你修改的是对象内部属性，不需要__block，直接通过指针修改即可。
• dealloc里借用了self：在dealloc中调用self的方法，ARC下不会报错，但如果你这方法里又访问了某个已经被释放的属性，就会产生EXC_BAD_ACCESS。dealloc里只做资源释放，其他逻辑全部挪出去。
• 主线程死锁：记住“同步+主队列=死锁”这个口诀，做题时看到dispatch_sync和dispatch_get_main_queue组合，直接判断死锁，除非当前不在主线程执行。
• 字符串比较：题目里经常出现isEqualToString和==混用的陷阱。==比较的是指针地址，isEqualToString比较的是内容。如果两个字符串都来自字面量，==可能返回YES，但来自变量拼接时，==基本返回NO。笔试时要看清对象创建方式。

6.2 排查线上问题的工具与方法

虽然这是笔试题，但面试官问“你怎么排查内存泄漏”时，你最好能说出具体工具。我在日常开发中最常用的组合是Instruments的Leaks模板加Xcode Memory Graph。

Leaks模板能帮你发现循环引用导致的内存泄漏，但如果对象已经被释放，Leaks里就找不到了。这时候用Memory Graph，点击某个对象，能看到谁持有它，顺着引用链找，就能发现是哪个属性没有被释放。

我还习惯在ViewController里加一段dealloc日志：

- (void)dealloc { NSLog(@"%@ dealloc", NSStringFromClass(self.class)); }

然后把App跑一遍，如果某个页面返回后没有打印这行日志，说明页面没被释放，循环引用嫌疑非常大。这个方法比Instruments直观多了，尤其是页面跳转链路复杂时。

6.3 做题顺序与时间分配

如果你要拿这套卷二（B）来模拟面试，我给一个时间分配参考：选择题不超过15分钟，填空题不超过20分钟，剩下的时间全部放在代码输出题和方案设计题上。代码输出题是拉开差距的地方，写之前先在草稿纸上画清楚对象引用关系和队列执行顺序，不要看到代码就猜输出。

方案设计题尽量画图配合文字，但注意我这里说的“画图”不是mermaid，你用文字直接分点说清流程就行。比如设计网络层，你可以说：第一步封装请求配置，第二步管理缓存读写，第三步对错误分类处理，第四步提供日志上报接口。分点表述有层次，面试官看起来也舒服。

7. 这份笔试题对职业发展的启发

把整套卷二（B）过一遍，你会发现货拉拉当年要的人和现在很多中大型互联网公司要的人几乎一样：基础扎实、懂原理、能解决线上问题。它没有考Swift的新语法，没有考AR场景，甚至连当时很火的RxSwift都没碰，考的全是iOS开发里不会过时的底层能力。

基于这套题，我建议iOS开发者把重心放在几个方向：

一是把Objective-C的Runtime和内存管理彻底吃透。就算你平时写Swift，App启动时的动态库加载、OC和Swift混编时的消息转发都离不开这些知识。

二是多做多线程排查练习。线上崩溃有一大半和线程问题有关，GCD、NSOperation、锁的底层实现原理一定要能讲清楚。

三是重视网络层弱网优化。业务App的体验瓶颈往往不在UI，而在网络。学会配合Charles或者现网工具抓包分析弱网场景，这个经验很难从书上学到，但极其值钱。

四是养成写自动化脚本的习惯。打包、证书更新、上传，这些重复劳动完全可以交给脚本，省下的时间用来做架构设计或者学新东西，性价比高得多。

最后再分享一个小技巧：面试刷题时不要只看答案解析，一定要动手敲一遍。哪怕只是把代码贴到Playground或小工程里跑一跑，看看实际输出是不是和你预想的一致，这比自己死记硬背强十倍。很多看起来平平无奇的代码，跑起来才明白坑在哪里。这套卷二（B）里至少有一半的题目，我能根据真实工程经验给你讲出设计它们的原因，这比答案本身更值得研究。