2023年好未来秋招移动端开发岗第四批笔试的邮件躺在我邮箱里时说实话有点意外。好未来家主要做教育产品学而思网校、学而思培优、题拍拍这些App都是他们自家的移动端产品技术沉淀和流量体量都不小所以笔试的含金量在教培行业里算比较高的。我投的是移动端开发工程师简历上写的主要是Android方向但好未来的笔试向来不局限单一平台iOS、跨端、前端基础都会涉及。这篇文章把我参加的那场第四批笔试的完整经历、题型分布、考后复盘都整理出来题目是我凭记忆还原的和原卷肯定有字面出入但考察的知识点和难度能保证真实可参考。开头先说结论这套笔试题的难度属于中等偏上题量大时间紧想靠临时刷题混过去基本不可能但如果你在项目里真正折腾过几个App、踩过生产环境的坑大部分题是能答出东西来的。1. 第四批笔试的整体盘子题量、时间、平台和监考方式1.1 第四批是什么概念投递时间线是怎么走的好未来的秋招一般从7月底开放内推8月正式网申然后按批次安排笔试。前两批通常是全国统考量大、岗位多、HC充足第三批开始进入补录状态第四批基本就是秋招的尾巴到10月下旬甚至11月初还在发笔试的情况都有。我当时是在11月收到的第四批笔试通知说明前几批招聘还没完全收满或者是岗位新增了需求。第四批笔试有个特点候选人池子比前几批小得多这时候筛选标准不会有明显放水甚至因为HC少了题目的区分度反而要更高。从我实际考下来的感受看好未来的笔试题目并不是那种故意刁难人的怪题而是把计算机基础、移动端专项、算法、场景设计四块内容都覆盖到每一块都在考察你平时做项目时的真实积累。所以如果你也收到的是后续批次的笔试心态上别摆烂认真对待机会反而是实实在在的。1.2 笔试平台、时长和纪律要求好未来用的笔试平台是牛客网电脑端答题手机端小程序监控双机位模式下手机要放在侧后方约45度角位置能拍到答题人和屏幕。考试总时长是两小时题量约为35~40道其中选择题占大头算法编程题4道场景设计/简答题2道左右。整个系统是题组顺序作答还是自由切换我记得牛客平台一般允许跨题题组切换但选择题提交后不能回看修改所以做的时候要果断别在一道题上纠结太久。有一点值得提醒考试过程中系统有切屏检测超过一定次数的切屏会被记录为作弊。我考试时有一道算法题想临时搜一下API用法切出去一次就被弹了警告后面全程老老实实。这个细节对结果影响很大宁可对不熟悉的API靠猜也不要因为切屏被标记成异常而取消成绩。2. 选择题里的计算机基础题网络、操作系统、数据库一个都没落下2.1 TCP/UDP、HTTP/HTTPS、HTTP2.0这些网络题是真高频移动端开发每天都会和网络打交道所以网络协议在笔试选择题里占比很高。我这场遇到的网络相关题目大概占了选择题的20%左右其中有几道值得单独拿出来说第一道是TCP和UDP的区别选项里包含了“TCP支持广播UDP支持单播”“TCP提供可靠传输UDP提供尽力而为的传输”“TCP头部比UDP头部更长”“TCP面向字节流UDP面向报文”等说法。正确答案是后三个。TCP的可靠传输依赖于确认、重传、序号机制而UDP的头部只有8字节没有这些复杂机制所以更轻量。这道题看起来简单但很多人在“TCP面向字节流还是面向报文”这个点上容易混淆。TCP确实是把应用层数据当作无结构的字节流来传输而每个TCP报文段传输的是这个字节流的一个片段UDP则完整保留应用层报文的边界。深入网络库实现比如OkHttp底层用的就是TCP而视频通话、实时语音这种允许一定丢包的场景才用UDP。第二道是HTTPS的握手过程问的是“在TLS握手过程中客户端和服务端哪一个步骤先完成密钥交换”。这块很多人会背得乱七八糟。其实HTTPS握手可以简单拆成这么几件事先TCP三次握手建立连接然后是除第一个ClientHello和最后一个Finished之外交换证书、协商加密套件、通过非对称加密交换预主密钥最后由双方各自生成会话密钥并用对称加密通信。笔试里问到“HTTPS握手为什么比HTTP慢”时要答出两点多了TLS握手的一个RTT以及证书验证和密钥协商带来的计算开销。这也是移动端面试里“如何优化首屏加载速度”的常见切入点后面场景题我也会讲。第三道是HTTP/1.1和HTTP/2.0的对比。HTTP/2.0增加了多路复用、头部压缩、服务端推送。关于多路复用题目会问“HTTP/2.0在一个TCP连接上能否同时传输多个请求和响应”答案是可以。通过流ID区分不同的请求响应避免了HTTP/1.1队头阻塞的问题。不过HTTP/2.0的传输层仍然依赖TCP所以TCP级别的队头阻塞问题依然存在只是被缓解了没有根除。这个细节在选择题里常作为高区分度选项出现。2.2 进程、线程、死锁与内存管理操作系统相关题目也是选择题里的常客。好未来的笔试里遇到了几道和移动端结合比较紧密的题一道是进程和线程的对比问的是“以下哪种说法正确”。选项包括进程是资源分配的基本单位、线程是CPU调度的基本单位、同一进程内的线程共享地址空间、不同进程间的数据可以直接互相访问。前三个是对的第四个是错的。对应到Android场景里App启动时系统会fork出一个新进程该进程天生自带一个主线程其他组件比如Service、BroadcastReceiver都在主线程的上下文中运行而线程则可以通过new Thread创建。做过Android开发的人应该对这些概念不陌生。另一道是死锁的四个必要条件互斥、占有并等待、不可剥夺、循环等待。题目问“破坏死锁条件的方法中哪种做法对应资源一次性分配”答案对应的是破坏“占有并等待”。这个知识点在Android里其实不太会直接用到但如果你写过并发下载或者多线程上传模块应该能理解线程A持有了文件锁再去申请网络连接资源很容易出问题。最稳的做法是资源统一分配或统一释放这也是很多下载库内部线程池的设计思路。还碰到一道内存管理题关于虚拟内存和页面置换。问的是LRU算法的核心思想。LRULeast Recently Used最近最少使用在Android里不只是面试题概念图片加载框架Glide的内存缓存、LruCache的实现原理就是这个。我当时看到这道题几乎直接选了答案因为LruCache源码我研究过好几遍。它的核心就是在达到容量上限时淘汰最久没有被访问的那一项而LruCache内部借助LinkedHashMap来实现访问顺序的记录。笔试里能碰到自己项目里用过的算法确实能加分。2.3 数据库和Linux命令选择题里也不少数据库在移动端开发岗的笔试里不会考得很深主要以索引、事务、SQL基础为主。我遇到了一道关于索引失效的题“在什么情况下即使字段上建了索引查询也可能全表扫描”选项里有对索引字段进行函数操作、使用左模糊like、隐式类型转换、使用OR连接非索引列。结果四个都是。这道题表面在考数据库实际在考你有没有踩过数据量大了之后接口变慢的坑。移动端接口的性能瓶颈很多时候不在客户端代码而在服务端SQL写得不好尤其是联表查询和索引失效导致的慢SQL。所以笔试考这个不奇怪做客户端的人也要懂一点数据库。Linux命令考了一道文件权限的题给的是一串权限字符串“rwxr-xr--”问属主、属组、其他用户的权限分别是什么。答案是属主可读可写可执行属组可读可执行其他用户只可读。这种题纯属送分但你得清楚数字表示法rwx7r-x5r--4。Android的adb shell也经常用到Linux权限概念比如查看/data目录会提示permission denied就是这个权限模型在起作用。3. 移动端专项选择题Android、iOS、跨端好未来考得真的细3.1 Android机制题Handler、Activity启动模式、内存泄漏移动端专项的选择题是重头戏占据了整个笔试题量的大约30%。Android方向考了好几道经典题我按记忆把能还原的都写出来。第一道是Handler消息机制。题目给了一段代码在主线程创建一个Handler重写handleMessage方法然后在子线程调用sendMessage问最终handleMessage运行在哪个线程。答案是主线程。这背后就是Looper和MessageQueue的配合主线程通过Looper.loop()不断从MessageQueue中取消息Handler在创建时就绑定了主线程的Looper所以sendMessage只是把Message放进主线程的消息队列真正执行handleMessage的是主线程。这道题在Android面试里几乎是必考题但笔试选择题里把它藏在消息机制的整体流程里容易让人看漏。如果你能把Handler的源码流程画出来这题就白送了。第二道是Activity启动模式。题目描述了一个场景MainActivity启动SecondActivitySecondActivity的启动模式是singleTask然后问按返回键后栈内Activity如何变化。singleTask的核心逻辑是如果栈中已经存在该Activity的实例就会把该实例上面的所有Activity清出栈并回调该实例的onNewIntent。所以返回时你会直接回到MainActivity而不是再经历SecondActivity的重建。这个知识点在实际开发中最常出现在App通知栏跳转、扫码落地页这种场景因为要避免重复创建同一个页面。第三道是关于内存泄漏的判断。题目给出了四种代码静态变量持有Activity引用、Handler持有Activity、匿名内部类持有外部类引用、Bitmap用完未recycle。问哪些会造成内存泄漏。前三种都会第四种在Android 8.0之后Bitmap的内存分配已经放到了Java堆并且有GC自动回收手动调用recycle反而是不推荐的。这里考的是一个相对新的Android版本变化很多人还在用旧的知识点答题容易选错。越到后面的批次笔试题有时会越贴近新版系统行为建议复习时多看一眼Android官方文档的更新不要只看几年前的面试题汇总。3.2 iOS基础题也来了ARC、runloop、响应链虽然不是iOS岗位专招但好未来这套卷子里iOS基础题也有一定比例。毕竟移动端开发岗会统一笔试Android方向和iOS方向共用一张卷子或者相近的两套卷子都有可能。我遇到的iOS题主要有这些一道关于ARC自动引用计数的题问强引用循环会导致什么。答案是对象之间循环持有导致内存无法释放。这个对应到iOS开发就是Block块里使用self、delegate属性的循环引用等问题。做Android的人看到这题也不用慌理解引用计数和循环引用的概念是通用的Java的GC里也有类似概念。还有一道关于runloop的题问RunLoop的主要作用是什么。选项包括保持线程存活、处理事件源、在特定时机执行回调等。答案是所有这些。RunLoop在iOS里非常重要因为主线程的RunLoop保证App一直在跑而不是执行完就退出在Android里虽然叫法不同但主线程的消息循环本质是一样的所以只要理解“线程里有一个事件循环机制”这个核心iOS的题也能答出来。3.3 跨端与前端框架题vue、uni-app这类移动端框架该怎么选这个部分我觉得是好未来笔试比较有意思的地方。教育类App的业务形态决定了一个App往往需要同时覆盖多个平台iOS、Android、甚至小程序的开发成本和维护成本都很高所以跨端框架是非常实际的选型问题。题目里考了一组关于移动端跨端方案的题目问我印象最深的一道是针对“移动端vue开发框架”的选型。它给了React Native、Flutter、uni-app、Taro四个选项问哪个是基于vue语法且可以一套代码同时编译到App和小程序的框架。答案是uni-app和Taro都可以。那道题还带了一个追问问这些框架和原生开发相比的优劣选项里包含“跨端代码复用率高”“包体积和性能通常不如原生”“可以访问系统底层全部API”“热更新能力受平台限制”等。前两个和第四个对第三个不对。原因在于RN和uni-app等跨端框架提供的原生能力是封装好的基础模块对于系统底层的API支持往往不如原生直接Flutter虽然渲染性能很好但访问底层硬件能力也需要通过channel与原生通信不是说所有API都能直接调。这一点在答案之外其实值得展开说跨端框架的核心取舍永远在开发效率与性能表现之间。如果你是一个正在准备移动端秋招的读者建议把uni-app和Flutter的对比记清楚因为它们几乎是考题常客。uni-app的优势是上手门槛低、生态里有大量vue组件、开发速度快劣势是性能上不如原生尤其是复杂动画和游戏型首屏体验。Flutter的优势是渲染性能好一套Dart代码可以做到像素级一致的跨端UI劣势是Dart语言的学习成本以及原生插件需要自己写更多的桥接代码。我在笔试时选择了uni-app相关选项因为它的vue语法和中文文档生态更贴近我做过的小程序项目这题也帮我拿到了准确分。4. 算法与数据结构编程题四道题全部思路复盘4.1 第一题字符串处理题注意边界条件就一定得分第一道算法题相对简单给了一个字符串压缩的需求如果字符串如aabcccccaaa压缩后变成a2b1c5a3如果压缩后的字符串长度不小于原字符串则返回原字符串。这个题的思路非常直接遍历字符串用计数器统计连续相同字符的次数把字符和次数拼接到结果字符串中。复杂度是O(n)空间是O(n)。这种题看起来简单但有几个边界条件容易出错字符串为空的情况、字符串只有一个字符的情况、字符串最后一段连续字符在循环结束后还没处理的情况。我当时的处理方式是在循环结束后再补一次拼接操作这样能正确处理以连续相同字符结尾的字符串。另外注意题目要求如果压缩后长度不小于原字符串返回原字符串这个条件在写代码时特别容易忘记而它恰恰是LRU这种题外最典型的“陷阱式要求”。好在我在牛客网刷题的时候见过几道类似的算是送分题大概花了8分钟解决。4.2 第二题动态规划股票买卖问题的变体第二道算法题是一道典型的动态规划。题目大意是给定一个数组prices其中prices[i]表示某支股票第i天的价格你先可以完成任意次数的交易但必须卖出后才能再买入问最大利润。这道题是“最佳买卖股票时机含冷冻期”的简化版也可以用贪心做因为能交易任意次每次上涨都可以获取利润所以贪心解法是只要今天的价格比昨天高就累加差价。代码大概长这样def maxProfit(prices): if not prices: return 0 profit 0 for i in range(1, len(prices)): if prices[i] prices[i-1]: profit prices[i] - prices[i-1] return profit这道题如果只写对贪心解法其实已经能拿大部分分数。但如果你能在这个基础上用动态规划写一个状态转移版本可能更有区分度。动态规划的核心思路是维护每天持有股票和持有现金两种状态分别计算每天的状态值递推公式为持有现金的状态等于max(昨天现金昨天持有今天卖出)持有股票的状态等于max(昨天持有昨天现金-今天买入)。笔试时时间有限我直接用的贪心因为已经把原理想清楚了写得快且不容易出错。4.3 第三题二叉树层序遍历树的题要记牢BFS模板第三道算法题是二叉树层序遍历的变体。输入的是一棵二叉树的根节点要求按层输出每层节点并且是从底层向上输出。也就是自底向上的层序遍历。核心思路还是BFS但最后要把结果反转过来。def levelOrderBottom(root): if not root: return [] res [] from collections import deque queue deque([root]) while queue: level [] for _ in range(len(queue)): node queue.popleft() level.append(node.val) if node.left: queue.append(node.left) if node.right: queue.append(node.right) res.append(level) return res[::-1]这道题有个细节在for循环中len(queue)必须在循环前固定下来否则随着popleft操作queue的长度在变化循环次数就不对了。这个bug我见过的同学踩过很多次。解决方案是用level_size len(queue)先在循环外部保存或者像上面代码里直接借助range(len(queue))的特性因为range的参数在第一次求值时就已经确定。这题的运气成分不大BFS模板背熟就能过。4.4 第四题LRU缓存设计考工程实现能力第四道算法题不是纯算法而是数据结构设计实现一个LRULeast Recently Used缓存支持get和put操作容量有限当缓存满时淘汰最久未使用的key。这题在移动端开发岗笔试里出现频率极高因为LruCache本身就是Android官方提供的类笔试考它可以说就是想看看你是否真的理解并手写过底层实现。用Python实现的话最经典的做法是借助OrderedDictfrom collections import OrderedDict class LRUCache: def __init__(self, capacity: int): self.capacity capacity self.cache OrderedDict() def get(self, key: int) - int: if key not in self.cache: return -1 self.cache.move_to_end(key) return self.cache[key] def put(self, key: int, value: int) - None: if key in self.cache: self.cache.move_to_end(key) self.cache[key] value if len(self.cache) self.capacity: self.cache.popitem(lastFalse)如果笔试环境允许使用语言自带的OrderedDict这题几分钟就能写出来。如果要求手写底层实现就需要用HashMap加双向链表来模拟访问顺序的维护。我当时选择的是OrderedDict因为时间紧能拿满分的方案就是好方案。但面试环节如果被追问一定要能说出双向链表HashMap的完整设计思路不然笔试得分有帮助、面试就露馅了。这里也建议看这道题的同学回去自己手写一遍双向链表版本这和Android LruCache的源码逻辑是一致的。5. 场景设计与开放题考察的不是答案而是工程判断力5.1 直播课堂App首帧卡顿你会怎么优化场景开放题里有一道我印象很深的题目现有学而思网校App的直播课堂页面用户进入直播间的首帧渲染时间过长要求分析可能的原因并给出优化方案。这题不是简答题里唯一的题但我认为它最能区分有没有真实项目经验的人。我的答题思路从数据链路的角度展开。首帧渲染时间从用户点击进入直播间的行为开始算到直播画面绘制到屏幕上为止可以拆成路由跳转耗时、页面布局构建耗时、播放器初始化耗时、第一帧视频数据下载与解码耗时。每段都可以有对应的优化策略。路由跳转方面可以预创建直播页面的Fragment用容器复用布局构建方面减少嵌套层级把复杂的布局用AsyncLayoutInflater或者Compose来做异步化播放器初始化方面使用播放器预加载池在用户还在列表页时就提前初始化一个待用的播放器实例数据下载方面首帧数据使用更快的低码率流或边缘节点缓存优先到达客户端后续再无缝切换高码率。这整套方案其实是我在某次性能优化项目里亲手做过的方案迁移答题时直接映射了过去。提示看题别慌把题干里的现象拆开从端到端的每个环节找瓶颈这种回答方式比只写一句“用缓存”要扎实得多。面试官看的不是你能背多少优化名词而是你能不能把链路讲清楚。5.2 消息推送到达率提升方案这题和业务强相关还有一道开放题涉及消息推送。教育类App的核心业务是上课提醒、课程营销通知所以推送到达率直接关系业务指标。题目问的是如果发现App的推送到达率下降你会从哪些维度去排查和解决这题对Android同学来说主要考厂商通道理解。Android的推送到达率受制于系统限制尤其是国产ROM的省电策略所以常规的解决手段包括优先接入厂商推送通道比如小米推送、华为推送、OPPO推送、vivo推送在App进程存活时用长连接通道下发消息在混合方案中按设备和产品策略选择通道。排查维度方面要先看分发链路服务端是否把消息分发给了厂商通道、厂商通道token是否有效、用户是否关闭了通知权限、App进程被杀后是否还能收到离线消息。每一个环节都可能丢消息所以这题的回答核心是“链路拆解分环节验证”。iOS方向答这题会简单一些因为苹果的APNs通道稳定可靠推送到达率主要是证书配置、环境切换导致的失败。这个问题我认为好未来出得非常贴近业务因为学而思网校每天要对大量用户发上课提醒推送是刚需中的刚需。5.3 项目深挖题你的项目里最复杂的点是什么最后一道开放题是类似半结构化面试的选一个你做过的项目讲一下你理解中最复杂的点以及你是怎么解决的。这道题没有标准答案主要看你的表达逻辑和技术深度。我的回答选了一个我做过的列表页流畅度优化项目从现象滑动掉帧出发用Profile工具定位问题onBindViewHolder里做了图片加载和JSON解析到优化方案预解析缓存、异步加载占位、DiffUtil精准更新最后给出优化结果掉帧率下降了一个数量级。这种题我的建议是不要吹自己没有做过的东西。因为你永远不知道面试官后面会不会追问细节。与其编一个高并发架构不如讲一个自己真正解决过的、规模小但有完整链条的性能问题。诚实、具体、有数据才是最好的回答方式。6. 考后复盘时间分配、准备动作、经验教训6.1 做题顺序和时间分配的建议整场笔试总时长两小时我的实际分配大概是选择题45分钟算法题55分钟场景题15分钟剩余时间检查和补漏。这个分配看起来算法题占比很高因为算法题的四道题大题分值是选择题的好几倍一定要留够时间。如果你算法基础比较弱建议先快速做完送分的选择题然后优先做算法题里最简单的那道把自己会做的都拿稳再来拼难题。选择题要注意牛客平台“提交之后不可回看”的规则所以每道选择题都必须在当前页面做出判断不要期望后面还有修改机会。遇到拿不准的选择题我会先根据常识排除两个明显错的再从剩下两个里选一个更合理的然后立刻做下一题绝不在单道选择题上耗超过2分钟。这套策略帮我省下了大量时间也保证了后面算法题有充足编码时间。6.2 我复盘下来考前最值得做的三类准备第一类是背熟高频考点。移动端笔试的高频考点非常固定Handler机制、Activity启动模式、进程与线程、HTTPS握手流程、TCP和UDP、跨端框架选型。这些知识点你要做到看到题就能反应出来不要在大脑里现场推导。尤其是Handler和消息机制这种一定要把源码流程吃透如果选择题考变体你还是能做对。第二类是算法要刷到“套路化”的程度。笔试里的算法题很少考清奇思路基本都是经典题型的变体。LRU缓存、股票买卖、二叉树遍历、字符串处理、动态规划里的背包问题和爬楼梯等都是在牛客、LeetCode上反复出现的类型。你把高频题型练到位笔试时看到题目就大概能判断出它属于哪个类型用什么模板去套。第三类是准备一个真实可讲的项目。场景题和开放题说不准但一定会考。你不需要准备十个项目但需要把一个项目从背景、技术方案、踩坑、优化结果这四层讲得非常清楚。这个项目不用高大上哪怕只是一个课程表App、一个校园助手只要有完整的逻辑链条和性能数据就能在开放题里发挥巨大作用。6.3 笔试之后的流程节奏笔试结束大约一周内会收到后续通知好未来的流程一般是笔试合格后进入初试然后复试和HR面。笔试成绩会保留到当批次招聘结束。如果你前面有面试已经通过了但卡在HC问题第四批笔试是一个能重新证明自己的机会我身边的例子是有人第二批发过笔试但第三批面试挂掉后第四批笔试又重新走的完整流程。这个在招聘末尾阶段并不罕见所以第四批笔试不等于陪跑反而是再拼一次的机会。我自己的经验是笔试后第二天就把能回忆的题目整理到了笔记里把不确定的知识点都查了一遍。这个动作让我在后来的面试中直接受益——有好几次面试官问的问题恰恰就是笔试里我发现薄弱后补学过的内容。所以建议大家不管笔试成绩如何考完都抽出一小时做一次复盘这对后续帮助是实打实的。