企业官网建设流程全解析

吃过2018年京东iOS笔试题的亏的人应该不少，我前阵子重新翻出这份题目来复盘，最大的感受是：这套题放在今天依然是很好的面试复习提纲。那年正值iOS 11/12交替、iPhone X全面屏刚普及，Swift还没在社区里形成绝对统治力，OC依然是电商App的主力语言。所以整张卷子非常“工程向”，不考炫技、不抠偏门，多数题都是你平时写业务就绕不开的东西。

无论你是准备秋招的在校生，还是想跳槽的客户端工程师，把这份卷子对应的知识点吃透，基本等于把iOS面试最常考的底层框架完整过了一遍。这篇文章我就按自己的理解，把这份笔试题背后的考察逻辑、核心考点、答题思路和避坑方法逐一拆开讲。

1. 京东2018秋招iOS笔试题：整体画像与命题逻辑拆解

1.1 电商客户端面试为什么偏爱“工程落地”题

京东APP是典型的电商业务形态，首页信息流、商品详情、购物车、订单状态流转、秒杀活动，每一个模块都对列表流畅度、图片加载、弱网处理、复杂状态同步有很高要求。这就决定了它的技术面试不会像某些公司那样抱着纯数据结构不放，而是特别爱把底层机制和业务场景绑在一起考。

举个例子，同样是考Runtime，理论型公司可能让你默写消息转发流程，京东这类工程型公司更可能问“线上有个埋点需求，要在不侵入业务代码的情况下统计所有按钮点击，你会怎么设计”。你会发现前者考的是记忆，后者考的是用底层知识解决实际问题的能力。2018年秋招的题就是这么个风格：表面在问原理，实际在暗示你“以后来了要能扛业务”。

所以看这份卷子，不能只看单题怎么答，要先看懂它的命题偏好——考点集中在iOS日常开发的高频区域，并且特别强调“能不能落地上线”。你在复习时如果只顾着刷概念题，不结合场景做推导，笔试很容易翻车。

1.2 从解题中总结出的能力分布

我复盘时把这份卷子的主要题型按知识域做了个粗略归类，比例大致如下：

这套分布是有道理的。对iOS工程师来说，OC语言和内存管理是基本功，连引用计数都讲不清楚的人，上线后很容易制造内存泄漏；Runtime是iOS动态性的灵魂，大厂App普遍用它做AOP埋点、防崩溃、动态化；多线程和UI性能直接决定用户体感；网络和存储是电商业务的数据血管。它看起来是一张卷子，其实就是一个大厂iOS工程师的日常能力清单。

1.3 知识点迭代慢，所以老试卷不过时

很多人一看到“2018年”就觉得过期了，其实iOS底层核心机制迭代得非常慢。ARC引用计数规则没变、RunLoop的源码到今天还是那套逻辑、Runtime的消息转发流程更是十几年稳如泰山。真正变化大的是Swift语法和上层框架，但那份卷子偏偏重点考变化最小的部分。

换句话说，这份题考的不是“最新技术”，而是“iOS开发者的内功”。内功是不分年份的，你今天去面一些大厂，把这份卷子拿出来当模拟题做，命中率依然很可观。这也是我把这些老题重新拿出来逐题聊的原因。

2. 语言底层与内存管理：先把OC的根刨清楚

2.1 一个对象占多少内存，怎么算才是对的

这类题在2018年卷子里几乎是必出的，而且往往以“一个NSObject实例占用多少内存”开头。很多人的第一反应是8字节，因为NSObject只有一个isa指针。这个答案只能拿一半分，因为它忽略了系统的内存分配机制。

我们来看底层逻辑。OC对象在运行时对应的是objc_object结构体，NSObject本质上就是objc_object加一些方法。一个NSObject实例的大小可以用class_getInstanceSize([NSObject class])拿到，实际返回的是8，也就是isa指针的大小。但系统通过malloc分配内存时，会遵循16字节对齐规则，所以malloc_size((__bridge void *)obj)返回的通常是16。也就是说，“对象实际占多少内存”在不同层面有不同答案：objc层面是8字节，堆上实际是16字节。

这个考点延伸出去，就是带成员变量的对象怎么算内存。比如一个类有两个int属性，结构体大小是16字节（isa8 + int4 + int4），但经过对齐后仍然分配16字节。如果再加一个double，结构体是24字节，按16字节对齐就变成32字节。面试官想听的，不是你记得对齐规则，而是你能说出为什么系统要按16字节对齐——为了CPU访问效率，同时也方便内存池管理。

顺带说一个容易踩的坑：很多人会把class_getInstanceSize和malloc_size混为一谈。前者是对象本身需要的内存，后者是系统实际给的内存，两者有差异是正常的，不需要纠结。答题时按这个思路展开，比背结论要显得有深度。

2.2 weak、delegate、block、NSTimer：循环引用全家桶

这份卷子考循环引用从来不手软，一般会给你几段代码，让你判断会不会泄漏，并说明理由。我印象比较深的是结合NSTimer出的题，因为NSTimer对target是强引用的，很容易构造循环。

先说delegate为什么用weak。delegate关系里，控制器持有tableView，tableView的delegate指向控制器。如果delegate是strong，就会形成控制器→tableView→控制器的循环；用weak之后，tableView只是弱引用它的代理，不增加引用计数，循环就断了。这和__weak局部变量原理一样，都是通过“不参与引用计数”来打破环。

Block的循环引用要更隐晦。最常见的情况是：控制器持有block属性，block内部又用了self。只要block被self持有，block里的self就会被强引用，形成self→block→self的环。解法是常见的__weak typeof(self) weakSelf = self，在block里用weakSelf。但这里有个高阶细节——如果block内部存在异步延迟，而weakSelf已经被释放了，业务逻辑就会中断。所以更稳妥的写法是进block后先__strong typeof(weakSelf) strongSelf = weakSelf，再做判断：

__weak __typeof(self) weakSelf = self; self.block = ^{ __strong __typeof(weakSelf) strongSelf = weakSelf; if (!strongSelf) return; // 使用strongSelf，避免执行过程中self被释放 };

NSTimer的循环更经典，因为timerWithTimeInterval:target:selector:...会对target做强引用。如果你在控制器里创建timer，controller持有了timer，timer又强持有controller，就把控制器死死锁住。2018年那会儿官方建议用block方式创建timer，把target换成一个不持有外部对象的中间对象，这样就切断了引用链。我实际开发中用得更多的是封装一个WeakProxy，把timer的target指向这个代理，代理对controller做弱引用。

还有一个高频题是“weak底层怎么实现”。这题要答到SideTable和散列表：weak引用会被注册到SideTable中的弱引用表，对象释放时会通过dealloc找到这个表，把所有weak引用置为nil。知道这层，才能解释为什么weak只能用于对象、不能用于非OC对象，以及为什么__unsafe_unretained不自动置空。

2.3 Runtime消息发送和Method Swizzling

Runtime在2018年秋招里的考法已经从“默写流程”升级到“讲清楚每一步会在什么场景触发”。最典型的题是：向一个对象发送一个不存在的方法，会发生什么？它的完整链路是：

1. 编译器把[obj foo]翻译成objc_msgSend(obj, @selector(foo))。
2. 运行时先在obj的类对象里查找方法缓存，缓存没命中就查方法列表。
3. 都找不到时，先走resolveInstanceMethod:，你可以在这里用class_addMethod动态添加实现。
4. 如果没处理，再走forwardingTargetForSelector:，可以把消息转发给其他对象。
5. 如果还是没处理，走methodSignatureForSelector:和forwardInvocation:，实现完整的消息转发。
6. 都没有，最终触发doesNotRecognizeSelector:，程序崩溃。

这道题想拿高分，就得多说一句：消息转发机制是OC动态性的根基，也是很多防崩溃和AOP方案的基石。比如有些人会在第三步动态添加方法，有些人会在第四步把某个不存在的selector转发给一个“防崩溃对象”，让app不至于闪退。

Method Swizzling也是必考。常见考法是“如何在不改变原有实现的情况下，给所有viewController的viewWillAppear加日志”。标准做法是交换两个方法的实现：

+ (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class cls = [UIViewController class]; SEL originalSel = @selector(viewWillAppear:); SEL swizzledSel = @selector(xxx_viewWillAppear:); Method originalMethod = class_getInstanceMethod(cls, originalSel); Method swizzledMethod = class_getInstanceMethod(cls, swizzledSel); method_exchangeImplementations(originalMethod, swizzledMethod); }); }

这题的坑很多，比如为什么要在+load里做、为什么要用dispatch_once、如果父类子类都实现了Swizzling会不会导致父类实现被覆盖。我在项目里踩过最深的就是在+initialize里做Swizzling，因为+initialize可能被触发多次，导致交换多次方法实现，直接让调用进入到无限递归。所以记住一个原则：Swizzling尽量在+load里做，而且要保证只执行一次，并且要在方法调用发生之前。

2.4 KVO的实现原理，别只背“用了isa切换”

这份卷子大概率会带一道KVO题，因为KVO和KVC在日常开发里用得实在太频繁。大多数人的回答是“KVO基于Runtime，会自动生成一个子类，重写setter方法”。这个答案能及格，但很难出彩。

完整链条是这样的：调用addObserver:forKeyPath:时，Runtime会动态创建一个当前类的子类，名字通常是NSKVONotifying_XXX，然后把对象的isa指针指向这个子类。之后对属性赋值时，实际调用的是子类重写过的setter方法，这个setter先调用willChangeValueForKey:，再调用super的setter，最后调用didChangeValueForKey:，并在didChangeValueForKey:里通知观察者。

这里有个值得深挖的细节：KVO重写setter后，如何手动触发和自动触发。如果我在业务代码里直接操作成员变量而不走setter，KVO是不会触发的，这就是为什么KVO要求属性必须通过setter赋值。有些团队想批量刷新，就会手动调用willChangeValueForKey:和didChangeValueForKey:，这也能解释为什么很多老面试官爱问“手动触发KVO的方式”。

我自己的体会是，KVO在2018年那会儿用得很多，后来很多团队转向了Block回调或者RxSwift这类方案来减少KVO的不确定性。但底层原理没变，答KVO的时候把isa-swizzling和setter重写讲透，就已经赢过一半的候选人。

3. 多线程、UI与性能优化：把卡顿和并发掰扯清楚

3.1 GCD和NSOperation如何选，不要再说“随便用”

2018年这份卷子里有一类题我非常喜欢：几个网络请求并发执行，全部结束后统一刷新UI，你怎么实现。多数人会直接答dispatch_group，但这题它的意图其实想问你能不能分清GCD与NSOperation的适用边界。

用GCD的dispatch_group是最直接的解法：

dispatch_group_t group = dispatch_group_create(); dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); for (NSURLRequest *request in requests) { dispatch_group_enter(group); dispatch_async(queue, ^{ // 发起请求... dispatch_group_leave(group); }); } dispatch_group_notify(group, dispatch_get_main_queue(), ^{ // 全部完成，刷新UI });

这里有个隐藏坑：enter和leave必须成对出现。如果网络请求回调里因为异常提前return，没走到leave，group的计数就永远不会归零，notify也不会执行。所以写生产代码时，最好在请求回调里用defer或者兜底逻辑保证leave一定被调用。

GCD虽然好用，但遇到“请求A之后做请求B，B之后再并发做C和D”这类依赖关系时就比较吃力。NSOperation可以通过addDependency:精确控制依赖，还可以通过maxConcurrentOperationCount设置并发数，这对控制同时联网的请求数很有帮助。我自己的经验是：简单并发用GCD，复杂依赖和需要取消操作时用NSOperation。笔试里把这句话写出来，面试官会知道你真的在工程上做过取舍。

3.2 列表快速滑动依然掉帧，排查思路是什么

关于UITableView流畅度的题，在电商系面试里出现频率极高。2018年京东的首页结构非常复杂，图片多、模块多、接口多，滑动掉帧是纯业务驱动的痛点。所以卷子里就出现了类似的问题：列表滚动卡顿，你如何定位和解决。

从排查路径看，核心思路是区分“主线程CPU耗时”和“渲染层耗时”。

第一步，打开Instruments的Time Profiler，看主线程上哪些方法占用时间长。常见元凶排名是：

• 图片的解码和缩放：UIImage从网络数据到可显示是需要解码的，如果直接在cellForRowAtIndexPath里做，主线程会卡。
• 复杂的AutoLayout计算：约束越多，计算越复杂。
• 动态行高计算：每个cell都现场算高度，滚动时会频繁触发计算。

第二步，用模拟器或真机的Debug选项看离屏渲染。这里最常见的坑是给UIImageView加cornerRadius和masksToBounds，以及给view加阴影。这些操作会触发离屏渲染，在列表快速滑动时极其费性能。解决方案是预裁剪圆角图片，或用UIBezierPath绘制圆角，而不是直接依赖系统属性。

第三步，检查cell的复用是否合理。比如不同样式的cell混在一个table里，应该注册多个不同的cell类，而不是在同一个cell里动态添加子视图。动态添加子视图不仅影响复用，还会让约束计算反复触发。

放一个我当时做项目时的优化清单，当滑动仍然掉帧时按顺序排查：

这道题答得好不好，关键在于有没有“排查”思维，而不仅仅是背优化手段。面试官想看到的是你拿到一个真实问题以后，按什么顺序快速定位和验证，而不是一上来就堆优化术语。

3.3 RunLoop到底在循环什么，怎么用它做监工

RunLoop在题库里属于“看似简单、实际最能拉差距”的一题。2018年很多候选人都会说“RunLoop是事件循环，用来保证线程不退出”，但这只是第一层。真正有深度的回答至少要覆盖：

• 线程和RunLoop是一一对应的，主线程的RunLoop默认开启，子线程默认不开启。
• RunLoop有Source0、Source1、Timer、Observer四类事件源。
• Mode的作用是隔离事件源，主要场景是kCFRunLoopDefaultMode和UITrackingRunLoopMode，滚动时主线程切换Mode，导致定时器不执行。

关于定时器这个点，典型考题是“滑动页面时NSTimer不回调怎么办”。原因是滑动时RunLoop切换到TrackingMode，Timer不被调度。解决方案是：

• 将Timer加入NSRunLoopCommonModes；
• 或改用GCD定时器，因为GCD是单独队列，不依赖RunLoop Mode。

RunLoop还有一个高频用处是卡顿监控。思路是往主线程RunLoop注册一个Observer，每次进入kCFRunLoopBeforeSources或kCFRunLoopAfterWaiting时记录时间戳，等RunLoop从其他状态回来时计算本轮的耗时。如果超过阈值（比如50ms），就认为有卡顿发生，再把线程的调用栈上报。这个方案后来成了很多APM SDK的雏形，面试时能说出这层，会让人觉得你真的用过。

3.4 iOS分屏、多窗口对布局的挑战，笔试题背后的新场景

2018年正好是iPad分屏能力普及的阶段，卷子里偶尔会夹带一道关于屏幕适配的题，本质上你要处理的不只是屏幕尺寸不同，而是同一时刻可能有多个不同宽度的窗口同时存在。这意味着AutoLayout不能假设“我的view肯定是全屏的”。

典型解法是用UIViewController的traitCollection.horizontalSizeClass判断当前环境是紧凑型还是常规型，不同尺寸下切换布局。还有一个细节：分屏下viewSafeAreaInsetsDidChange会被频繁调用，不能把insets相关计算写在viewDidLoad里，必须在布局方法里重新计算。这个点在笔试里作为“延伸讨论”提一嘴，会显得你对新场景有敏感度。

4. 网络层、数据存储与架构设计：从单点功能到整体设计

4.1 HTTPS证书校验和中间人攻击，到底在问什么

网络层的题，京东这套卷子基本绕不开HTTPS，尤其喜欢问“客户端怎么确认服务器身份”。表面考察的是TLS流程，实际想看你有没有真正接入过。

简单捋一下：HTTPS通过非对称加密协商出一个对称密钥，之后用对称加密传输数据。客户端要确认自己连的服务器是真的，就需要验证服务器返回的证书。证书由CA签发，客户端内置了受信任的CA根证书。服务端证书会形成一个证书链，客户端逐级验证，最终如果证书链能追溯到信任的根证书，才认为服务器身份可信。

在iOS工程里，这个逻辑体现在AFNetworking的securityPolicy上。默认模式是AFSSLPinningModeNone，只校验证书链，不做公钥绑定。更安全的是AFSSLPinningModeCertificate或AFSSLPinningModePublicKey，把服务器公钥或证书内置到App里，防中间人抓包。很多金融和电商类App为了安全，会使用公钥绑定，因为测试证书可以被替换，但公钥一般不变。

这里有一个比较细的考点：中间人的危害到底是什么。如果客户端不做证书校验，攻击者在自己机器上装一个伪造证书，就有可能在用户和服务器之间建立双向代理，看到所有明文流量。所以“HTTPS是不是安全”的关键不在于加密算法本身，而在于“是否验证了证书”。

我当时复习时把AFNetworking的源码看了一遍，着重看AFSecurityPolicy的几个方法，笔试里碰到这题就把“校验证书链”和“选择pin模式”这两点展开，很快就和只会背TLS握手流程的人拉开了距离。

4.2 登录态、商品缓存、头像分别用什么存储

这类存储选型题非常贴合电商业务。2018年卷子里有一道典型的：登录状态、用户头像、商品列表缓存，你怎么选型。

首先要分清三层：

• NSUserDefaults适合存小规模的配置项，比如主题色、开关设置、用户ID。它底层其实就是plist文件，读写是整体加载的，不适合存大数据。登录token这种小字符串放在这里没问题。
• SQLite适合存结构化、可查询的数据。商品列表缓存用SQLite很合适，因为商品字段多、数量大、还需要按条件查询和分页。iOS里常用FMDB做封装，注意打开WAL模式能大幅减少读写的锁冲突。
• 用户头像这种图片类内容，一般放在文件系统里，路径存到数据库。不要直接往NSUserDefaults里塞NSData，分分钟撑爆。

深层一点，面试官可能追问“为什么不用CoreData”。CoreData也不是不行，但从工程可控性来说，SQLite的SQL语义更明确、排查问题更直观。很多大厂App最终都选择了SQLite系的ORM或自定义存储层，不是因为它最潮，而是因为可控。你答题时提到“数据库版本迁移”也很加分，因为表结构变更是一切本地存储绕不开的坎，2018年那会儿主流做法是用FMDB的user_version配合自定义迁移脚本。

4.3 京东这种体量的App，代码架构应该怎么组织

架构题几乎是所有大厂笔试的压轴戏。2018年京东卷子里有一题大约是：面对几百人的客户端团队，你怎么设计App的架构，让它能并行开发、互不干扰。

答题思路不能只停留在MVC和MVVM。面试官想听的是模块化和组件化。

至少在思路上提四点：

1. 基础层：包含网络、存储、日志、埋点等基础设施，用CocoaPods私有仓库管理，每个库独立版本号。
2. 业务模块层：按业务域划分，比如首页、商品详情、购物车、订单，模块之间不能直接引用对方的头文件。
3. 组件通信：模块之间通过路由或协议通信。iOS生态里常见方案有基于URL的路由，以及基于Protocol的依赖注入。CTMediator这种基于Target-Action的方案在一个阶段也比较流行，它的核心是减少模块间的编译依赖。
4. 壳工程：只负责组装模块、配置启动流程，不写业务。

再深一层，可以提一下“组件化过程中容易翻车的点”。比如模块划分如果没有和业务边界对齐，拆着拆着就变成“互相依赖的地狱”；比如基础库升级会影响所有业务模块，所以必须建立灰度机制。这些都是工程落地才会遇到的问题，笔试里能主动说出来，比单纯列“我用了MVVM”要有说服力。

顺带可以联系一下“混合开发方案”这个延伸考点。电商App经常要做活动页，这里就涉及WKWebView与原生交互，以及React Native、Flutter等跨端方案。2018年团队里比较常见的是URL拦截和JavaScriptCore注入，后续才慢慢演化为更成熟的桥接方案。笔试里即便不要求你写具体实现，至少要把“为什么需要混合开发”“混合开发的风险”讲清楚，因为这是大厂客户端团队无法回避的现实。

5. 常见问题与备考避坑指南

5.1 笔试答题最容易出现的4个扣分点

我看了很多人的复盘，发现扣分往往不是知识不够，而是“答题方式”出了问题。

第一，只写答案不写理由。比如问“运行时会崩溃吗”，直接就答“会”。面试官看不到你的推理过程，他就无法判断你是真懂还是蒙的。任何判断都要带走代码逻辑，比如“因为weak不会增加引用计数，所以……”

第二，底层机制只会说到“好像”。这个特别常见，比如能说出“Block会截获变量”，但说不清__block变量被包装成结构体后如何在堆上共享。这种半碗水的水平在笔试里会露出马脚，因为人家会顺着你的话往下追问。

第三，代码不编译就交。笔试里写OC代码的语法其实不难，难的是在纸上保证每行都不出错。我的建议是写完后在脑子里模拟执行一遍，特别检查循环引用、代理是否weak、字符串为空等边界。

第四，不按题目限定环境回答。题目问“在iOS 11及以上”，你却拿iOS 14的新API作答，方向就歪了。答题时先确认系统版本、线程、内存环境，再给结论。

5.2 高频问题排查工具速查表

这份卷子虽然不直接考工具，但如果你能在相关题目里顺带提到工具，会显得你是实战派。我整理了一张速查表：

Charts这种抓包工具，平时调试网络特别方便。有时候后端说“接口返回正常”，你拿代理一看，发现请求体多了个字段，或者证书在多环境切换时失效，问题一下就定位了。笔试里解释网络问题时顺手提一句“用Charles验证过请求链路”，比空谈理论扎实得多。

5.3 基于这套题的复习路线，我踩过坑后总结的时间表

如果你准备面试，我建议按这个节奏来：

第一周，专攻OC语言和内存管理。每天过一遍引用计数、weak原理、Block、循环引用，然后刷对应的手写题。不要背题，要把每个问题整理成“原理+场景+解法”三段式。

第二周，多线程和UI性能。多线程重点做分组并发、依赖、线程安全的代码题；UI性能重点理解自动布局、cell复用、离屏渲染。最好打开Instruments把卡顿Demo真的跑一遍。

第三周，网络和架构。把AFNetworking的源码过一遍，理解HTTPS下的安全策略；架构部分去找一篇组件化落地的工程文章，结合自己项目画出模块关系图。

第四周，冲刺模拟。用这份2018年的题目做一次全真模拟，限定时间写出答案，然后逐题对照查漏。

我当年的教训是：只读不写。看了很多Runtime源码，但一到手写题就卡壳。从第二次复习开始，我强制自己每天手写两道题，一周后手感和表达能力都明显提升。

写在最后的经验

这套2018年的笔试题我反复看了很多遍，每看一遍都有新收获。早年我自己面试也挂过很多次，后来发现一个规律：只要能把这些高频问题做一次“从概念到源码再到业务场景”的完整整理，面试时表达出来就完全不慌。别把笔试当成考试，把它当成一次自己项目的“故障排查练习”，你会发现那些底层机制其实都是你平时写代码时踩过的坑。最后再分享一个小技巧，每个考点都尝试写成一篇自己能讲10分钟的文章，用“讲得出”代替“记得住”，这会让你在技术面试里的表现发生质变。