面试过程中被多次问道性能优化，想了解一下这类问题的期望答案

[WarWithinMe]

最近面试发现有些面试官喜欢问“性能优化”问题，例如“你有没有什么性能优化的案例”等。

我自己做 UI 开发大概 16 年（包括大学时间），被问到这类问题，我第一反应就是没有什么问题足以让我记住一辈子，然后逢人就会拿出来娓娓道来。倒不是说我完全不去考虑性能问题，而是觉得这些都是基本操作，好像没有什么特别值得一提。我能想到的，比较宏观的有 iOS/MacOS 系统的 CALayer 需要通过 IPC （涉及到序列化和反序列化）让后台进程做图形渲染，那么遇到高性能绘图的需求，就需要考虑用别的方案以规避序列化这个耗时的操作；比较微观的有在写 GPU shader 的时候，如果 warp 线程组里面的 memory access 能按照硬件条件对齐地址，那么就可以一次性进行 memory 读取，否则会导致多次读取。感觉这些真讲起来也比较抽象，没这类经验的人听了也白听。然后，还有重度计算的任务看看能否拆成多个子任务然后丢给多个线程从而充分利用 CPU ；什么重交互的 UI （例如 feed 流），期望是在重度交互过程中能保持 60FPS 的帧率这类感觉都太基础。

在我看来优化的思路主要就是看看算法是否做了很多冗余的东西，降低其复杂度，避免不必要的代码。然后分析一下硬件瓶颈（每个硬件都能成为瓶颈，包括 CPU ，内存，磁盘，网络等），一般情况下想办法充分利用硬件资源即可。得要具体问题具体分析。

记得年前字节的面试官整个面试不停提及性能优化这个关键词，但最后我发现他在乎的是诸如用户输入事件需要 debounce 这类在做一个 search input 时的应该默认就加上的基本操作。。

所以大家面对这类问题都是会怎么回答，才能让面试官满意。或者说面试官到底期望一个什么样的答案？

[happyz90]

我觉得这个问题更侧重于看你“分析问题解决问题”的能力，因为性能问题并不是一个固定的问题，不同的场景有不同的影响因素和优化手段。在对底层实现有一定的了解的基础上，准确识别瓶颈所在，然后根据具体上下文设计针对性的方案。既考察了对系统底层掌握程度，又能了解你灵活分析与解决问题的能力。

[happyz90]

不小心点了回复，接上文。。。所以面试官重点想听的就是发现问题、分析问题、解决问题的「过程」。

[WarWithinMe]

@happyz90 当时讲了一些前司项目上的问题，然后说了我自己的见解和解决方案，好像没有太大作用。比如前司架构因坚定执行函数式编程导致导致大量临时变量产生，从而周期性触发浏览器 GC ，就会周期性卡顿。或是编译 Skia 到 WebAssembly ，用它绘制 canvas ，并实现 tile rendering （类似 Figma 的技术），从而规避超大文档的渲染性能问题等。不过也有可能我表达有问题，或者这些事情不太符合预期？

[happyz90]

@WarWithinMe 可能比较偏向于描述最终结论了？「是因为 xx 导致了卡顿」，而不是「怎样一步步排查而发现是因为 xx 导致的卡顿」。我觉得性能问题的重点就是过程，比如可能排查了一星期，最终只要改动一行代码。

[WarWithinMe]

@happyz90 确实，有个面试官是跟我说“那你用到什么指标啥的”。。

[murmur]

除了 pdd ，没几家配谈性能优化，现在的性能优化要么是骨架图这种虚假安慰，要么是砍功能

产品经理堆一堆屎给用户，后台又是隐私窃取又是 PCDN 还要保活，这个情况下能在低端机上真的做出优化的只有 pdd

[ChatGOP]

说实话， 这些问题完全是八股文。面试人喜欢你就会要你， 不会太在意你的回答的。通常面试前一分钟基本决定了你的面试结果

[howfree]

1.我来现在的公司做了大半年的性能优化，有些项目交付的时候，需要压测报告，这个是硬指标，也面了很多人，主要就是招来做性能优化的，确实实际处理过性能优化的人，还是太少，大部分都是八股文的那些东西；
2.一个人做没做过性能优化，对于真的处理过的人来说，很容易判断出来
3.八股文如果比较强的话，也是加分项
4.更多考虑的还是处理疑难问题的实际经验和能力，性能优化就是很好的一个考察点，案例越详细，越真实，会更加分
5.也和大厂的朋友聊过，因为刚做的时候，也没经验，最开始就是调整代码(前后端调整，数据库层面、还有就是中间件的调整)，再不行就向上调整需求方案，再不行就加钱，提高环境配置，工具可能就是 JProfiler,阿里的阿尔萨斯这些，但是更多的还是从实际情况入手
6.我是做 java 的，性能优化基础知识可能会比较注重线程池、多线程、数据库、缓存、mq 这些

[night98]

瞎编就行，构造一个场景，然后 balabala 说尝试各种方案，然后说一个最合理的方案就行了。要么就是直接找各种大佬的博客看优化案例然后自己虚构一个稍微改编一下，当然最好的方案还是自己实际遇到并处理过。

[iOCZS]

“他在乎的是诸如用户输入事件需要 debounce 这类在做一个 search input 时的应该默认就加上的基本操作”---这算鸡毛优化，属于交互规范了。
我觉得大部分项目不需要刻意优化，能做到适老、无障碍、合理降级已经非常不错了。
没有严重的内存泄漏、卡顿、崩溃已经达标。当然包的体积能小点最好了。

[gransh]

那个词叫 [问到] ，我一眼看成性道...

[ltaoo1o]

面试官都是带着答案来问问题的，我之前也是。刚好能说到答案，面试官就会认为你会，很满意，和自己观点相同。
你说到一个面试官没接触过的，即使是对的，面试官自己都不懂，就不满意。好的面试官还会和你聊一聊，你这时候就要说服面试官，但是效果肯定不如说到预先的答案上好。

面试官水平有高有低，面试面的就是和面试官是否投缘，你会的刚好也是面试官会的，你的观点也刚好是面试官的观点，这样 100%稳了。

[cobbage]

搞了一年的运维大部分优化搞的 sql 层面，业务 tob 的。想实战参与下别的手段上点中间件类的奈何没机会。前段基本（老项目）大部分搞点限制条件，渲染批量还是单个，看能缓存不，也有些项目有 bug 的碰到了一个级联多选疯狂请求后台的。

[yhxx]

从前端的角度来说一点我自己的理解吧

我几乎每次面试都会被问到这个话题，自己面试别人的时候也很喜欢问
首先从我的经历来看，肯定不是楼上老哥们说的“完全是八股文。面试人喜欢你就会要你， 不会太在意你的回答的。
面试官都是带着答案来问问题的，刚好能说到答案，面试官就会认为你会，很满意，和自己观点相同。”

这个话题一般比较开放，如果面试的是一个比较资深的岗位，期望的答案一般是希望能体现出候选人有渊博完备的知识体系，同时有丰富的实践经验和业务理解 ，最好还能有足够前瞻的技术视野。

比如可以从那个被问烂了的“从输入 url 开始到页面加载完成都发生了什么”聊起，讲一下有哪些流程，每个节点上有哪些优化点，哪些部分分别可以提升加载、渲染、交互的流畅程度，有什么弊端。

再整理一下如何衡量性能，都有哪些指标，监控 & 诊断、数据驱动优化。

业务中遇到了哪些性能问题，如何分析、如何解决，成效如何。

未来展望，比如 HTTP3 、边缘计算，balabala


其实面试中遇到这种题挺好的，完全可以充分体现自己的知识深度广度，更重要的是能耗掉相当多的面试时间。你也不想聊了 20 分钟之后，面试官：我没啥可问的了，我们来一道 3D 接雨水吧？

[yty2012g]

我之前问类似于这样的问题（往往是配合具体场景），我想要听到候选人谈到的点：
1 、你是怎么发现/识别到性能优化点的？发现问题的方式方法很多，那你怎么识别到是这里需要做性能优化的？
2 、识别到性能优化点后，你是怎么思考解决的？你做过哪些思考和尝试，怎么体现出深度？
3 、升华一下，你怎么能避免以后不出现类似的性能问题？你能提炼/总结/沉淀出什么经验

[zongwan]

感觉问题出在：你的存量知识自认为过大（也或许真的大到让人敬佩），导致增量太小，遇到了瓶颈

我现在依稀记得在 React 的 setState 诞生以前，我们是使用 setData 后 pre_update ，然后在 next_frame 去 update ，避免多模块直接触发渲染
还有比如，在用到定时任务的时候采用质数间隔，避免同一时间同时执行

时不时经常念叨一些之前的这些存量知识，来提高增量
毕竟偶尔要给新人做下培训，还有同事之间的技术分享
（才华横溢的同事太多，我的这点存量知识永远跟不上同事的脑洞）

[xlzyxxn]

作为一个后端来谈谈我对 性能优化 这个问题的看法：

最近在看一本书：《微服务架构设计模式》，里面有一句话是“方法架构的设计，就是选择和取舍”；目的是为了解决一个问题(或者说当前和未来短期内的一个关注点)

所以这是在不同历史进程、以及各种场景下，各个技术选项的客观分析，和自己的一个思考过程；比如说从单体到微服务，从裸机到云原生，JDK 中从 LongAotmic 到 LongAddr ；比如 docker 相比裸机，性能要损耗一点，但是在环境一致性或者说部署流程方面带来了极大便利，这时候该怎么取舍？比如说前端工程化这个过程中，为什么会有 npm/yarn/pnpm 这些，现代化构建工具 Vite 、Rspack 为什么出现？前端技术选型我是直接用 vue 或者 React ，还是要选 nextjs 或者 nuxtjs ？

我觉得这是针对具体场景所作出自己思考的一个过程，这一刻不管是程序员还是别的职业，都是在问遇到一个场景时，你应对的方案有哪些？你要怎么选择？（实践论告诉我们，可以参考前人经验，结合自己实践。）

[WarWithinMe]

@zongwan 确实可能是个人认知问题，我自己觉得这些都是很小事。在实际的工作中，基本上是，某个地方卡顿，然后 devtool 调查一下时间消耗在哪里，解决一下就完事了，也不是什么 rocket science 。

另外很多东西，比如一开始就知道它的原理/逻辑/思路，甚至连后续调优的过程都不存在，因为会在最初的实现中就已经规避了。比如 Apple SwiftUI 1 出来的时候，它的实现差不多是只要有一个数据改动，整个视图树几乎要从头开始对比（因为它最开始不能很细致地收集依赖），是到最近的版本才加了更细粒度的依赖收集。。当时用 SwiftUI ，直接放弃用不它自带的那一套，自己写了一套来达到精准触发视图更新。对此，我也是觉得不是什么 rocket science ，没啥需要特别说明的。

我感觉是挺难满足到面试官要求。上面一些 v 友提到可以说说解决问题的思路，分析问题等，其实我也是拿这些来回复面试官，例如关于如何制作一个高效的渲染功能（说的就是现在那些白板 app 的那个画布），我大概讲了我前司的架构问题，然后说了我自己的方案（不过因为我没权力去让方案落地，所以可以认为我是纸上谈兵），总的来说就是采用类似 Figma 的方案，用 WebAssembly 编译 Skia ，自己渲染，结合 tile rendering 来优化一下重绘。不过对方就完全不感兴趣。。

[dcatfly]

@yhxx #14 这个老哥说的不错 问到性能优化主要还是想看面试者是否有系统化的知识体系 或者说看面试者是如何发现并解决问题的，如果只是回答一些零散的优化点 那跟考八股没啥区别。

[ltaoo1o]

@yhxx 这道题我认为最契合八股了，怎么答现在网上一搜一大把。先从哪里说，要讲什么部分，哪些部分涉及前端可以多讲，哪里可以举例说明，这八股味还不够明显吗。
这其中有哪些环节是前端可以参与并改变，很小一部分对吧，剩下的都是靠背，什么三次握手 SSL 证书等等，前端能参与的部分又 99% 的业务用不上，在我看来就是考验记忆力。

考这道题，可以从前端可能会遇到的问题来考，比如动画卡顿，可以引导往浏览器渲染流程上思考。白屏时间过久，又应该怎么思考怎么解决。
这样考了知识点，也考了解决问题的能力，看面对问题是否有条理有思路。


面试，永远不是以考倒候选人为目的，而是筛选，筛选出自己符合能力的人，没有人是全知全能的。

[chashao]

我认为回答给面试官性能优化的流程会比较好
比如我在做游戏的性能优化，一般得先通过数据找到问题出现的地方，这是一个由粗到细的过程（从线上性能数据日志开始），然后根据出现问题的地方设计优化方案，方案里会考虑当前引擎里能不能做、如何兼容旧引擎、会不会产生很大的 patch 量等因素，然后制作一个可以重复复现性能问题的 Demo ，通过方案使用与否的性能指标对比来落地，最后再通过线上数据得出优化结果。

[kingcanfish]

@ltaoo1o #12 同意的 我面试最害怕的就是面试官做过和我差不多的项目 然后他就会自然而然的往他自己的解法上靠， 实际上每个人项目条件和环境都不同，解决方案都是不同的，有些水平不高的面试官就认定他的解法时最优的，你没想到你就是不行 非常无语

[nrtEBH]

这是典型的开放性问题 类似后端面试的系统架构设计 考的一个是经验一个是实际经手案例 然后是结构化分析问题设定边界拆解回答的思维过程 在其中再继续深挖你的技术深度

[LandCruiser]

你麻省理工毕业的，或者谷歌工作回国的，面试官一个屁都不敢放，这个行业现在已经和技术没关系了。