网易iOS校招笔试复盘：Runtime、内存管理与多线程核心考点解析

我帮好几个师弟师妹复盘过网易2018校招iOS开发工程师笔试卷，说实话，这份卷子在当年的大厂校招里算是比较有代表性的。它不考偏题怪题，而是把iOS开发工程师日常最常碰到的语言特性、内存管理、runtime机制、并发模型、UI渲染链路和工程化认知全部串联起来。几年后再看，iOS面试题的核心框架其实没有太多变化，只是技术在演进，考察角度更细了。这篇文章不打算把原题一张张抄出来当题库念，而是基于这份卷子的考察逻辑，把iOS校招笔试和后续面试里真正重要的考点拆开讲清楚，并附上我当时帮人复盘时积累的实操经验和避坑记录。

如果你正准备参加大厂iOS岗校招，或者工作一两年想跳槽，想系统梳理一遍iOS开发的核心知识，这篇文章应该能给你一条比较清晰的备考主线。

1. 笔试卷的整体布局与考察逻辑

1.1 基础语法与语言特性：不是背概念，而是考“能不能写稳”

网易这份2018年的笔试卷，选择题和填空题部分覆盖了大量Objective-C的语言细节。比如分类（Category）与扩展（Extension）的区别、属性关键字在不同场景下的语义差异、block对变量的捕获规则、字符串和集合类在可变与不可变之间的底层差异。很多人觉得这些是“基础题”，应该拿满分，但实际失分率很高。原因在于，校招笔试题很少直接问“什么是分类”，而是会给你一段看似正常的代码，问最终输出是什么，或者会不会崩溃。比如在一个分类里声明了一个和主类同名的方法，调用时走的是哪一个；比如用copy修饰NSMutableArray属性后，往里添加元素会不会崩溃。这类题考察的不是记忆力，而是你对Objective-C运行时查找方法、属性修饰符底层实现的理解程度。

我当时给师弟的建议是：不要靠刷题背答案，而是把每一个知识点在工程里的真实行为验证一遍。比如分类和主类同名方法为什么分类会“覆盖”主类实现？因为在runtime的方法列表插入逻辑里，分类的方法会被插入到类方法列表的前面，而运行时消息查找是顺着方法列表依次查找的，先找到谁就调用谁。你如果只用“分类优先级更高”这种话术去答题，换一个场景就懵了。只有真正理解方法列表的插入机制，才能应对考官换着花样出题。

1.2 从整体难度阶梯看大厂筛选逻辑

网易2018校招iOS笔试卷的整体难度呈现明显的阶梯式上升。前面60%左右是“会者不难”的基础题，考察候选人的日常积累；中间30%是runtime、内存管理、多线程、Autorelease机制等进阶题，考察的是候选人是否真正理解iOS底层运行原理；最后10%是结合工程场景的开放题，比如“如何优化UITableView的滑动流畅度”“App启动时间过长怎么排查”，这类题没有标准答案，但能直接筛选出有真实项目经验、有性能调优意识的人。

这种难度设计其实反映了大厂校招的核心逻辑：基础决定下限，底层原理决定上限。你不能指望一个完全没接触过iOS的人通过刷两周题就能通过，但也不需要你已经是资深架构师。关键看你有没有形成“遇到问题愿意往底层多挖一层”的习惯。所以，这份卷子给备考者的启示是：复习时不要只盯着高频题，更要建立完整的知识链路，把语言、运行时、系统框架串起来理解。

1.3 2018年时间点与技术背景

2018年这个时间点，iOS生态正处于一个重要过渡期。iPhone X带来了刘海屏和Safe Area概念，iOS 11引入了大标题导航栏、File Provider、Drag and Drop等新特性，iOS 12则在性能优化上下了很大功夫。网易这份笔试卷里也明显带上了这些时代印记，比如会考察Safe Area与Auto Layout的配合、iPhone X底部Home Indicator的适配、以及64位架构下的一些兼容性问题。

如果你现在才看到这份题，会觉得有些考点已经“过时”了，比如iOS 11的适配细节现在基本不用单独处理。但考察背后的能力模型并不过时：快速学习新系统特性、从系统变更中找到对现有工程的影响范围、在兼容与创新之间做取舍。这也是为什么我建议校招同学不要只刷最新面经，老牌大厂的历年题同样值得做一遍，因为它能帮你建立iOS开发的纵向历史观。

2. 内存管理：校招笔试里的送分题与连环坑

2.1 ARC不是自动垃圾回收

笔试卷里关于内存管理的题目几乎每年都有，网易这份也不例外。但很多候选人有一个根深蒂固的误解，觉得ARC等于Java里的垃圾回收，写代码时完全不用关心内存。这个误解在笔试里会吃大亏。ARC是编译期的内存管理优化，它在编译阶段帮你在合适的位置插入retain、release、autorelease调用，但它的前提是编译器能正确分析对象的生命周期。一旦出现编译器无法确定的情况，比如block对self的强引用、delegate用strong修饰、NSTimer对target的持有，ARC是帮不了你的，循环引用该发生还是会发生。

我印象比较深的一道题是：在一个视图控制器里用[NSTimer scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:]创建了一个重复定时器，并且在dealloc里invalidate，问这个控制器会不会正常释放。很多人答“会”，因为dealloc里做了清理。但实际答案是不会。因为scheduledTimerWithTimeInterval方法会将timer添加到当前RunLoop的common mode中，而RunLoop会对timer强引用，timer又会强引用target（也就是控制器），形成一个self -> timer -> self的循环，dealloc根本不会被调用。正确的做法是在viewWillAppear里创建timer，在viewWillDisappear里invalidate，或者使用iOS 10之后提供的block版本timer，在block里使用__weak修饰self打破循环。

2.2 循环引用：所有大厂面试必问的连环坑

循环引用这一块，笔试卷通常会从三个角度去考：代理属性、block、NSTimer。

代理属性考的是weak和assign的区别。很多人知道delegate要用weak，但不知道为什么。如果delegate用strong，那么两个对象会互相持有，谁都没法释放。那为什么不能用assign？因为assign在对象释放后不会自动置nil，再向这个野指针发消息会直接崩溃。而weak在对象释放时由runtime自动把指针置为nil，消息发送时就变成了向nil发消息，不会崩溃。这个“自动置nil”的机制，很多人只是在概念上知道，笔试里一旦问到底层怎么实现的，就卡住了。其实weak表是一张哈希表，以对象地址为key，value是weak指针地址的数组。对象释放时会根据对象地址找到所有weak指针，逐个置为nil。

block的循环引用更隐蔽。常考的场景是：在block里直接使用self的属性，或者调用self的方法。如果你不假思索地写self.name = xxx，block就会强引用self；如果self又通过属性持有这个block，就形成了循环。笔试卷里经常给出一段代码，让你指出哪里有问题并改错。标准答案是使用__weak typeof(self) weakSelf = self;，在block内部再用__strong typeof(self) strongSelf = weakSelf;。很多初学者只写了weakSelf，其实在block执行期间，如果self已经被释放，weakSelf就变成nil了，block里后续的self操作都不会执行。用strongSelf可以保证在block执行期间self不会被释放，同时不产生循环引用。这个“先weak后strong”的技巧，笔试和面试都极爱考。

2.3 从笔试题延伸：引用计数与autorelease的底层细节

Objective-C的引用计数原理也是网易这类笔试卷的常客。核心问题是：retain增加引用计数、release减少引用计数、当引用计数降为0时调用dealloc。但ARC下你不需要手动调用这些方法，编译器会在合适的位置插入。

比较进阶的考点是autorelease。比如@autoreleasepool的作用范围、什么时候释放、一个对象的autorelease是在什么时候真正release的。很多人只知道“@autoreleasepool包裹的代码在作用域结束时释放”，但RunLoop与autoreleasepool的关系才是大厂真正想考的。每个RunLoop周期里，系统会创建一个autoreleasepool，在RunLoop休眠前或退出时drain。这就是为什么在循环里大量创建临时对象时，需要手动加一个@autoreleasepool来及时释放内存，而不是等整个RunLoop周期结束。

2018年笔试那会儿，还有一道关于dealloc的题也很有区分度：问在dealloc里能不能用self访问属性、能不能调用self的方法、能不能用weakSelf。答案是：在dealloc期间，对象正在被释放，不应该使用self访问属性或调用方法，因为相关对象可能已经释放，会造成野指针。正确做法是直接使用成员变量来清理资源。这个知识点很多工作一两年的开发者也未必注意得到。

3. Runtime与动态特性：iOS开发的核心灵魂

3.1 消息发送与消息转发：从“方法调用”说起

Objective-C的消息机制是runtime最核心的内容，也是网易笔试卷区分度最高的考点之一。基本问题通常是：[obj doSomething]这行代码在运行时发生了什么。答案是编译器会将其转换为objc_msgSend(obj, @selector(doSomething))，然后runtime根据obj的isa指针找到对应的类，在类的方法列表（包括父类链）中查找对应的IMP，找到后调用；找不到则进入消息转发流程。

消息转发流程是笔试和面试都很爱深入追问的部分，分为三个阶段：

第一阶段，动态方法解析。runtime会调用+resolveInstanceMethod:，你可以在这里用class_addMethod动态添加一个实现。

第二阶段，快速转发。如果动态解析不处理，runtime会调用-forwardingTargetForSelector:，你可以把消息转发给另一个对象。这个机制常被用来实现“多继承”效果，比如让一个对象代理另一个对象的方法。

第三阶段，完整转发。如果前两步都不处理，runtime会调用-methodSignatureForSelector:获取方法签名，然后调用-forwardInvocation:，你可以把方法调用包装成NSInvocation，做统一处理或转发给多个对象。如果这一步也不处理，最终会抛出unrecognized selector sent to instance异常。

我当时给师弟讲这一段的时候，让他把消息转发想成一个“层层上报的流程”：先问自己能不能动态补一个实现，不能再问有没有备用对象能处理，还不行就把完整方法调用包装起来做统一处理，最后实在不行就崩溃。这样记不仅笔试能写出流程图式的回答，面试时也不会被追问卡住。

3.2 Method Swizzling：看起来简单，坑却不少

Method Swizzling在runtime类题目里出现频率很高，网易2018年这道题我印象很深：给一个黑盒类添加日志统计功能，要求不改变原有类的实现，写出实现思路。标准答案是使用Method Swizzling，交换两个方法的IMP。

交换方法的核心代码很简单：

+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class class = [self class]; SEL originalSelector = @selector(viewDidLoad); SEL swizzledSelector = @selector(swizzled_viewDidLoad); 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); } }); }

但真正决定你能不能拿高分的，是你能不能说出这段代码里几个关键细节。第一，Swizzling要在+load里做，因为+load是类加载时调用，能保证交换只发生一次；第二，要用dispatch_once保证线程安全；第三，为什么不直接method_exchangeImplementations，而要先用class_addMethod判断？因为如果原类本身没有实现“被交换的方法”，而是从父类继承来的，直接交换会把父类的方法实现也换掉，影响范围过大。先用class_addMethod给当前类添加一个原selector的实现，就可以把影响控制在这个类内部。

这些细节在笔试里很难想到，但你一旦在项目里真正做过Swizzling（比如无侵入统计页面停留时长、处理iOS系统版本兼容问题），就会理解这段代码为什么必须这么写。这也是为什么我反复跟校招同学讲：遇到runtime相关题目，不要只背最终代码，一定要理解每一步在防御什么。

3.3 KVO的实现原理：为什么说它是“用runtime拼出来的”

KVO也是网易这类笔试卷的常客，而且经常和KVC一起考。基础题是：什么是KVO、什么是KVC、两者有什么区别。进阶题是：KVO的底层实现是什么，手动触发KVO怎么做，KVO的优缺点是什么。

KVO的底层机制大概是：当你对一个对象添加KVO监听时，runtime会动态生成一个该类的子类NSKVONotifying_原类名，并将对象的isa指针指向这个子类。子类重写了被观察属性的setter方法，在setter里先调用willChangeValueForKey:，再调用父类的setter，最后调用didChangeValueForKey:。手动触发KVO就是要自己调用这两个方法。

这道题的考察深度往往在于：为什么KVO能监听到属性变化，但监听数组变化却经常失效。因为直接对NSMutableArray调用addObject:是不会触发KVO的，必须通过KVC的可变数组代理方法mutableArrayValueForKey:获取代理对象，再通过代理对象操作数组，KVO才会生效。很多做惯了业务开发的人在这上面踩过坑，搞不清楚为什么数据明明变了，UI却没有刷新。

另外有一个多年后被问烂了的问题：如果父类和子类都监听同一个属性，KVO会触发几次。答案是子类监听触发一次、父类监听触发一次，总共两次。这在嵌套KVO场景里很容易惹出问题，笔试卷偶尔也会拿这个做文章。

3.4 associated object与分类添加属性

分类里不能直接添加成员变量，这是Objective-C语言层面的限制。但业务中经常需要在分类里“添加属性”，怎么办？用associated object。网易笔试里有道题就是：给UIView添加一个分类，要求可以让任意UIView绑定一个字符串，写出实现。

实现不难：

static const char kAssociatedKey = 'kAssociatedKey'; @implementation UIView (Associated) - (void)setCustomTagInfo:(NSString *)customTagInfo { objc_setAssociatedObject(self, &kAssociatedKey, customTagInfo, OBJC_ASSOCIATION_COPY_NONATOMIC); } - (NSString *)customTagInfo { return objc_getAssociatedObject(self, &kAssociatedKey); } @end

但面试时通常会追问：OBJC_ASSOCIATION_COPY_NONATOMIC是如何影响内存管理的、什么时候会触发release。答案在于，associated object的释放时机是对象自身dealloc时，runtime会统一调用_object_remove_assocations来释放所有关联对象。如果关联策略是retain或copy，会先release旧值再设置新值。这个机制在日常开发中用来给系统类扩展轻量级状态非常顺手，但要注意不能滥用，尤其是用strong策略关联一个持有大量资源的对象时，要谨慎管理生命周期。

4. 并发与Runloop：笔试里最容易失分的两个模块

4.1 GCD的队列层级与“死锁”问题

GCD相关题目在网易2018校招笔试卷里分量很重，而且多数是以代码分析的形式出现。最经典的考察点是：在主线程执行以下代码会发生什么。

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

答案是死锁。原因很清晰：主线程同步派发一个任务到主队列，任务需要主线程执行，但主线程正在等待同步任务执行完毕，互相等待，谁也不让谁。这个例子几乎出现在每一家公司的iOS笔试题里，但每年还是有很多人答错，或者只知道“会死锁”，却说不清原因。备考时一定要把队列、线程、同步/异步派发的关系彻底理清。

再进阶一点的题目是：在自定义串行队列里执行同步任务到自身队列，会不会死锁。答案也是会。因为同步派发会阻塞当前线程并等待任务完成，而任务又被派发到同一个串行队列，需要等待队列里前一个任务（当前任务）完成，形成循环等待。同理，dispatch_sync到并行队列则不会死锁，因为并行队列不需要等待前面的任务完成，系统会直接开新的线程执行任务。

这里建议你把GCD的核心概念整理成一张对照表来记忆：串行队列 + 同步派发 = 大概率死锁（同队列）；串行队列 + 异步派发 = 按顺序执行但不阻塞；并行队列 + 同步派发 = 在新线程执行，不阻塞当前线程；并行队列 + 异步派发 = 常见方式，不阻塞当前线程，并发执行。

笔试之外，面试官还可能追问：dispatch_group怎么实现等所有任务完成后再统一刷新UI，dispatch_semaphore怎么控制并发数。这些属于iOS多线程开发的高频工具，建议每个都写个小demo跑一遍，光看概念印象不深。

4.2 线程安全与原子性：atomic不等于线程安全

线程安全相关的题，网易笔试主要考两类：一类是NSMutableArray、NSMutableDictionary在多线程环境下读写崩溃问题；另一类是atomic属性是否保证线程安全。

先说前者。多线程并发操作NSMutableArray，最常见的崩溃日志是“index out of bounds”或者“malloc: *** error for object ... pointer being freed was not allocated”。原因是数组在扩容、插入、删除时，如果另一个线程同时读取，可能读到中间状态。解决方案有几种：加锁（NSLock、@synchronized、os_unfair_lock）、用并行队列包裹写操作、或者用更底层的pthread_rwlock做读写分离。笔试卷一般会让你选择最合适的方案，这时候不要只看答案，要能说出每种方案的优缺点。比如@synchronized简单但性能一般，它底层是递归锁，适合轻量级保护；os_unfair_lock性能更好但不支持递归；读写锁适合读多写少的场景。

再说atomic。atomic的作用是保证属性的setter和getter原子性，也就是多线程同时set，不会让属性处于未定义状态。但它并不保证“业务逻辑”的线程安全。举个例子，如果两个线程同时执行self.count += 1，即使count声明为atomic，最终结果也未必是2。因为+=实际是“读取旧值、计算新值、写入新值”三步，原子性只能保证单步读写安全，不能保证三步作为一个整体不被插队。这个考点非常经典，也经常在面试中被追问出一个反问：那怎么才能做到线程安全？答案是加锁或者使用专门的原子操作。

4.3 Runloop与事件循环：为什么App能“一直活着”

Runloop是iOS开发里出了名的“不见得每天直接用，但面试总要考”的知识点。网易2018年笔试卷也涵盖了Runloop的常见模式，包括Runloop有哪几种运行模式（Default、Common、Tracking、Initialization等）、Timer在滑动时为什么会被暂停、如何让NSTimer在UIScrollView滑动时依然工作。

Timer在滑动时被暂停的根本原因，是UIScrollView滑动时主线程Runloop会切换到UITrackingRunLoopMode，而NSTimer默认添加到了NSDefaultRunLoopMode，在Tracking模式下不会被处理。解决办法有两个：把timer添加到NSRunLoopCommonModes，或者放到子线程的Runloop里。这个知识点非常实用，因为很多人在做轮播图时遇到过图片轮播在滑动时停顿的问题，原因就在这里。

进阶点在于Source0和Source1的区别。Source0是用户主动触发的事件，比如点击屏幕；Source1是系统内核事件，比如基于Port的通信。笔试卷一般不会让你抠这种细节，但面试官如果顺着Runloop往下问，你最好能答出来。再往下就是Autoreleasepool与Runloop的关系、Runloop在AFNetworking常驻线程中的应用。当时我在给师弟梳理时，让他把Runloop想象成一个“大管家”，没有事件就睡觉，有事件就分发给对应的人处理，这个类比在理解层面帮助很大。

5. UI与渲染：从Auto Layout适配到离屏渲染

5.1 Auto Layout、Safe Area与UIStackView的适配

2018年的iOS笔试如果完全避开Auto Layout和iPhone X适配，反而奇怪。网易那份卷子里就有关于Safe Area的题目，比如“在iPhone X上，如何让内容避开底部Home Indicator区域”。这在iOS 11之后有成熟的API，直接使用view.safeAreaLayoutGuide即可，Adaptive Layout中还有additionalSafeAreaInsets可以额外扩展安全区域。

同时，UIStackView也是当时比较新的考点。UIStackView并不是一个真正意义上的布局控件，而是一个容器，它帮你去管理内部子视图的约束关系。它解决的核心痛点是：当多个视图水平或垂直排列，间距和尺寸需要动态变化时，手写约束会非常繁琐。用UIStackView可以极大减少约束代码，而且配合分布对齐选项（Fill、FillEqually、FillProportionally、EqualSpacing、EqualCentering），可以实现很多复杂布局。笔试里可能会给你一段描述，问用什么控件实现最合适，这时候如果你只会Auto Layout，不会UIStackView，就会失分。

但也要提醒一句：UIStackView在嵌套复杂布局时性能未必好，它本质上是将多个约束组合起来管理，层级嵌套过深会带来约束计算量上升。所以我在实际项目中的经验是：简单的等分、自适应排列优先用UIStackView，复杂的交错布局还是要回到Auto Layout甚至手动frame。

5.2 离屏渲染：iOS性能优化里绕不开的坎

离屏渲染在网易2018年笔试中出现过一道很经典的题：设置UIView的圆角效果，什么时候会触发离屏渲染，什么时候不会。很多人只知道“设置圆角会触发离屏渲染”，但实际是否触发，取决于实现方式。

如果你用view.layer.cornerRadius配合view.layer.masksToBounds = YES，并且在view上还有内容（包括背景图片、子视图、背景色），那么iOS会触发离屏渲染。因为系统需要先把view的内容渲染到一个离屏的缓冲区，再通过圆角路径裁切后合成到屏幕。如果你只是给UIImageView设置圆角，且不设置masksToBounds，系统可以直接在渲染阶段处理，不一定会产生离屏渲染。

离屏渲染为什么需要关注？因为它在GPU渲染管线里是额外的一步，尤其是tableview滚动时，如果有大量页面同时触发离屏渲染，会发现滑动帧率明显下降，出现掉帧。优化手段常见的有几种：用UIBezierPath做圆角裁剪、把圆角提前合成到图片上、用CAShapeLayer配合mask、或者只对最上层视图设置圆角并配合图层透明度处理。笔试如果考到性能优化，不从离屏渲染的角度答，就少了一个关键得分点。

5.3 UITableView滚动流畅度与卡顿排查

UITableView的性能优化是iOS笔试和面试最高频的开放题之一。网易2018年笔试卷有一道“如何保证UITableView滑动流畅”，虽然不要求写代码，但需要你给出系统性的优化方案。常规答案分几个层面：

第一层是cell复用，这个是最基础的，必须答到，但光答这个不够。

第二层是高度计算。如果cell高度是动态的，不要每次都调用heightForRowAtIndexPath去实时计算，最好缓存高度；使用Auto Layout时要注意约束完整性，减少约束冲突。iOS 11之后可以使用UITableViewAutomaticDimension，但要注意预估行高estimatedRowHeight的设置，设置得当可以显著提升首次加载速度。

第三层是渲染压力。减少离屏渲染、减少复杂图层层级、避免在cellForRowAtIndexPath里做大量耗时操作，比如图片解码、字符串计算。尤其是图片，如果用UIImage imageNamed:加载大图，每次滚动都可能触发图片解码，造成卡顿。比较成熟的方案是使用异步解码、提前裁剪、按需加载。

第四层是数据源与UI更新。不要在后台线程直接操作UI，不要在主线程做大量计算。如果数据是分页加载的，要注意批量更新和差量刷新，避免reloadData拖慢滚动。

答这种题时，如果能把“CPU耗时点”和“GPU耗时点”分开讲，面试官会认为你有实际的iOS开发性能调优经验，而不只是背答案。

6. 网络与工程化：进阶笔试里最容易拉开差距的部分

6.1 HTTP、HTTPS与TCP三次握手的基础知识

网易2018校招iOS笔试卷的网络题，难度不低。常见考点包括：HTTP和HTTPS的区别、TLS握手过程、TCP和UDP的区别、TCP三次握手和四次挥手、HTTP的请求头与响应头常见字段、GET与POST的区别。这些知识在大学课程里都学过，但校招笔试会结合iOS开发场景出题，比如“ATS（App Transport Security）是什么，为什么要用HTTPS”。

ATS是iOS 9之后引入的网络传输安全机制，默认要求所有网络请求都使用HTTPS。如果你的App因为某些原因需要兼容HTTP接口，必须在Info.plist里配置NSAppTransportSecurity的例外字段。这个考点我在实际项目里遇到过很多次，特别是接手旧项目时，发现一堆HTTP接口上线时配置不规范，审核时容易被拒。所以笔试里如果考到ATS，最好能说明配置的细节和潜在风险。

6.2 Charles抓包与接口调试的实操技巧

网络调试是iOS开发日常离不开的能力，网易笔试卷里的网络题也会间接考察类似思路，比如“线上有用户反馈接口返回异常，但你本地复现不了，如何排查”。这种开放题最稳妥的思路就是：先用Charles抓包看看线上接口的完整请求和响应，确认是入参、出参还是网络链路问题。

Charles抓包本身不复杂，但要抓HTTPS的明文字段，需要在手机上安装并信任Charles的SSL证书。这里有一个经常踩到的坑：安装了证书后，如果App开启了证书校验（SSL Pinning），依然抓不到包。遇到这种情况，需要暂时禁用证书校验或使用支持SSL Pinning绕过的方式。不过这部分内容在面试中最好谨慎展开，重点应该放在你的排查思路和工具使用是否熟练。

还有一个实用技巧：用Charles做接口的断点调试（Breakpoints）与本地映射（Map Local），可以快速mock后端返回数据，很多UI联调场景用这个方式特别高效。但这里要提醒一点，工程里不要为了测试方便把mock数据写死在代码里，我曾经见过一个App上线后还在读取本地mock数据，界面一片假数据，这种问题在Code Review时要重点防范。

6.3 证书管理、签名机制与上架流程

iOS开发者的App证书管理、描述文件（Provisioning Profile）、上架流程，是大厂iOS笔试卷里比较偏实践的考点，尤其对于有上架经验的候选人，这类题几乎是送分题。网易2018年也有类似题目，比如“描述文件过期会导致什么问题”、“Xcode里的证书和描述文件之间的关系是什么”。

简单梳理一下：开发者证书（Certificate）用来签名你的App，确保App的开发者身份合法；描述文件（Provisioning Profile）是把开发者证书、App ID和测试设备捆绑在一起的配置文件。真机调试、发布TestFlight、上架App Store，都需要对应的描述文件。如果描述文件过期，最直接的表现是App无法装在真机上，或者提交到App Store时校验失败。

很多同学第一次接触时会被一堆证书和过期时间搞懵，其实只要掌握一个核心流程：用Apple ID登录开发者中心生成证书，打开Xcode的Signing & Capabilities自动管理签名，真机调试时确保设备被加进描述文件。上架流程通常是：在App Store Connect创建应用信息 -> 构建版本（用Xcode Archive上传） -> 选择构建版本 -> 填写审核资料 -> 提交审核。2018年的上架流程和现在差别不大，只是审核材料要求越来越细，像隐私政策、收集数据的说明，现在都必须写得很清楚。

6.4 混合开发与架构选型：2018年的热与冷

混合开发方案在2018年非常热，网易笔试卷里也有关于Hybrid App和跨端框架的开放题。那时React Native已经火了两三年，Flutter刚起步，Weex在国内也有不少落地案例。笔试卷可能会问：你如何看待原生开发与跨端框架的选型，在什么场景下选择React Native，什么场景下继续使用原生。

我当时给师弟准备的答题框架是：永远不要脱离业务形态来谈技术选型。如果你的团队以iOS和Android双端为主、业务需求变化快、UI复杂度不高，跨端方案可以明显提升并行效率。如果业务追求极致体验，重度依赖系统硬件能力（比如地图导航、音视频处理、AR），那么原生依然是更稳的方案。近两年Flutter和RN各有起落，国内大厂也有不少团队转回原生或自研方案，这个趋势本身就是很好的谈资。

架构题也是笔试的压轴常客。MVC、MVVM、MVP的区别和适用场景，组件化方案如何设计，Router如何解耦页面跳转。网易2018年笔试卷我记得后面有一道开放题，是“如何设计一个App的架构来支持多人协作开发和多功能模块扩展”，这题没有标准答案，但最容易踩的坑是答得过于宏大、抽象，没有落到具体工程细节。比较好的答法是：先用一句话说明架构目标，然后从工程分层、模块划分、通信机制、依赖管理、持续集成几个维度展开，每个维度给出一个具体例子。比如工程分层上，可以把“基础层（网络、存储、工具）- 业务层（页面、组件）- 应用层（启动、路由）”分开。通信机制上，可以用协议接口约束模块间的调用，避免相互直接依赖。这样一来，即使面试官追问，你也有足够的细节支撑。

7. 常见问题与避坑实录

7.1 笔试常见易错点速查

我在帮人复盘网易2018年题时，把历届同学最容易出错的点整理成了一个快速自查表。

这张表可以直接拿来当考前最后一天的速查记忆卡，比翻厚重的笔记高效得多。

7.2 面试追问时最容易暴露问题的地方

笔试过关后，面试官喜欢顺着笔试里的错题或薄弱点往下追问。我见过最多的翻车场景是：笔试里写了__weak typeof(self) weakSelf = self;，但面试官问“为什么用weak而不是assign”时答不上来；笔试题里写了dispatch_async，但问“并行队列和串行队列在性能上差多少”时就说不出所以然；知道KVO可以监听属性变化，但问“KVO会不会导致循环引用”时完全没有思路。

所以准备面试时，不要只准备“正确答案”，还要为每个答案准备至少两个“为什么”和两个“如果”。比如你知道delegate要用weak，那还要知道weak底层是怎么自动置nil的；你知道block里用了weakSelf，那还要能说清楚什么时候需要strongSelf；你知道GCD并行队列并发执行，那还要能说明并发任务多了以后线程爆炸的风险以及DispatchSemaphore怎么控制最大并发数。

7.3 备考策略与资料整理建议

关于怎么准备这类大厂笔试卷，我给身边人推荐的方式一直是“三遍法”。

第一遍：限定时间独立做一遍，把不会的题目标记出来，重点收集做错的题。注意一定要独立完成，不要一边看答案一边写，否则根本看不出自己的知识盲区。

第二遍：一道题一道题去溯源。做错的每一道题，都要找到对应的官方文档或权威博客，把背后的机制搞清楚。比如block捕获变量，去看clang转换后的C++代码；KVO底层，看runtime源码里NSObject的响应方法；GCD死锁，用Playground写个demo复现一下。这个阶段最耗时，但收获最大。

第三遍：合上题目，按知识域复述整个答题思路。不需要背原题，而是把每个知识点的来龙去脉讲给自己听。能讲得清楚，面试就不会太慌。

我自己在iOS开发里摸爬滚打这些年，最大的体会是：大厂校招笔试不像很多人想的那样只是“筛选简历的工具”，它更像是给候选人一面镜子，让你看到自己在整个iOS知识体系里还有哪些盲区。网易2018这份卷子虽然已经过去几年，但它的题目质量和考察思路放到今天依然很有参考价值。你把它当成一块磨刀石，磨的不仅是答案本身，更是你拆解问题、钻到底层原理的能力。

最后再分享一个小技巧：做笔试卷时，遇到不会的题先别忙着查资料，拿一张纸把自己“猜”的答案和理由写下来，哪怕写的是“我不确定，但我认为……”。这个动作很关键，因为它逼你把隐性的直觉转成显性的逻辑链。答完之后再对照解析，你会发现自己真正的思考断点在哪里。iOS开发是一个需要持续自省的领域，笔试只是第一关，后面还有更长的路。

祝你顺利拿下offer。