荣耀通用软件工程师一面：项目深挖与长列表优化

《面试题目》

1. 自我介绍。
2. 挑一个项目讲。
3. 这个项目你遇到的比较困难的问题是什么？这个问题你怎么解决？
4. 另一个项目，我看是支持图片跟视频上传的，问一下这个图片和视频的分辨率、码率，还有大小的限制是什么？
5. 刚才提到了图片压缩算法，你用的是什么算法？压缩比是多少？
6. 问准备毕业论文了吗（没）。你学过的课程里，你觉得在专业课中哪一门课最难？然后你是怎么去学它、怎么克服这些困难的？
7. 介绍一下你熟悉哪些数据结构，这些数据结构适用哪些场景，然后选择一到两个数据结构讲一讲它们的实现原理。
8. React Native，瀑布流如何优化长列表性能？
9. 专业排名是多少？
10. 反问。

《参考解析》

上传类项目要能当场报出「分辨率、码率、大小」这些硬数字。 面试官问这种参数不是要背出教科书上限，而是验证项目是不是你真做的。答法是把限制分成三层：客户端限制（用户选图/选视频时先按大小与时长拦截，给出压缩提示）、服务端限制（网关与对象存储的请求体上限、单文件上限、允许的格式白名单，以及超限时的返回码）、业务限制（分辨率与码率按用途分档，比如头像走 512×512、列表缩略图走 720p、原图归档保留原尺寸）。再补一句这些数字怎么定的：从存储成本、带宽成本、移动端流量和实际观看设备推导，并说明前端在上传前会做尺寸与压缩预处理来少传流量。

图片压缩要讲清算法与压缩比的由来。 常见答案是：先做尺寸缩放（按目标显示尺寸的 2 倍导出，避免大图小用），再用有损编码压——WebP 或 AVIF 在同等主观质量下比 JPEG 小不少，移动端可用平台原生编码；质量参数一般落在 70–85 之间，再高收益很小。压缩比不要报一个孤立的数字，要说清基准与场景：相对原始 JPEG 的体积、在主观质量基本不降的前提下大约能省多少，并说明怎么验证（对比压缩前后 PSNR/SSIM 与肉眼抽样、再结合线上图片下载耗时与流量变化）。如果被追问无损场景（合同、票据、截图文字），要回答此时改用 PNG/WebP 无损或调高质量参数，宁可大也不糊。

数据结构这题按「操作复杂度 → 适用场景」组织，别只背实现。 先说熟悉哪些：数组、链表、哈希表、栈与队列、堆、二叉搜索树与平衡树、跳表、并查集、Trie。然后按「你最常做哪些操作」排序选结构：随机访问多用数组，频繁头尾增删用链表或双端队列，按 key 快速查找用哈希表，需要有序遍历或范围查询用平衡树或跳表，取最大/最小用堆，前缀匹配用 Trie。挑一两个讲原理时讲得动：哈希表说清哈希函数、冲突处理（拉链与开放寻址）、负载因子与扩容的均摊代价；堆说清完全二叉树的数组表示、sift up 与 sift down、以及建堆为什么是 O(n) 而逐个插入是 O(n log n)。如果项目里用过（LRU 用哈希表加双向链表、定时器用小顶堆），顺手举出来最有说服力。

React Native 瀑布流长列表优化，核心是「少渲染、少测量、少持有」。 虚拟化：用 FlatList 的 getItemLayout（两列瀑布流按列维护累积高度，给出每项的偏移）避免动态测量，配 windowSize、maxToRenderPerBatch、initialNumToRender、removeClippedSubviews 控制渲染窗口；复用：keyExtractor 用稳定 ID、组件用 React.memo 包住并把回调 useCallback 化，减少整列表重渲染，图片统一用带缓存的图片组件并预设占位尺寸防止滚动中跳动；onEndReached 分页加载，注意加节流与「正在加载中」判断避免重复触发。更重的场景再提：FlashList 换掉 FlatList、把图片解码与布局测量放到原生侧、复杂项改用原生驱动动画（useNativeDriver）而不是 JS 线程计算。

「最难的问题」用四段式讲，重点在排查过程而不是结论。 结构是：现象与影响（怎么发现的、影响了谁、量级多少）→ 定位过程（怎么缩小范围、用什么工具看日志/抓包/比对版本、排除了哪些可能）→ 根因与修复（改了什么、为什么这样改）→ 验证与预防（怎么确认修好了、加了什么监控或校验避免复发）。面试官最想听的是第二段，所以要把「我先假设是 A，验证后排除，再怀疑 B」的推理说出来，哪怕最后根因是个很傻的配置错误。如果问题涉及协作或排期，也照实说，比如跨端对齐成本、方案被推翻过一次，反而显得真实。避免只讲「我查了半天最后发现是缓存问题」这种只有结论的答法。