做门禁、闸机、考勤这类项目的开发者大多把注意力放在怎么识别得准上很少有人在项目上线前认真想过另一个问题这些人脸数据到底存在设备的什么地方员工离职之后要怎么做才算真的把它删干净这篇以百度智能云人脸离线识别 SDK 的 Android 版为对象顺着数据流向走一遍落盘在哪、落的是什么、占多少空间、删除时要动几处、清理动作怎么设计最后把合规那一层收成几句话。动笔前先说明一件事这套 SDK 的接口名在不同版本、不同专版之间并不统一。本文以官方《Android V9.0-SDK》为准2026-10-09 查阅凡是遇到命名或数值有差异的地方都会逐处标出来方便你对照自己手上那一版文档。一、数据集中的地方是一个 SQLite 文件先看官方对这套 SDK 的定位。百度智能云人脸离线识别 SDK 的官方文档《概览》里写得很直接人脸离线识别 SDK包含人脸采集、活体检测、人脸对比/识别、人脸库管理等能力并全部离线化、本地化。此 SDK 一经授权激活可完全在无网环境下工作所有数据皆在设备本地运行处理可根据业务需要进行灵活的上层业务开发。同一份文档里人脸库管理一节给的是容量口径支持人脸库、人脸组、用户、Face 4 个维度的增删改查设置人脸库推荐 5w 以内实际应用中 1W 以下最佳可根据业务需要适当调整。那么本地具体是哪个文件《Android V9.0-SDK》的 FaceApi 类说明里给了答案会在默认路径创建 face.db 人脸库文件、进行对人员信息和人脸特征的增删改查、都会保存在该文件中。路径也写明了dataLibrary 中默认会将注册的用户信息默认储存在 data/data/包名/database 数据库的 face.db 默认路径下。V9.0 文档在人脸库与特征缓存一节里还给它归了类SQLiteface.db持久化人员 ID、姓名、特征和可选头像。所以结论很简单也很关键在一台 Android 设备上所有人脸数据集中在一个face.db里它是一个 SQLite 数据库。知道这一点后面所有的备份、迁移、清理动作才有落点——你要操作的从来不是一堆散落的图片而是一个有明确路径的库文件。二、落进库里的是特征值不是照片第二个要搞清楚的问题face.db里存的到底是图像还是数值《Android V9.0-SDK》给了一条带免责说明的口径通用 9.0 Demo 使用512 字节特征数组。紧接着还有一句免责说明大意是不同专版可能不同必须以实际拿到的那一版 SDK 随附说明为准末句为本文对该说明的转述。同一文档的示例代码里也写着byte[] feature new byte[512];。也就是说一条人脸在通用版 Demo 的库里占的是 512 字节的特征向量不是一张 JPEG。这里要补一句版本差异。《Android-3568专版SDK》文档更新 2026-06-03在 Feature 实体类的说明里写的是feature byte[] 人员特征通常为512 字节组数3568 专版 SDK 为 1024 字节所以 512 这个数不是全平台统一值专版会把特征向量放大。按官方那句免责说明你在算容量、做迁移之前先确认自己拿到的是哪一版。另外有个细节值得单独提醒。同一份 V9.0 文档里demo 层的注册接口签名是这样的registerUserIntoDBmanager(String groupName, String userName, String picName, String userInfo, byte[] faceFeature)注意picName这个参数——它意味着注册流程除了写特征值还会带上一个图片名也就是 demo 在应用层另外留存了人脸图片文件此处为本文从接口签名所作的推断请以你自己工程的实现为准。这就带来一个很容易被忽略的后果你的设备上可能存在两份数据一份是face.db里的特征值一份是应用层自己管的图片文件。做清理时只删了库图片文件还躺在存储里这是很常见的疏漏。上线前请在自己的工程里确认一遍注册流程到底往磁盘写了哪些东西路径分别在哪。三、算一笔存储账1 万人占多少空间有了512 字节 / 条这个口径存储量就可以估算了。以下数字是按官方通用版 Demo 的特征字节数做的推算不是官方给出的容量承诺实际占用还会包含用户信息、索引和图片文件请以实测为准库规模特征值理论占用说明1,000 人约 0.49 MB按 512 B/条 折算10,000 人约 4.88 MB官方建议的最佳区间上限50,000 人约 24.41 MB官方推荐的容量上限100,000 人约 48.83 MB超出官方推荐区间如果用的是 3568 专版这类 1024 字节特征向量的版本上表数字要翻一倍。可以看到磁盘占用基本不构成瓶颈——5 万人的特征值也就二十几 MB。真正的约束在另外两个地方官方给的容量建议区间5w 以内、1W 以下最佳这是产品侧的口径超了不该自己硬扛检索耗时。官方规格表里写着5万本地人脸库检索速度: 20ms并随附备注以上指标以 RK3288 作为参考由最新版 SDK 运行在真实设备上采用真实数据集所得但算法性能受实际运行设备、实际数据集等情况影响以上数字仅供参考。换硬件这个数就得重新实测。所以选型和扩容时别盯着磁盘容量做决策那笔账算错了方向。四、删除动作必须成对数据库和 SDK 缓存是两份数据现在进入正题。这是这套 SDK 在处理数据删除时最容易出错的一处而官方文档里已经把话说得很直接。《Android V9.0-SDK》人脸库与特征缓存一节开门见山写了这么一句写入数据库不会自动更新 SDK 缓存。新增、删除或全量替换人员时必须同步更新两处数据。同一节把两处数据的分工也解释了Demo 同时维护- SQLiteface.db持久化人员 ID、姓名、特征和可选头像。- SDK 内存缓存用于运行时 1:N 高速检索。也就是说识别时比对的是内存缓存不是你那个face.db文件。同一个意思官方在 FaceApi 类的删除接口说明下又说了一遍这句在 V9.0 与 3568 专版两份文档里都有根据姓名在数据库删除用户若产出成功识别前需要在 SDK 缓存中也删除该接口或者从新获取一次数据库信息刷新一遍 SDK 缓存。上句按官方原文逐字照录仅略去句尾的文档交叉引用具体识别接口可参考 6.6 FaceSearch 识别对象其中产出从新两处疑为文档笔误标出来方便你在原文档中定位。把这两句话翻译成现场会发生的事你从数据库里删掉了一个离职员工但没有同步 SDK 缓存那么在下一次重新加载缓存之前这个人仍然能被刷开门。数据在逻辑上删了在运行期没删。这不是文档写得晦涩而是这套架构的必然取舍——识别时先和内存中的特征比对才能达到规格表里那个 20ms 的量级此处因果关系为本文推断官方文档只说明了缓存机制本身未解释设计动机。快是要付代价的代价就是删除动作必须成对做。顺便把版本差异说清楚这一点对老项目尤其重要。《Android-3568专版SDK》的 FaceSDKManager 类方法表里这个同步到缓存的动作登记为InitPush参数写的是Context:上下文功能说明是将人脸数据库中的人脸特征注册到sdk内存以上为该方法表行内容的照录。而在 V9.0 通用版的 FaceSDKManager 方法说明中没有出现InitPush这个名字对应的能力由pushPerson/pushPersons/pushAllPersons承担。所以如果你手上的代码还在调initPush或pushPersonById先别急着当成错误——InitPush在 3568 专版文档里查得到pushPersonById这个名字本文在 V9.0 与 3568 专版两份文档里都没查到它更多出现在早年示例与第三方教程中。两者指向同一个结论接口名与 SDK 版本绑定写代码前请以你手上那一版文档为准不要照抄本文或网上的示例。五、几个删除/注册接口用途各不相同在动手清理之前先把可用的接口分清楚它们的作用范围完全不同用错了就会出现我明明删了的错觉。接口归属类官方说明原文userDeleteByName(String userName)FaceApiString:用户名 根据用户名删除用户pushPerson(int id, byte[] feature)FaceSDKManager单个添加人脸新人脸特征注册到 sdk 缓存中delFeature(int id)FaceSDKManager清空单个缓存数据featureClean()FaceSDKManager清空全部缓存数据pushPersons(List users)FaceSDKManager批量添加人脸保留缓存中的人脸追加新的人脸pushAllPersons(List users)FaceSDKManager获取数据库全部人脸清空当前 sdk 缓存中的人脸并从新添加上表接口名与功能说明均照录《Android V9.0-SDK》FaceApi 类方法说明FaceSDKManager 类方法说明两节。注上表依 V9.0 通用版照录。若你用的是 3568 专版等版本同位置的方法名可能不同——例如 3568 专版文档里FaceSDKManager 侧的缓存同步接口就是InitPush。对照代码大致是这样示意代码按官方接口说明拼的调用顺序实际以你的工程为准// 场景一某人员离职先按姓名查出 id再同时删库与缓存 ListUser users FaceApi.getInstance().getUserListByUserName(张三); FaceApi.getInstance().userDeleteByName(张三); for (User u : users) { FaceSDKManager.getInstance().delFeature(u.getId()); // 同步删除缓存中的该条特征 }// 场景二某个人换了照片先删掉旧特征再重新注册 FaceSDKManager.getInstance().delFeature(userId); FaceSDKManager.getInstance().pushPerson(userId, newFeature);// 场景三设备要回收或转场清空全部缓存 FaceSDKManager.getInstance().featureClean();需要说明两点一是上面代码里的调用顺序是按删除后立即同步这一目的写的。官方给出的表述是删除数据库记录时同步调用delFeature并未规定固定的调用顺序与线程模型请以你的工程实际流程和实测结果为准。二是featureClean()的官方说明是清空全部缓存数据只写了缓存未提及数据库侧。所以数据库里的用户记录是否要同时清掉需要你在应用层一并处理——别只清了一边此处为本文推断依据是官方对该接口的说明原文只覆盖缓存数据。六、清理动作应该怎么设计把上面的点收拢成几条可执行的原则1删除必须成对且做成幂等。删库和删缓存写成同一个方法调用方不需要记住第二步。理由见第四节官方明确写了写入数据库不会自动更新 SDK 缓存。重复调用不报错避免批量处理时中途失败导致状态不一致。2批量清理后统一刷一次缓存。这一点官方在增删改同步一节里给了推荐写法照录如下删除数据库记录时同步调用delFeature批量刷新时可先featureClean再分批pushPersons。底库加载的做法同一节也给了先featureClean()再按批pushPersons(batch)当前 Demo 每批读取 1000 条避免把全部对象同时保留在内存中并特别提醒底库加载期间不要开放识别入口。这三条可以直接搬进你的清理流程。另外底库读取属于耗时操作。官方在数据库初始化接口的说明里写着该操作为耗时操作需要在线程中进行原文见《Android-3568专版SDK》FaceApi 类init接口说明所以刷新动作不要放在主线程也不要每人删完就刷一次。3清理要留痕。记录谁在什么时候删了谁、删除前后的库内人数。这不只是为了排查问题——人脸数据属于敏感个人信息删除行为本身需要可追溯合规层面的依据见第七节。4把删干净定义清楚。按第二节的发现干净至少包含face.db里的特征、SDK 内存缓存、应用层的图片文件、以及任何你自己做的备份或导出文件。缺一项都不算。七、合规这条线三句话说完人脸信息属于敏感个人信息——这个定性写在《中华人民共和国个人信息保护法》第二十八条里原文明确列举包括生物识别……等信息第二十九条要求处理敏感个人信息应当取得个人的单独同意。真正与本文直接相关的是第四十七条。它对应当主动删除列举了几种情形其中两项可以直接套到前面的场景上以下节选该条第一三项有下列情形之一的个人信息处理者应当主动删除个人信息个人信息处理者未删除的个人有权请求删除一处理目的已实现、无法实现或者为实现处理目的不再必要三个人撤回同意。员工离职属于第一项处理目的不再必要用户撤回同意是第三项明文列举。所以第四节说的删库 删缓存必须成对不只是工程规范还是这条法定义务的落地动作——只删一边等于义务没履行完。合规检查项的完整清单等保、个保法共 12 条我在站内另一篇里逐项列过这里不重复《人脸识别合规自查清单从等保到个保法的12条检查项》。需要更细的落地依据可以对照国家标准 GB/T 41819-2022《信息安全技术 人脸识别数据安全要求》2022 年 10 月 14 日发布、2023 年 5 月 1 日实施现行有效具体条款请以国家标准全文公开系统的标准正文为准。最后留一句产品侧的话。百度智能云人脸离线识别 SDK 的《概览》在适用场景特点里明确列了一条安全行业特点所带来的人脸数据敏感性即使可以连接公网也不可请求。也就是说这套方案从设计上就没有把数据传出去这一步。对医院、政企、金融这类对数据出境极度敏感的场景来说这不是一个可以后期补的功能而是选型阶段就得成立的架构前提——数据不出设备很多合规问题在架构层面就不存在了。最后声明以上只做工程参考不构成法律意见。具体合规方案请结合业务场景并由法务评估。八、上线前自检清单把全文要点收成一张表在上线前逐项对一遍检查项要确认的内容版本口径确认拿到的是通用版还是专版特征字节数按该版文档取值数据落点确认face.db实际路径以及是否有自定义路径图片文件注册流程是否在应用层另外存了人脸图片路径在哪删除成对删库后是否同步删除了 SDK 缓存中的对应特征批量清理批量删除后是否统一刷新缓存而非逐条刷新是否放在子线程底库加载大底库是否分批推送加载期间是否关闭了识别入口全量重置featureClean()后数据库用户记录是否一并清理删除留痕删除操作是否有日志能否还原谁在何时删了谁容量口径库规模是否在官方建议区间内超限是否重新实测耗时同意流程人脸信息的告知与同意是否单独完成备份清理自建备份或导出文件是否纳入清理范围九、本文与站内同主题几篇的边界数据清理这条线站内已经有过几篇从不同角度写过。把边界划清楚省得你重复翻找已发布的文章它解决什么本文的增量在哪《百度人脸离线SDK规模化部署指南从10台到1000台的运维实战》8/03批量部署的运维流程其中数据清理一节给出从数据库和 SDK 缓存都删掉的完整流程本文不重复流程而是把为什么要成对追溯到官方定义并补上专版与版本命名差异《百度人脸离线SDK生产环境踩坑汇总从授权失效到多线程崩溃这一篇全搞定》7/31故障现象排查注册只写库没写缓存会识别不到本文讲的是删除方向的同一类问题以及它对应的法定义务《人脸识别合规自查清单从等保到个保法的12条检查项》9/08合规检查项全集本文只保留与删除动作直接相关的那条法定义务不重复检查项《智慧校园人脸识别落地方案电子班牌、门禁、智慧食堂离线SDK怎么选怎么搭》8/10业务侧说明只存特征值、不存原图本文关注的是这些特征值落在哪个文件、删的时候要动几处如果你只是想把人删干净看 8/03 那篇的流程就够如果想知道为什么这么设计、官方怎么要求的、专版有什么不一样这篇补的就是这一层。数据来源本文技术内容回源以下百度智能云官方文档2026-10-09 查阅《人脸离线识别 SDK 概览》更新 2026-08-26SDK 定位与所有数据皆在设备本地运行处理、适用场景特点、人脸库容量口径、规格信息与测速备注《Android V9.0-SDK》当前通用版face.db创建与默认路径、registerUserIntoDBmanager签名、512 字节特征数组口径及免责说明、人脸库与特征缓存一节两处数据的分工、写入数据库不自动更新缓存、启动加载与增删改同步的官方推荐写法、FaceApi 与 FaceSDKManager 两类的接口说明《Android-3568专版SDK》更新 2026-06-03InitPush接口说明、删除接口下的缓存同步注意事项原文、Feature 实体类的 512 / 1024 字节口径说明同一产品的不同版本文档存在命名与数值差异例缓存同步接口在 V9.0 通用版为pushPerson系列在 3568 专版为InitPush特征向量在通用版为 512 字节在 3568 专版为 1024 字节本文已逐处标注请以你实际使用的 SDK 版本对应文档为准。法规与标准出处《中华人民共和国个人信息保护法》2021 年 8 月 20 日通过2021 年 11 月 1 日施行第二十八条、第二十九条、第四十七条GB/T 41819-2022《信息安全技术 人脸识别数据安全要求》2022 年 10 月 14 日发布、2023 年 5 月 1 日实施条款细节请以国家标准全文公开系统正文为准本文为技术实践记录涉及的性能与容量数字均为参考值实际表现受设备、数据与环境影响请以自测结果为准。相关文章专栏专栏一专栏二专栏三专栏四参考来源百度人脸识别离线SDK官网登陆百度智能云-管理中心你们的人脸库现在是怎么做人员离职清理的是应用层定时同步还是靠人工在设备上点评论区聊聊你们踩过的坑。