在软件工程的长河中，我们总是在寻找那个完美的平衡点。尤其是在ZuoSDK重构或者封装的时候，那种想要“一劳永逸”的冲动简直难以抗拒。你kan着项目里散落一扫的扫脸相关代码，心里大概只有一个念头：把它们dou塞进那个黑盒子里让主工程变得干干净净。

这种想法太诱人了就像整理房间时把所有杂物一股脑塞进衣柜，关上门眼不见为净。但Zui近在重构扫脸SDK的过程中，我不得不按住这种冲动。特别是关于“结果页”和“历史记录”这两个模块，我Zuo出了一个kan似保守、实则深思熟虑的决定：坚决不把它们整合进SDK。

这不仅仅是一个技术选型的问题，geng关乎我们对SDK边界的理解。今天我想聊聊这背后的逻辑，以及为什么有时候“留一手”比“全盘接收”要高明得多。

封装的陷阱：当“彻底”变成负担

上一篇文章里我提到了这两周在死磕扫脸SDK，首要任务是稳住原有的功Neng。而这一篇，我想聊聊后面那个geng容易让人踩坑的误区：扫脸相关的代码确实多，但这并不意味着它们dou有资格住进SDK的“豪宅”里。

刚开始的时候，我也动摇过。kan着那些处理健康结果、生成PDF报告、管理历史记录的代码，心里总有个声音在说：“既然dou和扫脸有关，为什么不一起打包呢？这样kan起来多彻底啊。”

但冷静下来一想，Ru果真的这么Zuo了后果可Neng有点严重。想象一下Ru果SDK里不仅有相机、人脸识别算法、信号处理，还塞进了结果页、历史记录列表、PDF生成逻辑，甚至还有会员体系、埋点统计、首页卡片展示规则……这哪里还是SDK？这简直就是披着SDK外衣的另一个App外壳。

这种Zuo法带来的直接后果就是SDK变得极其臃肿。它不再是一个纯粹的扫脸工具，而是一个携带了特定业务逻辑的“巨无霸”。别的AppRu果想接入这个SDK，不仅要获得扫脸Neng力，还得被迫接受这套页面设计、这套文案风格、这套历史记录规则。这显然违背了我们ZuoSDK的初衷——复用与解耦。

划清界限：SDK应该“变强”而非“变重”

这里我想抛出一个核心观点：SDK应该变强，但不应该变重。

所谓的“变强”，是指它在核心Neng力上要无可挑剔。比如它必须Neng独立处理相机调用、人脸精准识别、测量判断、信号质量处理、健康指标计算、疾病风险评估以及总分重算。这些是硬骨头，是SDK安身立命的根本，必须由它来搞定。

而“不变重”，则是说它不要把那些属于特定App的业务逻辑背在身上。结果页怎么跳转、历史记录怎么存、PDF怎么排版、会员权益怎么校验、埋点数据怎么上报，这些统统不应该出现在SDK的代码里。

为什么？因为这些东西换一个产品，规则可Neng就全变了。A产品可Neng希望历史记录按时间倒序排列，B产品可Neng只想保留Zui近的三条；A产品的结果页是红底白字，B产品可Neng喜欢极简风。Ru果把这些dou写死在SDK里那这个SDK的复用性就荡然无存了。

两类代码的博弈

在拆分代码的时候，我试着把它们分成了两类：

第一类，是通用Neng力。比如心率、血压、血糖、BMI、疾病风险、健康总分。这些数据是任何Appdou需要的基础，所以它们的计算逻辑必须留在SDK里。不管接入方是谁，只要输入信号一样，算出来的分数必须一致。

第二类，是业务规则。比如页面上怎么展示“正常”、“偏高”、“偏低”这些文案，颜色是选绿色还是红色，弹窗的样式如何，PDF生成的模板长什么样。这些完全取决于当前App的产品设计，和SDK的核心算法没有半毛钱关系。

结果页与历史记录：为何必须留在主工程？

回到标题的问题，为什么不整合结果页与历史记录？原因其实hen简单，但hen容易被忽视。

从用户的角度kan，扫脸是一个连贯的体验：打开页面对准人脸，倒计时测量，kan到结果。但在代码的层面这其实至少是两个维度的东西。

Ru果我把结果页也塞进SDK，那么每次SDKgeng新一个字段，或者调整了一下展示规则，主工程里的结果页、PDF、历史记录甚至首页卡片dou可Neng跟着出问题。这种耦合度太高了维护起来简直是噩梦。

geng关键的是SDK不应该知道App是怎么组织页面的，也不需要知道历史是怎么保存的。

数据的波动与业务的处理

这里有一个hen典型的例子。扫脸测量不像用户手动输入体重，它受光线、距离、晃动、人脸状态的影响非常大。同一个用户连续测几次结果可Neng会有波动。

在原来的项目里App在把结果写入历史记录之前，会结合用户资料和历史数据Zuo一次平滑处理，避免结果浮动太大吓到用户。这显然是当前App的业务规则，属于“怎么展示这些数字”的范畴。

Ru果我把这个逻辑也塞进SDK，那就意味着SDK必须理解当前App的历史数据结构和用户资料规则。这太荒谬了。SDK只需要知道参与评分的指标就够了至于怎么存、怎么展示，那是App自己的家务事。

中间层的艺术：隔离而非绑定

当然不把结果页整合进SDK，并不意味着主工程就要和SDK藕断丝连。相反，我特意在主工程里保留了一小段中间代码。这段代码的作用非常关键：它专门Zuo数据整理，把App的数据模型转换成SDKNeng理解的格式，再把SDK返回的结果转换回App需要的模型。

有人可Neng会说：“这不是多此一举吗？这不是又多了一层？”

其实不然。这段代码本身不Zuo估算，也不重新实现算法，它只负责把App和SDK隔开。它就像一个翻译官，确保两边虽然语言不通，但Neng顺畅交流。

比如在Swift代码里我们可Neng会kan到这样的逻辑：

let request = ZZHFaceScanSDK.EstimationRequest(
    redSignal: redSignal,
    greenSignal: greenSignal,
    blueSignal: blueSignal,
    sampleRate: sampleRate,
    userProfile: profile.toSDKProfile,
    measurementContext: context.toSDKContext
)
switch engine.estimate {
case let .success:
    return .success)
case let .failure:
    return .failure(.estimationFailed(
        code: error.code,
        message: error.localizedDescription
    ))
}

你kan，这里没有传页面颜色，没有传文案，没有传历史记录，也没有传PDF相关的数据。SDK只拿到了它Zui关心的那些原始信号和用户画像。至于返回的结果，也会被转换成主工程熟悉的`HostEstimateResult`。

这样Zuo的好处显而易见：结果页、历史记录和PDF不需要跟着SDK的类型变化到处改。

展示规则的独立性

还有一段代码，我一开始也纠结过要不要放进SDK，那就是关于展示规则的逻辑。比如血压字符串怎么拼，心率状态怎么分，颜色怎么取。

Zui后我决定，这部分逻辑必须留在App里。它大概长这样：

enum SC_FaceScanHealthDisplayRules {
    static func bloodPressureText -> String {
        "\)/\)"
    }
    static func heartRateStatus -> HealthStatus {
        if metrics.heartRate <60 {
            return .low
        } else if metrics.heartRate> 100 {
            return .high
        }
        return .normal
    }
}

这段代码不属于SDK的核心Neng力，它解决的是当前App页面的视觉呈现问题。Ru果把它放进SDK，那么下次产品经理说“我们要把心率正常的颜色从绿色改成蓝色”，你就得去改SDK，然后重新发版，所有接入了这个SDK的Appdou得跟着变。这显然是不合理的。

克制是架构师的修养

这次Zuo完SDK重构，我对“边界”这个词有了geng深的理解。ZuoSDKhen容易有一种冲动：既然要封装，那就干脆把扫脸目录里的东西dou移走，越干净越好。

但真正的架构设计，往往是在Zuo减法。Neng删的旧算法代码要删，但不该进SDK的业务代码，也不Neng为了“kan起来geng彻底”就硬塞进去。

虽然主工程里确实还留了一些扫脸相关的文件，但现在的代码结构反而geng清晰了。一眼就Nengkan明白：哪些是在调用SDK，哪些是在服务当前App的页面和历史，哪些只是为了隔离数据结构。

所以回到Zui初的问题：为何SDK不整合结果页与历史记录？

因为一件是SDK应该算出来的数字，另一件是App自己决定怎么展示这些数字。

把这两件事分开，SDK才Neng保持干净、纯粹，成为一个真正可复用的扫脸工具；而App也Neng保留足够的自由度，去打造属于自己的独特用户体验。这不仅仅是代码的拆分，geng是责任的划分。在未来的日子里当业务需求像潮水一样涌来时你会庆幸自己今天守住了这条防线。

---