作为一个在Android圈子里混了快十年的老开发每年校招季都会被各种学弟学妹问“爱奇艺笔试考什么”。说实话2020年那场校招Android方向的笔试题在我印象里算是比较有代表性的——它不堆砌偏题怪题而是把Android开发日常真正依赖的基础能力翻来覆去地考。如果你正在准备大厂校招或者工作两三年想回头检验一下自己的底子这篇内容值得你花15分钟慢慢看。我会尽量还原当时题目的考察逻辑把每一类题背后真正想考的知识点拆开揉碎讲清楚顺便附上我这些年面试别人、带新人时总结的一些复习思路。1. 笔试题整体拆解爱奇艺Android方向到底考什么1.1 题型结构与考察维度解析爱奇艺2020校招Android方向的笔试题整体分成了三大块单选题、多选题、编程题。有些批次的试卷还会加入简答题但主体仍然是选择和编程。选择题部分Java基础和数据结构占了差不多一半的篇幅。这并不是爱奇艺特有的偏好而是国内互联网大厂Android岗位笔试的通用套路。原因很简单校招生没有太多真实项目经验面试官能考察的只有基础功。Java的集合类、并发工具、JVM内存模型这些内容直接决定了你未来写业务代码时会不会埋坑。比如HashMap在1.7和1.8版本之间的实现差异看起来是个八股文考点实际上关系到你在高并发场景下能不能意识到“哦这里可能会死循环”。数据结构与算法的选择题则集中在数组、链表、二叉树、堆这几个高频考点。HashMap的扩容机制、链表反转的迭代和递归两种写法、二叉树的前中后序遍历这些都是选择题和编程题之间的桥梁。你要是把这些基础数据结构吃透了编程题基本不会慌。Android基础的选择题反而没有想象中那么多但每一道都很有分量。Handler消息机制、Activity启动模式、View的绘制流程、事件分发机制这几个老生常谈的考点几乎必考。爱奇艺这种视频类App业务场景里充满了播放器状态切换、弹幕实时刷新、列表滑动加载这类需求而这些需求恰恰是Handler和View机制的典型应用场景。编程题部分一般是两道题。一道偏算法常见的有LRU缓存设计、最长回文子串、二叉树的最近公共祖先另一道偏字符串处理或者动态规划偶尔会出现模拟题考察你写代码的严谨度。1.2 从题目反推爱奇艺的用人标准我后来参与过几次校招面试再回头看这份笔试题最大的感受是出题人不是在为难你而是在筛选“基础扎实、能干活、有潜力”的人。为什么这么说你看题目分布就能明白。选择题里Java和数据结构占比高说明他们默认Android开发首先是Java开发编程题不考太偏的算法说明他们不指望校招生上来就能手写红黑树但至少得能手写链表反转和二叉树遍历Android部分的题目紧扣日常开发说明他们希望你对运行时的机制有真实理解而不是只停留在API调用层面。爱奇艺App本身是一个超级复杂的客户端播放器、弹幕、会员购买、推荐流、搜索、个人中心这些模块对性能和稳定性的要求都很高。如果你在笔试阶段就暴露了Handler机制理解不到位、线程使用随意、内存泄漏意识缺失这类问题即使其他科答得再好也很难拿到面试机会。反过来基础题答得漂亮的候选人通常在实际编码中的代码规范性和问题排查能力也不会差。所以这份笔试题的本质是一面镜子照出你过去几年的积累。你现在刷题不只是在应付考试更是在给自己未来的工程能力打底子。2. 核心考点精讲选择题里的Java与数据结构2.2 Java并发与集合源码考点解析Java部分的笔试题目如果让我列一个优先级我会这样排集合类源码 JVM内存模型 并发编程。集合类里HashMap是绝对的重点。从1.7到1.8HashMap的底层结构从数组加链表变成了数组加链表加红黑树这一变化背后有很深的考量。1.8之前当哈希冲突严重时链表会变得很长查询时间复杂度退化到O(n)而红黑树的引入让最坏情况的时间复杂度降到了O(logn)。但是红黑树的维护成本很高所以JDK的设计者设置了一个阈值链表长度超过8且数组长度超过64时才转树。很多人只记住了阈值8却忽略了数组长度64这个前置条件笔试里的陷阱往往就藏在这种细节里。还有一个高频考点是HashMap在多线程环境下扩容时可能出现的死循环问题。这个问题在1.8之后虽然通过引入高低位链表等方式得到了缓解但HashMap仍然不是线程安全的容器。选择题里如果问到“以下哪些集合类是线程安全的”标准的正确选项是ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue这些而HashTable虽然线程安全但因为性能问题已经不推荐使用。并发部分synchronized和volatile的区别是必考题。volatile保证了可见性但无法保证原子性synchronized既能保证可见性也能保证原子性。笔试题目经常给一段多线程的代码片段问你最后的输出结果实际上就是在考察你能否识别出volatile在i这种复合操作上的局限性。线程池也是常客。ThreadPoolExecutor的七个核心参数——corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler每一个都需要理解到位。选择题容易考的是当任务数超过corePoolSize且队列已满时任务会交给谁处理正确的流程是先创建非核心线程非核心线程也满了之后触发拒绝策略。这个流程如果记混了后面聊到性能优化时会露怯。JVM内存模型考得相对简单主要是堆、栈、方法区、程序计数器这四块的基本职责以及垃圾回收的基本算法。Android开发接触的ART虚拟机虽然和标准JVM有差异但内存分区的思路是相通的。如果你能在选择题里展现出你对“哪些对象会进入老年代”的判断力面试官对你的印象分会明显提升。2.3 高频算法选择题与手写代码注意事项算法题选择题其实挺有迷惑性的。出题人会在复杂度分析上做文章。比如问“在有序数组中查找某个元素最优算法的时间复杂度是多少”很多人会条件反射地答O(logn)但题目可能改为“在有序但经过旋转的数组中查找”这时候最优解仍然是二分但边界判断条件多了很多细节。这类题考的不是背答案而是你是否真正理解算法每一步在干什么。二叉树的遍历无论是递归还是非递归写法都必须烂熟于心。选择题喜欢考“给定前序遍历和中序遍历求后序遍历的结果”本质上是在考你对遍历顺序的推导能力。这一类题如果画图推导十秒钟就能出答案如果靠脑中空想很容易绕晕。我建议备考时养成习惯遇到树相关的题先在草稿纸上画出结构比纯靠记忆靠谱得多。动态规划和字符串处理在选择题里一般以简单模型出现比如斐波那契数列、最长公共前缀。但编程题里动态规划的难度会高一个档次这里先按下不表等会儿单独说。说到手写代码我提几个笔试时特别容易扣分的地方边界检查数组访问越界、字符串空指针、链表为空或只有一个节点这些情况必须提前处理。循环终止条件while循环里忘记移动指针最容易导致死循环一旦触发在线评测的超时机制整题不得分。变量命名虽然在线笔试不要求命名完美但a、b、c这种命名会让阅卷人本能地觉得你代码习惯不好。用node、current、nextStr这种有含义的命名成本和收益完全不成比例。算法题的练习我不建议一上来就刷LeetCode高频200题。先按照“数组与字符串 - 链表 - 栈与队列 - 二叉树 - 排序与二分 - 动态规划”的顺序每个模块精刷10道左右把每道题的分析过程和代码实现都写在笔记里比盲目刷500道有效得多。我当年备考时用的就是这种模块化刷题法面试遇到的面试题基本都能在笔记里找到同类题。3. Android专项盘点从Handler到Binder3.1 Handler机制、消息循环与线程通信考点Handler机制在爱奇艺这类笔试中的出现频率用“次次必考”来形容一点不夸张。视频App的播放进度条刷新、弹幕加载、点赞动画这些操作都跑在Handler创建的循环里。核心考点是四件套Looper、MessageQueue、Handler、Message。你要能说清楚它们之间的关系——Looper负责循环MessageQueue负责存储待处理的消息Handler负责发送和处理消息Message是消息的载体。顺着这个思路几个经典问题就能迎刃而解为什么在子线程中new Handler会抛异常因为子线程默认没有Looper而Handler的构造器会尝试通过Looper.myLooper()获取当前线程的Looper取不到就会抛出RuntimeException。如何在子线程中创建Handler先调用Looper.prepare()为当前线程初始化Looper再创建Handler最后调用Looper.loop()启动消息循环。Handler.postDelayed是开启一个子线程延时执行吗不是。它只是把消息放进MessageQueue并按照时间戳排序Looper循环到时间点才取出该消息整个延时过程并没有新建线程。除了原理本身笔试也会考察内存泄漏隐患。非静态内部类Handler会持有外部Activity的引用当Activity即将销毁但MessageQueue中还有延迟消息时Activity无法被回收。正确的做法有两个一是使用静态内部类加WeakReference二是在onDestroy中移除所有回调与消息。我当时印象比较深的一道题问的是“如果主线程的MessageQueue中同时存在一个延迟10秒的消息和一个立即执行的消息Looper会如何处理”。很多人会以为Looper会先处理立即执行的消息再等待延迟消息。实际上Looper调用了MessageQueue.next()这个方法内部是阻塞的它会根据当前时间与消息时间戳的差值来计算阻塞时长。也就是说如果延迟消息排在队列前面即使后面的消息可以立即执行也要等延迟消息到期。这个机制保证了消息按时间戳顺序执行但也让很多人第一次理解了Looper的阻塞本质。3.2 View绘制流程、事件分发与滑动冲突View相关的考点在爱奇艺笔试里出现频率同样很高。一套完整的View绘制流程包括measure、layout、draw三个阶段每个阶段都有必考细节。measure阶段核心问题是MeasureSpec的三种模式——UNSPECIFIED、EXACTLY、AT_MOST。自定义View时你要根据父容器传入的MeasureSpec和自身设置的LayoutParams来确定最终尺寸。很多初学者在这里犯的错误是直接使用getWidth()和getHeight()但这两个方法返回的是layout阶段确定的尺寸在measure阶段调用得到的就是0。layout阶段考察的是子View在父View中的摆放位置。LinearLayout和RelativeLayout的布局规则不同面试官喜欢用“高度为wrap_content的FrameLayout子View的layout_gravity设置为center_horizontal”这种组合题来考察你对布局规则的理解。draw阶段最常见的坑是“在自定义View的onDraw方法里直接new对象”。一次页面刷新可能触发多次onDraw如果每次刷新都new Paint和Path内存和性能都会受到影响。正确的做法是把这些对象定义成成员变量在View创建时初始化一次。事件分发机制是很多应届生最头疼的部分它的核心是三个方法dispatchTouchEvent、onInterceptTouchEvent和onTouchEvent。有一道典型的选择题一个ViewGroup中有一个子View当手指触摸到子View的某个区域事件分发的调用顺序是什么正确的顺序是Activity的dispatchTouchEvent - ViewGroup的dispatchTouchEvent - ViewGroup的onInterceptTouchEvent - 子View的dispatchTouchEvent - 子View的onTouchEvent - 如果子View消费了则结束如果没有消费则回到ViewGroup的onTouchEvent。关于onClick和onTouch的触发关系也经常被拿来出题。onTouch优先于onClick执行因为onTouch是在dispatchTouchEvent阶段回调的而onClick是在ACTION_UP事件里通过performClick调用的。如果在onTouch中返回true消费了事件那么onClick不会再被触发。这些细节看起来绕但如果你自己实现过一个自定义View的滑动和点击共存逻辑就会深有体会。滑动冲突的处理笔试时不一定直接考但面试时大概率会被追问。同方向滑动冲突的解决思路是“根据业务场景决定由谁拦截”常见的判断依据包括滑动的速度、滑动的方向、子View是否到达了边界。处理方案是外部拦截法即在父View的onInterceptTouchEvent中决定是否拦截。3.3 Binder与IPC通信机制简析Binder机制对校招生来说是Android知识体系里公认的硬骨头。爱奇艺笔试很少直接让你写Binder的代码但会在选择题里穿插考察几个关键概念。Binder为什么被设计成Android的跨进程通信首选方案而不是使用传统的管道、消息队列或者共享内存答案是性能和安全性的综合考量。共享内存性能好但无法控制访问权限Socket和管道性能一般且数据拷贝开销大。Binder通过mmap在内核空间和用户空间之间只做一次数据拷贝并且在数据传输过程中通过UID/PID验证进程身份兼顾了性能与安全。ActivityManagerService、WindowManagerService这些系统服务都是运行在独立的进程里的App通过Binder与之通信。你在代码里调用startActivity()实际上是先通过Binder向AMS发送一个请求AMS再通过Binder通知Launcher有关系要处理。这条链路上的任何一个环节出错都会导致Activity启动异常。笔试里常考的“系统服务调用的大致流程”答案就是围绕这个Binder链路展开的。AIDL在笔试现场手写的概率很低但面试时要求手写AIDL的概率很高。你至少要能写出接口定义、Stub和Proxy的基本结构并理解它们各自的作用。Stub是服务端用于接收客户端调用的Binder实体Proxy是客户端持有的Binder代理两端通过transact方法和onTransact方法来序列化和反序列化数据。Binder这一块的学习我建议不要死记硬背而是找个机会把系统里的bindService流程走一遍。自己写一个远程Service通过AIDL传递自定义对象打印Log观察各个方法的调用时机比看十篇博客都有效。4. 编程题实操从读题到AC的完整过程还原4.1 典型编程题目的解题思路与边界处理爱奇艺2020年的编程题结合当时考生回忆和题型趋势我挑两道比较有代表性的题目来拆解思路。第一类是LRU缓存设计。题目描述通常是设计一个LRU缓存类支持get和put操作要求get和put的时间复杂度都是O(1)当缓存容量满时淘汰最久未使用的数据。这道题考察的是哈希表加双向链表也就是LinkedHashMap的底层实现逻辑。如果你能写出继承LinkedHashMap的解法说明你对Java集合框架有基本了解但这道题想拿高分需要自己手写双向链表加HashMap的组合结构class LRUCache { private MapInteger, Node map; private int capacity; private Node head, tail; // Node包含key、value和前后指针 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 tailPrev tail.prev; removeNode(tailPrev); map.remove(tailPrev.key); } Node newNode new Node(key, value); addToHead(newNode); map.put(key, newNode); } } }这里的细节很多为什么需要双向链表而不是单向链表因为删除一个节点时如果是单向链表你需要遍历到该节点的前驱节点时间复杂度退化为O(n)。为什么需要HashMap做key到节点的映射因为纯链表查找需要遍历而O(1)的get操作必须依赖哈希表。边界处理上要注意capacity为1的情况以及get一个不存在的key时返回-1。很多人在这些边界条件上翻车其实只要在写之前把空链表、单节点链表、满容量这三种情况想清楚代码就会稳很多。第二类是字符串类的编程题比如最长回文子串。这道题可以用中心扩展法也可以用动态规划。中心扩展法的思路是遍历每个字符以该字符为中心向两边扩展同时考虑奇数长度和偶数长度两种情况记录最长回文的起止位置。这个解法的时间复杂度是O(n²)空间复杂度是O(1)在线笔试的时限范围内完全够用。动态规划解法的递推关系是dp[i][j] (s.charAt(i) s.charAt(j)) dp[i1][j-1]需要注意填表顺序必须按子串长度从小到大填因为短串的结果会被长串依赖。笔试时如果遇到这种两道题的组合我的建议是先花两分钟快速判断题目难度然后先写自己有把握的那道把分数稳稳拿到手再回头攻克难的。4.2 在线笔试环境下的时间分配与踩坑实录在线笔试和平时在IDE里写代码体验差异非常大。我当时踩过的坑现在分享出来供你参考第一个坑是自动补全的缺失。很多笔试平台没有代码提示写一个HashMap的常用方法名都可能卡壳。比如getOrDefault、computeIfAbsent这些在IDE里打字打顺手了的方法在笔试平台里拼错一个字母就会编译失败。建议备考期间尽量在无补全的环境下练习手写代码或者用记事本写写完了再放到IDE里编译检查。第二个坑是输入输出的格式。在线评测对输入输出的严格程度超出预期多打一个空格、少一个换行都可能导致WA。字符串处理题尤其容易踩这个坑next()和nextLine()的区别split()方法处理正则表达式时的转义问题这些都是现场最容易卡壳的地方。我在笔试时曾经因为sc.nextLine()和sc.nextInt()混用导致读入异常整道题前功尽弃后来总结经验读取完数字后如果需要继续读字符串务必先调一次sc.nextLine()把换行符吃掉。第三个坑是时间规划。笔试总时长一般90分钟到120分钟选择题加上编程题节奏非常紧凑。我的策略是选择题每道最多90秒超过就标记一下先跳过编程题先花5分钟通读题目选择一道思路最清晰的开始写控制在30分钟内完成剩下时间用来调试和做第二道题。如果第一道题写了20分钟还没编译通过果断换题别死磕。跳出笔试本身来说这些在线评测的经验在真实面试的手写代码环节同样适用。面试官看着你写代码时最在意的不是你能否十秒内给出最优解而是你能否在压力下保持逻辑清晰、边界处理完整。这个能力只能通过反复练习来培养没有任何捷径。5. 备考路线与阶段性复盘建议5.1 按时间倒排的复习计划参考这里我结合自己带过的实习生备考经历给出一个从零开始、八周可行的复习计划供你参考第1到2周Java基础攻坚复习集合类源码重点看HashMap、ArrayList、LinkedList、ConcurrentHashMap的源码复习JVM内存模型和常见垃圾回收算法把synchronized和volatile的区别彻底搞清楚。第3到4周数据结构与算法按模块刷题数组、链表、字符串、二叉树、排序与二分这五个模块各刷10道左右重点记录每个模块的典型题目和解题套路。第5到6周Android核心机制结合源码深入理解Handler机制、View绘制流程、事件分发机制重点搞清楚“是什么、为什么、怎么做”三个层面的问题。条件允许的话可以自己动手写一个小Demo验证理解。第7周模拟考试找爱奇艺或其他大厂往年真题严格计时做三套完整的笔试题检验复习效果。做题时尽量使用笔试平台熟悉在线评测的输入输出格式和环境。第8周查漏补缺把错题整理成笔记重点巩固反复出错的知识点精读一两篇Handler和View源码的深度分析文章把框架性的理解进一步落到细节上。这个计划的核心逻辑是先把Java基础打牢再刷算法再啃Android最后用真题模拟检验。顺序不能乱因为Android部分的理解深度取决于Java基础的扎实程度而算法题的熟练度需要持续的训练来维持。5.2 笔试之外的准备简历、内推与心态笔试只是校招的关卡之一而且不是最难的。根据我自己的经验笔试之后还有两到三轮技术面试每一轮的难度都在递增。所以准备笔试的同时这几件事你最好同期做起来简历尽量控制在A4纸一页以内项目经历用STAR法则来描述——情境、任务、行动、结果。不要把“熟悉Android开发”这种空话写在上面而是要写清楚你具体处理过什么问题达到了什么效果。比如“通过优化RecyclerView的缓存策略将列表滑动帧率从48fps提升到60fps”这种描述比任何形容词都更有说服力。内推是值得争取的资源。如果能找到在目标公司工作的学长学姐帮忙内推简历被HR看到的概率会大很多而且有些部门内推可以跳过部分笔试流程直接进入面试。心态方面校招是一场持久战难免会遇到连续被刷的情况。我的建议是每次笔试或面试结束后当天晚上做一个复盘记录下哪些问题答得不好然后针对性地补强。不要沉浸在“我是不是不适合做开发”这种负面想法里事实上大部分拿到顶尖offer的人在前期都经历过多次失败。你看到的那些光鲜的秋招总结贴背后往往藏着几十份石沉大海的简历。根据我个人带新人的经验一个候选人能否通过校招起决定作用的往往不是智商而是准备程度。基础题能不能稳稳答对编程题能不能在压力下写出边界完整的代码遇到不会的问题能不能展现出分析思路和学习能力这些都可以通过系统的准备来提升。爱奇艺这份笔试虽然已经过去几年但它考察的那些知识点至今仍是Android面试的核心。把这些问题吃透你收获的不只是一场笔试的通过更是一套做Android开发的基本功。