2025年秋招我完整走了一遍联想移动端方向的笔试流程从投递到收到笔试通知再到考完复盘整个过程比想象中更“卷”也更“细”。今天把整个笔试的题型结构、考点分布、答题思路和踩坑经验整理出来给后面准备移动端方向校招的朋友一个参考。这篇内容既包括客观题和编程题的分析也会把我在准备期间搜索过的高频问题比如移动端性能优化、vConsole调试、ECharts在移动端的tooltip显示、跨端框架选型这些串起来讲帮你看清楚联想这类大厂移动端笔试到底在考什么以及应该怎么准备。如果你是准备秋招的应届生或者工作1-2年想跳槽到移动端方向这篇文章都值得花半小时细读。笔试题目不会每年一成不变但考点方向、考察思路和答题框架是相对稳定的掌握这些比刷一堆题更值钱。1. 笔试整体结构与考点分布1.1 题型构成与时间分配联想移动端类岗位的笔试整体分成三大部分客观选择题、编程题、主观问答题。三个部分在同一次在线笔试中完成总时长通常在90到120分钟之间不同批次会有差异。我参加的这场是120分钟题量不算少时间压力主要集中在前面的选择题和后面的编程题上。客观选择题约占40%覆盖计算机基础数据结构、操作系统、网络、移动端专业知识和少量逻辑推理题。这部分看起来简单实际挖坑很多尤其是移动端相关的选择题会考一些平时开发中不太注意的细节比如Android的启动模式、iOS的RunLoop机制、H5页面在WebView中的渲染差异等。编程题一般有2道难度分布是中等到偏难。我遇到的题目一道是纯算法题类似LeetCode中等偏上的数组动态规划另一道是结合移动端场景的模拟题设计一个简化版的双端队列要求考虑并发或内存约束。编程题支持的语言比较全Java、Kotlin、C、Python、JavaScript都可以但注意部分题目会限制语言灵活性建议提前看清要求。主观问答题占比不高但很关键。题目通常是给你一个具体的移动端业务场景让你描述技术方案或优化思路。比如我遇到的一道题是“一个电商App首页在低端Android机型上首屏加载超过5秒请分析可能原因并给出优化方案。”这种题目没有标准答案考察的是你的知识广度和工程思维。1.2 移动端岗位笔试的底层逻辑很多人备考时容易陷入“刷题越多越好”的误区但大厂笔试真正想筛选的其实是三类能力基础扎实度、工程落地能力、学习深度。基础扎实度靠选择题和第一道编程题检验这部分是“硬门槛”数据结构、网络、操作系统的基本功不过关后面再强也白搭。工程落地能力靠第二道编程题和主观题检验考察你能否把理论知识应用到真实场景中。学习深度最直接体现在主观题里同样一个性能优化问题有人只能答出“图片压缩、懒加载”这种三板斧有人能从指标采集、瓶颈定位、优化手段、收益评估完整展开差距一下就拉开了。从我自己的备考经验来看在准备联想这类大厂的移动端笔试时建议按照“基础 项目 场景题”三条线并行复习不要只盯着算法题。算法题决定你的下限但没有场景题的深度思考很难在众多候选人中脱颖而出。2. 移动端核心基础与性能优化考点深挖2.1 渲染机制与首屏优化思路移动端笔试中渲染机制是出现频率极高的考点同时也是主观题的最佳素材。我在备考时把“从URL输入到页面展示”这条链路完整梳理了一遍笔试时帮了大忙。以Android端加载一个H5页面为例完整链路是DNS解析 - TCP连接 - TLS握手 - 发送HTTP请求 - 服务器响应 - 浏览器/WebView接收HTML - 解析HTML构建DOM树 - 解析CSS构建CSSOM - 执行JavaScript - 构建渲染树 - 布局 - 绘制 - 合成。每一个环节都可能成为性能瓶颈。我在笔试主观题里用的答题框架是“先定位再优化”。不要一上来就写“压缩图片、开启缓存”这种零散方案而是先说明如何定位问题用Chrome DevTools的Performance面板记录页面加载过程或者用Lighthouse跑一次性能评分看FCPFirst Contentful Paint、LCPLargest Contentful Paint、TTITime to Interactive各项指标到底差在哪里。定位之后再分阶段给方案我列个表格方便你理解阶段常见问题优化方案网络请求DNS解析慢、TCP握手慢、请求串行DNS预解析、HTTP/2多路复用、资源CDN化资源加载HTML阻塞渲染、JS阻塞解析、图片体积大内联关键CSS、script加defer/async、图片WebP化页面渲染重复布局、强制同步布局、长列表卡顿减少DOM层级、批量DOM操作、虚拟列表用户感知白屏时间过长、loading体验差骨架屏、首屏接口前置、关键资源预加载实际上首屏优化的核心矛盾是“资源体积”和“渲染速度”的平衡。我在答题时特意强调了一个容易被忽略的点真正影响首屏体验的往往不是页面总量而是关键渲染路径上的资源量。你的页面可能总共有4MB资源但只要首屏真正依赖的只有500KB优化这500KB比优化剩下的3.5MB更有意义。移动端性能优化大概率会出现在主观题里建议准备一个自己熟悉的项目案例作为素材从指标采集到优化落地再到效果数据形成闭环答题时直接套用。2.2 内存管理与卡顿治理性能优化的另一个高频考点是内存和卡顿治理尤其针对Android和iOS平台。选择题里可能出现“内存泄漏的常见原因”“如何检测卡顿”“GC机制”等知识点主观题里则可能让你分析某个页面滑动卡顿的原因。先说内存泄漏。Android里最常见的是Activity泄漏例如Handler持有Activity引用、单例持有Context、匿名内部类持有外部类引用等。笔试中如果让你列举内存泄漏场景建议从“静态引用、非静态内部类、Handler、资源未关闭”四个角度回答。如果能够补充一句“用LeakCanary做自动化检测用Memory Profiler分析堆转储文件”会让答案更有落地感。卡顿治理的核心指标是帧率但又不能只看帧率。现代性能优化框架更关注“掉帧”和“慢函数”。笔试中遇到卡顿问题我的答题思路是首先用Systrace或PerfDog抓trace找到卡顿发生时主线程在执行什么任务如果是Layout任务检查是不是布局层级过深如果是Java方法执行时间过长老检查是否在UI线程做了IO操作如果是频繁GC检查是否在循环中创建了大量对象。我在真实项目中遇到过一个问题长列表滑动时频繁触发GC原因是列表项的图片控件在每次bind时都重新创建了Bitmap。解决方式很简单改为复用Bitmap或在缓存中加载但这类问题在笔试里经常会变形为“ListView/RecyclerView的优化方案”所以底层原理一定要吃透。关于帧率你还需要理解一个概念Android的垂直同步机制VSYNC也就是系统以16.6ms为周期发出绘制信号如果一帧的渲染时间超过16.6ms就会掉帧。笔试中可能会问你“为什么帧率低于60fps就会感觉卡顿”这时你就可以从VSYNC和人的视觉暂留特性来解释。2.3 性能指标与监控方案联想这类大厂的笔试主观题非常看重“量化思维”。答性能优化题时如果你能说出具体的指标名称、采集方式、监控方案会明显提升答案的含金量。我整理了几个移动端性能场景的关键指标启动耗时冷启动和热启动分别统计冷启动指进程从创建到首页可交互一般以onFirstFrame和onIdle为节点。卡顿率统计单位时间内掉帧次数或主线程阻塞超过阈值比如100ms的次数。内存峰值通过Debug.getMemoryInfo或Instruments采样关注PSS和Java Heap两个值。网络请求耗时分DNS、连接、请求、响应四个阶段统计。页面渲染耗时从数据回包到首帧渲染完成的时间。在监控方案上Android开发可以用Matrix做APM框架iOS可以用自研的AOP方案或接入Firebase Performance。H5页面则可以用PerformanceObserver sendBeacon上报关键指标。笔试中即使不要求你写出完整监控代码能提到这些方案也说明你有实战经验而不只是背概念。这里我给你一个可以参考的简版H5性能上报代码笔试或项目里都能用// 页面加载完成后收集关键性能指标并上报 window.addEventListener(load, () { // 优先使用PerformanceObserver监听LCP if (PerformanceObserver in window) { const observer new PerformanceObserver((list) { const entries list.getEntries(); const lcpEntry entries[entries.length - 1]; report({ type: lcp, value: lcpEntry.startTime }); }); observer.observe({ entryTypes: [largest-contentful-paint] }); } // 采集navigation timing数据 const nav performance.getEntriesByType(navigation)[0]; const data { dns: nav.domainLookupEnd - nav.domainLookupStart, tcp: nav.connectEnd - nav.connectStart, request: nav.responseStart - nav.requestStart, dom: nav.domContentLoadedEventEnd - nav.navigationStart }; report(data); }); function report(data) { // 用sendBeacon保证页面关闭时也能发送 navigator.sendBeacon navigator.sendBeacon(/api/perf, JSON.stringify(data)); }笔试中如果没时间写代码你只需要把核心思路讲清楚先用Performance API采集再用sendBeacon或fetch上报最后在监控平台上聚合展示。链路完整比某个细节完美更重要。3. 框架与工程化考点技术选型、调试与数据可视化3.1 移动端Vue开发框架怎么选联想的移动端笔试虽然没有直接问“请推荐一个移动端Vue框架”但主观题和选择题里会渗透技术选型的思路。比如给你一个业务场景问你选择跨端方案还是原生方案或者问某两种框架的对比。这里我把最常被问到的移动端Vue相关框架整理一下备考时可以当速查表用框架类型核心特点适用场景VantVue组件库轻量、组件全、按需引入、适合H5移动端Web页面、商城活动页NutUIVue组件库京东出品、组件风格统一、对业务组件覆盖好电商类H5、中立业务uni-app跨端框架Vue语法、一套代码编译到多个平台小程序H5App多端覆盖Taro跨端框架React/Vue语法都支持、对小程序生态适配好小程序为主、兼顾H5Capacitor混合容器基于WebView原生化、JS调用原生能力快速把Web应用打包成App笔试里如果问“移动端Vue框架怎么选”不要只说“Vant好用”这种主观结论。我的建议是围绕三个维度展开业务形态是纯H5还是需要跨端、团队技术栈团队擅长Vue2还是Vue3、包体体积和性能要求是否对首包有严格限制。我在项目里实际用过的方案是H5业务页用Vant Vue 3小程序端用Taro Vue 3原生App内嵌的WebView页面用Vite Vant。三个场景分开管理避免用一个重型框架去覆盖所有诉求。笔试中如果你能这样结合场景讲选型逻辑会比单纯背框架特性拿到的分高。另外要特别复习一下Vue 3相对于Vue 2的关键变化比如Composition API、Teleport、Fragment、createRenderer、响应式系统的Proxy实现。选择题里可能直接考“以下哪个是Vue 3的新特性”或者“Proxy相比Object.defineProperty的优势”这些都属于基础送分题但很多人因为平时写业务不关注底层反而容易丢分。3.2 移动端调试工具链vConsole嵌入与使用调试工具是移动端开发的日常刚需笔试里不是直接考你“vConsole怎么用”而是可能会在描述一个场景时让你给出调试方案。另外面试环节大概率会追问题“你在移动端开发时怎么调试真机页面”浏览器端调试有DevTools但到了手机上的H5页面尤其是微信内置浏览器或App内WebView外部调试工具往往连不上。vConsole就是一个轻量的移动端调试面板让你直接在页面上看到日志、网络请求、Cookie和LocalStorage信息。在笔试中如果要答“移动端调试方案”我建议按以下顺序组织如果页面运行在Android的Chrome中优先使用Chrome DevTools远程调试通过USB连接电脑在chrome://inspect里查看页面。如果是App内置WebView需要在原生端开启WebView的调试开关Android的WebView.setWebContentsDebuggingEnabled(true)iOS在Safari开发菜单里选模拟器或真机。如果以上方案都受限比如直接在微信里调试H5建议在页面中嵌入vConsole。vConsole的嵌入方式很简单我习惯通过CDN引入的方式在测试环境动态加载。下面是一个可以在移动端浏览器任意页面插入使用vConsole的示例// 只会在非生产环境自动加载vConsole并等DOM加载完成后再插入 (function () { const isProd window.location.hostname production.example.com; if (isProd) return; // 兼容已存在vConsole的情况避免重复引入 if (window.vConsole) return; function loadScript(src, cb) { const script document.createElement(script); script.src src; script.onload cb; document.head.appendChild(script); } function initVConsole() { const vConsole new window.VConsole(); // 可以通过面板切换插件或者直接打印日志 console.log(vConsole 已加载可以在页面上查看网络请求和日志); } if (document.readyState complete) { loadScript(https://cdn.jsdelivr.net/npm/vconsolelatest/dist/vconsole.min.js, initVConsole); } else { window.addEventListener(load, function () { loadScript(https://cdn.jsdelivr.net/npm/vconsolelatest/dist/vconsole.min.js, initVConsole); }); } })();注意这个脚本的关键点等页面load事件触发后再加载vConsole避免阻塞首屏渲染同时判断生产环境再跳过加载。笔试中如果让你设计一个调试方案能考虑到“调试工具不能影响线上性能”这点就是加分项。有一种常见的场景是你没法控制页面代码但需要在别人的线上页面里调试信息如何处理。这时候可以在浏览器地址栏执行一个自执行的JavaScript脚本去动态插入vConsole或者通过书签的方式在需要的时候运行。我自己实测下来在移动端浏览器的地址栏直接输入javascript:协议开头的代码块部分浏览器会拦截所以更稳妥的方案是用一个本地的代理工具比如Charles或Whistle对目标页面注入脚本。笔试中如果问到这种场景你提到用抓包工具做脚本注入面试官会觉得很经验丰富。3.3 ECharts在移动端的实践细节tooltip显示时机问题数据可视化在移动端笔试里很少作为大题出现但选择题和问答题偶尔会涉及。我在准备期间搜过一个问题“ECharts折线图在移动端怎么让它渲染完成后显示最后一个点的tooltip”。这个问题虽然很具体但背后考察的是你对ECharts生命周期和事件系统的理解。先说原理ECharts的tooltip可以通过dispatchAction主动触发核心API是chart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: lastIndex })。但要注意必须在图表渲染完成后执行否则图表实例还没readydispatchAction会无效。网上很多答案会告诉你直接调用setOption后立刻dispatchAction但实际在移动端图表的渲染是异步的直接调用可能会踩坑。推荐的做法是监听finished事件这是ECharts 5.x提供的渲染完成事件const chart echarts.init(document.getElementById(chart)); const option { xAxis: { type: category, data: [周一, 周二, 周三, 周四, 周五, 周六, 周日] }, yAxis: { type: value }, series: [ { type: line, data: [120, 200, 150, 80, 170, 110, 230], symbol: circle, symbolSize: 8 } ], tooltip: { trigger: axis } }; chart.setOption(option); // 监听渲染finished事件保证绘图完成 chart.on(finished, function () { const lastIndex option.xAxis.data.length - 1; chart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: lastIndex }); });试卷里如果出现这类题目除了代码正确还要注意两点第一showTip的dataIndex是x轴数据对应的索引不是鼠标坐标。如果你用x或y属性控制位置在移动端反而容易定位不准因为tooltip默认会跟随坐标。第二移动端屏幕窄折线图数据密集时最后一个点的tooltip可能被屏幕边缘裁剪。更好的做法是给tooltip配置confine: true让tooltip在图表容器内自动调整位置tooltip: { trigger: axis, confine: true, backgroundColor: rgba(0,0,0,0.7), textStyle: { color: #fff } }笔试或实际项目中遇到“图表显示不出来”“tooltip不出现”这类问题用得上的一套排查思路是先确认ECharts版本再确认容器是否有宽度移动端常见问题容器display为none时初始化的图表宽度为0然后检查是否有报错信息最后再考虑事件触发时机。多数情况下问题都出在容器宽度或初始化时机上而不是ECharts本身。4. 跨端与浏览器能力考点从WebView到移动端API4.1 WebView容器与移动端API设计思路移动端笔试的隐藏考察点是“你对移动端运行环境的理解有多深”。这里的运行环境不光是系统层面还包括页面实际运行的宿主容器比如Android WebView、iOS WKWebView、小程序容器、浏览器App等。我搜过“夸克移动端API”这组热词。夸克作为一个移动端浏览器提供了一些Web API能力比如渲染、下载、语音播报等扩展能力。虽然笔试不会直接考“夸克的API有哪些”但这类浏览器自带能力背后的设计思路是移动端开发者应该理解的浏览器本质是提供Web能力的宿主环境它既受限于标准Web API又可以扩展自己的私有API。笔试题目如果问“移动端Web页面调用系统能力”你应该想到几个方向通过URL Scheme唤起原生App例如appname://openpage?paramsxxx。通过标准Web API调用设备能力例如navigator.vibrate振动、navigator.geolocation定位、navigator.mediaDevices摄像头。通过JS Bridge调用宿主App原生方法这是App内置WebView最常用的方式核心是注册一个native方法供JS调用并定义好回调协议。在浏览器App中可能通过其私有API如夸克的分屏、云加速做能力增强。以JS Bridge为例我在项目里常用的一种简单实现是用window.postMessage或prompt实现双向通信笔试中如果让你设计一个JS Bridge的通信协议可以从下面三方面展开JS侧如何调用原生注入全局方法或拦截URL Scheme、原生如何回调JSevaluateJavascript或postMessage、参数传递和错误处理怎么设计。一个安全的JS Bridge必须考虑白名单校验、参数类型校验、超时处理。这些细节是面试官区分候选人的关键只答出“JS调用原生方法”是及格线能答出“安全性设计和异常处理”才是加分项。4.2 Python在移动端工具链中的角色看到“Python移动端GUI”这个热词时我第一反应是很多人在备考时把精力放偏了。笔试考Python大概率是在算法编程题里考而不是让你做移动端GUI。Python本身不是移动端主流开发语言但在移动端开发流程中Python经常作为自动化脚本、数据采集、接口Mock、性能分析工具存在。笔试编程题如果允许用Python我推荐用它解决算法题因为代码量少、快。不过有几个细节要注意实测联想的在线OJ对Python的版本一般是3.x支持标准库但第三方库比如numpy不一定可用。做题时尽量避免用非标准库尤其是涉及数组、排序、动态规划的题目。如果你非要了解Python在移动端的可能应用场景这里给出几个我实际用过的接口Mock服务用Flask或FastAPI快速起一个本地接口服务模拟App的登录态、列表数据方便联调。自动化打包脚本用Python写脚本调用Gradle命令批量打包不同渠道包并自动上传到分发平台。性能数据采集用adb命令结合Python脚本自动化采集Android设备的CPU、内存、帧率数据。笔试结束后有一道编程题我用的就是Python题目大致是“给定一个数组找出所有和为target的三元组”这类题目用Python写非常快但要注意边界条件。我的经验是如果你Python更熟练编程题优先用Python但如果题目明确要求实现某个数据结构比如实现一个LRU缓存用Java或C会更符合出题人的预期。4.3 UI还原与设计协作Figma拨号弹出窗的还原要点Figma在移动端开发流程中的使用不是笔试的重点但2025年的移动端笔试趋势是考题越来越贴近真实工作流。我搜过“Figma移动端拨号弹出窗”这个热词如果有人考到UI还原类的题目大概率会涉及类似交互细节。先说Figma与前端协作的基本流程设计师在Figma中完成设计稿开发者在Figma的“开发者模式”Dev Mode中查看尺寸、标注、切图。关键的还原点包括基础尺寸换算Figma默认字体单位是px但移动端开发时要根据设计稿宽度做rem或rpx换算。通常统一以375px为基准宽度也就是iPhone SE的宽度。弹出窗样式拨号弹出窗这类组件需要注意蒙层透明度通常是rgba(0,0,0,0.5)、圆角值、底部按钮的高度一般不能低于48px方便手指点击。交互反馈弹出窗出现和消失的动画时长一般在200-300ms使用ease-out缓动函数不能让用户觉得生硬。边缘安全区域如果弹出窗底部有按钮要适配HOME线的安全区俗称“小黑条”需要给底部留出env(safe-area-inset-bottom)的空间。笔试中如果给出一个设计稿要求你描述实现方式可以从HTML结构、CSS样式、交互逻辑三个层面来答。比如拨号弹出窗的HTML结构包含蒙层、弹窗卡片、拨号盘、关闭按钮CSS样式需要实现居中定位、圆角、阴影交互逻辑需要处理点击蒙层关闭、输入号码格式化、拨号按钮回收等。我实际做一个拨号弹窗时比较简洁的实现是这样的div classoverlay idoverlay div classdialog div classtitle拨打电话/div div classphone-input input typetel idphoneInput placeholder请输入号码 / /div div classactions button classbtn cancel取消/button button classbtn confirm拨打/button /div /div /div.overlay { position: fixed; inset: 0; background: rgba(0, 0, 0, 0.5); display: flex; align-items: center; justify-content: center; z-index: 1000; } .dialog { width: 80%; background: #fff; border-radius: 16px; padding: 24px; box-shadow: 0 8px 30px rgba(0, 0, 0, 0.2); transform: translateY(20px); animation: slideUp 0.25s ease-out forwards; } keyframes slideUp { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } .actions { display: flex; justify-content: space-between; margin-top: 20px; } .btn { flex: 1; height: 48px; border: none; border-radius: 8px; font-size: 16px; } .btn.cancel { margin-right: 12px; background: #f2f3f5; } .btn.confirm { background: #1677ff; color: #fff; }注意弹出窗在移动端常见的一个坑是输入框唤起系统键盘时弹窗会被顶起或遮挡。解决方案是使用position: fixed配合visualViewport监听键盘高度或者直接把输入框放在弹窗可视区域的上半部分。如果你在笔试题目里能补充这个细节说明你真的做过移动端UI。5. 高频问题与答题策略5.1 常见问题速查与答题框架综合我和同期备考同学的反馈移动端笔试中反复出现的高频问题可以整理成一张速查表考点方向常见问法推荐答题框架页面渲染页面加载慢的原因和优化链路拆解 - 指标定位 - 分层优化 - 效果评估应用启动冷启动优化怎么做启动阶段拆分 - 找出耗时任务 - 异步/懒加载/预初始化卡顿优化列表滑动卡顿如何排查采集trace - 定位主线程耗时 - 针对性优化跨端方案如何选择跨端框架业务需求 - 团队能力 - 性能与包体权衡网络请求移动端弱网优化有哪些手段请求合并 - 缓存策略 - 弱网检测与降级内存管理如何检测和避免内存泄漏泄漏场景 - 检测工具 - 代码规范与审查页面兼容iOS和Android的H5差异事件差异 - 样式差异 - API差异 - 降级方案这里我要特别提醒一个容易被忽视的点答题时要注重“分层表达”。比如问你移动端性能优化方案你可以按“应用层、系统层、网络层”分层作答也可以用“更快的资源加载、更少的渲染耗时、更好的用户感知”这层逻辑来组织。分层表达的意义在于让你的答案看起来有体系而不是零散的经验堆砌。我在笔试中遇到的问答题实际上要求字数不多但你写的内容越多越容易被高分。不过要注意写得多不代表写流水账每一句话都应该有信息量。举例说明同样是答图片优化如果你只写“进行图片压缩”这句信息量为零如果你写“将PNG大图转为WebP格式同时根据设备DPR加载不同分辨率图片首屏图片体积降低了40%”这才是有价值的答案。5.2 时间分配与检查清单在线笔试的时间分配直接影响最终成绩。我自己的策略是分三轮作答第一轮10-15分钟快速浏览全卷标记选择题里的“不确定项”和编程题的难度判断。选择题不确定的先凭第一直觉选上不要纠结太久因为后续题目可能更值分。第二轮70-80分钟完成编程题和主观题。编程题优先做“看起来最像原题”的那道因为这类题你脑中已有成熟思路能做出来就赚到了。主观题至少留出15分钟保证每一道都写满。第三轮10-15分钟回头检查选中的不确定选择题并且重点复查编程题的边界条件。在线OJ最怕的不是算法错误而是数组越界、空指针、整数溢出这种低级失误。我根据自己的经验整理了一张笔试临场检查清单编程题是否能通过题目给出的示例用例边界输入空数组、单元素、最大数值是否特殊处理编程题的复杂度是否在题目限制内如果要求O(nlogn)我用O(n^2)的解法会不会超时主观题是否给出了具体的指标或数据避免只写“优化”不写“优化后提升了多少”。选择题是否相信第一直觉客观题频繁改答案往往得不偿失。是否留出了至少5分钟的缓冲时间应对意外情况断网、代码调试5.3 备考期间的高效复习路径最后分享一点备考思路。我准备联想移动端笔试大约用了三周每天有效学习时间2-3小时不算长但比较有针对性。第一周打基础刷数据结构与算法题重点关注数组、链表、树、动态规划、双指针这几类。移动端岗位的算法题难度一般不会到竞赛级LeetCode Hot 100加上剑指Offer已经足够。第二周补专业把Android/iOS/移动端H5的基础知识点过一遍重点看启动流程、生命周期、渲染机制、网络编程、存储方案。同时整理2-3个自己熟悉的项目案例包括背景、难点、方案、成效。第三周做模拟做往年的大厂移动端笔试真题模拟真实考试的时间限制。推荐用牛客网或赛码网练习因为联想笔试用的就是牛客网平台提前熟悉在线编程的输入输出方式和IDE体验很重要。我在准备期间把“B站移动端技术框架有哪些”这个热词也找出来研究了一下。B站移动端早期以原生开发为主后来在部分业务中引入了跨端方案、Flutter等技术同时其iOS和Android端都有一些自研的架构组件。笔试中如果考到“业界移动端实践案例”你可以拿B站、知乎、美团这些头部App的技术分享来佐证你的观点但要注意如果你对某个框架没有亲自用过就不要展开细节一句话带过就好否则容易被追问。另外关于前文搜到的“好用的移动端Vue开发框架”如果笔试或面试真的问到你不要只推荐某一家而是给出选择框架的判断标准。我的建议是优先选择社区活跃度高、类型定义完善、按需引入机制成熟的框架。Vant和NutUI在H5场景都很好用uni-app更适合需要同时覆盖小程序和H5的业务但如果你的项目只做App内嵌WebView没必要引入跨端框架Vite Vant Vue 3已经足够轻快。还有一个我踩过的坑说出来给各位提个醒笔试前一定要检查自己的电脑环境包括网络稳定性、浏览器兼容性、IDE的快捷键设置。我第一次参加某大厂笔试时因为IDE默认的自动保存延迟导致一段写了一半的代码在提交时被截断最后那道编程题没过。从那以后我每次在线笔试前都会先花5分钟在平台上跑一道“AB”这种最简单题目确认提交、判题、编译环境全部正常。最后再分享一个小技巧。笔试结束后不管感觉考得好不好尽量回忆整理一下题目和你的答案。大厂笔试通常不是一锤定音因为后续还有面试笔试中的场景题很可能会变成面试官追问的话题。如果你笔试时写的方案不够完善在面试前有足够时间重新审视这个题目给出更成熟的答案同样能扳回一城。我这次就是笔试结束后把主观题答案重新整理了一遍在后面的面试中又把这道题展开讲了一遍效果比笔试时临场发挥好得多。 2025联想移动端笔试全解析：题型考点与备战策略
2025年秋招我完整走了一遍联想移动端方向的笔试流程从投递到收到笔试通知再到考完复盘整个过程比想象中更“卷”也更“细”。今天把整个笔试的题型结构、考点分布、答题思路和踩坑经验整理出来给后面准备移动端方向校招的朋友一个参考。这篇内容既包括客观题和编程题的分析也会把我在准备期间搜索过的高频问题比如移动端性能优化、vConsole调试、ECharts在移动端的tooltip显示、跨端框架选型这些串起来讲帮你看清楚联想这类大厂移动端笔试到底在考什么以及应该怎么准备。如果你是准备秋招的应届生或者工作1-2年想跳槽到移动端方向这篇文章都值得花半小时细读。笔试题目不会每年一成不变但考点方向、考察思路和答题框架是相对稳定的掌握这些比刷一堆题更值钱。1. 笔试整体结构与考点分布1.1 题型构成与时间分配联想移动端类岗位的笔试整体分成三大部分客观选择题、编程题、主观问答题。三个部分在同一次在线笔试中完成总时长通常在90到120分钟之间不同批次会有差异。我参加的这场是120分钟题量不算少时间压力主要集中在前面的选择题和后面的编程题上。客观选择题约占40%覆盖计算机基础数据结构、操作系统、网络、移动端专业知识和少量逻辑推理题。这部分看起来简单实际挖坑很多尤其是移动端相关的选择题会考一些平时开发中不太注意的细节比如Android的启动模式、iOS的RunLoop机制、H5页面在WebView中的渲染差异等。编程题一般有2道难度分布是中等到偏难。我遇到的题目一道是纯算法题类似LeetCode中等偏上的数组动态规划另一道是结合移动端场景的模拟题设计一个简化版的双端队列要求考虑并发或内存约束。编程题支持的语言比较全Java、Kotlin、C、Python、JavaScript都可以但注意部分题目会限制语言灵活性建议提前看清要求。主观问答题占比不高但很关键。题目通常是给你一个具体的移动端业务场景让你描述技术方案或优化思路。比如我遇到的一道题是“一个电商App首页在低端Android机型上首屏加载超过5秒请分析可能原因并给出优化方案。”这种题目没有标准答案考察的是你的知识广度和工程思维。1.2 移动端岗位笔试的底层逻辑很多人备考时容易陷入“刷题越多越好”的误区但大厂笔试真正想筛选的其实是三类能力基础扎实度、工程落地能力、学习深度。基础扎实度靠选择题和第一道编程题检验这部分是“硬门槛”数据结构、网络、操作系统的基本功不过关后面再强也白搭。工程落地能力靠第二道编程题和主观题检验考察你能否把理论知识应用到真实场景中。学习深度最直接体现在主观题里同样一个性能优化问题有人只能答出“图片压缩、懒加载”这种三板斧有人能从指标采集、瓶颈定位、优化手段、收益评估完整展开差距一下就拉开了。从我自己的备考经验来看在准备联想这类大厂的移动端笔试时建议按照“基础 项目 场景题”三条线并行复习不要只盯着算法题。算法题决定你的下限但没有场景题的深度思考很难在众多候选人中脱颖而出。2. 移动端核心基础与性能优化考点深挖2.1 渲染机制与首屏优化思路移动端笔试中渲染机制是出现频率极高的考点同时也是主观题的最佳素材。我在备考时把“从URL输入到页面展示”这条链路完整梳理了一遍笔试时帮了大忙。以Android端加载一个H5页面为例完整链路是DNS解析 - TCP连接 - TLS握手 - 发送HTTP请求 - 服务器响应 - 浏览器/WebView接收HTML - 解析HTML构建DOM树 - 解析CSS构建CSSOM - 执行JavaScript - 构建渲染树 - 布局 - 绘制 - 合成。每一个环节都可能成为性能瓶颈。我在笔试主观题里用的答题框架是“先定位再优化”。不要一上来就写“压缩图片、开启缓存”这种零散方案而是先说明如何定位问题用Chrome DevTools的Performance面板记录页面加载过程或者用Lighthouse跑一次性能评分看FCPFirst Contentful Paint、LCPLargest Contentful Paint、TTITime to Interactive各项指标到底差在哪里。定位之后再分阶段给方案我列个表格方便你理解阶段常见问题优化方案网络请求DNS解析慢、TCP握手慢、请求串行DNS预解析、HTTP/2多路复用、资源CDN化资源加载HTML阻塞渲染、JS阻塞解析、图片体积大内联关键CSS、script加defer/async、图片WebP化页面渲染重复布局、强制同步布局、长列表卡顿减少DOM层级、批量DOM操作、虚拟列表用户感知白屏时间过长、loading体验差骨架屏、首屏接口前置、关键资源预加载实际上首屏优化的核心矛盾是“资源体积”和“渲染速度”的平衡。我在答题时特意强调了一个容易被忽略的点真正影响首屏体验的往往不是页面总量而是关键渲染路径上的资源量。你的页面可能总共有4MB资源但只要首屏真正依赖的只有500KB优化这500KB比优化剩下的3.5MB更有意义。移动端性能优化大概率会出现在主观题里建议准备一个自己熟悉的项目案例作为素材从指标采集到优化落地再到效果数据形成闭环答题时直接套用。2.2 内存管理与卡顿治理性能优化的另一个高频考点是内存和卡顿治理尤其针对Android和iOS平台。选择题里可能出现“内存泄漏的常见原因”“如何检测卡顿”“GC机制”等知识点主观题里则可能让你分析某个页面滑动卡顿的原因。先说内存泄漏。Android里最常见的是Activity泄漏例如Handler持有Activity引用、单例持有Context、匿名内部类持有外部类引用等。笔试中如果让你列举内存泄漏场景建议从“静态引用、非静态内部类、Handler、资源未关闭”四个角度回答。如果能够补充一句“用LeakCanary做自动化检测用Memory Profiler分析堆转储文件”会让答案更有落地感。卡顿治理的核心指标是帧率但又不能只看帧率。现代性能优化框架更关注“掉帧”和“慢函数”。笔试中遇到卡顿问题我的答题思路是首先用Systrace或PerfDog抓trace找到卡顿发生时主线程在执行什么任务如果是Layout任务检查是不是布局层级过深如果是Java方法执行时间过长老检查是否在UI线程做了IO操作如果是频繁GC检查是否在循环中创建了大量对象。我在真实项目中遇到过一个问题长列表滑动时频繁触发GC原因是列表项的图片控件在每次bind时都重新创建了Bitmap。解决方式很简单改为复用Bitmap或在缓存中加载但这类问题在笔试里经常会变形为“ListView/RecyclerView的优化方案”所以底层原理一定要吃透。关于帧率你还需要理解一个概念Android的垂直同步机制VSYNC也就是系统以16.6ms为周期发出绘制信号如果一帧的渲染时间超过16.6ms就会掉帧。笔试中可能会问你“为什么帧率低于60fps就会感觉卡顿”这时你就可以从VSYNC和人的视觉暂留特性来解释。2.3 性能指标与监控方案联想这类大厂的笔试主观题非常看重“量化思维”。答性能优化题时如果你能说出具体的指标名称、采集方式、监控方案会明显提升答案的含金量。我整理了几个移动端性能场景的关键指标启动耗时冷启动和热启动分别统计冷启动指进程从创建到首页可交互一般以onFirstFrame和onIdle为节点。卡顿率统计单位时间内掉帧次数或主线程阻塞超过阈值比如100ms的次数。内存峰值通过Debug.getMemoryInfo或Instruments采样关注PSS和Java Heap两个值。网络请求耗时分DNS、连接、请求、响应四个阶段统计。页面渲染耗时从数据回包到首帧渲染完成的时间。在监控方案上Android开发可以用Matrix做APM框架iOS可以用自研的AOP方案或接入Firebase Performance。H5页面则可以用PerformanceObserver sendBeacon上报关键指标。笔试中即使不要求你写出完整监控代码能提到这些方案也说明你有实战经验而不只是背概念。这里我给你一个可以参考的简版H5性能上报代码笔试或项目里都能用// 页面加载完成后收集关键性能指标并上报 window.addEventListener(load, () { // 优先使用PerformanceObserver监听LCP if (PerformanceObserver in window) { const observer new PerformanceObserver((list) { const entries list.getEntries(); const lcpEntry entries[entries.length - 1]; report({ type: lcp, value: lcpEntry.startTime }); }); observer.observe({ entryTypes: [largest-contentful-paint] }); } // 采集navigation timing数据 const nav performance.getEntriesByType(navigation)[0]; const data { dns: nav.domainLookupEnd - nav.domainLookupStart, tcp: nav.connectEnd - nav.connectStart, request: nav.responseStart - nav.requestStart, dom: nav.domContentLoadedEventEnd - nav.navigationStart }; report(data); }); function report(data) { // 用sendBeacon保证页面关闭时也能发送 navigator.sendBeacon navigator.sendBeacon(/api/perf, JSON.stringify(data)); }笔试中如果没时间写代码你只需要把核心思路讲清楚先用Performance API采集再用sendBeacon或fetch上报最后在监控平台上聚合展示。链路完整比某个细节完美更重要。3. 框架与工程化考点技术选型、调试与数据可视化3.1 移动端Vue开发框架怎么选联想的移动端笔试虽然没有直接问“请推荐一个移动端Vue框架”但主观题和选择题里会渗透技术选型的思路。比如给你一个业务场景问你选择跨端方案还是原生方案或者问某两种框架的对比。这里我把最常被问到的移动端Vue相关框架整理一下备考时可以当速查表用框架类型核心特点适用场景VantVue组件库轻量、组件全、按需引入、适合H5移动端Web页面、商城活动页NutUIVue组件库京东出品、组件风格统一、对业务组件覆盖好电商类H5、中立业务uni-app跨端框架Vue语法、一套代码编译到多个平台小程序H5App多端覆盖Taro跨端框架React/Vue语法都支持、对小程序生态适配好小程序为主、兼顾H5Capacitor混合容器基于WebView原生化、JS调用原生能力快速把Web应用打包成App笔试里如果问“移动端Vue框架怎么选”不要只说“Vant好用”这种主观结论。我的建议是围绕三个维度展开业务形态是纯H5还是需要跨端、团队技术栈团队擅长Vue2还是Vue3、包体体积和性能要求是否对首包有严格限制。我在项目里实际用过的方案是H5业务页用Vant Vue 3小程序端用Taro Vue 3原生App内嵌的WebView页面用Vite Vant。三个场景分开管理避免用一个重型框架去覆盖所有诉求。笔试中如果你能这样结合场景讲选型逻辑会比单纯背框架特性拿到的分高。另外要特别复习一下Vue 3相对于Vue 2的关键变化比如Composition API、Teleport、Fragment、createRenderer、响应式系统的Proxy实现。选择题里可能直接考“以下哪个是Vue 3的新特性”或者“Proxy相比Object.defineProperty的优势”这些都属于基础送分题但很多人因为平时写业务不关注底层反而容易丢分。3.2 移动端调试工具链vConsole嵌入与使用调试工具是移动端开发的日常刚需笔试里不是直接考你“vConsole怎么用”而是可能会在描述一个场景时让你给出调试方案。另外面试环节大概率会追问题“你在移动端开发时怎么调试真机页面”浏览器端调试有DevTools但到了手机上的H5页面尤其是微信内置浏览器或App内WebView外部调试工具往往连不上。vConsole就是一个轻量的移动端调试面板让你直接在页面上看到日志、网络请求、Cookie和LocalStorage信息。在笔试中如果要答“移动端调试方案”我建议按以下顺序组织如果页面运行在Android的Chrome中优先使用Chrome DevTools远程调试通过USB连接电脑在chrome://inspect里查看页面。如果是App内置WebView需要在原生端开启WebView的调试开关Android的WebView.setWebContentsDebuggingEnabled(true)iOS在Safari开发菜单里选模拟器或真机。如果以上方案都受限比如直接在微信里调试H5建议在页面中嵌入vConsole。vConsole的嵌入方式很简单我习惯通过CDN引入的方式在测试环境动态加载。下面是一个可以在移动端浏览器任意页面插入使用vConsole的示例// 只会在非生产环境自动加载vConsole并等DOM加载完成后再插入 (function () { const isProd window.location.hostname production.example.com; if (isProd) return; // 兼容已存在vConsole的情况避免重复引入 if (window.vConsole) return; function loadScript(src, cb) { const script document.createElement(script); script.src src; script.onload cb; document.head.appendChild(script); } function initVConsole() { const vConsole new window.VConsole(); // 可以通过面板切换插件或者直接打印日志 console.log(vConsole 已加载可以在页面上查看网络请求和日志); } if (document.readyState complete) { loadScript(https://cdn.jsdelivr.net/npm/vconsolelatest/dist/vconsole.min.js, initVConsole); } else { window.addEventListener(load, function () { loadScript(https://cdn.jsdelivr.net/npm/vconsolelatest/dist/vconsole.min.js, initVConsole); }); } })();注意这个脚本的关键点等页面load事件触发后再加载vConsole避免阻塞首屏渲染同时判断生产环境再跳过加载。笔试中如果让你设计一个调试方案能考虑到“调试工具不能影响线上性能”这点就是加分项。有一种常见的场景是你没法控制页面代码但需要在别人的线上页面里调试信息如何处理。这时候可以在浏览器地址栏执行一个自执行的JavaScript脚本去动态插入vConsole或者通过书签的方式在需要的时候运行。我自己实测下来在移动端浏览器的地址栏直接输入javascript:协议开头的代码块部分浏览器会拦截所以更稳妥的方案是用一个本地的代理工具比如Charles或Whistle对目标页面注入脚本。笔试中如果问到这种场景你提到用抓包工具做脚本注入面试官会觉得很经验丰富。3.3 ECharts在移动端的实践细节tooltip显示时机问题数据可视化在移动端笔试里很少作为大题出现但选择题和问答题偶尔会涉及。我在准备期间搜过一个问题“ECharts折线图在移动端怎么让它渲染完成后显示最后一个点的tooltip”。这个问题虽然很具体但背后考察的是你对ECharts生命周期和事件系统的理解。先说原理ECharts的tooltip可以通过dispatchAction主动触发核心API是chart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: lastIndex })。但要注意必须在图表渲染完成后执行否则图表实例还没readydispatchAction会无效。网上很多答案会告诉你直接调用setOption后立刻dispatchAction但实际在移动端图表的渲染是异步的直接调用可能会踩坑。推荐的做法是监听finished事件这是ECharts 5.x提供的渲染完成事件const chart echarts.init(document.getElementById(chart)); const option { xAxis: { type: category, data: [周一, 周二, 周三, 周四, 周五, 周六, 周日] }, yAxis: { type: value }, series: [ { type: line, data: [120, 200, 150, 80, 170, 110, 230], symbol: circle, symbolSize: 8 } ], tooltip: { trigger: axis } }; chart.setOption(option); // 监听渲染finished事件保证绘图完成 chart.on(finished, function () { const lastIndex option.xAxis.data.length - 1; chart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: lastIndex }); });试卷里如果出现这类题目除了代码正确还要注意两点第一showTip的dataIndex是x轴数据对应的索引不是鼠标坐标。如果你用x或y属性控制位置在移动端反而容易定位不准因为tooltip默认会跟随坐标。第二移动端屏幕窄折线图数据密集时最后一个点的tooltip可能被屏幕边缘裁剪。更好的做法是给tooltip配置confine: true让tooltip在图表容器内自动调整位置tooltip: { trigger: axis, confine: true, backgroundColor: rgba(0,0,0,0.7), textStyle: { color: #fff } }笔试或实际项目中遇到“图表显示不出来”“tooltip不出现”这类问题用得上的一套排查思路是先确认ECharts版本再确认容器是否有宽度移动端常见问题容器display为none时初始化的图表宽度为0然后检查是否有报错信息最后再考虑事件触发时机。多数情况下问题都出在容器宽度或初始化时机上而不是ECharts本身。4. 跨端与浏览器能力考点从WebView到移动端API4.1 WebView容器与移动端API设计思路移动端笔试的隐藏考察点是“你对移动端运行环境的理解有多深”。这里的运行环境不光是系统层面还包括页面实际运行的宿主容器比如Android WebView、iOS WKWebView、小程序容器、浏览器App等。我搜过“夸克移动端API”这组热词。夸克作为一个移动端浏览器提供了一些Web API能力比如渲染、下载、语音播报等扩展能力。虽然笔试不会直接考“夸克的API有哪些”但这类浏览器自带能力背后的设计思路是移动端开发者应该理解的浏览器本质是提供Web能力的宿主环境它既受限于标准Web API又可以扩展自己的私有API。笔试题目如果问“移动端Web页面调用系统能力”你应该想到几个方向通过URL Scheme唤起原生App例如appname://openpage?paramsxxx。通过标准Web API调用设备能力例如navigator.vibrate振动、navigator.geolocation定位、navigator.mediaDevices摄像头。通过JS Bridge调用宿主App原生方法这是App内置WebView最常用的方式核心是注册一个native方法供JS调用并定义好回调协议。在浏览器App中可能通过其私有API如夸克的分屏、云加速做能力增强。以JS Bridge为例我在项目里常用的一种简单实现是用window.postMessage或prompt实现双向通信笔试中如果让你设计一个JS Bridge的通信协议可以从下面三方面展开JS侧如何调用原生注入全局方法或拦截URL Scheme、原生如何回调JSevaluateJavascript或postMessage、参数传递和错误处理怎么设计。一个安全的JS Bridge必须考虑白名单校验、参数类型校验、超时处理。这些细节是面试官区分候选人的关键只答出“JS调用原生方法”是及格线能答出“安全性设计和异常处理”才是加分项。4.2 Python在移动端工具链中的角色看到“Python移动端GUI”这个热词时我第一反应是很多人在备考时把精力放偏了。笔试考Python大概率是在算法编程题里考而不是让你做移动端GUI。Python本身不是移动端主流开发语言但在移动端开发流程中Python经常作为自动化脚本、数据采集、接口Mock、性能分析工具存在。笔试编程题如果允许用Python我推荐用它解决算法题因为代码量少、快。不过有几个细节要注意实测联想的在线OJ对Python的版本一般是3.x支持标准库但第三方库比如numpy不一定可用。做题时尽量避免用非标准库尤其是涉及数组、排序、动态规划的题目。如果你非要了解Python在移动端的可能应用场景这里给出几个我实际用过的接口Mock服务用Flask或FastAPI快速起一个本地接口服务模拟App的登录态、列表数据方便联调。自动化打包脚本用Python写脚本调用Gradle命令批量打包不同渠道包并自动上传到分发平台。性能数据采集用adb命令结合Python脚本自动化采集Android设备的CPU、内存、帧率数据。笔试结束后有一道编程题我用的就是Python题目大致是“给定一个数组找出所有和为target的三元组”这类题目用Python写非常快但要注意边界条件。我的经验是如果你Python更熟练编程题优先用Python但如果题目明确要求实现某个数据结构比如实现一个LRU缓存用Java或C会更符合出题人的预期。4.3 UI还原与设计协作Figma拨号弹出窗的还原要点Figma在移动端开发流程中的使用不是笔试的重点但2025年的移动端笔试趋势是考题越来越贴近真实工作流。我搜过“Figma移动端拨号弹出窗”这个热词如果有人考到UI还原类的题目大概率会涉及类似交互细节。先说Figma与前端协作的基本流程设计师在Figma中完成设计稿开发者在Figma的“开发者模式”Dev Mode中查看尺寸、标注、切图。关键的还原点包括基础尺寸换算Figma默认字体单位是px但移动端开发时要根据设计稿宽度做rem或rpx换算。通常统一以375px为基准宽度也就是iPhone SE的宽度。弹出窗样式拨号弹出窗这类组件需要注意蒙层透明度通常是rgba(0,0,0,0.5)、圆角值、底部按钮的高度一般不能低于48px方便手指点击。交互反馈弹出窗出现和消失的动画时长一般在200-300ms使用ease-out缓动函数不能让用户觉得生硬。边缘安全区域如果弹出窗底部有按钮要适配HOME线的安全区俗称“小黑条”需要给底部留出env(safe-area-inset-bottom)的空间。笔试中如果给出一个设计稿要求你描述实现方式可以从HTML结构、CSS样式、交互逻辑三个层面来答。比如拨号弹出窗的HTML结构包含蒙层、弹窗卡片、拨号盘、关闭按钮CSS样式需要实现居中定位、圆角、阴影交互逻辑需要处理点击蒙层关闭、输入号码格式化、拨号按钮回收等。我实际做一个拨号弹窗时比较简洁的实现是这样的div classoverlay idoverlay div classdialog div classtitle拨打电话/div div classphone-input input typetel idphoneInput placeholder请输入号码 / /div div classactions button classbtn cancel取消/button button classbtn confirm拨打/button /div /div /div.overlay { position: fixed; inset: 0; background: rgba(0, 0, 0, 0.5); display: flex; align-items: center; justify-content: center; z-index: 1000; } .dialog { width: 80%; background: #fff; border-radius: 16px; padding: 24px; box-shadow: 0 8px 30px rgba(0, 0, 0, 0.2); transform: translateY(20px); animation: slideUp 0.25s ease-out forwards; } keyframes slideUp { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } .actions { display: flex; justify-content: space-between; margin-top: 20px; } .btn { flex: 1; height: 48px; border: none; border-radius: 8px; font-size: 16px; } .btn.cancel { margin-right: 12px; background: #f2f3f5; } .btn.confirm { background: #1677ff; color: #fff; }注意弹出窗在移动端常见的一个坑是输入框唤起系统键盘时弹窗会被顶起或遮挡。解决方案是使用position: fixed配合visualViewport监听键盘高度或者直接把输入框放在弹窗可视区域的上半部分。如果你在笔试题目里能补充这个细节说明你真的做过移动端UI。5. 高频问题与答题策略5.1 常见问题速查与答题框架综合我和同期备考同学的反馈移动端笔试中反复出现的高频问题可以整理成一张速查表考点方向常见问法推荐答题框架页面渲染页面加载慢的原因和优化链路拆解 - 指标定位 - 分层优化 - 效果评估应用启动冷启动优化怎么做启动阶段拆分 - 找出耗时任务 - 异步/懒加载/预初始化卡顿优化列表滑动卡顿如何排查采集trace - 定位主线程耗时 - 针对性优化跨端方案如何选择跨端框架业务需求 - 团队能力 - 性能与包体权衡网络请求移动端弱网优化有哪些手段请求合并 - 缓存策略 - 弱网检测与降级内存管理如何检测和避免内存泄漏泄漏场景 - 检测工具 - 代码规范与审查页面兼容iOS和Android的H5差异事件差异 - 样式差异 - API差异 - 降级方案这里我要特别提醒一个容易被忽视的点答题时要注重“分层表达”。比如问你移动端性能优化方案你可以按“应用层、系统层、网络层”分层作答也可以用“更快的资源加载、更少的渲染耗时、更好的用户感知”这层逻辑来组织。分层表达的意义在于让你的答案看起来有体系而不是零散的经验堆砌。我在笔试中遇到的问答题实际上要求字数不多但你写的内容越多越容易被高分。不过要注意写得多不代表写流水账每一句话都应该有信息量。举例说明同样是答图片优化如果你只写“进行图片压缩”这句信息量为零如果你写“将PNG大图转为WebP格式同时根据设备DPR加载不同分辨率图片首屏图片体积降低了40%”这才是有价值的答案。5.2 时间分配与检查清单在线笔试的时间分配直接影响最终成绩。我自己的策略是分三轮作答第一轮10-15分钟快速浏览全卷标记选择题里的“不确定项”和编程题的难度判断。选择题不确定的先凭第一直觉选上不要纠结太久因为后续题目可能更值分。第二轮70-80分钟完成编程题和主观题。编程题优先做“看起来最像原题”的那道因为这类题你脑中已有成熟思路能做出来就赚到了。主观题至少留出15分钟保证每一道都写满。第三轮10-15分钟回头检查选中的不确定选择题并且重点复查编程题的边界条件。在线OJ最怕的不是算法错误而是数组越界、空指针、整数溢出这种低级失误。我根据自己的经验整理了一张笔试临场检查清单编程题是否能通过题目给出的示例用例边界输入空数组、单元素、最大数值是否特殊处理编程题的复杂度是否在题目限制内如果要求O(nlogn)我用O(n^2)的解法会不会超时主观题是否给出了具体的指标或数据避免只写“优化”不写“优化后提升了多少”。选择题是否相信第一直觉客观题频繁改答案往往得不偿失。是否留出了至少5分钟的缓冲时间应对意外情况断网、代码调试5.3 备考期间的高效复习路径最后分享一点备考思路。我准备联想移动端笔试大约用了三周每天有效学习时间2-3小时不算长但比较有针对性。第一周打基础刷数据结构与算法题重点关注数组、链表、树、动态规划、双指针这几类。移动端岗位的算法题难度一般不会到竞赛级LeetCode Hot 100加上剑指Offer已经足够。第二周补专业把Android/iOS/移动端H5的基础知识点过一遍重点看启动流程、生命周期、渲染机制、网络编程、存储方案。同时整理2-3个自己熟悉的项目案例包括背景、难点、方案、成效。第三周做模拟做往年的大厂移动端笔试真题模拟真实考试的时间限制。推荐用牛客网或赛码网练习因为联想笔试用的就是牛客网平台提前熟悉在线编程的输入输出方式和IDE体验很重要。我在准备期间把“B站移动端技术框架有哪些”这个热词也找出来研究了一下。B站移动端早期以原生开发为主后来在部分业务中引入了跨端方案、Flutter等技术同时其iOS和Android端都有一些自研的架构组件。笔试中如果考到“业界移动端实践案例”你可以拿B站、知乎、美团这些头部App的技术分享来佐证你的观点但要注意如果你对某个框架没有亲自用过就不要展开细节一句话带过就好否则容易被追问。另外关于前文搜到的“好用的移动端Vue开发框架”如果笔试或面试真的问到你不要只推荐某一家而是给出选择框架的判断标准。我的建议是优先选择社区活跃度高、类型定义完善、按需引入机制成熟的框架。Vant和NutUI在H5场景都很好用uni-app更适合需要同时覆盖小程序和H5的业务但如果你的项目只做App内嵌WebView没必要引入跨端框架Vite Vant Vue 3已经足够轻快。还有一个我踩过的坑说出来给各位提个醒笔试前一定要检查自己的电脑环境包括网络稳定性、浏览器兼容性、IDE的快捷键设置。我第一次参加某大厂笔试时因为IDE默认的自动保存延迟导致一段写了一半的代码在提交时被截断最后那道编程题没过。从那以后我每次在线笔试前都会先花5分钟在平台上跑一道“AB”这种最简单题目确认提交、判题、编译环境全部正常。最后再分享一个小技巧。笔试结束后不管感觉考得好不好尽量回忆整理一下题目和你的答案。大厂笔试通常不是一锤定音因为后续还有面试笔试中的场景题很可能会变成面试官追问的话题。如果你笔试时写的方案不够完善在面试前有足够时间重新审视这个题目给出更成熟的答案同样能扳回一城。我这次就是笔试结束后把主观题答案重新整理了一遍在后面的面试中又把这道题展开讲了一遍效果比笔试时临场发挥好得多。