每年秋招季图形学、图像处理方向的同学总会纠结一个问题B站的图像引擎岗到底考什么我今年完整走了一遍2023届B站图像引擎方向的校招笔试流程把这套题从头到尾复盘了一遍。说实话它和我预想的不太一样——不是单纯的图形学八股也不是纯粹的数据结构刷题而是把渲染基础、图像算法、视频处理、工程实现能力揉在一起考。这篇文章把我的复盘笔记整理出来针对准备投递B站图像引擎方向的同学也适合所有打算走渲染、图像算法、视频处理方向的应届生参考。我会按考点专题拆解讲清楚每类题目背后的考察意图、答题思路和容易踩的坑。1. 从岗位JD反推考察逻辑图像引擎在B站到底做什么很多同学复习时容易陷入一个误区把B站的图像引擎岗当成游戏引擎岗或图形学算法岗来准备然后对着PBR、光线追踪、实时全局光照猛刷。但B站本质上是一家视频社区它的图像引擎方向核心业务场景和游戏公司有本质区别。1.1 业务场景决定考点权重我在投递前专门扒了B站图像引擎相关的业务链路大致可以分成四块播放器侧的图像处理视频解码后的色彩空间转换、HDR映射、超分、插帧、弹幕渲染合成。直播间的实时特效美颜、滤镜、人脸关键点跟踪、AR挂件、实时分割这里需要GPU高性能实现。互动玩法和3D渲染小世界、动态壁纸、互动视频里的3D场景渲染但占比远低于图像处理。移动端性能优化GPU带宽、功耗、发热控制这是B站非常重视的工程议题。如果你把这四个场景列出来就能理解为什么这套笔试卷里线性代数、渲染管线和图像卷积占了那么大比重而PBR材质这类游戏渲染内容一道题都没出现。这不是偶然是岗位定位决定的。1.2 从考察三角看命题人的出题思路复盘完整套题我总结出B站图像引擎方向的考察三角数学与图形学基础向量、矩阵、坐标变换、渲染管线各阶段的作用。这是区分会调API和理解渲染本质的分水岭。图像处理与视频编码滤波、插值、色彩空间、量化、码控相关概念。这是B站业务中真正高频使用的底层能力。工程与算法实现手写图像缩放、矩阵操作、连通域标记这类题目。表面是算法题实际考察的是你对图像数据在内存中如何排布、如何高效访存的理解。这个三角在选择题、编程题、简答题三个题型中反复交叉出现。我建议后面准备的同学不要孤立地刷图形学题而是把自己的知识体系按这三个方向搭骨架再往里面填细节。2. 基础选择题里藏着的高频考点从坐标变换到渲染管线B站这套笔试的选择题部分大概有二十道左右覆盖C基础、线性代数、图形学、图像处理四个模块。这里不是要把所有题都罗列出来而是挑几个最有代表性的考点讲清楚考察逻辑和答题时要避开的陷阱。2.1 线性代数不是考公式是考几何直觉选择题里有一道让我印象很深给出一个3x3矩阵问它作用在二维坐标上会产生什么变换效果。选项包括旋转、缩放、平移、错切。这种题看起来简单但命题人会在矩阵数值上做手脚比如给出一个非正交矩阵很多人会想当然地选旋转实际上它同时包含了旋转和缩放。我的答题思路是碰到变换矩阵先用两个特殊向量去验证——看它把x轴单位向量变换到了哪里把y轴单位向量变换到了哪里。如果两个变换后的向量长度都变了说明含缩放如果夹角不再是90度说明含错切如果最后一列有平移分量还要把齐次坐标考虑进去。这样两步验证比背公式可靠得多而且速度很快30秒内能出结果。另一个高频考点是向量叉积的方向判定。在图像引擎里叉积常用于计算法线、判断三角面片的朝向。对B站这种大量使用2D渲染和图像处理的场景叉积的z分量符号判定会反复出现比如判断点是否在三角形内、判断多边形顶点的环绕顺序。这类题要特别注意坐标系是左手系还是右手系B站客户端在移动端OpenGL ES环境下是右手坐标系和Web侧的左手坐标系某些图形库容易混淆出题人很喜欢在这里埋坑。2.2 渲染管线不要只背阶段名字要理解数据流动渲染管线相关题目基本是必考的但B站的考法和传统图形学课程不太一样。课程里喜欢考顶点着色器和片段着色器哪个先执行这种流程题B站则更喜欢给一个实际场景让你判断瓶颈在哪、应该优化哪个阶段。比如有一道选择题大意是在移动端渲染大量2D精灵比如弹幕、挂件每个精灵需要做旋转缩放怎样组织绘制调用效率最高。表面看是渲染优化题实际上考察的是你对顶点缓冲区、实例化绘制、合批这些工程手段的理解。如果只背过渲染管线分为应用阶段、几何阶段、光栅化阶段这道题会很懵。我复盘时把这部分知识整理成一个数据流视角的框架模型数据如何进入显存顶点着色器如何做坐标变换光栅化如何生成片元片段着色器如何决定颜色最后经过哪些测试与混合操作输出到帧缓冲。每个阶段都对应一类工程问题——数据上传慢就优化顶点缓冲顶点计算量大就简化顶点数或做LOD片元计算量大就降低分辨率或提前做裁剪。用这个框架去套选择题里的实际场景正确率高很多。2.3 C与内存布局图像引擎的隐形门槛选择题里混了不少C基础题我当时有些意外后来想通了图像引擎方向写的是底层代码内存布局、对象生命周期、并发安全这些基本功不过关后面真上了项目就是事故现场。其中一道题考察的是结构体内存对齐给了一个包含uint8_t、float、uint16_t成员的结构体问sizeof值是多少。这类题不难但要注意默认对齐规则下结构体大小会被补齐到最大成员对齐数的整数倍。如果你刷过LeetCode但没在C里处理过图像像素缓冲区的排列很容易在这里翻车。图像引擎里处理RGB数据、顶点数据时内存布局直接决定性能这种题考察的是工程敏感度。还有一道涉及shared_ptr循环引用的问题。图像特效链路里渲染层和特效层经常互相持有对方的管理对象如果设计不当就会出现循环引用导致的内存泄漏。这种题难度不高但能反映你有没有真的写过需要自己管理生命周期的C项目。我的建议是复习C时与其纠结lambda表达式的各种捕获写法不如把精力放在智能指针、移动语义、内存对齐、多线程同步这几个和图像引擎强相关的主题上。3. 图像处理与视频编码笔试里最容易被低估的硬骨头如果你把B站图像引擎方向的笔试当成图形学考试来准备大概率会在图像处理和视频编码这部分损失惨重。我刷题前有心理预期知道视频网站必然会考视频内容但没想到会考到这么细。这部分是拉开分差的关键。3.1 图像缩放与插值算法问法可以千变万化核心就那几个选择题里关于图像缩放的题目就有两到三道。从最近邻插值、双线性插值到双三次插值命题人关心的不是你记不记得公式而是不同算法在什么场景下用、各自有什么代价和缺陷。有一个选择题的陷阱我差点踩进去问双线性插值相对于最近邻插值的优势是什么。选项里有一个是计算速度更快看起来很合理因为双字让人感觉复杂度更高但实际上是错的。最近邻插值计算量最小双线性插值由于要做四次像素读取和三次线性插值计算量是成倍增加的。它的优势在于边缘更平滑不会出现明显的锯齿和马赛克效应。我当时给自己建了一张对比表后面复习时很好用最近邻插值计算量O(1)每像素速度最快适合实时预览但质量差容易产生锯齿。双线性插值每像素需要4次采样和3次插值计算质量和速度均衡是图像缩放、纹理采样中最常用的方案。双三次插值每像素需要16次采样质量最好但计算量最大适合离线处理或高质量缩放场景。如果笔试里出现双线性插值和最近邻插值的区别这类题答题时除了算法本身最好还能提到GPU纹理采样时的处理方式——现代GPU的纹理采样单元内置了双线性过滤能力你用一行纹理采样代码硬件内部做的就是双线性插值这样能体现你对硬件实现也有概念分数会高一些。3.2 色彩空间与HDRB站业务的真实高频需求视频处理绕不开色彩空间笔试里考察了sRGB、线性空间、伽马校正、HDR、色调映射这些概念。说实话图形学课程里也会讲但B站的考法更贴近视频业务的实际逻辑。有一道题是为什么在渲染时要在线性空间进行计算而最终输出要经过伽马校正。这道题如果在图形学课程里标准答案是保证光照计算符合物理规律。但结合视频业务你还需要理解视频文件存储的sRGB像素值不是物理亮度而是经过伽马编码的非线性值。如果直接把sRGB值当作线性值去做混色、滤镜、色彩变换中间调会偏暗画面失真。再往深一层HDR相关的色调映射也是视频网站的高频需求。笔试里有一道简答题问的是HDR内容如何在SDR显示器上显示。答题要点是HDR内容亮度范围远大于SDR需要进行色调映射将高动态范围压缩到低动态范围常见算法有Reinhard全局映射、Filmic映射、基于亮度直方图的局部映射等。同时还要考虑色彩空间转换把BT.2020色域映射到BT.709色域。这个方向我在答题时有一个体会不要只罗列名词最好能落实到一条具体链路上。比如B站播放器处理HDR视频的典型流程是解码得到HDR帧从YCbCr转换到RGB并做色彩空间变换进入线性空间做色调映射然后做伽马校正输出到SDR帧缓冲。把这个链路写出来阅卷人就知道你不仅懂概念还懂业务落地。3.3 视频编码基础I帧、P帧、B帧与码率控制B站没有自研视频编解码器但那道关于视频编码的选择题仍然让我印象深刻给了三个帧类型问它们在解码时的依赖关系。这道题的考点是I帧关键帧独立解码不依赖其他帧。视频切片、随机播放入口都是从I帧开始。P帧前向预测帧参考前面的I帧或P帧解码。B帧双向预测帧参考前后的帧解码压缩效率最高但解码需要缓冲未来帧引入了延迟。B站作为一个视频网站对编码格式、帧类型排布、码率档位的理解是基础中的基础。你可以不用会写编码器但必须要知道编码参数如何影响画面质量和带宽占用。笔试题里还有一处考察CBR和VBR的区别。CBR是恒定码率简单可控但画面质量波动大VBR是可变码率在画面静止时用低码率、运动剧烈时用高码率画质更稳定但码率峰值不可控。B站这种视频平台做转码时通常会选择接近VBR的策略用更精细的码率控制算法在保证画质的同时控制存储和带宽成本。答题时如果能提到场景切换时需要插入I帧以便快速刷新画面这层工程细节会比单纯背概念得分高很多。4. 编程题复盘双线性插值、三角形包含与图像缩放的那些坑编程题是这套笔试的大头题量在两道到三道之间要求用C或Python实现。题型涵盖图像缩放、几何判断、矩阵操作、连通域标记等。这里我挑两道最有代表性的讲一下解题思路和笔试环境中容易出问题的细节。4.1 手写双线性插值缩放考点不是算法是边界处理第一道编程题是给定一张灰度图WxH和缩放倍数用双线性插值实现缩放输出目标尺寸的图像。题目本身不复杂算法核心公式我在复习时背得很熟但真正动手写的时候边界处理差点翻车。双线性插值的核心思路是目标图像上的像素点映射回源图像上会有一个浮点坐标取这个浮点坐标周围的四个最近像素按距离加权平均得到新像素值。例如目标坐标(x_dst, y_dst)通过缩放比例映射到源坐标(src_x, src_y) (x_dst * scale_x, y_dst * scale_y)然后取src_x的整数部分x0和小数部分fx同理取y0和fy四个源像素分别是(x0, y0), (x01, y0), (x0, y01), (x01, y01)插值结果为v (1-fx)(1-fy)v(x0, y0) fx(1-fy)v(x01, y0) (1-fx)fyv(x0, y01) fxfy*v(x01, y01)实际踩坑点有两个。第一个是当src_x或src_y接近源图像边缘时x01或y01会越界必须做clamp处理。我在笔试时一开始没写边界钳制直接用数组索引程序在缩放倍数大于1时直接越界崩溃。这里需要注意的细节是浮点坐标有可能是负的尤其是做坐标对齐时用(x_dst 0.5) * scale - 0.5这种对称采样的写法时x0可能算出-1此时也要钳制到0。第二个坑是目标坐标与原图坐标的中心对齐问题。如果不做中心对齐直接把src_x x_dst * scale缩放后图像会整体偏移半个像素视觉效果会有轻微偏斜。笔试题目没有明确要求但如果你在代码注释里写一句这里采用中心对齐采样避免像素偏移这会成为加分项。我在笔试时的实现代码如下面的示例尽量精简但保留了必要的边界处理void bilinearScale(const uint8_t* src, int srcW, int srcH, uint8_t* dst, int dstW, int dstH) { float sx static_castfloat(srcW) / dstW; float sy static_castfloat(srcH) / dstH; for (int y 0; y dstH; y) { float srcY (y 0.5f) * sy - 0.5f; int y0 static_castint(floorf(srcY)); float fy srcY - y0; y0 std::max(0, std::min(y0, srcH - 1)); int y1 std::min(y0 1, srcH - 1); for (int x 0; x dstW; x) { float srcX (x 0.5f) * sx - 0.5f; int x0 static_castint(floorf(srcX)); float fx srcX - x0; x0 std::max(0, std::min(x0, srcW - 1)); int x1 std::min(x0 1, srcW - 1); float v00 src[y0 * srcW x0]; float v10 src[y0 * srcW x1]; float v01 src[y1 * srcW x0]; float v11 src[y1 * srcW x1]; float v v00 * (1 - fx) * (1 - fy) v10 * fx * (1 - fy) v01 * (1 - fx) * fy v11 * fx * fy; dst[y * dstW x] static_castuint8_t(v 0.5f); } } }写完代码后我还做了两个简单测试放大两倍后图像的四个角像素颜色是否保持原来的角颜色缩小后图像的平均亮度是否和原图接近。这两个测试能快速发现坐标映射和边界处理的问题建议笔试时自己也跑一下。4.2 点与三角形的位置关系从叉积符号到边界判定第二道编程题是给定平面上一个点P和三角形三个顶点A、B、C判断P是否在三角形内部包含边界。这道题看着像计算几何实际上是图形学里最基础的射线求交、裁剪、光照判定逻辑的简化版。这里我采用的是叉积符号法三角形三条边AB、BC、CA分别和点P构成三个叉积如果三个叉积符号相同全正或全负P在三角形内部。核心公式是d1 cross(AB, AP) (B.x - A.x) * (P.y - A.y) - (B.y - A.y) * (P.x - A.x)d2 cross(BC, BP)d3 cross(CA, CP)如果d1、d2、d3同号或为零则P在三角形内。这个算法的时间复杂度是O(1)非常快适合批量处理大量点。笔试填空题/编程题里经常会出现。但这里有一个很容易被忽略的边界情况当点恰好落在三角形的某条边上时对应叉积为0。如果直接用全正或全负判断零值会导致结果不确定。我在笔试里额外处理了这个情况d1、d2、d3中有一个为0而另外两个同号时也判定为内部因为题目要求包含边界。另一种更稳妥的解法是用重心坐标把P表示成P u * A v * B w * C其中u v w 1如果u、v、w都在[0, 1]范围内则P在三角形内。重心坐标法的好处是不仅能判断是否在内部还能直接输出插值权重这在渲染管线里做顶点属性插值时用得上。笔试时写这种方法能体现你对图形学更深入的理解。4.3 编程题之外的隐藏考察点内存管理与性能编程题里有一个不写出来但实际存在的考察维度你的代码是否考虑到性能。同样实现图像缩放有人用vectorvectoruint8_t做二维数组访问时连续两次索引缓存局部性差有人直接用一维数组用y * width x计算索引访存连续性能好很多。B站的图像处理都是高性能场景笔试环境虽然不会真正压测你的代码但阅卷人看到一维数组指针运算的风格和二维vector的风格打分是有差异的。我建议写图像类编程题时统一用一维数组加步长索引的方式同时注意循环顺序——先循环y再循环x保证对源图像的内存访问是行优先的这对缓存友好。另外笔试时如果题目没有明确要求优化也尽量保证代码是纯函数式的不要改入参。把输入的原图作为不可变数据输出写到新的缓冲区里这种设计更符合图像引擎中多线程处理的习惯多个线程同时处理不同图像块时不能互相干扰。5. 简答与设计题如何组织一个让阅卷人点头的方案这套笔试卷最后有两道简答/设计题都是开放性问题没有标准答案但非常考验工程思维。我从里面挑两道最具代表性的讲讲答题时应该怎么搭框架、列要点。5.1 设计一个实时的视频美颜滤镜流水线这道题几乎是B站这种视频社区必考的摄像头采集视频流经过美颜处理最终渲染到屏幕请设计一个完整的处理链路并说明每一步的算法选型和原因。我的答题框架分成五个模块采集与预处理从摄像头拿到YUV帧先做降噪。简单方案是空间域的高斯滤波计算量可控但要在美颜前做否则后续滤镜会放大噪声。人脸关键点检测用轻量级人脸关键点模型如人脸106点或240点定位脸部区域。这里我强调了一个工程细节关键点检测不需要每帧都跑可以在检测到脸后使用跟踪算法如光流或卡尔曼滤波来降低计算频率比如每5帧检测一次中间帧用跟踪结果做插值。皮肤区域检测与美颜处理在YCbCr或RGB空间里通过肤色范围Cr通道的阈值分割在大约77到127之间Cb通道在133到173之间具体值需要根据实际效果调整找出皮肤区域。美颜的核心是双边滤波或导向滤波做保边磨皮而不是用高斯滤波全部糊掉因为高斯滤波会把眼睛、眉毛等高频细节也磨没了画面会显得很假。妆容与滤镜叠加通过颜色查找表LUT做风格化滤镜用图层混合模式做妆容效果。B站直播场景里还要考虑美妆贴纸和人脸关键点的对齐这需要把2D贴纸通过仿射变换或透视变换贴着关键点位置做渲染。编码与输出美颜后的帧要送入编码器。如果是在直播链路里这里必须考虑整个流水线的延迟预算——从采集到编码建议控制在100毫秒以内否则观众侧的延迟会明显上升。这道题拿分的关键不在于你列出了多少个算法而在于你有没有考虑性能与画质的平衡。比如人脸关键点检测用轻量级模型、磨皮用双边滤波的分层实现高频层与低频层分离后分别处理、滤镜用LUT查表而不是像素级逐项计算这些都是实际工程落地时会做的取舍。把这些写进去阅卷人就知道你不是只会背算法的学生。5.2 弹幕渲染的性能优化从CPU到GPU的降本增效另一道设计题和B站主营业务强相关如何优化客户端弹幕渲染性能使其在高密度弹幕下依然保持流畅。这道题的答题思路不能只停留在减少绘制数量上。我把弹幕渲染的性能优化拆成四个层次数据层弹幕数据从网络到达后先做解析和过滤丢弃已经过期、在屏幕外和重复的弹幕减少无效数据量。合批与实例化把同一样式的弹幕文本合并成一个批次绘制。每条弹幕是一个纹理文字渲染到纹理上用实例化绘制一次提交多个四边形避免每条弹幕都调用一次Draw Call。缓存弹幕文字不变时纹理缓存复用。只有文字内容、颜色、边框样式变化时才重新生成纹理。弹幕纹理采用字幕渲染的典型方案——字符图集Glyph Atlas把常用汉字和符号预先烘焙到一张大纹理上。渲染策略在GPU端处理弹幕的移动和透明度变化CPU只负责传初始数据和更新逻辑参数。开启硬件加速后弹幕的位移动画全部交给顶点着色器做这样即使弹幕数量达到几百条CPU的占用率也几乎不变。我还特意提到高密度弹幕时可以用一个淡出策略——当屏幕上弹幕数量超过阈值时优先渲染高优先级弹幕如付费弹幕、彩色弹幕、大字号弹幕普通弹幕做降级处理降低透明度或延迟显示。这不是简单的性能取舍而是产品层面的体验设计。能把这一层考虑到答题的完整度会高很多。5.3 简答题的通用答题框架复盘这两道设计题我发现可以用同一个框架来应对输入-处理-输出三段式加上性能考量与异常处理。具体来说先明确输入是什么YUV帧、弹幕数据列表再说明处理链路里每一步做什么、为什么这么做然后是输出是什么RGB帧、合成后的画面最后补充整个方案在性能上的瓶颈在哪里、你如何优化它。最后别忘了异常情况——内存不足时怎么办、摄像头权限被拒绝时怎么办、弹幕量突然暴增时怎么办。这些异常处理的细节恰恰是区分应届生和工程师的地方。6. 复盘与自查笔试后我重新画了一遍考点地图考完试当天晚上我没有立刻去对答案而是把整张试卷的考点重新画了一遍地图用来检查自己哪些地方学得扎实、哪些地方只是知道但不会用。这套复盘方法也推荐给接下来要投递的同学。6.1 从考试题型反推知识薄弱点我把自己在两个小时内遇到的所有题目按轻松答出犹豫后答出完全不会三档做了标记。结果发现犹豫和不会的题目高度集中在两个区域视频编码相关概念、GPU并行计算的细节。视频编码那块我平时看图形学帖子时很少主动去碰因为觉得和自己方向没关系。但笔试里明确考了I帧、P帧、B帧的依赖关系和码率控制这提示我如果目标岗位在视频网站视频编解码的基础知识是绕不开的哪怕不深入实现也要能说清楚帧类型、GOP结构、码控对画质和带宽的影响。GPU并行计算那块有一道题考察了GPU线程组织的基本概念线程束Warp、工作组、共享内存这些名词我虽然知道但在真实图像处理里使用它们的经验几乎为零。笔试后我特意去写了一个简单的GPU高斯滤波核通过共享内存做分块处理再来回看那道题一下就理解了考点背后的工程价值。6.2 图像引擎方向校招复习的优先级排序基于这次笔试的体验我给后续准备的同学排一个复习优先级按投入产出比从高到低排列第一优先级线性代数基础、渲染管线全流程、图像插值与滤波算法这些是考得最多、也最容易短期提分的部分。第二优先级色彩空间与伽马校正、视频编码基础概念、C内存布局与智能指针这部分决定你能不能拿到第二梯队分数。第三优先级GPU计算基础、并行算法优化思路、实时渲染中的性能分析这些在笔试中占比不大但简答题里容易成为拉分项面试环节也一定会被问到。每次刷题或复习时建议顺手记一个场景-技术对照表。比如看到弹幕过多导致卡顿就联想到合批、纹理图集、GPU顶点动画看到视频滤镜颜色发灰就联想到线性空间与伽马校正。你积累的场景越多笔试和面试时就越有素材。6.3 给下一届同学的几个实操建议最后说几个具体建议都是我自己踩过的或复盘时觉得值得注意的点第一笔试环境如果支持本地编译一定要写完代码后自己构造一组测试数据跑一遍。我写图像缩放那道题时最初用了一个1x1的小图做测试发现数组越界后马上修正了如果没有这个测试那道题大概率要扣分。第二简答题尽量画流程图手绘或文字描述均可把链路阶段和阶段之间的输入输出关系标注清楚。阅卷人看一屏幕文字方案会头疼但看到一条清晰的处理链路会很快get到你的思路。第三准备一份自己的项目案例库每个案例能一句话说清楚背景、技术难点、我的方案、最终效果。笔试卷虽然没有直接问项目但简答题里你引用自己项目经验时的细节程度会让阅卷人对你的真实水平有一个很直观的预判。笔试的意义不是让你考完就忘而是帮你把散落的知识点通过岗位视角重新组织起来。图像引擎方向的边界其实很宽从矩阵运算到视频编码从渲染管线到并行计算每个方向都值得持续深入。希望这份复盘能帮你少走一些弯路祝你顺利。