企业官网建设流程全解析

商汤科技2018校招iOS开发工程师笔试第二场，这个标题放到今天来看依然有嚼头。一方面商汤作为AI视觉领域的头部公司，它的技术笔试题向来不水；另一方面，iOS开发岗位在校招笔试里其实有点“夹心层”的意思——既要比拼通用算法功底，又要考察客户端特有的知识体系，还要看你对AI应用场景有没有sense。我身边不少当年一起刷题的朋友，有的栽在内存管理细节上，有的挂在架构设计题上，回头复盘时都感慨：这类笔试考察的不是你会不会写UI，而是你有没有完整的客户端工程思维。

这篇文章我就以商汤这场笔试为切入点，拆一拆AI公司iOS岗位笔试题背后的考察逻辑，把核心知识点、备考策略、常见失分点一次讲透，给正在准备校招或跳槽的朋友一份可落地的参考。

1. 笔试背后的岗位定位：AI公司要什么样的iOS工程师

1.1 商汤科技与iOS岗位的特殊性

商汤科技的核心业务集中在计算机视觉和深度学习平台，很多人会下意识觉得，这种公司招iOS开发可能就是做做官网App或者内部工具。实际上完全不是这样。AI公司的客户端岗位，尤其是商汤这种算法驱动型公司，iOS工程师要承担的任务往往是把算法能力产品化——人脸检测的实时预览、AR特效的渲染管线、视频流的高性能处理、模型在端侧推理的调度，这些都落在客户端工程师肩上。

这也决定了笔试的出题方向和纯互联网公司的iOS岗有明显差异。普通电商类App可能更偏重业务架构、页面性能优化、数据缓存策略，而商汤这种AI公司会更看重你对底层原理的理解、对性能瓶颈的敏感度，以及把复杂算法工程化的能力。2018年这个时间点，Core ML刚推出不久，端侧跑模型还是新鲜事，但商汤的笔试里已经开始渗透这类思维了。

1.2 校招笔试的三层考察结构

拿我接触过的商汤校招笔试题型来看，整体可以分成三层递进结构。

第一层是语言基础与内存管理，重点考察OC的运行时特性、引用计数机制、block的坑。这一层刷掉的是基础不牢的人。第二层是UI与架构设计，Auto Layout、UIKit生命周期、MVC/MVVM的适用场景、组件化思路。这一层刷掉的是只会写页面但不理解架构的人。第三层是算法与系统设计，常规的数据结构与算法题之外，还会出现和图像处理、性能优化相关的场景题。这一层刷掉的是缺乏工程深度的人。

三层结构层层递进，你光会刷LeetCode不够，光会写OC也不够，得把两者结合起来。这也是很多科班出身但没接触过客户端开发的同学最难受的地方——算法题能AC，一碰到客户端场景题就无从下手。

2. 笔试核心考点拆解：OC语言与内存管理

2.1 引用计数与自动释放池的深入理解

2018年那会儿，Swift已经出了四年，但OC依然是大厂笔试的绝对主力。商汤这场笔试也不例外，围绕内存管理的题目占了不少分值。引用计数是OC内存管理的基石，但笔试题不会直接问你“什么是引用计数”，而是会绕几个弯。

我记得有一道典型的题目是考察weak修饰符和dealloc的执行顺序，以及__weak变量在ARC下的实现原理。很多人知道weak引用会自动置nil，但说不清背后的objc_loadWeak和objc_storeWeak的调用机制，也不知道SideTable和weak_table_t是怎么组织的。这类题考的不是记忆，而是你有没有真正读过runtime源码。

自动释放池也是高频考点，尤其在runloop循环和线程之间的关系上。题目经常会把autoreleasepool、runloop、线程保活三个概念揉在一起考。如果只是背概念，遇到这种综合题很容易懵。这里我建议备考时把runloop的源码执行流程过一遍，搞清楚kCFRunLoopEntry、kCFRunLoopBeforeWaiting、kCFRunLoopExit这几个时机和自动释放池的创建销毁对应关系，题目再怎么变都能接住。

2.2 Block的循环引用与底层结构

Block几乎是iOS笔试必考，商汤这场也不例外。但它的考察方式比较狡猾：不是直接问“block为什么会循环引用”，而是给一段嵌套代码，让你分析有没有循环引用、如果有应该怎么改。

我在实际开发中踩过一次很深的坑，是在一个图像处理工具类里用block做异步回调，回调里又持有了self去更新UI，而self又通过属性持有这个工具类实例，结果整个控制器在pop之后根本不走dealloc。后来用Instruments的Leaks模板一查，才发现是循环引用。这类经验在笔试里特别加分，因为面试官问的不只是会不会用__weak，而是有没有真正被坑过、有没有自己的排查方法论。

Block底层结构也是常考点，尤其需要说清楚block会捕获哪些变量、为什么局部变量需要__block才能修改、三种block（_NSConcreteStackBlock、_NSConcreteMallocBlock、_NSConcreteGlobalBlock）分别在什么场景下出现。这里我给一个记忆口诀：无捕获变量的是全局block，栈上创建的是栈block，栈block被copy后变成堆block。笔试如果涉及block底层，把这个链条讲清楚基本就稳了。

2.3 内存管理题目的实战表格

为了让大家看得更清楚，我把商汤这类AI公司笔试里最常见的几种内存管理考察方式整理成了一张表，方便对照复习。

这张表里的每一行，都是在实际笔试和面试里反复出现过的。我建议备考时不要只盯着概念背，而是每一条都能讲出一个自己写代码时遇到的真实场景，这样笔试的简答题和面试的追问环节都能从容应对。

3. UI与架构设计：从页面搭建到工程思维

3.1 Auto Layout的性能陷阱与优化思路

商汤笔试的UI部分不太会考你怎么拖控件，而是更倾向于考察你对UIKit机制的理解深度。Auto Layout是其中一个绕不开的考点，但我发现很多同学对它的理解停留在怎么用，对于它为什么在你视图层级复杂时会出现性能问题，基本没概念。

Auto Layout本质上是一个约束求解过程，系统需要把所有的约束转成线性方程组，然后用Cassowary算法求解。当约束数量爆炸的时候，布局计算就会成为性能瓶颈。尤其是在列表页的cell里，如果每个cell里有几十个视图并且都用了约束，滑动时就会频繁触发求解计算，掉帧就出现了。

我记得有一道题目是问“如何优化一个复杂cell的布局性能”，答案其实可以分几个维度：减少视图层级、把固定不变的部分用frame布局、动态部分才用约束、避免约束冲突导致的额外求解。这里我有一个看法：2018年那会儿很多人推崇纯代码加Masonry，但到了今天，我更推荐在性能敏感的场景直接上frame计算加缓存，把复杂布局拆成几个独立模块分别算frame。笔试时如果能讲出这种基于性能考量的技术选型逻辑，比单纯罗列API要有说服力得多。

3.2 事件传递链与响应链机制

事件传递链也是商汤这类笔试喜欢考的点。它不会直接问你“hitTest怎么用”，而是给一个复杂的嵌套视图结构，问点击某个位置时事件会怎么传递、哪个视图最终响应。

这里面有两个核心链条需要记清楚：一个是查找链，事件从UIApplication往下分发，通过hitTest:withEvent:逐级查找最合适的响应视图；另一个是响应链，找到的视图如果无法处理事件，就沿着nextResponder往上抛。这两个方向正好相反，容易搞混。

我建议用一个比喻来理解：查找链就像快递员送件，拿着包裹从小区门口开始问每个楼栋有没有收件人，一路问到具体房间；响应链则像收件人拒收后退件，从具体房间一路退回快递站。这样理解之后，不管题目怎么嵌套视图，你都能顺着链条推出来结果。

3.3 MVC、MVVM与组件化架构的取舍

商汤笔试的架构题通常比较开放，比如给一个业务场景，让你设计架构方案。这类题目看着自由，其实有明确的踩分点。重点是你要能说出不同架构之间的优劣对比，以及你选择的架构在特定场景下解决了什么问题。

我常用的答题框架是先问三个问题：业务是否复杂、团队人员水平如何、是否需要跨端复用。如果是AI类的产品，比如实时视频流处理，那View层和业务逻辑之间天然有一道屏障，因为算法能力是在独立的管理器里封装的，这时候MVP或者MVVM会比MVC更合适。如果只是工具型App，MVC的简单直接反而是优点。

组件化也是当年的大热考点，商汤笔试里出现过一道关于模块间通信的题目。我的经验是，组件化不是越彻底越好，而是要看业务是否有真正的独立模块需要并行开发。通信方案的选择上，如果追求编译期安全，就用protocol加依赖注入；如果追求灵活，可以用消息转发机制做解耦，但要接受字符串调用的不确定性。

4. 算法与数据结构：校招笔试的硬通货

4.1 算法题的难度与题量分布

商汤作为AI公司，笔试的算法题难度定在中上水平。2018年这场第二场笔试，题量不是很大，但每道题都需要想一阵子。相比纯互联网大厂那种三题定胜负的模式，商汤的算法题更注重和实际业务场景的结合。

印象里涉及到的题型有二叉树遍历的变体、链表的操作、动态规划的经典模型，以及字符串处理。难度上大概是LeetCode的Medium偏上，偶尔会有一道Hard级别的压轴题。我给备考者的建议是，不要押题，而是把每种数据结构和它的典型应用场景吃透。比如二叉树，你不仅要会前中后序遍历和层序遍历，还要理解递归和迭代两种写法的差异，因为很多变体题都是从遍历框架延伸出来的。

4.2 一道典型算法题的多角度拆解

我举一个当年备考时反复练过的例子：给定一个字符串，找出最长的不含重复字符的子串长度。这题LC上是Medium，但商汤笔试里经常以变形的方式出现，比如加一个条件“只包含小写字母”或者“允许最多K个重复字符”。

基础解法是滑动窗口加哈希表，左右指针维护窗口边界，哈希表记录每个字符最后出现的位置。对于标准版本，代码不长，但有几个细节容易错。我给出一个模板：

def lengthOfLongestSubstring(s: str) -> int: char_index = {} left = 0 max_len = 0 for right, ch in enumerate(s): if ch in char_index and char_index[ch] >= left: left = char_index[ch] + 1 char_index[ch] = right max_len = max(max_len, right - left + 1) return max_len

这里的关键点，一个是更新left时要判断上一次出现位置是否在当前窗口内，另一个是char_index要在更新left之后才赋值，否则会覆盖掉旧位置导致判定错误。这种细节笔试时特别容易踩坑，我建议刷题时把这类代码多默写几遍，形成肌肉记忆。

如果题目升级为“允许最多K个重复字符”，思路就要从滑动窗口升级为带状态控制的滑动窗口，维护一个计数数组，当窗口内重复次数超限时收缩左边界。这类变体考察的就是能不能举一反三，把基础模板在限定条件下灵活调整。

4.3 图像处理相关算法的基础储备

商汤笔试里有一个特色题型，其他互联网公司很少见，就是和图像处理结合的算法题。不一定会直接让你写图像处理的代码，但可能会考察一些基础概念，比如卷积操作的时间复杂度、图像缩放算法的选择、颜色空间转换的原理。

我觉得备考时不需要深入学OpenCV，但至少要搞明白：一张W乘H的图像，用K乘K的卷积核做卷积，时间复杂度是多少；最邻近插值和双线性插值的区别是什么；RGB转灰度图常用公式为什么是那个权重。这些知识在客户端开发里也很有用，商汤的很多业务都是实时视频流处理，这些概念能直接体现你和AI公司业务场景的匹配度。

5. 系统设计题：从客户端视角解决AI落地问题

5.1 实时视频流处理的设计思路

商汤笔试的系统设计题我认为是整张卷子里最见功力的部分。它不是让你设计一个电商秒杀系统，而是给你一个移动端的AI应用场景，让你设计技术方案。

举个例子，当时有一道类似的题：设计一个实时人脸检测的iOS应用，要求耗电低、帧率高、不阻塞主线程。这个题看起来开放，但考察点非常集中。首先是采集层，你要说服面试官用AVCaptureSession的预设和格式输出，说明为什么选YUV而不是RGB，因为YUV在后续算法处理中更友好。然后是处理层，算法检测的耗时如果超过帧间隔，你要考虑丢帧策略还是降分辨率策略。最后是展示层，要用Core Animation的专用图层直接渲染CMSampleBuffer，避免多余的CPU和GPU拷贝。

我当时的回答思路是分模块逐个击破，从采集到处理到渲染画出数据流，然后针对每个环节的瓶颈给出优化方案。这套思路后来我用到了实际项目中，做了一个基于Vision框架的实时人脸关键点检测Demo，踩了不少坑才跑顺。笔试和实际开发的差别在于，你可以把方案说得理想化，但一定要有取舍逻辑，面试官最反感的是“这里用高端的XXX技术就行”这种没有权衡过程的回答。

5.2 端侧模型推理与性能的平衡

AI公司笔试题还有一个避不开的考点：端侧模型推理。2018年Core ML刚起步，很多模型还在用OpenCV加自研引擎跑，但笔试题已经开始考察你对端侧推理的理解了。

核心矛盾很简单：模型越准确，计算量越大，手机扛不住；模型越小，速度越快，但准确率下降。这个权衡怎么取舍，就是出题人想看到的思考过程。我建议答题时从这几个维度展开：模型的量化方式、推理框架的选择、CPU/GPU的调度策略、内存占用与包体积的平衡。

针对端侧推理还有一个容易被忽略的点，就是热启动和冷启动的差异。模型加载到内存里是一次性的开销，但初始化时间往往很长，如果每次进页面都重新加载模型，体验会很差。设计上通常会在App启动后的空闲时段预加载模型，或者在首次使用前做预热。这个细节如果在笔试时主动提出来，面试官会对你的工程经验另有加分。

5.3 网络层与弱网环境下的AI能力保障

AI能力上到移动端，网络是绕不过去的坎。商汤笔试里出现过一道网络相关的题目，大意是设计一个上传图片到云端识别的流程，要求保证弱网环境下的成功率。

这不只是一道iOS网络题，而是一道系统设计题。答题时要考虑连接层的网络库选型、超时重试机制、图片上传的压缩策略、断点续传的实现方案。我见过不少同学只知道用AFNetworking，但说不出AFNetworking内部是怎么管理请求任务的，也说不出遇到连接超时时应该怎么设置重试策略才能避免雪崩。

这里我提供一个实用的思路：请求从文本到图片，要分级设计。文本请求超时时间短一些，图片上传超时时间拉长，并且要支持队列和优先级。弱网环境下，单纯重试会产生大量并发请求导致带宽全被占用、彻底连不上服务器，所以要引入退避策略。第一次失败等1秒再重试，第二次失败等2秒，第三次等4秒，指数退避加抖动，这样既不暴击服务器，又能保证用户体验。这类经验在笔试和面试里都很加分，因为它是你真实调过的接口、踩过的坑才能沉淀出来的。

6. 备考刷题与实战经验：从笔试题到Offer的最后一公里

6.1 笔试的答题节奏与时间分配策略

校招笔试的时间一向紧张，商汤这场也不例外。我当年参加过的笔试经验是，选择题和简答题要控制在总时长的四分之一以内，把大头时间留给算法题和系统设计题。因为算法题不是会不会的问题，而是能不能在高压环境下快速写出边界情况都考虑到的代码的问题。

策略上我推荐三步走：第一，拿到卷子先把所有题目扫一遍，标注难度和分值，先做自己最有把握的题目，把保底分拿到；第二，再做中等难度的题，这类题通常是笔试的分水岭；第三，最后攻克难题，就算做不出来，也要把思路和伪代码写上去，很多笔试是人工阅卷，看到有思考痕迹的答案会给过程分。

还有一个很多人忽略的点：笔试环境的熟悉程度。商汤用的在线笔试系统，有些是不支持本地编译调式的，代码写错一个括号可能整题废掉。我建议备考阶段就习惯在网页里写代码，不开IDE提示，纯手敲，锻炼一次性写对的准确度。

6.2 高频失分点与独家避坑技巧

这几年我帮不少学弟学妹复盘过笔试题，发现失分点有很强的规律性，在这里整理一份避坑清单。

第一，内存管理题目里，__weak变量在ARC下使用时如果没判空就访问，容易出现野指针崩溃。笔试写代码时可能不影响编译，但面试官一眼就能看出来你是否有防御式编程的习惯。第二，滑动窗口类的算法题，边界条件最容易错，尤其是更新左指针和记录最新索引的顺序问题，我前面的代码模板里专门标注了这个细节。第三，系统设计题里，只给方案不给理由，是最容易丢分的地方，每个技术选型都要有对比和权衡过程。

另外我特别想强调一个经验：笔试对概念题的回答，不要只写结论，把推导过程也写上去。比如考自动释放池，你回答“自动释放池在runloop休眠时释放对象”，这个没错，但只能拿一半分。你要是能把“RunLoop在BeforeWaiting时调用autoreleasePoolPop和autoreleasePoolPush，object啊object”的源码流程写出来，就能拉开差距。

6.3 从笔试到面试的延伸准备

笔试只是第一关，商汤这类公司通常会在面试环节就你笔试的答案深挖两三轮。所以交卷之后不是结束，而是新一轮准备的开始。

我建议笔试结束后第一时间把每道题重新复盘一遍，特别是当时没做出来或者犹豫过的题，把答案整理成自己的理解版本。面试时大概率会问你“这道题当时为什么这么答”“现在有没有新的想法”，如果你能现场给出比笔试时更完整的方案，那会是很大的加分项。

另外，商汤的面试还会围绕iOS和AI的结合展开很多开放性讨论。建议提前关注端侧推理框架、Metal性能优化、Vision框架的使用这类话题，不需要深入源码级别，但要能说出基本的技术选型依据和实际落地过程中的体验。我记得自己面试时被问到“如果让你在iPhone上实现实时美颜，你的技术路线是什么”，这个问题既考iOS知识又考AI工程思维，核心就是看你有没有能力把两套知识体系打通。