2023年秋招那阵儿我刚好帮几个学弟学妹做过笔试前的突击串讲其中小红书Android岗的第三批笔试让我印象很深。这场笔试不像很多大厂那样纯考LeetCode冷题它明显带着“小红书风格”——Android技术栈考察比例不低、题目叙述长、场景贴近真实业务而且第三批次的题在重复率极低的情况下还能做到和大厂常规题库拉开区分度。这篇就结合我当时带人复盘的过程把这场笔试考了什么、怎么准备、有哪些容易被忽略的坑一次性写透。1. 小红书第三批笔试的整体观感题量、时长与批次差异先给没参加过的人一个直观概念。小红书秋招笔试走的是牛客网这类在线笔试平台Android开发岗和客户端开发岗统一用一套卷子不是单独出Android卷。第三批笔试的时长一般是90到120分钟题量在20道左右包含单选、多选、填空和两道手撕代码题其中代码题占分最重属于“一道AC与否直接决定过不过线”的那种权重。批次之间的差异值得提前说清楚。小红书秋招笔试是分批开放、分批考的第一批和第二批的题目偶尔会在牛客、力扣讨论区被回忆出来但第三批的题目重复率极低基本不用指望靠背题碰运气。它的题目风格也跟前两批不太一样第三批更偏向“业务场景结合基础原理”比如给你一个具体的列表卡顿问题让你挑出可能导致卡顿的原因这种题要求你真正做过优化光靠背书很难蒙对。另外第三批笔试的时间点通常在九月中下旬到十月初这时候大厂笔试撞车严重很多人是在一天内连打两场笔试的状态下去做的。我带的学弟当时就是下午刚做完美团笔试晚上接着打小红书脑子已经接近过载。所以如果你也面临类似情况我的建议是考前把小红书近两年的技术文章和开源项目扫一遍对“社区、内容分发、图片加载、Feed流”这些业务关键词建立条件反射比临时刷十道难题有用得多。2. 开场定生死两道手撕代码题的高频模型与解题套路代码题是整场笔试的胜负手小红书Android岗的代码题整体难度在力扣中等偏上偶尔压到困难题的边但不会出那种需要冷门数据结构的题。从我和身边人复盘的结果看第二批和第三批的代码题集中在几类模型上。2.1 数组与区间处理最常见的“送分题”陷阱小红书的业务大量涉及内容排序、推荐位调整、笔记列表分页所以数组和区间处理的题出现频率极高。第三批有一道题跟“合并重叠区间”非常接近但它不是直接给你一个二维数组让你合并而是加了一层业务包装给定一组笔记的曝光时间段要求统计总曝光时长重叠部分只计一次。这种题本质上就是合并区间但很多人死在读题上——把开始和结束时间看反了或者忘了处理“一个区间完全包含另一个区间”的情况。合并区间有两个关键点一是先按左端点排序二是维护当前区间的右边界并不断和下一个区间的左端点比较。具体来说排序后初始化当前区间的左端点start和右端点end遍历每个区间时如果下一个区间的start小于等于当前的end就说明重叠把end更新为两者中的较大值否则就把当前区间收割掉然后更新start和end。这里最容易出错的是边界条件——区间相接比如[1,2]和[2,3]算不算重叠题目里一般会明确说明“无重叠”是指首尾相接如果没说明就按实际业务逻辑推断。曝光时长场景下首尾相接的两个时间段算连续曝光不该重复统计。2.2 动态规划第三批的压轴题常客DP是不少人的噩梦但小红书笔试的DP题有个特点状态定义比较直白难在递推公式的细节上。第三批有一道题让我印象很深类似“打家劫舍”的变体——一排笔记每篇有一个点赞数但不能同时选相邻的两篇求最大点赞总数。这是个非常经典的线性DP状态转移方程就是dp[i] max(dp[i - 1], dp[i - 2] value[i])但笔试加了个限制第一篇和最后一篇也被视为相邻因为是循环列表。循环数组的处理方式有两种第一种是把数组拆成两个场景分别跑DP——不考虑第一篇、不考虑最后一篇取较大值第二种是状态压缩加环形标记。用第一种方案的代码要干净很多适合笔试场景。我见过不少人在这一步翻车拆了场景但忘了把dp数组重新初始化或者两个场景共用一个dp数组导致状态污染。所以如果笔试遇到环形DP我强烈建议写两个独立函数分别处理宁可代码多几行也不要为了“优雅”引入难排查的bug。2.3 字符串与模拟题考验“读题耐心”的题型第三批笔试题里经常出现长叙述的字符串模拟题这类题算法本身不难但输入输出的格式细节多。比如有一道题要求处理“笔记话题标签”的解析输入是带#分隔的字符串要求提取出符合特定规则的话题词并按字典序排序去重输出。考察的无非是字符串分割、排序、去重但很多人栽在“话题词可以包含字母数字和下划线但首字符不能是数字”这种规则上。遇到这类题第一件事不是写代码而是把规则逐条列在草稿纸上标出每个规则对应的输入样例。写的时候用一个单独的布尔函数去判断“合法话题词”不要把所有逻辑堆在主流程里这样既好调试又不容易漏规则。输出格式上要注意题目要求的是按字典序还是按原出现顺序以及去重是严格区分大小写还是不区分这些细节在样例里通常会埋坑。3. 选择题里的Android主战场从热词反推高频考点小红书笔试的选择题对Android考的相当细而且角度刁钻。结合我看到的考生回忆和我自身的技术积累我把出现过的、以及大概率会出现的考点分成几类每一类背后都有明显的小红书业务影子。3.1 AMS与Activity启动流程考的是“链路记忆”而非单点记忆Activity管理服务AMS相关的题在客户端笔试里出现频率极高小红书也不例外。但第三批的题目不再是简单问“Activity启动时系统会调用哪个方法”而是给出一条包含多个环节的链路让你选出顺序正确的一项或者故意在某一步插入一个无关选项考察你有没有把整个流程串起来。从startActivity到界面可见核心链路是startActivity通过Binder跨进程通知AMSAMS对Activity进行生命周期调度并维护任务栈然后通知应用进程创建Activity并回调onCreate、onStart、onResume。要特别注意的是onResume执行完后界面才真正可交互而onStart只是“可见但不可交互”。选择题非常容易在这里挖坑问你“哪个回调执行后Activity才可交互”答案是onResume而不是onStart。另外一个高频变体是启动模式。标准模式standard会多次实例化单顶模式singleTop只要栈顶是同一个实例就复用单任务模式singleTask会在目标任务栈里查找并清除其上的Activity单实例模式singleInstance则整个系统只有一个实例且独占一个任务栈。小红书偏爱考singleTask和singleInstance的区别尤其结合“从通知栏点击跳转到一个页面希望栈里只有一个该页面实例”这种业务场景来出题。3.2 消息循环与Handler机制为什么主线程不能做耗时操作很多客户端笔试题绕着Handler转是意料之中的小红书的题也不例外。比较常见的是问你“在主线程中执行Thread.sleep(5000)会发生什么”又或者“handler.postDelayed的精准度如何”。这些题表面考Handler实际考你有没有真正理解消息循环的机制。主线程从Looper.loop()进入无限循环从消息队列取消息并分发处理。如果你在某个消息的处理函数里执行了耗时操作这个循环就被卡住了后续的UI刷新、触摸事件、四大组件回调全都排队等着。postDelayed的“延迟”也不是精确的定时任务它只是把消息按时间戳插入队列如果队列前面有耗时消息实际执行时间会延后。选择题里要区分“延迟时间从调用时刻起算”这个描述严格来说postDelayed是按它被插入队列的时间起算的而不是实际入队时间这个细节容易被忽略。还有个连环坑是Looper和Handler的绑定关系。子线程里默认没有Looper如果直接new Handler()会抛异常必须先Looper.prepare()再Looper.loop()。笔试题偶尔会把“在子线程中创建Handler是否必须调用prepare”作为判断题答案是必须除非用HandlerThread它内部已经封装好了这一步。3.3 自定义View与触摸事件分发小红书业务的重中之重小红书App的核心就是信息的上下滑动浏览自定义View和触摸事件分发的考察权重极高。选择题常考dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent三个方法的调用顺序以及requestDisallowInterceptTouchEvent的作用。标准的事件分发顺序是Activity.dispatchTouchEvent到ViewGroup.dispatchTouchEvent再依次尝试每个子View的dispatchTouchEvent如果子View的onTouchEvent返回true事件就由子View消费如果子View都不消费则父View的onTouchEvent处理最后回到Activity。requestDisallowInterceptTouchEvent(true)的作用是禁止父View拦截后续事件典型场景是内层水平滑动的列表嵌套在垂直滑动的列表里内层不想让外层抢走滑动。从这个角度看真题第三批考过一道“列表中嵌套横向滑动条目水平滑动容易误触变成垂直滑动”的题问你怎么解决答题思路就是三层触摸事件分发的消费优先逻辑、requestDisallowInterceptTouchEvent的使用、以及滑动角度差值的阈值判断。3.4 图片加载与内存优化把“小红书为什么不卡”当成一道题拆解图片加载是小红书笔记流的核心所以笔试里出现相关题目很自然。选择题角度比较多的包括Bitmap的内存计算、inSampleSize采样压缩、LruCache缓存淘汰策略、Glide的四级缓存流程。Bitmap内存计算是最经典的一题一张宽width像素、高height像素的图片采用ARGB_8888格式每个像素占4字节内存占用就是width * height * 4字节。如果你把一张1920 * 1080的图片加载进内存不开任何压缩大概需要1920 * 1080 * 4 8294400字节约7.9MB。对一个Feed流来说滑几屏就上GB了所以必须用inSampleSize做采样用RGB_565每个像素2字节节省内存或者用复用与缓存减少重复分配。Glide的四级缓存顺序是活动资源ActiveResources、内存缓存LruCache、磁盘缓存DiskLruCache、网络/来源。选择题爱考的是“第一次加载一张网络图片缓存读取顺序是什么”答案是先查活动资源、再查内存缓存、再查磁盘缓存都没有才走网络。还有个容易错的点是内存缓存的键由图片URL、宽高、变换等组合而成不同尺寸的同URL图片不是同一个键。3.5 布局优化与渲染性能RecyclerView是永远的神小红书笔试第三批有一道让我印象很深的题给定一个列表页滑动掉帧的场景让你选出有效的优化手段并排除掉无效手段。选项包括setItemViewCacheSize、setHasFixedSize(true)、setDrawingCacheEnabled(true)、asyncLayoutInflater等。setHasFixedSize(true)的作用是告诉RecyclerView Item的尺寸固定可以跳过某些测量步骤但如果Item高度会变化开了这个反而会导致显示异常。setItemViewCacheSize是设置额外的ViewHolder缓存数量对快速滑动时减少重复绑定有一定帮助但治标不治本。setDrawingCacheEnabled在大部分场景已经被官方不建议使用开错了反而增加内存占用。真正有效的优化还包括布局扁平化用ConstraintLayout减少层级、ViewHolder里减少不必要的findViewById用ViewBinding、图片加载做尺寸匹配和裁剪、预加载下一页数据。选择题的坑通常在于“看似相关实则无用”的选项比如hardwareAccelerated设置——这个选项本身能加速渲染但如果你问的是“列表滑动掉帧”它远不如减少布局层级来得直接。4. 隐藏的进阶考点从搜索热词里挖技术风向我整理这次笔试相关的搜索热词时发现几个很有意思的高频词——android studio hedgehog、AGP 8、R8、APEX、OpenOCD、OTA、动态图标主题。这些词放在一起能明显看出2023年秋季Android技术栈的关注点而这恰好也是笔试选择题的“元考点”。4.1 AGP与R8构建工具链的版本兼容性2023年Android Studio已更新到Hedgehog版本2023.1.1内部默认的Gradle插件AGP版本到了8.x。很多人问“Hedgehog是否支持AGP 8”实际上是反了——Hedgehog本身就包含对AGP 8.x的支持但在老项目上升级AGP 8会有很多兼容性坑比如compileSdk最低要求、JDK版本要求、namespace配置要求。笔试考构建工具的题目不会让你写gradle脚本但会在选择题里问你“R8的作用是什么”。R8是ProGuard的替代品负责代码压缩、资源压缩、混淆和优化。和ProGuard相比R8在压缩率和编译速度上都有提升。容易考到的点是开启R8后哪些代码会被移除不可达代码、哪些要保留通过keep规则显式声明的类和方法、为什么反射调用需要keep因为R8无法静态分析反射目标不加规则会被混淆或移除。这块想速成的话建议把AGP 8的变更日志过一遍重点记住几条默认使用namespace、BuildConfig默认关闭、JDK 17为编译默认版本。笔试不会出太深但知道这些能帮你排除不少干扰项。4.2 ABI与动态模块Android动态图标和APEX背后的系统分区逻辑搜索热词里“android动态图标主题”和“android apex”这两个词值得展开说。动态图标是Android 13开始支持的主题化图标能力——系统根据壁纸颜色动态调整应用图标的色调和背景。这类题目看似是系统功能题实际上考的是你对Monochrome图标、AdaptiveIconDrawable的理解。选择题大概率会问“实现动态图标需要提供哪几种图层”答案是前景层foreground、背景层background以及单色层monochrome缺一不可。APEX则是一个相对冷门但2023年多次被提及的概念。它是Android引入的一种可更新的系统组件包格式用于让某些系统组件通过OTA更新而不需要完整刷机。选择题如果考APEX一般问的是它的特点可以独立更新、具有版本控制、更新失败可以回滚。这些选项属于“多选一眼就能看出正确描述”的送分题前提是你知道APEX和普通APK的差异——APEX是一个APK容器但更新优先级更高且支持启动时激活。4.3 OpenOCD与蓝牙调试嵌入式调试与车载Android的交叉点搜索热词里“android openocd”和“android 车载”放在一起看说明2023年下半年行业对Android Automotive和底层调试的关注度明显上升。OpenOCD本身是嵌入式开发常用的片上调试工具用于通过JTAG/SWD接口对芯片进行调试。在Android场景里它主要面向开发板、车机、IoT设备的底层调试。笔试不太可能直接考OpenOCD的具体命令除非你是做大屏或车机专项但它背后考察的是调试思维当你需要调试一个系统服务或Native层问题时如何定位问题边界。如果选择题里出现“如何调试系统Server进程的问题”候选答案可能有adb logcat、dumpsys、OpenOCD连接JTAG、gdb attach。正确的思路是先通过dumpsys和logcat定位到具体模块再决定是否需要底层调试工具介入而不是一开始就上OpenOCD。车载方向更值得关注的是蓝牙相关的题目因为车载系统里蓝牙电话、蓝牙音频是核心功能。Android蓝牙协议栈在2023年前后经历了从BlueZ到Bluedroid的全面切换选择题可能涉及蓝牙权限BLUETOOTH_CONNECT、BLUETOOTH_SCAN、BLE广播与扫描的区别、经典蓝牙与BLE的通信模型差异。这块对非车机方向的人来说属于“复习了就能拿分不复习就瞎蒙”的性价比区间建议考前用半天把蓝牙基础概念过一遍。4.4 内容URI与FileProvider跨应用文件共享的历史包袱热词里一堆content://长串是搜索时自动带出来的URI示例。Android 7.0开始强制要求应用间共享文件使用content://协议禁止直接传file://路径否则抛FileProviderException。小红书作为典型的图片密集型应用笔试考这个概率不小。FileProvider的原理是通过AndroidManifest里配置provider节点定义file_paths映射把内部路径映射成可外传的content://URI。不同App的authority不一样所以你会看到各种com.baidu.searchbox.fileprovider、com.ss.android.uri.key之类的长串。选择题考的是跨应用传递图片路径时为什么用content://而不是file://答案核心是file://暴露了真实路径且缺乏权限控制content://则通过URI授权grantUriPermission临时授予对方读写权限更安全。另一个相关考点是ExternalStorage和分区存储。Android 10API 29开始强制分区存储应用访问公共目录需要申请权限且只能访问自己创建的文件Android 11进一步放开MANAGE_EXTERNAL_STORAGE权限但需特殊声明。这类题目比较容易出现在多选题里判断哪个操作在分区存储下是被允许的。记住一个原则分区存储下应用可以无权限读自己App专属目录下的文件访问公共媒体文件图片、音频、视频需要读取权限访问其他应用的专属目录则被禁止——除非用户通过系统文件选择器主动授权。5. Android方向的备考侧重点哪些分能拿、哪些分不要强求在线笔试的备考策略和面对面面试完全不同面试可以靠表达和思路加分笔试只看最终结果。尤其是选择题你没有任何解释机会对就是对、错就是错。所以这场笔试的备考策略应该是“扬长避短、稳拿基础分”。5.1 复习优先级排序先框架、后细节、再冷门选择题复习的优先级我建议按以下顺序排四大组件与启动模式这是必考基础题把onCreate/onStart/onResume/onPause/onStop/onDestroy的调用时机和栈内变化梳理清楚再背熟四种启动模式的区别就能应对八成相关题。消息循环与线程Handler、Looper、MessageQueue的关系主线程和子线程的数据更新边界runOnUiThread与Handler.post的异同。这块属于“理解了不会错、不理解靠背很难背完”的考点。RecyclerView与列表优化ViewHolder复用、区别notifyDataSetChanged和notifyItemChanged、LayoutManager的预取机制。小红书是做Feed流的列表相关题目几乎必出。图片加载与内存管理Bitmap内存计算、缓存策略、OOM的常见触发场景和规避方案。网络与数据解析HTTP/HTTPS、OkHttp拦截器、Retrofit注解、JSON解析的性能问题。这些是客户端开发的基本功笔试会偶尔穿插。冷门拓展如上文提到的APEX、OpenOCD、主题化图标复习不在多知道核心概念即可。5.2 多选题的答题策略宁缺毋滥还是放手一搏在线笔试的多选题是最容易丢分的题型。小红书的多选题一般是“每题有几个正确选项全部选对才得分少选、多选、错选都不得分”。在这种规则下我的策略是“只选确定正确的选项”不确定的坚决不选。因为多选一个错误项整题分数归零少选一个正确项同样是零分。与其赌一个不确定的选项不如保守一点把确定的分拿稳。举个例子考“下列哪些操作可能导致OOM”这类题时加载超大Bitmap、在循环中创建大量短生命周期对象并持引用、使用Handler持有Activity引用导致泄漏这三项你确定是对的就选三项。如果第四个选项“在onDraw里new一个Paint对象”你不太确定那就不选——虽然它实际也可能导致内存抖动但笔试的“可选可不选”边界模糊落袋为安更重要。5.3 编程题的代码规范判题机为什么对你的代码零容忍笔试编程题用的是在线判题系统它不会看你的代码风格但会对格式和边界有极其严格的约束。我复盘过不少“明明逻辑对但就是没AC”的案例常见原因有多行尾输入处理错误牛客这类平台常常需要你从System.in循环读取到文件末尾很多人只读了一次nextLine就以为输入结束了导致少处理一组数据。边界指数组下标越界比如处理循环数组时i % n的写法在n 0时会抛异常而输入限制里可能没说n不会为0。输出格式多一个空格或换行有些题目要求每行末尾不能有尾随空格判题机会严格比对。这个最冤但出现频率不低。数据范围超int有些题目的数据范围看起来不大但中间计算结果会溢出int要用long。比如动态规划里累加点赞数时n到10万时就可能超int上限。长期养成的习惯是把“数据范围读取-边界判断-输入输出格式”这三个环节当成编程题的一部分来对待而不是写完核心逻辑就交卷。笔试的时候宁可留出五分钟检查这些细节也不要赶着提交然后看着“通过率0%”怀疑人生。6. 实战复盘一份典型的小红书第三批笔试时间分配方案很多考生倒不是在知识点上落败而是败在时间分配上。第三批笔试的代码题通常放在最后但选择题前面的确容易卡太久导致编程题只剩十几分钟。我给学弟学妹定的时间分配方案是这样的总时长120分钟题量22道其中选择题17道、编程题2道另有几道填空/简答。前60分钟做选择和填空每道选择题最长不超过3分钟超过就标记跳过。填空题如果遇到不会的果断放弃填一个最可能的答案不要恋战。中间30分钟做第一道编程题第一道通常比第二道简单务必做出来并AC这是全卷的保底分。最后30分钟做第二道编程题如果15分钟内没有完整思路立刻退回暴力解法拿部分分。笔试平台一般按测试样例给分暴力解法只要能通过部分样例就比空着强。剩余时间检查优先检查输入输出格式、边界条件再回头看不确定的选择题但要克制改答案的冲动除非找到明确错误。这个方案有一个前提你对Android基础知识足够熟。如果选择题十几道全都在“犹豫”这个时间分配是撑不住的。所以考前最后一周我建议拿牛客上的小红书历年真题第一批和第二批回忆版做一次限时模拟感受一下真实节奏。7. 一些值得额外聊的细节题型之外的信息差最后这部分我想说一点不一定直接考、但对整场笔试有隐形帮助的内容。7.1 善用编辑器里的代码片段模版笔试平台的在线编辑器不像IDE那么好用没有自动补全、没有自动导包、没有“整理代码”的快捷键。所以平时刷题的时候建议把常用的模板写到本地笔记里考前过一遍快速IO模板BufferedReaderStringTokenizer而不是直接用Scanner。笔试数据量大的时候Scanner会慢得怀疑人生。常用数据结构的手写模板并查集、前缀和、树状数组、堆的调整。虽然笔试不强制你手写但万一平台不让你引入某些工具类手写模板能救命。调试输出模板用System.err.println打印中间结果而不影响答案输出这是在线笔试环境里一个非常实用的技巧。7.2 留意笔试邀请邮件里的“注意事项”很多人把笔试邀请邮件当成普通通知扫一眼就过去了但这封邮件里往往藏着关键信息是否开摄像头、是否允许切屏、是否可以用本地IDE、是否支持Java/Kotlin/C多语言。小红书第三批笔试明确要求开摄像头和防切屏如果考试中途切出考试页面会被系统记录甚至直接判违规。有些人习惯本地写代码再粘贴到网页在防切屏模式下这个操作要格外小心提前弄清规则再决定是否使用这种方式。另外如果用本地IDE务必确认你本地的语言版本和平台一致。比如平台用Java 8你本地用的是Java 17某些API在Java 8里不存在提交后编译就直接挂了。笔试前配好一个“最保守、最兼容”的本地环境反而比追求新版特性更稳。7.3 简历方向与笔试的联动我后来复盘学弟拿到面试的历程发现一个容易被忽略的点笔试成绩不是孤立的它会和你的简历方向联动。小红书Android岗的笔试考察风格是“基础扎实 业务敏感”如果你简历上写了做过列表优化、图片加载、性能优化相关的项目笔试里对应的题目通常就是你展示优势的地方。所以笔试前重新读一遍自己的简历把与技术栈相关的项目输出整理成几句话用了什么方案、解决了什么问题、达到什么量化结果。虽然笔试不考自我介绍但这个梳理过程能帮你在面对“下列哪些方案可以提升列表滑动流畅度”这样的题目时瞬间从自己的实践经验里找到答案而不是靠猜。7.4 心态管理第三批是机会不是“剩余批次”很多考生默认第三批是“别人挑剩下的时间点”觉得不如前两批光鲜。实际上秋招笔试分批是招聘流程的设计不代表第三批的岗位饱和度低。第三批笔试往往在九月底十月初这个时间点有一部分前期拿到意向书的候选人会释放名额岗位总量未必少再加上第三批笔试的题目重复率低、区分度高一份扎实的笔试成绩更容易让面试官眼前一亮。我带的学弟就是第三批笔试通过后拿到面试机会的他后来跟我说笔试成绩在面试官沟通时被主动提起过——“笔试表现不错尤其是代码题写得干净”。这说明笔试不只是敲门砖它会在后续面试里持续赋能。所以如果你正好分到了第三批不要有“是不是没坑了”的焦虑把精力全部放在“用这份卷子证明自己的技术深度”上反而更能发挥出真实水平。祝准备秋招笔试的各位都能稳定发挥把该拿的分都装进兜里。