2023年秋招的移动端岗位笔试我踩过的坑和复盘都在这里了。先说下背景我是2023届毕业生主攻Android方向也补了一些iOS和跨端知识。OPPO秋招的移动端岗笔试是我秋招季里印象最深的一场不是因为题最难而是因为它覆盖面很广、出题非常贴近实际开发尤其是对“移动端性能优化”和“技术框架理解”的考察明显不是靠刷LeetCode就能应付的。这篇文章把整场笔试从头到尾复盘一遍包括题型分布、我当时的答题思路、考完之后的查漏补缺以及一些踩坑经验希望能给后面准备OPPO或其他大厂移动端岗位笔试的同学一些参考。1. 笔试前的准备与岗位认知很多人拿到笔试通知的第一反应是开始刷题这没错但如果你连这个岗位到底要什么样的人都不知道刷题方向很容易跑偏。我在收到OPPO移动端岗笔试通知后先做了三件事扒岗位JD、看面经、梳理自己的知识树。1.1 OPPO移动端岗笔试到底考什么先说结论OPPO的移动端笔试不是纯粹的数据结构和算法考试它对“工程落地能力”的考察占比很高。整场笔试大概2小时题型分为客观题、简答题和编程题三部分。客观题里除了常规的计算机基础还有大量跟移动端相关的场景题比如内存抖动怎么排查、卡顿掉帧怎么分析、启动速度怎么优化这类的。这就意味着你要是只刷算法题而忽略了移动端本身的八股和实战经验客观题会吃大亏。我当时在牛客网上翻了不少往年的笔经发现OPPO出题有一个明显倾向它喜欢把“线上问题”搬到试卷里让你根据实际场景给出排查方案和优化思路。比如有个印象很深的题目给了你一段内存泄漏的代码让你找出泄漏点并说明怎么用工具定位这完全就是在模拟真实开发中遇到问题的过程。1.2 我的备考资料与复习路线我的备考周期大概两周资料主要是这几类计算机基础数据结构、操作系统、网络用王道考研系列复习重点放在链表、树、哈希表、TCP/UDP、进程线程这些高频考点上。移动端专项Android性能优化、Handler机制、事件分发、自定义View、Jetpack常用组件这些是Android方向的核心。刷题平台LeetCode Hot 100 剑指Offer重点是字符串处理、链表、二叉树、动态规划这几类。面经整理牛客网、掘金上看OPPO往年的移动端笔经面经把高频考点整理成笔记。这里想多说一句复习一定要有侧重。我当时因为时间紧把大部分精力放在了Android性能优化和常见机制上事实证明这个决策是对的。笔试里考到的客观题大半都跟这两个方向相关。1.3 考前调试环境准备OPPO用的是牛客网的在线笔试系统支持多种语言Android/iOS开发一般选Java或者C写的比较多我用的是Java。考前一定要做两件事一是把牛客网的在线编程环境提前熟悉一下看看代码补全、编译报错这些功能好不好用二是测试摄像头和麦克风OPPO的笔试要求开启摄像头监控这个环节出了问题会很麻烦。另外强烈建议把本地开发环境也准备好。我当时用的是IDEA额外装了Java的JDK 11。虽然牛客网是在线编译但本地有个环境可以快速验证一些不确定的API用法比在在线编辑器里干等编译结果要快得多。笔试不是开卷考试该背的八股还是要背但遇到记不准的API本地快速验证一下能节省大量时间。2. 题型全拆解从选择题到编程题进到笔试页面那一刻先把整个试卷从头到尾扫一遍看清楚每道题的分值再决定做题顺序。OPPO的笔试不会把题目分成多个部分让你分别提交而是一整份试卷客观题和编程题混在一起。我当时是先做编程题回头再做的客观题这个策略后面会详细说。2.1 客观题计算机基础与移动端专项客观题大概有20道左右分为单选题和多选题。考察范围包括数据结构、操作系统、网络协议以及移动端特有的机制。我回忆几道比较典型的题第一类是Java基础考的是HashMap在JDK 1.8中的实现原理包括数据结构是什么数组链表红黑树、什么时候会触发红黑树化、扩容的时机和方式。这类题只要认真准备过Java集合源码基本十拿九稳。第二类是操作系统考的是死锁产生的四个必要条件互斥、占有且等待、不可剥夺、循环等待以及如何打破这些条件来预防死锁。这个也是经典中的经典属于送分题。第三类是网络考的是TCP三次握手和四次挥手的状态转换具体考了TIME_WAIT状态出现在哪一端、持续多久、为什么要等待2MSL。这里有个容易记混的点TIME_WAIT是主动关闭连接的那一端进入的状态目的有两个一是确保最后一个ACK能被对方收到二是让旧连接的报文在网络中自然消失。第四类是移动端专项考的是Android的Handler机制。题目问你Looper.loop()为什么不会阻塞主线程、MessageQueue.next()在没有消息时会怎样答案是会调用nativePollOnce进入休眠等有消息时通过epoll机制唤醒。这种题对做过Android开发的人来说不算难但如果你只学过理论没真正看过源码很容易答错。第五类还是移动端专项考的是事件分发机制给你一个场景问你触摸事件会先经过Activity还是ViewGroup还是View。这个就是标准的三大分发方法dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent记住“从上往下分发、从下往上处理”就对了。多选题目要注意别漏选。我做题的时候有个习惯对不确定的选项会在草稿纸上先写一下分析然后再勾选。尤其是多选题OPPO的规则是多选、少选、错选都不得分所以宁可保守一点不确定的选项别选。我当时有一道关于JVM内存模型的题有个选项拿不准最后还是没选事后对答案发现那个选项确实是错的逃过一劫。2.2 简答题性能优化与技术选型高频考点简答题是整场笔试的分水岭也是OPPO拉开分数差距的地方。第一道简答题考的是“App启动速度优化”。这题我在准备阶段重点复习过所以答得比较顺。我的回答思路分三块启动阶段的拆分冷启动和热启动的区别。冷启动要经历创建进程、初始化Application、创建MainActivity、首帧绘制整个过程越短越好。具体优化手段Application的onCreate里不要做耗时操作能延迟初始化的就用延迟初始化SharedPreferences的加载会比较耗时可以用异步加载的方式首屏可以通过设置启动背景windowBackground来优化视觉上的等待时间减少首帧绘制前的布局层级避免过度绘制。工具使用用systrace或者Perfetto来抓取启动过程的耗时分布定位瓶颈是真正的解法。第二道简答题考的是“移动端App内存泄漏的常见原因和排查方法”。这个也是高频考点我当时的回答是常见原因静态变量持有Activity引用最常见、Handler持有Activity的引用且任务未及时移除、匿名内部类的隐式引用、单例模式持有Context、资源未关闭比如BroadcastReceiver未反注册、Cursor未关闭、IO流未关闭。排查方法用Android Studio自带的Memory Profiler观察内存占用变化用LeakCanary在Debug版本中自动检测泄漏用MAT分析heap dump文件通过Dominator Tree查看引用链。简答题的答题策略跟编程题不一样不需要写出能直接运行的代码但需要你像写技术方案一样把思路理清楚。我的经验是按照“问题是什么-为什么会出现-怎么排查-怎么解决-如何预防”这个结构来组织答案条理清晰也方便阅卷人给分。2.3 编程题数据结构和移动端场景算法编程题一共三道难度从easy到medium偏上没有特别偏门的题。但如果你的算法底子不好或者只刷过LeetCode的hot题可能还是会在某一道题上卡住。第一道题是字符串处理题目大概意思是给定一个字符串请你找出最长的不含重复字符的子串长度。这个就是LeetCode的第3题滑动窗口的经典应用。用两个指针维护一个窗口用HashMap存储窗口内字符的最大下标遍历过程中不断更新左边界和最大长度。这题我写得比较快大概5分钟就AC了。第二道题是一个有趣的场景题给定一个数组代表一个App每天的日活用户数请你找出“第一个连续三天增长”的起始下标。比如数组是[5, 3, 4, 6, 8, 2]那么下标2开始的3天是[4, 6, 8]正好是连续增长的。这题其实就是一个数组遍历的easy题但加了App日活的外壳。我当时的解法是for循环遍历检查i、i1、i2三个元素是否严格递增。第三道题是稍微有一点绕的实现一个简化版LRU缓存。这题我印象非常深因为现场写的时候差点翻车。核心是维护一个双向链表和一个HashMapget和put操作都要求O(1)时间复杂度。我在写双向链表的时候一开始忘记处理头尾节点的特殊情况导致空指针好在代码逻辑不复杂调试了一下就通过了。建议备考时把LRU的链表实现和LinkedHashMap实现都写一遍做到手写不卡壳。3. 移动端核心知识点复盘笔试过了之后我花了两天时间把整张试卷涉及的知识点系统复盘了一遍。这里面有几个点特别值得展开说因为它们不只是笔试会考面试、日常开发中同样会用到。3.1 移动端性能优化全家桶OPPO笔试对性能优化的偏爱是有原因的。ColorOS本身就是OPPO的核心竞争力而系统级优化的基础就是对App性能的理解。性能优化这个大类基本可以拆成四个维度启动速度、流畅度、内存、包体积。启动速度的优化除了前面说的Application耗时拆分还有几个进阶思路值得了解用启动器框架比如AndroidX的StartUp管理初始化任务让可以并行的任务并行执行对ContentProvider进行裁剪——这也是很多App启动慢的隐藏原因第三方SDK动不动就注册一个ContentProvider导致Application attachBaseContext阶段就要加载一堆类。如果你对启动速度优化有自己的实战案例哪怕只是把某个SDK从冷启动初始化改成按需初始化效果从数据上体现出来了笔试中写出来绝对是加分项。流畅度优化说白了就是减少卡顿掉帧。这里要理解Vsync和Choreographer的工作机制知道掉帧的本质是单帧绘制时间超过16.6ms。优化手段一般是减少布局层级用ConstraintLayout或自定义View代替多层嵌套、避免在onDraw里创建对象、用RecyclerView代替ListView并做好 ViewHolder复用、避免在主线程做耗时操作。Android官方也提供了Layout Inspector、GPU Profiler这些工具来定位问题解决卡顿的第一步永远是“找到卡在哪里”。内存优化考查频率最高的就是内存泄漏和内存抖动。泄漏问题前面已经提过这里说下内存抖动。内存抖动是短时间内大量创建和销毁对象导致频繁GC表现为掉帧、卡顿。常见场景是在循环中拼接字符串导致大量StringBuilder对象、在onDraw中创建Paint或Bitmap对象等。音频开发中有个经典场景实时音频处理中每帧都new一个byte数组导致内存疯狂抖动优化方式就是把数组定义为成员变量重复使用同一块缓冲区。包体积优化这个在笔试里出现频率相对低但偶尔会在选择题中出现。核心思路是开启资源混淆和压缩minifyEnabled、shrinkResources、用WebP代替PNG/JPG、合理使用App Bundle、删除无用依赖和重复资源。尽量控制原生库so的数量和架构兼容范围。3.2 移动端技术框架选型思路笔试简答题有时候会问“你了解哪些移动端跨平台开发框架说说它们的优缺点”。这题一方面考察你的技术视野另一方面考察你在真实项目中做技术选型的能力。主流的移动端开发框架有四个方向原生Android/iOS各自开发、React NativeFacebook开源、FlutterGoogle开源、uni-app国内用的很多基于Vue语法。这个问题不能只答“Flutter好推荐用Flutter”而要结合具体业务场景来回答。比如你的团队是Web前端出身Vue技术栈比较熟那uni-app的上手成本就低于Flutter如果你的App对UI一致性和流畅度要求极高业务又偏向中大型那Flutter的渲染性能和跨平台UI一致性就是优势如果你只是给现有App做一个简单页面那直接上React Native或者WebView都能快速交付。我当时的回答思路是先说框架对比再结合一个假设场景做技术选型最后给出结论。这种答法比较完整能体现你有“做决策”的能力而不只是“知道概念”。另外一个常考的点是“说说B站移动端技术框架”。B站在技术分享上比较开放很多资料都公开了。B站iOS端和Android端早期都是原生为主后来在跨端方面做了不少尝试包括自研的跨端方案和React Native的引入。这个问题在笔试中出现一般是考察你平时是否关注行业动态和技术社区。说实话这种题没有标准答案你只要能说出几个B站公开的技术方案再表达自己对技术选型的思考就行。3.3 移动端调试难题与线上问题定位笔试里有一类题会给你一个线上Crash日志让你定位问题。这个非常考验实战经验比如日志里看到的常见崩溃类型空指针、数组越界、类转换异常、资源找不到。我印象里有一道题给的日志是NullPointerException堆栈指向的是一个自定义Adapter的getView方法。答案思路是从堆栈中找到崩溃的具体行号然后去看这一行访问了哪个对象可能是ViewHolder里的控件没findViewById也可能是数据源里的某个字段是null。这里想顺带提一个很实用的调试技巧vConsole。它就是为移动端Web调试而生的可以在手机浏览器任意页面注入使用就相当于给移动端网页加了一个迷你版DevTools。笔试里如果考到“如何远程调试移动端页面”vConsole是一个很好的答案。具体用法非常简单只需要在HTML中引入vConsole的脚本然后初始化一下script srchttps://unpkg.com/vconsole/dist/vconsole.min.js/script script // 初始化 var vConsole new VConsole(); console.log(Hello world); /script引入之后页面上会悬浮一个VConsole的按钮点击后可以看到Console日志、Network请求、Element结构、Cookie、LocalStorage等信息。在真实项目中一般会通过配置开关动态决定是否加载vConsole只在测试环境或者需要远程排查问题时才启用。如果你连这个都知道笔试的“实操题”基本就稳了。3.4 移动端数据可视化ECharts的特殊渲染场景结合热搜词来看ECharts在移动端的应用也是一个值得准备的知识点。OPPO笔试不一定直接考这个但“移动端如何展示图表”这种场景题有概率出现特别是它们家的健康类App运动数据、睡眠图表都是核心功能。ECharts是一个功能非常强大的前端图表库在移动端使用时有几个细节需要特别注意。第一个是首屏渲染速度移动端性能本来就不如PCECharts初始化时如果图表数据量很大渲染耗时会明显增加。优化思路是只初始化首屏可见的图表等滚动到可见区域时再懒加载初始化。第二个是折线图tooltip的显示问题。有网友问“ECharts折线图在移动端怎么让它渲染完成后显示最后一个点的tooltip”这个需求在移动端其实很常见比如你要展示最近7天的运动步数趋势希望打开页面后自动在数据末端弹出tooltip提示框。实现思路有几种最简单可靠的是用dispatchAction手动触发tooltip的显示// 假设chart已经初始化并且setOption完成 myChart.setOption(option); // 渲染完成后手动触发最后一个数据点的tooltip myChart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: option.series[0].data.length - 1 });这里要注意一个坑dispatchAction需要在setOption同步渲染完成之后调用否则可能拿不到正确的坐标。如果你的数据是异步加载的一定要在setOption之后、数据完全渲染好的时机去触发比如通过setTimeout延迟100ms左右或者监听rendered事件后再执行。第三个坑是移动端图表交互的点击精度问题。ECharts默认可以显示tooltip但在触屏设备上手指的点击精度远不如鼠标很容易点不准。可以用ECharts的axisPointer 移动端的touch事件来替代hover。ECharts在移动端的触摸交互其实已经做得不错了支持缩放、滑动、双指操作等手势但前提是你必须开启dataZoom和toolbox的相应配置。这些细节在日常开发中很实用笔试如果你能写出来阅卷人会认为你是有实际项目经验的。4. 编程题实操两道典型题的完整解题思路编程题是笔试中分值占比最高、也最能拉开差距的部分。我单独拿出两道印象最深的题做一个完整的解题复盘。4.1 滑动窗口最长无重复子串这道题是笔试的第二题LeetCode第3题属于“面试必刷100题”级别的经典题。题目就不重复了直接说解题思路和代码。解法用滑动窗口核心思路是维护一个“不含重复字符的窗口”不断把右边界向右扩展同时保证窗口内没有重复字符。一旦发现重复字符就把左边界跳到重复字符上次出现的位置的后一格。class Solution { public int lengthOfLongestSubstring(String s) { if (s null || s.length() 0) { return 0; } // 用HashMap记录每个字符最近一次出现的下标 MapCharacter, Integer map new HashMap(); int maxLen 0; int left 0; for (int right 0; right s.length(); right) { char c s.charAt(right); if (map.containsKey(c)) { // 如果重复字符在当前窗口内则移动左边界 // 注意这里不能直接取map.get(c)1因为可能left已经越过了这个位置 left Math.max(left, map.get(c) 1); } map.put(c, right); maxLen Math.max(maxLen, right - left 1); } return maxLen; } }这里面的一个关键细节是 left Math.max(left, map.get(c) 1) 这行代码。如果你直接写 left map.get(c) 1会出现一个边界问题当遇到重复字符但这个字符上次出现的位置已经在当前left的左边也就是窗口外时你如果把left直接设为 map.get(c) 1左边界反而会往左移动计算结果就错了。但实际情况是重复字符在窗口之外并不会影响当前窗口的无重复性。用Math.max来限制left只能往右走就规避了这个坑。这题看起来简单但一定要自己动手写一遍。笔试环境没有LeetCode的提示没有“通过”按钮你写完编译通过后要自己想测试用例来验证。我当时写完后测了三个用例空串、全重复字符串、全不重复字符串基本覆盖了边界情况。4.2 移动端场景实现LRU缓存这道题是笔试的压轴题分值最高也是我最紧张的一道。题目要求自己实现一个LRU缓存包含get和put两个方法要求时间复杂度都是O(1)。这个就是LeetCode第146题。O(1)的时间复杂度意味着必须用HashMap来存储数据而为了维护“最近使用”的顺序还需要一个双向链表。每次get一个key就把这个节点移动到链表头部每次put一个key如果key已存在则更新value并移到头部如果不存在则插入头部如果容量满了就移除链表尾部的节点。我当时的实现用的是自建双向链表class LRUCache { class Node { int key; int value; Node prev; Node next; Node(int key, int value) { this.key key; this.value value; } } private int capacity; private MapInteger, Node map; private Node head; private Node tail; public LRUCache(int capacity) { this.capacity capacity; map new HashMap(); head new Node(-1, -1); tail new Node(-1, -1); head.next tail; tail.prev head; } public int get(int key) { if (!map.containsKey(key)) { return -1; } Node node map.get(key); moveToHead(node); return node.value; } public void put(int key, int value) { if (map.containsKey(key)) { Node node map.get(key); node.value value; moveToHead(node); } else { if (map.size() capacity) { Node removedNode removeTail(); map.remove(removedNode.key); } Node newNode new Node(key, value); map.put(key, newNode); addToHead(newNode); } } private void addToHead(Node node) { node.prev head; node.next head.next; head.next.prev node; head.next node; } private void removeNode(Node node) { node.prev.next node.next; node.next.prev node.prev; } private void moveToHead(Node node) { removeNode(node); addToHead(node); } private Node removeTail() { Node node tail.prev; removeNode(node); return node; } }这里最关键的坑有两个。第一个是哨兵节点dummy head/tail的使用很多第一次手写双向链表的人容易漏掉这一层结果在删除头节点或者尾节点时出现空指针。第二个是 removeTail 的时候一定要把节点的key保留下来因为你在map里删除的是这个key而不是value。如果Node里只存value不存key删除的时候你就没办法从map中删掉对应的KV了。我当时写完这道题又检查了一遍put的流程确认没有边界问题然后才提交。笔试结束后我回忆了一下这道题大概是45码左右的体量在15分钟内写完加调试难度其实还行。关键是你平时一定要手写过如果只看过答案没动手笔试时很容易在指针操作上卡壳。5. 笔试中的时间分配与答题策略笔试的时间是固定的但每个人的做题顺序和节奏不一样。我自己总结了一套比较稳的打法分享出来给大家参考。5.1 开考后前10分钟先做全局浏览很多人一进笔试就开始做题我觉得这是最大的浪费。正确做法是先花5-8分钟把整张试卷从头到尾看一遍看清楚有几道客观题、几道简答题、几道编程题分别占多少分。然后在草稿纸上给自己定一个时间预算。比如总分100分时间是120分钟那你给每道题的预算就是“分值比例 x 时间”客观题占比40%那最多花48分钟编程题占比40%最多花48分钟。全局浏览还有一个好处你能提前发现那些“送分题”和“坑题”。比如某道多选题你一眼就知道答案那可以放在后面快速做完某道编程题看起来要花不少时间那就优先做。我当时浏览完试卷后发现编程题有一道关于日活用户数的场景题非常简单于是决定先做编程题再做客观题。那时候心里很有底因为编程题一共三道我能拿下的就有两道半剩余的时间可以安心做客观题。5.2 时间预算表各题型的时间分配我做一个典型的时间分配表供参考题型题量预估时间答题策略单选题10-12道15分钟快速作答不纠结超过1分钟的题多选题5-8道15分钟宁少勿多不明确的选项不选简答题2-3道30分钟按“问题-原因-方案”结构化作答编程题2-3道40分钟先易后难留10分钟自查这个表不是死的但是“编程题留出充裕时间”这个原则是铁的。因为编程题编译调试很费时间你要是挤到最后20分钟才开始做心态很容易崩。5.3 遇到不会的题怎么处理笔试里遇到不会的题非常正常关键是心态要稳住。我的原则是先跳过最后再说。如果是客观题不确定的选项先在草稿纸上记下来最后如果还有时间再回头思考。如果是简答题一定要写点什么哪怕不确定答案也要按照自己理解的思路去写写错不扣分但写空肯定没分。如果是编程题不会做就先把暴力解法写出来能过多少用例算多少。笔试判分不是只有“全对”和“全错”很多题是按用例比例给分的暴力解法通常能过一部分简单用例有分总比没分好。6. 常见问题与避坑指南这是这个篇幅最想写的部分。笔试考的不只是知识点还有很多琐碎但致命的细节一个不注意就能毁掉整场考试。6.1 在线笔试环境与网络问题在线笔试最怕的是什么是考到一半断网。虽然牛客网有断线重连机制但万一你连回来的时候代码没保存损失就大了。保险做法是编程题的代码写完一段就手动复制一遍到本地记事本里网络差的情况下尤其管用。另外笔试开始前一定确认浏览器是Chrome或者Edge的最新版并把弹窗拦截关掉。有的学校网络会屏蔽在线笔试的一些资源最好提前连上考场给的网络测试链接做一次完整测试。如果是在家笔试建议用有线网络WiFi的稳定性在关键时刻真的不靠谱。6.2 摄像头监控与诚信机制OPPO笔试要求开启摄像头监考不管是手机端还是电脑端都要配合。笔试过程中系统会随机抓拍或者录屏还有AI辅助监考检测到异常行为会标记试卷。这里有个非常容易踩的坑不要中途切出浏览器去查资料。哪怕你切出去看的是完全无关的内容系统也可能会判定为作弊。笔试全程尽量保持浏览器窗口在前台就算你只是去本地IDEA验证代码也要注意切窗口的频率。我全程都开着本地IDEA但只切换过两三次基本都在安全范围内。如果你觉得自己代码不熟练一定要提前把常用的代码片段放在本地草稿里而不是临时去查。6.3 代码提交的常见失误编程题写完后提交前一定要检查几个地方类名和方法签名是否和题目要求一致。牛客网的代码模板一般已经写好了main或者类名你只需要在内部实现即可但有时候题目要求的方法签名和默认模板不一样就要自己改。如果签名不一致编译报错的不是语法错误而是“找不到主类”这种错误很伤。输入输出格式是否匹配。牛客网一般是从标准输入读数据用System.out输出。不要自己加多余的提示信息比如“请输入xx”输出格式会被当成错误。空指针和边界条件。如果要求输入可能为空代码里一定要对null做处理。我在做最长无重复子串时第一行就写了 s null 的判断这就是在预防空指针。6.4 心态管理与长时间对抗的体力准备最后说一个很多人忽视的点笔试是体力活。2小时高度集中大脑持续高速运转真的很消耗精力。我在笔试前吃了点东西、提前上了厕所、把手机调成勿扰模式避免一切干扰。笔试过程中一旦有一道题卡住了不要死磕。我当时在做一道多选题时犹豫了将近3分钟后来果断标记了选项就跳过了先去完成后面能拿分的题。笔试不是高考不是每道题都必须做对你需要的是在有限时间内拿到尽可能多的分数。考完之后别急着关网页先用手机或者备忘录把还记得的题目大概写下来。我每次笔试完都会习惯性做这件事一方面方便复盘另一方面防止面经忘记。两天后我会专门花时间把整张试卷涉及到的知识点过一遍整理成笔记这个习惯在秋招中帮了我很多。7. 考后复盘与查漏补缺笔试结束后我做了一次完整的复盘翻出所有题目分类整理了错题和模糊知识点。这一步非常重要因为OPPO的笔试只是第一关后面大概率还有一轮或者两轮面试笔试中暴露出来的薄弱点面试中很可能被再次问起。我自己在复盘后发现有两个知识点掌握得不够扎实。第一个是Handler的消息屏障Message Barrier机制之前只是知道有这个东西但对它的应用场景理解不深。后来我补了一下发现它主要用于UI帧刷新和同步屏障比如Choreographer就是通过消息屏障来安排帧回调的。这个知识点了解到“能给别人讲明白”的深度之后我心里才觉得真学透了。第二个是View的绘制流程。知道measure、layout、draw很简单但要说出DecorView怎么把XML解析成View树、getMeasureSpec的三种模式怎么用、自定义View的onMeasure为什么要处理wrap_content每个问题都能讲清楚才是真的掌握。现在回头看这种“能不能把它讲清楚”的判断标准笔试中特别适用——你会不会考官一测试就知道。另外我也把笔试题中涉及的技术框架类知识系统整理了一遍特别是跨平台方案的对比、性能优化的排查路径这些在面试中几乎是必问的。整理的时候我会做成表格把React Native、Flutter、uni-app、原生开发在性能、开发效率、生态、团队要求这几个维度上做对比。这样面试官问起来我能快速在脑子里调出框架回答起来条理清晰。8. 一点个人建议回头看整个准备和参加OPPO秋招移动端岗笔试的过程我最想跟学弟学妹们分享的几点真实感受是移动端的笔试越来越看重“工程落地能力”刷题之外一定要抽出时间整理自己的项目经历和性能优化实战案例考官很看重这个时间管理在笔试中极其关键会做的题一定要稳拿分不会的题不要死磕留出时间回头检查笔试后的复盘一步都不要省你复盘出的每一个知识点都可能在面试中救你一命考场上遇到陌生的题不要慌静下来想想它的本质是什么你完全有能力解决。最后再送给大家一个我在整个秋招中反复验证的小技巧每次笔试或者面试前把自己整理的高频考点笔记从头到尾翻一遍不需要背只需要把每个关键概念在脑子里过一遍能说出“它是什么、为什么、怎么用”这三件事就够了。希望这篇复盘能对大家有所帮助祝你们的秋招一路顺风。 OPPO秋招移动端笔试复盘：从性能优化到算法题的全流程经验
2023年秋招的移动端岗位笔试我踩过的坑和复盘都在这里了。先说下背景我是2023届毕业生主攻Android方向也补了一些iOS和跨端知识。OPPO秋招的移动端岗笔试是我秋招季里印象最深的一场不是因为题最难而是因为它覆盖面很广、出题非常贴近实际开发尤其是对“移动端性能优化”和“技术框架理解”的考察明显不是靠刷LeetCode就能应付的。这篇文章把整场笔试从头到尾复盘一遍包括题型分布、我当时的答题思路、考完之后的查漏补缺以及一些踩坑经验希望能给后面准备OPPO或其他大厂移动端岗位笔试的同学一些参考。1. 笔试前的准备与岗位认知很多人拿到笔试通知的第一反应是开始刷题这没错但如果你连这个岗位到底要什么样的人都不知道刷题方向很容易跑偏。我在收到OPPO移动端岗笔试通知后先做了三件事扒岗位JD、看面经、梳理自己的知识树。1.1 OPPO移动端岗笔试到底考什么先说结论OPPO的移动端笔试不是纯粹的数据结构和算法考试它对“工程落地能力”的考察占比很高。整场笔试大概2小时题型分为客观题、简答题和编程题三部分。客观题里除了常规的计算机基础还有大量跟移动端相关的场景题比如内存抖动怎么排查、卡顿掉帧怎么分析、启动速度怎么优化这类的。这就意味着你要是只刷算法题而忽略了移动端本身的八股和实战经验客观题会吃大亏。我当时在牛客网上翻了不少往年的笔经发现OPPO出题有一个明显倾向它喜欢把“线上问题”搬到试卷里让你根据实际场景给出排查方案和优化思路。比如有个印象很深的题目给了你一段内存泄漏的代码让你找出泄漏点并说明怎么用工具定位这完全就是在模拟真实开发中遇到问题的过程。1.2 我的备考资料与复习路线我的备考周期大概两周资料主要是这几类计算机基础数据结构、操作系统、网络用王道考研系列复习重点放在链表、树、哈希表、TCP/UDP、进程线程这些高频考点上。移动端专项Android性能优化、Handler机制、事件分发、自定义View、Jetpack常用组件这些是Android方向的核心。刷题平台LeetCode Hot 100 剑指Offer重点是字符串处理、链表、二叉树、动态规划这几类。面经整理牛客网、掘金上看OPPO往年的移动端笔经面经把高频考点整理成笔记。这里想多说一句复习一定要有侧重。我当时因为时间紧把大部分精力放在了Android性能优化和常见机制上事实证明这个决策是对的。笔试里考到的客观题大半都跟这两个方向相关。1.3 考前调试环境准备OPPO用的是牛客网的在线笔试系统支持多种语言Android/iOS开发一般选Java或者C写的比较多我用的是Java。考前一定要做两件事一是把牛客网的在线编程环境提前熟悉一下看看代码补全、编译报错这些功能好不好用二是测试摄像头和麦克风OPPO的笔试要求开启摄像头监控这个环节出了问题会很麻烦。另外强烈建议把本地开发环境也准备好。我当时用的是IDEA额外装了Java的JDK 11。虽然牛客网是在线编译但本地有个环境可以快速验证一些不确定的API用法比在在线编辑器里干等编译结果要快得多。笔试不是开卷考试该背的八股还是要背但遇到记不准的API本地快速验证一下能节省大量时间。2. 题型全拆解从选择题到编程题进到笔试页面那一刻先把整个试卷从头到尾扫一遍看清楚每道题的分值再决定做题顺序。OPPO的笔试不会把题目分成多个部分让你分别提交而是一整份试卷客观题和编程题混在一起。我当时是先做编程题回头再做的客观题这个策略后面会详细说。2.1 客观题计算机基础与移动端专项客观题大概有20道左右分为单选题和多选题。考察范围包括数据结构、操作系统、网络协议以及移动端特有的机制。我回忆几道比较典型的题第一类是Java基础考的是HashMap在JDK 1.8中的实现原理包括数据结构是什么数组链表红黑树、什么时候会触发红黑树化、扩容的时机和方式。这类题只要认真准备过Java集合源码基本十拿九稳。第二类是操作系统考的是死锁产生的四个必要条件互斥、占有且等待、不可剥夺、循环等待以及如何打破这些条件来预防死锁。这个也是经典中的经典属于送分题。第三类是网络考的是TCP三次握手和四次挥手的状态转换具体考了TIME_WAIT状态出现在哪一端、持续多久、为什么要等待2MSL。这里有个容易记混的点TIME_WAIT是主动关闭连接的那一端进入的状态目的有两个一是确保最后一个ACK能被对方收到二是让旧连接的报文在网络中自然消失。第四类是移动端专项考的是Android的Handler机制。题目问你Looper.loop()为什么不会阻塞主线程、MessageQueue.next()在没有消息时会怎样答案是会调用nativePollOnce进入休眠等有消息时通过epoll机制唤醒。这种题对做过Android开发的人来说不算难但如果你只学过理论没真正看过源码很容易答错。第五类还是移动端专项考的是事件分发机制给你一个场景问你触摸事件会先经过Activity还是ViewGroup还是View。这个就是标准的三大分发方法dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent记住“从上往下分发、从下往上处理”就对了。多选题目要注意别漏选。我做题的时候有个习惯对不确定的选项会在草稿纸上先写一下分析然后再勾选。尤其是多选题OPPO的规则是多选、少选、错选都不得分所以宁可保守一点不确定的选项别选。我当时有一道关于JVM内存模型的题有个选项拿不准最后还是没选事后对答案发现那个选项确实是错的逃过一劫。2.2 简答题性能优化与技术选型高频考点简答题是整场笔试的分水岭也是OPPO拉开分数差距的地方。第一道简答题考的是“App启动速度优化”。这题我在准备阶段重点复习过所以答得比较顺。我的回答思路分三块启动阶段的拆分冷启动和热启动的区别。冷启动要经历创建进程、初始化Application、创建MainActivity、首帧绘制整个过程越短越好。具体优化手段Application的onCreate里不要做耗时操作能延迟初始化的就用延迟初始化SharedPreferences的加载会比较耗时可以用异步加载的方式首屏可以通过设置启动背景windowBackground来优化视觉上的等待时间减少首帧绘制前的布局层级避免过度绘制。工具使用用systrace或者Perfetto来抓取启动过程的耗时分布定位瓶颈是真正的解法。第二道简答题考的是“移动端App内存泄漏的常见原因和排查方法”。这个也是高频考点我当时的回答是常见原因静态变量持有Activity引用最常见、Handler持有Activity的引用且任务未及时移除、匿名内部类的隐式引用、单例模式持有Context、资源未关闭比如BroadcastReceiver未反注册、Cursor未关闭、IO流未关闭。排查方法用Android Studio自带的Memory Profiler观察内存占用变化用LeakCanary在Debug版本中自动检测泄漏用MAT分析heap dump文件通过Dominator Tree查看引用链。简答题的答题策略跟编程题不一样不需要写出能直接运行的代码但需要你像写技术方案一样把思路理清楚。我的经验是按照“问题是什么-为什么会出现-怎么排查-怎么解决-如何预防”这个结构来组织答案条理清晰也方便阅卷人给分。2.3 编程题数据结构和移动端场景算法编程题一共三道难度从easy到medium偏上没有特别偏门的题。但如果你的算法底子不好或者只刷过LeetCode的hot题可能还是会在某一道题上卡住。第一道题是字符串处理题目大概意思是给定一个字符串请你找出最长的不含重复字符的子串长度。这个就是LeetCode的第3题滑动窗口的经典应用。用两个指针维护一个窗口用HashMap存储窗口内字符的最大下标遍历过程中不断更新左边界和最大长度。这题我写得比较快大概5分钟就AC了。第二道题是一个有趣的场景题给定一个数组代表一个App每天的日活用户数请你找出“第一个连续三天增长”的起始下标。比如数组是[5, 3, 4, 6, 8, 2]那么下标2开始的3天是[4, 6, 8]正好是连续增长的。这题其实就是一个数组遍历的easy题但加了App日活的外壳。我当时的解法是for循环遍历检查i、i1、i2三个元素是否严格递增。第三道题是稍微有一点绕的实现一个简化版LRU缓存。这题我印象非常深因为现场写的时候差点翻车。核心是维护一个双向链表和一个HashMapget和put操作都要求O(1)时间复杂度。我在写双向链表的时候一开始忘记处理头尾节点的特殊情况导致空指针好在代码逻辑不复杂调试了一下就通过了。建议备考时把LRU的链表实现和LinkedHashMap实现都写一遍做到手写不卡壳。3. 移动端核心知识点复盘笔试过了之后我花了两天时间把整张试卷涉及的知识点系统复盘了一遍。这里面有几个点特别值得展开说因为它们不只是笔试会考面试、日常开发中同样会用到。3.1 移动端性能优化全家桶OPPO笔试对性能优化的偏爱是有原因的。ColorOS本身就是OPPO的核心竞争力而系统级优化的基础就是对App性能的理解。性能优化这个大类基本可以拆成四个维度启动速度、流畅度、内存、包体积。启动速度的优化除了前面说的Application耗时拆分还有几个进阶思路值得了解用启动器框架比如AndroidX的StartUp管理初始化任务让可以并行的任务并行执行对ContentProvider进行裁剪——这也是很多App启动慢的隐藏原因第三方SDK动不动就注册一个ContentProvider导致Application attachBaseContext阶段就要加载一堆类。如果你对启动速度优化有自己的实战案例哪怕只是把某个SDK从冷启动初始化改成按需初始化效果从数据上体现出来了笔试中写出来绝对是加分项。流畅度优化说白了就是减少卡顿掉帧。这里要理解Vsync和Choreographer的工作机制知道掉帧的本质是单帧绘制时间超过16.6ms。优化手段一般是减少布局层级用ConstraintLayout或自定义View代替多层嵌套、避免在onDraw里创建对象、用RecyclerView代替ListView并做好 ViewHolder复用、避免在主线程做耗时操作。Android官方也提供了Layout Inspector、GPU Profiler这些工具来定位问题解决卡顿的第一步永远是“找到卡在哪里”。内存优化考查频率最高的就是内存泄漏和内存抖动。泄漏问题前面已经提过这里说下内存抖动。内存抖动是短时间内大量创建和销毁对象导致频繁GC表现为掉帧、卡顿。常见场景是在循环中拼接字符串导致大量StringBuilder对象、在onDraw中创建Paint或Bitmap对象等。音频开发中有个经典场景实时音频处理中每帧都new一个byte数组导致内存疯狂抖动优化方式就是把数组定义为成员变量重复使用同一块缓冲区。包体积优化这个在笔试里出现频率相对低但偶尔会在选择题中出现。核心思路是开启资源混淆和压缩minifyEnabled、shrinkResources、用WebP代替PNG/JPG、合理使用App Bundle、删除无用依赖和重复资源。尽量控制原生库so的数量和架构兼容范围。3.2 移动端技术框架选型思路笔试简答题有时候会问“你了解哪些移动端跨平台开发框架说说它们的优缺点”。这题一方面考察你的技术视野另一方面考察你在真实项目中做技术选型的能力。主流的移动端开发框架有四个方向原生Android/iOS各自开发、React NativeFacebook开源、FlutterGoogle开源、uni-app国内用的很多基于Vue语法。这个问题不能只答“Flutter好推荐用Flutter”而要结合具体业务场景来回答。比如你的团队是Web前端出身Vue技术栈比较熟那uni-app的上手成本就低于Flutter如果你的App对UI一致性和流畅度要求极高业务又偏向中大型那Flutter的渲染性能和跨平台UI一致性就是优势如果你只是给现有App做一个简单页面那直接上React Native或者WebView都能快速交付。我当时的回答思路是先说框架对比再结合一个假设场景做技术选型最后给出结论。这种答法比较完整能体现你有“做决策”的能力而不只是“知道概念”。另外一个常考的点是“说说B站移动端技术框架”。B站在技术分享上比较开放很多资料都公开了。B站iOS端和Android端早期都是原生为主后来在跨端方面做了不少尝试包括自研的跨端方案和React Native的引入。这个问题在笔试中出现一般是考察你平时是否关注行业动态和技术社区。说实话这种题没有标准答案你只要能说出几个B站公开的技术方案再表达自己对技术选型的思考就行。3.3 移动端调试难题与线上问题定位笔试里有一类题会给你一个线上Crash日志让你定位问题。这个非常考验实战经验比如日志里看到的常见崩溃类型空指针、数组越界、类转换异常、资源找不到。我印象里有一道题给的日志是NullPointerException堆栈指向的是一个自定义Adapter的getView方法。答案思路是从堆栈中找到崩溃的具体行号然后去看这一行访问了哪个对象可能是ViewHolder里的控件没findViewById也可能是数据源里的某个字段是null。这里想顺带提一个很实用的调试技巧vConsole。它就是为移动端Web调试而生的可以在手机浏览器任意页面注入使用就相当于给移动端网页加了一个迷你版DevTools。笔试里如果考到“如何远程调试移动端页面”vConsole是一个很好的答案。具体用法非常简单只需要在HTML中引入vConsole的脚本然后初始化一下script srchttps://unpkg.com/vconsole/dist/vconsole.min.js/script script // 初始化 var vConsole new VConsole(); console.log(Hello world); /script引入之后页面上会悬浮一个VConsole的按钮点击后可以看到Console日志、Network请求、Element结构、Cookie、LocalStorage等信息。在真实项目中一般会通过配置开关动态决定是否加载vConsole只在测试环境或者需要远程排查问题时才启用。如果你连这个都知道笔试的“实操题”基本就稳了。3.4 移动端数据可视化ECharts的特殊渲染场景结合热搜词来看ECharts在移动端的应用也是一个值得准备的知识点。OPPO笔试不一定直接考这个但“移动端如何展示图表”这种场景题有概率出现特别是它们家的健康类App运动数据、睡眠图表都是核心功能。ECharts是一个功能非常强大的前端图表库在移动端使用时有几个细节需要特别注意。第一个是首屏渲染速度移动端性能本来就不如PCECharts初始化时如果图表数据量很大渲染耗时会明显增加。优化思路是只初始化首屏可见的图表等滚动到可见区域时再懒加载初始化。第二个是折线图tooltip的显示问题。有网友问“ECharts折线图在移动端怎么让它渲染完成后显示最后一个点的tooltip”这个需求在移动端其实很常见比如你要展示最近7天的运动步数趋势希望打开页面后自动在数据末端弹出tooltip提示框。实现思路有几种最简单可靠的是用dispatchAction手动触发tooltip的显示// 假设chart已经初始化并且setOption完成 myChart.setOption(option); // 渲染完成后手动触发最后一个数据点的tooltip myChart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: option.series[0].data.length - 1 });这里要注意一个坑dispatchAction需要在setOption同步渲染完成之后调用否则可能拿不到正确的坐标。如果你的数据是异步加载的一定要在setOption之后、数据完全渲染好的时机去触发比如通过setTimeout延迟100ms左右或者监听rendered事件后再执行。第三个坑是移动端图表交互的点击精度问题。ECharts默认可以显示tooltip但在触屏设备上手指的点击精度远不如鼠标很容易点不准。可以用ECharts的axisPointer 移动端的touch事件来替代hover。ECharts在移动端的触摸交互其实已经做得不错了支持缩放、滑动、双指操作等手势但前提是你必须开启dataZoom和toolbox的相应配置。这些细节在日常开发中很实用笔试如果你能写出来阅卷人会认为你是有实际项目经验的。4. 编程题实操两道典型题的完整解题思路编程题是笔试中分值占比最高、也最能拉开差距的部分。我单独拿出两道印象最深的题做一个完整的解题复盘。4.1 滑动窗口最长无重复子串这道题是笔试的第二题LeetCode第3题属于“面试必刷100题”级别的经典题。题目就不重复了直接说解题思路和代码。解法用滑动窗口核心思路是维护一个“不含重复字符的窗口”不断把右边界向右扩展同时保证窗口内没有重复字符。一旦发现重复字符就把左边界跳到重复字符上次出现的位置的后一格。class Solution { public int lengthOfLongestSubstring(String s) { if (s null || s.length() 0) { return 0; } // 用HashMap记录每个字符最近一次出现的下标 MapCharacter, Integer map new HashMap(); int maxLen 0; int left 0; for (int right 0; right s.length(); right) { char c s.charAt(right); if (map.containsKey(c)) { // 如果重复字符在当前窗口内则移动左边界 // 注意这里不能直接取map.get(c)1因为可能left已经越过了这个位置 left Math.max(left, map.get(c) 1); } map.put(c, right); maxLen Math.max(maxLen, right - left 1); } return maxLen; } }这里面的一个关键细节是 left Math.max(left, map.get(c) 1) 这行代码。如果你直接写 left map.get(c) 1会出现一个边界问题当遇到重复字符但这个字符上次出现的位置已经在当前left的左边也就是窗口外时你如果把left直接设为 map.get(c) 1左边界反而会往左移动计算结果就错了。但实际情况是重复字符在窗口之外并不会影响当前窗口的无重复性。用Math.max来限制left只能往右走就规避了这个坑。这题看起来简单但一定要自己动手写一遍。笔试环境没有LeetCode的提示没有“通过”按钮你写完编译通过后要自己想测试用例来验证。我当时写完后测了三个用例空串、全重复字符串、全不重复字符串基本覆盖了边界情况。4.2 移动端场景实现LRU缓存这道题是笔试的压轴题分值最高也是我最紧张的一道。题目要求自己实现一个LRU缓存包含get和put两个方法要求时间复杂度都是O(1)。这个就是LeetCode第146题。O(1)的时间复杂度意味着必须用HashMap来存储数据而为了维护“最近使用”的顺序还需要一个双向链表。每次get一个key就把这个节点移动到链表头部每次put一个key如果key已存在则更新value并移到头部如果不存在则插入头部如果容量满了就移除链表尾部的节点。我当时的实现用的是自建双向链表class LRUCache { class Node { int key; int value; Node prev; Node next; Node(int key, int value) { this.key key; this.value value; } } private int capacity; private MapInteger, Node map; private Node head; private Node tail; public LRUCache(int capacity) { this.capacity capacity; map new HashMap(); head new Node(-1, -1); tail new Node(-1, -1); head.next tail; tail.prev head; } public int get(int key) { if (!map.containsKey(key)) { return -1; } Node node map.get(key); moveToHead(node); return node.value; } public void put(int key, int value) { if (map.containsKey(key)) { Node node map.get(key); node.value value; moveToHead(node); } else { if (map.size() capacity) { Node removedNode removeTail(); map.remove(removedNode.key); } Node newNode new Node(key, value); map.put(key, newNode); addToHead(newNode); } } private void addToHead(Node node) { node.prev head; node.next head.next; head.next.prev node; head.next node; } private void removeNode(Node node) { node.prev.next node.next; node.next.prev node.prev; } private void moveToHead(Node node) { removeNode(node); addToHead(node); } private Node removeTail() { Node node tail.prev; removeNode(node); return node; } }这里最关键的坑有两个。第一个是哨兵节点dummy head/tail的使用很多第一次手写双向链表的人容易漏掉这一层结果在删除头节点或者尾节点时出现空指针。第二个是 removeTail 的时候一定要把节点的key保留下来因为你在map里删除的是这个key而不是value。如果Node里只存value不存key删除的时候你就没办法从map中删掉对应的KV了。我当时写完这道题又检查了一遍put的流程确认没有边界问题然后才提交。笔试结束后我回忆了一下这道题大概是45码左右的体量在15分钟内写完加调试难度其实还行。关键是你平时一定要手写过如果只看过答案没动手笔试时很容易在指针操作上卡壳。5. 笔试中的时间分配与答题策略笔试的时间是固定的但每个人的做题顺序和节奏不一样。我自己总结了一套比较稳的打法分享出来给大家参考。5.1 开考后前10分钟先做全局浏览很多人一进笔试就开始做题我觉得这是最大的浪费。正确做法是先花5-8分钟把整张试卷从头到尾看一遍看清楚有几道客观题、几道简答题、几道编程题分别占多少分。然后在草稿纸上给自己定一个时间预算。比如总分100分时间是120分钟那你给每道题的预算就是“分值比例 x 时间”客观题占比40%那最多花48分钟编程题占比40%最多花48分钟。全局浏览还有一个好处你能提前发现那些“送分题”和“坑题”。比如某道多选题你一眼就知道答案那可以放在后面快速做完某道编程题看起来要花不少时间那就优先做。我当时浏览完试卷后发现编程题有一道关于日活用户数的场景题非常简单于是决定先做编程题再做客观题。那时候心里很有底因为编程题一共三道我能拿下的就有两道半剩余的时间可以安心做客观题。5.2 时间预算表各题型的时间分配我做一个典型的时间分配表供参考题型题量预估时间答题策略单选题10-12道15分钟快速作答不纠结超过1分钟的题多选题5-8道15分钟宁少勿多不明确的选项不选简答题2-3道30分钟按“问题-原因-方案”结构化作答编程题2-3道40分钟先易后难留10分钟自查这个表不是死的但是“编程题留出充裕时间”这个原则是铁的。因为编程题编译调试很费时间你要是挤到最后20分钟才开始做心态很容易崩。5.3 遇到不会的题怎么处理笔试里遇到不会的题非常正常关键是心态要稳住。我的原则是先跳过最后再说。如果是客观题不确定的选项先在草稿纸上记下来最后如果还有时间再回头思考。如果是简答题一定要写点什么哪怕不确定答案也要按照自己理解的思路去写写错不扣分但写空肯定没分。如果是编程题不会做就先把暴力解法写出来能过多少用例算多少。笔试判分不是只有“全对”和“全错”很多题是按用例比例给分的暴力解法通常能过一部分简单用例有分总比没分好。6. 常见问题与避坑指南这是这个篇幅最想写的部分。笔试考的不只是知识点还有很多琐碎但致命的细节一个不注意就能毁掉整场考试。6.1 在线笔试环境与网络问题在线笔试最怕的是什么是考到一半断网。虽然牛客网有断线重连机制但万一你连回来的时候代码没保存损失就大了。保险做法是编程题的代码写完一段就手动复制一遍到本地记事本里网络差的情况下尤其管用。另外笔试开始前一定确认浏览器是Chrome或者Edge的最新版并把弹窗拦截关掉。有的学校网络会屏蔽在线笔试的一些资源最好提前连上考场给的网络测试链接做一次完整测试。如果是在家笔试建议用有线网络WiFi的稳定性在关键时刻真的不靠谱。6.2 摄像头监控与诚信机制OPPO笔试要求开启摄像头监考不管是手机端还是电脑端都要配合。笔试过程中系统会随机抓拍或者录屏还有AI辅助监考检测到异常行为会标记试卷。这里有个非常容易踩的坑不要中途切出浏览器去查资料。哪怕你切出去看的是完全无关的内容系统也可能会判定为作弊。笔试全程尽量保持浏览器窗口在前台就算你只是去本地IDEA验证代码也要注意切窗口的频率。我全程都开着本地IDEA但只切换过两三次基本都在安全范围内。如果你觉得自己代码不熟练一定要提前把常用的代码片段放在本地草稿里而不是临时去查。6.3 代码提交的常见失误编程题写完后提交前一定要检查几个地方类名和方法签名是否和题目要求一致。牛客网的代码模板一般已经写好了main或者类名你只需要在内部实现即可但有时候题目要求的方法签名和默认模板不一样就要自己改。如果签名不一致编译报错的不是语法错误而是“找不到主类”这种错误很伤。输入输出格式是否匹配。牛客网一般是从标准输入读数据用System.out输出。不要自己加多余的提示信息比如“请输入xx”输出格式会被当成错误。空指针和边界条件。如果要求输入可能为空代码里一定要对null做处理。我在做最长无重复子串时第一行就写了 s null 的判断这就是在预防空指针。6.4 心态管理与长时间对抗的体力准备最后说一个很多人忽视的点笔试是体力活。2小时高度集中大脑持续高速运转真的很消耗精力。我在笔试前吃了点东西、提前上了厕所、把手机调成勿扰模式避免一切干扰。笔试过程中一旦有一道题卡住了不要死磕。我当时在做一道多选题时犹豫了将近3分钟后来果断标记了选项就跳过了先去完成后面能拿分的题。笔试不是高考不是每道题都必须做对你需要的是在有限时间内拿到尽可能多的分数。考完之后别急着关网页先用手机或者备忘录把还记得的题目大概写下来。我每次笔试完都会习惯性做这件事一方面方便复盘另一方面防止面经忘记。两天后我会专门花时间把整张试卷涉及到的知识点过一遍整理成笔记这个习惯在秋招中帮了我很多。7. 考后复盘与查漏补缺笔试结束后我做了一次完整的复盘翻出所有题目分类整理了错题和模糊知识点。这一步非常重要因为OPPO的笔试只是第一关后面大概率还有一轮或者两轮面试笔试中暴露出来的薄弱点面试中很可能被再次问起。我自己在复盘后发现有两个知识点掌握得不够扎实。第一个是Handler的消息屏障Message Barrier机制之前只是知道有这个东西但对它的应用场景理解不深。后来我补了一下发现它主要用于UI帧刷新和同步屏障比如Choreographer就是通过消息屏障来安排帧回调的。这个知识点了解到“能给别人讲明白”的深度之后我心里才觉得真学透了。第二个是View的绘制流程。知道measure、layout、draw很简单但要说出DecorView怎么把XML解析成View树、getMeasureSpec的三种模式怎么用、自定义View的onMeasure为什么要处理wrap_content每个问题都能讲清楚才是真的掌握。现在回头看这种“能不能把它讲清楚”的判断标准笔试中特别适用——你会不会考官一测试就知道。另外我也把笔试题中涉及的技术框架类知识系统整理了一遍特别是跨平台方案的对比、性能优化的排查路径这些在面试中几乎是必问的。整理的时候我会做成表格把React Native、Flutter、uni-app、原生开发在性能、开发效率、生态、团队要求这几个维度上做对比。这样面试官问起来我能快速在脑子里调出框架回答起来条理清晰。8. 一点个人建议回头看整个准备和参加OPPO秋招移动端岗笔试的过程我最想跟学弟学妹们分享的几点真实感受是移动端的笔试越来越看重“工程落地能力”刷题之外一定要抽出时间整理自己的项目经历和性能优化实战案例考官很看重这个时间管理在笔试中极其关键会做的题一定要稳拿分不会的题不要死磕留出时间回头检查笔试后的复盘一步都不要省你复盘出的每一个知识点都可能在面试中救你一命考场上遇到陌生的题不要慌静下来想想它的本质是什么你完全有能力解决。最后再送给大家一个我在整个秋招中反复验证的小技巧每次笔试或者面试前把自己整理的高频考点笔记从头到尾翻一遍不需要背只需要把每个关键概念在脑子里过一遍能说出“它是什么、为什么、怎么用”这三件事就够了。希望这篇复盘能对大家有所帮助祝你们的秋招一路顺风。