企业官网建设流程全解析

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、i+1、i+2三个元素是否严格递增。

第三道题是稍微有一点绕的：实现一个简化版LRU缓存。这题我印象非常深，因为现场写的时候差点翻车。核心是维护一个双向链表和一个HashMap，get和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 Native（Facebook开源）、Flutter（Google开源）、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 src="https://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是一个功能非常强大的前端图表库，在移动端使用时有几个细节需要特别注意。第一个是首屏渲染速度，移动端性能本来就不如PC，ECharts初始化时如果图表数据量很大，渲染耗时会明显增加。优化思路是：只初始化首屏可见的图表，等滚动到可见区域时再懒加载初始化。

第二个是折线图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记录每个字符最近一次出现的下标 Map<Character, 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 Map<Integer, 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 时间预算表：各题型的时间分配

我做一个典型的时间分配表供参考：

这个表不是死的，但是“编程题留出充裕时间”这个原则是铁的。因为编程题编译调试很费时间，你要是挤到最后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秋招移动端岗笔试的过程，我最想跟学弟学妹们分享的几点真实感受是：移动端的笔试越来越看重“工程落地能力”，刷题之外，一定要抽出时间整理自己的项目经历和性能优化实战案例，考官很看重这个；时间管理在笔试中极其关键，会做的题一定要稳拿分，不会的题不要死磕，留出时间回头检查；笔试后的复盘一步都不要省，你复盘出的每一个知识点，都可能在面试中救你一命；考场上，遇到陌生的题不要慌，静下来想想它的本质是什么，你完全有能力解决。

最后再送给大家一个我在整个秋招中反复验证的小技巧：每次笔试或者面试前，把自己整理的高频考点笔记从头到尾翻一遍，不需要背，只需要把每个关键概念在脑子里过一遍，能说出“它是什么、为什么、怎么用”这三件事，就够了。希望这篇复盘能对大家有所帮助，祝你们的秋招一路顺风。