这一篇就接着动作活体往下讲：三色 / 炫彩 / 光照响应活体到底在验证什么，它补了动作活体的哪一块，又为什么仍然不能被理解成“已经证明真人可信”。
先把边界放在前面：本文只做防御视角的机制拆解，不提供绕过步骤、攻击样本、工具链、关键参数或可复现路径。FaceAISDK 仍然只是一个公开流程样本，主角不是某个 SDK，而是三色 / 炫彩活体这一类设计的防御位置。
1. 第一篇留下的问题
如果你是从这一篇才进来的，可以先把第一篇《看懂身份验证中的活体检测（一）：动作检测》当成前置阅读。那篇已经拆过一条基础链路：摄像头帧如何进入 SDK，如何变成 ML Kit / native face detector 输出的 Face / List<Face>，再如何被动作状态机消费。本文会保留必要上下文，但不重复展开 Face 对象的完整构造过程。
动作活体解决的是一个很朴素的问题：
画面里的人脸有没有按要求动起来？
它比静态照片校验更强，因为它要求一段时间里的姿态、眼睛、嘴部、表情等特征发生变化。第一篇里我们看到，动作状态机读取的是 ML Kit Face 输出的 pitch、yaw、眼睛开合概率、微笑概率和嘴唇轮廓变化，然后判断动作序列是否完成。
但动作活体也有一个结构性边界：
它验证“呈现了动作”，不验证“这段画面从哪里来”。
所以，防御演进的下一步很自然：既然只看动作还不够，那能不能再看人脸区域对屏幕光照变化的响应？能不能让画面不只是“动起来”，还要对系统主动给出的颜色变化做出合理反馈？
这就是三色 / 炫彩活体进入链路的原因。
2. 三色 / 炫彩 / 光照响应活体是什么
三色、炫彩、Color Flash、光照响应，这几个词在不同产品里叫法不完全一样，但它们要回答的是同一类问题：
当屏幕主动切换颜色时，画面里的人脸区域有没有出现相应的颜色 / 亮度响应？
换成防御语言，它验证的是：
人脸 ROI 是否随着屏幕颜色变化，呈现出相应的可见光响应。
这和动作活体的关注点不同。
动作活体问的是：
画面里的人脸有没有完成指定动作？
三色 / 炫彩活体问的是：
画面里的人脸区域，是否对屏幕发出的颜色变化产生了可见光响应？
前者看“动没动”，后者看“这张脸所在区域有没有跟着屏幕颜色变化而变化”。至于不依赖屏幕闪光、只从单帧人脸 crop 做分类的静默活体，留到第三篇单独讲。
3. 从公开流程看：这一层读的是什么信号
先不用懂活体检测，把这一层当成一条很普通的流水线就行：
摄像头拿到一帧画面 -> ML Kit 在画面里找脸 -> SDK 选出最大的人脸 -> 屏幕依次打白 / 红 / 绿 / 蓝光 -> SDK 只裁出人脸区域 -> 统计这块人脸区域的 RGB / 亮度变化 -> 判断颜色响应是否合理 -> 输出炫彩过程状态
这条链路里有几个词先对齐一下。
Face：ML Kit 检测出来的人脸对象，里面有脸框、角度、眼睛、轮廓等信息。它从摄像头帧到 Java 对象的构造链路，第一篇已经展开；本篇只看三色 / 炫彩如何继续使用它。boundingBox：这张脸在画面里的矩形位置，也就是“脸在哪一块”。ROI：Region of Interest，感兴趣区域。这里就是从整张图里裁出来的人脸区域。RGB / luma：RGB 是红、绿、蓝三个颜色通道，luma 可以粗略理解成亮度。gainScore：炫彩响应分，表示人脸区域对屏幕颜色变化的响应够不够明显。onProcessTips：过程状态码，比如动作完成、炫彩开始、炫彩通过、炫彩失败、环境光过强。
3.1 先拿到摄像头画面，再交给人脸检测
第一步不是活体判断，而是最基础的“画面进来”。Demo 用 CameraX 拿到一帧帧图像，再把图像交给 SDK：
[F1:138] cameraXFragment.setOnAnalyzerListener(imageProxy -> { // CameraX 每拿到一帧图像就回调这里
[F1:141] faceVerifyUtils.goVerifyWithImageProxy(imageProxy); // 把这一帧交给活体检测入口
[F2:95] DataConvertUtils.o0oOooO0(imageProxy, o0oo0ooo.OooOO0o); // 把 ImageProxy 转成 SDK 可处理的 Bitmap
[F2:97] o0oo0ooo.o0oOooO0(null, o0oo0ooo.OooOO0o); // 把 Bitmap 送进后续检测流程
这一段只说明一件事：后面的三色判断，最初来自摄像头实时画面。它不是直接从一张“人脸照片”开始，也不是从活体模型直接开始。
3.2 Face 从 ML Kit 来，不是炫彩逻辑自己算出来的
拿到 Bitmap 以后，SDK 会先调用 ML Kit 做人脸检测。只有先知道“脸在哪里”，后面才知道该裁哪一块区域去看颜色变化。
这部分和第一篇的动作活体有重叠，所以这里不再完整复写 native 人脸检测链路。读者只需要记住一件事：这里的 Face 不是炫彩检测模型算出来的“活体结果”，而是上游人脸检测链路给下游状态机的一份人脸结构化结果。
[F3:224] this.f59o0Oo0Ooo.o0oOooO0(false, bitmap2, ...); // 把 Bitmap 交给封装后的人脸检测器
[F4:183] this.f80o0oOooO0.process(InputImage.fromBitmap(bitmap, 0)) // 用 ML Kit 处理这张 Bitmap
[F4:196] Face face = (Face) Collections.max(list, f77o0Oo0Oo); // 如果有多张脸，选面积最大的那张
[F4:201] o0ooodoo.o0oOooO0(face, bitmap, list.size()); // 把最大脸、原图和人脸数量交给主状态机
所以这里的 Face 可以理解成“ML Kit 已经在画面里找到的人脸”。三色 / 炫彩逻辑不是先判断真假人，而是先复用这个 Face，用它的脸框去定位人脸区域。
3.3 屏幕不是随便闪，它会按序列显示白、红、绿、蓝
三色 / 炫彩检测要验证的是“屏幕打出的颜色，是否真的反映到摄像头里的人脸区域上”。所以它必须先让屏幕显示不同颜色。
[F3:172] public static int[] o0oOooO0() { // 生成一组炫彩颜色序列
[F3:174] arrayList.add(-65536); // 加入红色，对应 0xFFFF0000
[F3:175] arrayList.add(-16711936); // 加入绿色，对应 0xFF00FF00
[F3:176] arrayList.add(-16776961); // 加入蓝色，对应 0xFF0000FF
[F3:177] Collections.shuffle(arrayList); // 打乱红绿蓝顺序，避免固定顺序
[F3:178] int[] iArr = new int[4]; // 准备一个包含白色基线和三种颜色的数组
[F3:179] iArr[0] = -1; // 第一个颜色是白色，可以理解为基线光
[F3:184] iArr[i] = ((Integer) arrayList.get(i2)).intValue(); // 把打乱后的红绿蓝写入序列
-1 是白色，后面三个值分别是红、绿、蓝。这样设计的直觉很简单：先用白光拿一个基线，再看红光、绿光、蓝光照到脸上之后，人脸区域的颜色通道有没有跟着变化。
Demo 侧收到颜色后，会把颜色画到界面覆盖层上，也就是让屏幕真的变色：
[F1:117] public void onColorFlash(int color) { // SDK 通知 Demo 当前应该显示哪种颜色
[F1:118] faceCoverView.setFlashColor(color); // Demo 把这个颜色画到屏幕上
到这里，读者可以先抓住一句话：三色检测不是“看脸长什么样”，而是“屏幕给一个颜色刺激，再看摄像头里的人脸区域有没有被这个刺激影响”。
3.4 屏幕闪烁到底是什么，以及为什么要快速闪
这里说的“闪烁”，不是打开手机相机闪光灯，也不是额外调用什么神秘硬件。它本质上就是 SDK 通过回调告诉 App：“现在把屏幕区域刷成这个颜色。”App 收到颜色值后，把界面覆盖层改成对应的纯色。
[F8:8] public void onColorFlash(int i) { // SDK 定义的炫彩颜色回调入口
[F1:117] public void onColorFlash(int color) { // Demo 实现这个回调，接收当前要显示的颜色
[F1:118] faceCoverView.setFlashColor(color); // 把界面覆盖层设置成对应颜色，让屏幕真的变色
所以“屏幕闪烁”的代码原理很朴素：SDK 负责决定颜色序列和切换节奏，App 负责把颜色画到屏幕上。摄像头继续采集人脸画面，于是屏幕光、环境光和皮肤反射一起进入摄像头。
市面上的活体 SDK 往往会把这几种颜色放在一个很短的连续窗口里快速完成，原因主要有四个。
第一，颜色响应必须可比较。红、绿、蓝最好发生在同一次检测、同一张脸、同一距离、同一姿态附近。如果拖太久，用户头动了、距离变了、环境光变了，后面比较 RGB 变化就会混入太多无关因素。
第二，屏幕光本来就是一个主动挑战。系统主动给出白、红、绿、蓝，摄像头端应该看到对应响应。快速连续切换，可以让这组响应形成一段短时间内的“颜色响应曲线”，而不是几张彼此无关的照片。
第三，用户体验不能太长。身份验证里的活体检测通常要求几秒内完成，如果每种颜色都停很久，用户会觉得流程卡顿，也更容易移动、眨眼、偏头或退出。
第四，相机自动曝光和白平衡会影响颜色。代码里会给每个颜色阶段留一点等待时间，让画面稳定后再采样，但仍然把整个流程压在短窗口里：
[F5:427] if (state.f56o0Oo0Oo == 0) { // 如果炫彩计时还没启动
[F5:428] state.f51o0Oo0OOO.onProcessTips(25); // 发出状态码 25，表示炫彩开始
[F5:429] Intent lock = new Intent("com.myapp.action.APP_STATUS_CHANGE") // 准备通知 App 进入炫彩采样状态
[F5:431] LocalBroadcastManager.getInstance(state.f48o0oOooO0).sendBroadcast(lock); // 广播状态变化，配合后续采样流程
[F5:436] if (state.OooO0oo < state.OooO0Oo.length) { // 如果颜色序列还没有采完
[F5:437] long elapsed = System.currentTimeMillis() - state.f56o0Oo0Oo; // 计算当前炫彩阶段已过去多久
[F5:438] long need = state.OooO0oo * 1000L + 700L; // 给当前颜色阶段预留稳定和采样时间
[F5:439] if (elapsed <= need) return; // 时间没到就继续等待，不急着采样
[F5:442] Stat stat = computeRgbStat(roi); // 时间到了，再统计当前人脸 ROI 的 RGB / 亮度
[F5:443] state.OooO0o.add(state.OooO0oo, stat); // 保存这个颜色阶段的统计结果
[F5:444] state.OooO0oo++; // 切换到下一个颜色阶段
[F5:447] state.f51o0Oo0OOO.onColorFlash(state.OooO0Oo[state.OooO0oo]); // 通知界面显示下一种颜色
这里的“快速”不是高频频闪，也不是越快越好，而是“在用户还保持同一次检测姿态时，连续完成白、红、绿、蓝的刺激和采样”。这样得到的 RGB / luma 变化才更像同一轮检测里的可比较证据。
3.5 在组合模式里，动作完成后才进入炫彩
如果当前用的是动作 + 炫彩组合模式，流程通常不是一开始就打三色，而是先要求用户完成动作。动作通过以后，再进入屏幕变色阶段。
[F5:366] if (actionPassed) { // 如果动作检测已经通过
[F5:376] state.f51o0Oo0OOO.onTimeCountDown(1.0f); // 把动作阶段进度置为完成
[F5:377] state.f51o0Oo0OOO.onProcessTips(20); // 发出状态码 20，表示动作完成
[F5:378] if (state.o0oOo000() /*isColorFlash()*/) { // 如果当前模式包含炫彩检测
[F5:379] state.f51o0Oo0OOO.onColorFlash(state.OooO0Oo[0]); // 发出第一个屏幕颜色，启动炫彩
这几行解释了一个很容易误读的点：动作完成不等于整套活体完成。它只是把流程推进到下一层，让屏幕开始打颜色。
3.6 裁人脸 ROI：只看脸，不看整张画面
屏幕变色后，摄像头画面里的很多东西都会变亮或变色，比如背景、衣服、墙面。但三色 / 炫彩真正关心的是人脸区域，所以它用前面 ML Kit 给出的 Face.boundingBox 从整张图里裁出脸。
这里也能和第一篇接上：动作活体用同一个 Face 去读姿态角、眼睛概率、嘴唇轮廓；三色 / 炫彩则用同一个 Face.boundingBox 去裁 ROI。也就是说，第二篇不是换了一条完全独立的链路，而是在第一篇的人脸检测结果之上，继续问“这块脸有没有响应屏幕光”。
[F5:398] Rect r = face.getBoundingBox(); // 从 ML Kit Face 里取出人脸矩形框
[F5:399] int rx = RangesKt.coerceAtLeast(r.left, 0); // 人脸框左边界不能小于图像左边界
[F5:400] int ry = RangesKt.coerceAtLeast(r.top, 0); // 人脸框上边界不能小于图像上边界
[F5:401] int rw = RangesKt.coerceAtMost(r.right, fullBitmap.getWidth()) - rx; // 计算裁剪宽度，避免越过图像右边界
[F5:402] int rh = RangesKt.coerceAtMost(r.bottom, fullBitmap.getHeight()) - ry; // 计算裁剪高度，避免越过图像下边界
[F5:403] Bitmap roi = Bitmap.createBitmap(fullBitmap, rx, ry, rw, rh); // 从整张图里裁出人脸 ROI
这一步非常关键。它把问题从“整张画面有没有变色”，收束成“脸这块区域有没有合理变色”。如果不裁 ROI，背景光、衣服颜色、屏幕边缘反光都可能干扰判断。
3.7 正常肤色大概是什么，红绿蓝反光后大概会怎样
这块数据很关键。它是读者把“三色检测”从抽象概念理解成视觉信号的桥。
先说物理直觉。晚上手机屏幕照脸时，屏幕偏红，脸会被照得偏红；屏幕偏绿，脸会带一点绿；屏幕偏蓝，脸会带一点蓝。摄像头最终看到的是“环境光 + 屏幕光 + 皮肤反射 + 自动曝光 / 白平衡”混在一起的结果。
因此，三色 / 炫彩活体不是在找一个固定肤色，而是在看颜色变化的方向是否合理。红屏时，ROI 的 R 通道通常应该相对抬高；绿屏时，G 通道应该相对抬高；蓝屏时，B 通道应该相对抬高。
下面这些数值只是帮助理解的普通 sRGB 经验区间，不是 SDK 的固定判定阈值，也不是人种 / 肤色判断。真实值会受肤色、屏幕亮度、环境光、摄像头曝光、自动白平衡影响。
| 场景 |
ROI RGB 经验变化，按 0-1 归一化理解 |
代码真正检查的东西 |
| 白光 / 自然光基线 |
常见人脸区域大致可落在 R 0.50-0.85 / G 0.35-0.70 / B 0.25-0.60 |
作为后续增益比较的 baseStat |
| 红屏反光后 |
R 往往比基线抬高约 0.08-0.25，并应接近本轮采样里的 maxR |
红色阶段的 R 不能明显低于 maxR |
| 绿屏反光后 |
G 往往比基线抬高约 0.06-0.22，并应接近本轮采样里的 maxG |
绿色阶段的 G 不能明显低于 maxG |
| 蓝屏反光后 |
B 往往比基线抬高约 0.05-0.20，并应接近本轮采样里的 maxB |
蓝色阶段的 B 不能明显低于 maxB |
所以别把这件事理解成“SDK 规定真人肤色必须是多少”。更准确的理解是：它在同一轮检测中比较多个颜色阶段，看对应颜色通道有没有跟着屏幕刺激抬起来。
3.8 每一种颜色停一下，再采样 ROI 的 RGB / 亮度
屏幕刚变色时，摄像头画面不会瞬间稳定，自动曝光、白平衡和屏幕反光都需要一点时间。所以代码会等一小段时间，再统计当前人脸 ROI 的颜色。
[F5:436] if (state.OooO0oo < state.OooO0Oo.length) { // 如果还有颜色阶段没有采样
[F5:437] long elapsed = System.currentTimeMillis() - state.f56o0Oo0Oo; // 计算当前颜色已经显示了多久
[F5:438] long need = state.OooO0oo * 1000L + 700L; // 计算当前阶段需要等待的时间
[F5:439] if (elapsed <= need) return; // 时间还不够就先返回，继续等画面稳定
[F5:442] Stat stat = computeRgbStat(roi); // 对当前人脸 ROI 计算 RGB / 亮度统计
[F5:443] state.OooO0o.add(state.OooO0oo, stat); // 把这一次颜色阶段的统计值保存起来
[F5:444] state.OooO0oo++; // 进入下一个颜色阶段
[F5:447] state.f51o0Oo0OOO.onColorFlash(state.OooO0Oo[state.OooO0oo]); // 通知界面切换到下一种屏幕颜色
这段可以翻译成一句话：白、红、绿、蓝每个阶段都截一次脸，算一次颜色统计，最后把这些统计值放在一起比较。
3.9 判断一：对应颜色通道有没有成为本轮高响应
有了多次采样结果以后，算法先找出本轮检测里 R、G、B 三个通道各自的最大值。然后检查每个颜色阶段是否“像它应该像的样子”。
[F5:461] int[] colorSeq = state.OooO0Oo; // 取出本轮白 / 红 / 绿 / 蓝颜色序列
[F5:462] List<o0Oo0Ooo.oo000o> stats = state.OooO0o; // 取出每个颜色阶段的人脸 ROI 统计值
[F5:465] for (int i = 1; i < stats.size(); i++) { // 从第一个彩色阶段开始遍历统计值
[F5:467] if (s.f158o0oOooO0 > maxR) maxR = s.f158o0oOooO0; // 记录本轮 R 通道最大响应
[F5:468] if (s.f159o0ooODOO > maxG) maxG = s.f159o0ooODOO; // 记录本轮 G 通道最大响应
[F5:469] if (s.f160o0oOo000 > maxB) maxB = s.f160o0oOo000; // 记录本轮 B 通道最大响应
[F5:476] int violations = 0; // 准备记录颜色响应不符合预期的次数
[F5:480] if (color == 0xFFFF0000 && s.f158o0oOooO0 < maxR - 0.1) violations++; // 红屏时 R 通道不能明显低于本轮最大 R
[F5:481] if (color == 0xFF00FF00 && s.f159o0ooODOO < maxG - 0.1) violations++; // 绿屏时 G 通道不能明显低于本轮最大 G
[F5:482] if (color == 0xFF0000FF && s.f160o0oOo000 < maxB - 0.1) violations++; // 蓝屏时 B 通道不能明显低于本轮最大 B
[F5:486] if (violations > 0) { // 如果出现不符合预期的颜色响应
[F5:487] gainScore = 0.01f; // 直接把炫彩响应分压到很低
这里的判断很直白：红光照脸，R 通道应该是强响应；绿光照脸，G 通道应该是强响应；蓝光照脸，B 通道应该是强响应。如果对应通道没有起来，说明这轮屏幕颜色和人脸 ROI 的响应关系不够合理。
3.10 判断二：红 / 绿相对基线的增益够不够
第一层看的是“对应通道有没有接近本轮最大值”。第二层继续看“相对基线有没有明显抬高”。这里的 baseStat 可以理解成白光 / 初始阶段的人脸颜色基线。
[F5:494] double redGain = (rStat.f158o0oOooO0 - baseStat.f158o0oOooO0) // 计算红屏阶段 R 通道相对基线的增益
[F5:496] double greenGain = (gStat.f159o0ooODOO - baseStat.f159o0ooODOO) // 计算绿屏阶段 G 通道相对基线的增益
[F5:498] double avgGain = (redGain + greenGain) / 2.0; // 把红色增益和绿色增益做平均
[F5:508] float raw = (avgGain < 0.03d) ? 0.1f : 0.98f; // 平均增益太弱就给低分，否则给高原始分
[F5:509] gainScore = Math.min(1.0f, Math.max(0.0f, raw * 0.25f + 0.75f)); // 把原始分映射成最终炫彩响应分
[F5:512] state.OooO = gainScore; // 保存本轮炫彩响应分
这段说明，算法不是只看某个颜色通道有没有最大值，还会看它相对初始状态有没有“真正变亮 / 变强”。如果屏幕换色了，但脸部 ROI 的对应通道几乎没变化，avgGain 就会偏低。
3.11 输出状态：炫彩通过、失败，还是环境光异常
最后，gainScore 会进入过程状态判断。这里要注意，组合模式里还会同时检查另一个活体条件 OooOOo0，它属于下一篇静默活体链路，本篇只标出它是另一个条件，不展开 native 代码。
[F5:515] if (gainScore > 0.75 && state.OooOOo0 > 0.75) { // 炫彩响应分和另一个活体条件都通过
[F5:516] state.f51o0Oo0OOO.onProcessTips(22); // 发出状态码 22，表示炫彩活体通过
[F5:521] state.f51o0Oo0OOO.onProcessTips(24); // 发出状态码 24，表示环境光过强
[F5:523] state.f51o0Oo0OOO.onProcessTips(23); // 发出状态码 23，表示炫彩活体失败
所以，三色 / 炫彩这一层读到的信号可以总结成一句话：
它读的不是“这个人是谁”，也不是“这张脸是不是真人”的最终答案，而是“屏幕主动打出颜色后，摄像头里的人脸 ROI 是否出现了对应的 RGB / 亮度响应”。
对集成方来说，Face 来源、ROI 裁剪、RGB/luma 采样、gainScore 和 onProcessTips(22/23/24) 要分开理解。把它们混成一个“活体通过”总分，后面复盘问题时就会看不清到底是哪一层在起作用。
4. 它解决了动作活体的什么不足
动作活体看姿态、眼睛、嘴部、表情变化，解决的是“画面里的人脸有没有按要求动”。三色 / 炫彩补的是另一件事：系统主动改变屏幕亮度和颜色后，人脸 ROI 的 RGB / luma 是否跟着变化。
一句话概括：动作活体看“动没动”，三色 / 炫彩看“这张脸有没有被当前屏幕光影响到”。它不是替代动作，而是在动作之外补一类实时光照响应证据。
5. 但它仍然没有覆盖什么
三色 / 炫彩仍然主要停留在“呈现层”。它能说明人脸 ROI 在屏幕变色时出现了相应颜色 / 亮度响应，但不能天然证明输入一定来自可信摄像头，也不能证明采集链路中间没有异常层。
它也不等于深度、红外、多光谱或静默纹理分类。它能提高只靠动作判断的厚度，但不能单独承担“来源可信”和“身份可信”的结论。
6. 防御方该怎么理解这一层
防御方最应该记录的不是一个“通过 / 失败”，而是分层状态：动作完成 20、炫彩开始 25、炫彩通过 22、炫彩失败 23、环境光过强 24、gainScore、最终回调分数。这样后续才能知道失败是动作问题、光照响应问题、环境问题，还是组合链路里的其他条件问题。
三色 / 炫彩应该作为一层视觉证据进入更大的风控链路，和设备侧采集一致性、传感器信号、行为上下文、风险历史、来源完整性一起判断。它很有价值，但不要让它单独背“来源是否可信”的锅。
7. 小结
“三色有没有”的答案是：有，而且值得单独讲。
它不是动作活体的复述。动作活体看动作序列，三色 / 炫彩活体看人脸区域对屏幕颜色变化的响应。
它也不是终点。它让防线从“有没有动”走向“人脸区域是否响应屏幕光”，但它仍然没有天然覆盖来源可信、链路完整性、静默纹理分类、深度、多光谱和更完整的风控上下文。
所以，对防御方来说，三色 / 炫彩活体最正确的位置是：
一层有价值的光照响应证据，而不是整条身份验证链路的最终裁决。
文末预告
下一篇进入静默活体，也就是 libLiveness.so 这条链路。
这一层不再靠用户动作，也不靠屏幕三色闪光，而是看单帧人脸 crop 在模型里如何被分类。它补的是另一类视觉证据，但同样有自己的结构性边界。
活体检测的防御演进，仍然是一层一层长出来的。
代码索引说明：文中的 [F*] 标记来自我对 FaceAISDK 公开代码流程的防御侧整理，只用于定位流程证据；本文不包含攻击实现、复现路径或攻击样本。
[复制链接]
发表于 2026-7-17 21:53
分享到朋友圈