最近被問得最多的一件事就是鴻蒙人臉識別門禁到底怎么選型。不是市面上沒產(chǎn)品而是大多數(shù)方案還停留在“能演示”階段真要拉到園區(qū)、寫字樓、工地上批量部署問題就全冒出來了。我陪客戶跑了深圳好幾家方案商云識客是少數(shù)把“工程化”講得很實在的團(tuán)隊。這篇就把我們做選型和工程驗證時踩過的坑、比過的參數(shù)、驗證過的流程整理出來給正在糾結(jié)鴻蒙人臉識別門禁選型的朋友一個參考。這篇文章適合三類人看需要采購門禁設(shè)備的甲方技術(shù)負(fù)責(zé)人做系統(tǒng)集成的項目工程師以及準(zhǔn)備做鴻蒙設(shè)備應(yīng)用開發(fā)的嵌入式或應(yīng)用層開發(fā)者。它幫大家解決的核心問題不是“哪臺門禁機(jī)便宜”而是在鴻蒙生態(tài)里一臺人臉識別門禁從硬件模組、算法平臺到應(yīng)用交付怎樣才算是真正能落地的工程化方案。1. 選型前先把框架搭清楚鴻蒙門禁到底選什么1.1 為什么不能把“鴻蒙門禁”當(dāng)成“安卓門禁”來選很多渠道商會把安卓門禁加一個鴻蒙風(fēng)格桌面就叫“鴻蒙門禁”。這種產(chǎn)品本質(zhì)還是安卓的內(nèi)核和框架只是在UI層面換了層皮。真正值得選的鴻蒙門禁底座應(yīng)該是純正的HarmonyOS或開源鴻蒙OpenHarmony。工程化選型時我習(xí)慣先看兩件事。第一系統(tǒng)底座是不是真鴻蒙。HarmonyOS有完整的應(yīng)用生態(tài)和應(yīng)用簽名體系OpenHarmony則是開源底座更適合設(shè)備廠商做行業(yè)定制。門禁這種帶屏設(shè)備很多方案商選擇OpenHarmony因為它對驅(qū)動框架的開放程度更高系統(tǒng)裁剪自由度也更大。如果一臺設(shè)備連hap格式的應(yīng)用都跑不了那“鴻蒙”就值得打個問號。第二鴻蒙的分布式能力有沒有用起來。人臉門禁里有個典型場景訪客在門口刷臉結(jié)果要同步推送到前臺、管理員手機(jī)、電梯聯(lián)動。鴻蒙的分布式軟總線可以把門禁機(jī)、手機(jī)、后臺串成一張網(wǎng)絡(luò)這是傳統(tǒng)門禁最頭疼的聯(lián)動問題。當(dāng)然不是所有項目都需要分布式。如果客戶只是本地單機(jī)刷臉開門那分布式價值不大選型重點就回到識別速度和穩(wěn)定性如果是園區(qū)統(tǒng)一管理鴻蒙化的權(quán)限體系、設(shè)備聯(lián)動、原子化服務(wù)才是真正的核心價值。所以選型前先把“分布式用到什么程度”定義清楚能省下不少預(yù)算。1.2 選型前先回答三個問題任何設(shè)備選型本質(zhì)都逃不開三個問題場景是什么、規(guī)模有多大、要接哪些系統(tǒng)。人臉識別門禁也不例外而且這三個問題的答案直接影響硬件配置和系統(tǒng)架構(gòu)。接入規(guī)?，F(xiàn)場只有一扇門還是幾十上百個門點單機(jī)模式和集中管理模式的硬件需求差異很大。單機(jī)只要求設(shè)備本身穩(wěn)定集中管理則必須考慮邊緣服務(wù)器、統(tǒng)一管理平臺、數(shù)據(jù)回傳這些額外組件。很多項目前期沒規(guī)劃后端架構(gòu)門禁機(jī)上了一批之后才發(fā)現(xiàn)管理平臺能力跟不上最后只能推倒重來。場景復(fù)雜度室內(nèi)、室外、逆光、暗光、戴口罩、戴安全帽這些條件對攝像頭和算法的要求完全不同。室內(nèi)考勤機(jī)和室外人行通道閘機(jī)看起來都叫“人臉門禁”實際硬件規(guī)格差距可能翻倍。我遇到過客戶拿室內(nèi)機(jī)裝到室外結(jié)果大太陽底下識別率掉到50%以下最后整批返工。對接系統(tǒng)門禁記錄要不要對接人事系統(tǒng)、訪客系統(tǒng)、企業(yè)微信、釘釘或自研App這決定設(shè)備需要支持哪些協(xié)議。行業(yè)里常見的有ONVIF、GB28181、MQTT、HTTP API選型時必須逐條核對方案商支持程度而不是聽一句“都能對接”就完事。選型問題直接影響的維度接入規(guī)模多大是否需要邊緣服務(wù)器、統(tǒng)一管理平臺、集中運(yùn)維系統(tǒng)場景是否復(fù)雜攝像頭模組、補(bǔ)光方式、算法模型、防御等級對接哪些系統(tǒng)協(xié)議支持、SDK接口完整性、二次開發(fā)成本這三個問題對應(yīng)的就是“算力、算法、協(xié)議”。門禁設(shè)備每年出貨量很大但真正能做穩(wěn)定定制的產(chǎn)品不多。很多廠商直接用公版方案優(yōu)點是便宜省事缺點是定制能力幾乎為零。云識客這類偏工程化的團(tuán)隊會針對場景做軟硬一體調(diào)優(yōu)比如把活體檢測策略、補(bǔ)光參數(shù)、識別閾值做成可配置項而不是寫死在固件里。這個“可配置”在工程上非常重要因為每個現(xiàn)場的光線、人員流動節(jié)奏都不一樣一套參數(shù)打天下的方案最終一定會在某個現(xiàn)場翻車。2. 硬件與算法人臉識別門禁的“五官和大腦”2.1 主控SoC與系統(tǒng)底座工程化第一道門檻人臉門禁的核心芯片選型直接決定系統(tǒng)跑不跑得動、能不能長期維護(hù)。常見主控有兩類一類是老牌的IPC芯片方案另一類是瑞芯微RK3568、RK3588這類通用SoC。工程化選型時我按三個維度打分NPU算力、外設(shè)接口、鴻蒙適配成熟度。NPU算力決定人臉檢測、特征提取、活體判斷能不能流暢跑在本地。算力不夠就只能降分辨率、降幀率識別慢、誤識高用戶體驗直線下降。外設(shè)接口則看攝像頭、RFID讀卡器、繼電器鎖控、補(bǔ)光燈、以太網(wǎng)、4G、Wi-Fi這些模塊的接口數(shù)量和驅(qū)動支持缺一個后續(xù)都是要花人天去補(bǔ)的。最關(guān)鍵的是鴻蒙適配成熟度芯片廠商有沒有提供OpenHarmony的BSPHDF驅(qū)動是否覆蓋板載外設(shè)直接決定研發(fā)周期是兩周還是兩個月。我見過不少項目栽在BSP上。芯片選得很高端但廠商對OpenHarmony的支持只停留在“能開機(jī)”攝像頭驅(qū)動沒有、Wi-Fi模塊調(diào)不通最后整塊板子只能等廠商排期適配。云識客現(xiàn)場演示過他們基于OpenHarmony的門禁一體機(jī)給我的直觀感受是冷啟動、刷臉響應(yīng)的節(jié)奏與“套殼”方案完全不是一個體驗整個交互鏈路很跟手。這背后就是驅(qū)動層和應(yīng)用層做了深度優(yōu)化不是簡單堆硬件能實現(xiàn)的。內(nèi)存和存儲這塊也不能省。人臉庫、日志、離線緩存都會吃掉存儲做過門禁的人都有體會一臺設(shè)備用了半年存儲滿了導(dǎo)致UI卡死、重啟不斷的情況并不少見。選型時建議內(nèi)存不低于2GB存儲不低于16GB同時預(yù)留GPIO接口方便后期接閘機(jī)、道閘、電梯控制板。工程上的擴(kuò)展性往往比紙面參數(shù)更重要。2.2 攝像頭、補(bǔ)光與活體檢測識別率的分水嶺人臉識別門禁識別率好不好軟件算法只占一半攝像頭和補(bǔ)光占另一半。工程現(xiàn)場常見的攝像頭方案有三類單目RGB、雙目近紅外、3D結(jié)構(gòu)光或ToF。這三個方案不是簡單的好壞關(guān)系而是成本、場景、安全等級的權(quán)衡。方案原理優(yōu)點缺點適用場景單目RGB普通彩色攝像頭抓拍成本低、體積小受光線影響大、活體能力弱室內(nèi)、光線恒定的考勤機(jī)雙目近紅外一個RGB配一個紅外或雙紅外暗光可用、活體效果好成本中等、需要補(bǔ)光設(shè)計室內(nèi)外通用門禁3D結(jié)構(gòu)光/ToF深度信息建?；铙w最強(qiáng)、防頭模攻擊成本高、功耗大高安全級別場所實際項目里80%的園區(qū)門禁用雙目近紅外就夠了。近紅外的核心優(yōu)勢在于不管現(xiàn)場光線怎么變?nèi)四樚卣髟诩t外圖下都相對穩(wěn)定配合主動紅外補(bǔ)光白天黑夜識別效果基本一致。同時紅外圖天然不具備顏色紋理對照片、視頻、彩色打印面具的攻擊有天然抑制作用。不過要注意高級頭模攻擊仍然可能繞過紅外活體安全要求高的地方就得加3D結(jié)構(gòu)光或二次校驗。補(bǔ)光這塊的細(xì)節(jié)很多容易被采購忽略。補(bǔ)光燈波長一般選850nm或940nm850nm亮度高但有微弱紅點940nm無紅點但傳感器靈敏度略低。工程上我更看重補(bǔ)光均勻性如果補(bǔ)光板只有中心亮、四周暗人臉邊緣就會過曝識別率一定受影響。選型時有個土辦法拿設(shè)備在較暗的環(huán)境里連續(xù)抓拍20張圖看人臉區(qū)域的灰度值是否穩(wěn)定在合理區(qū)間這個測試比看參數(shù)表靠譜得多。2.3 人臉?biāo)惴ㄟx型開源模型與商用SDK怎么平衡人臉識別算法部分很多團(tuán)隊第一反應(yīng)是用開源的免費(fèi)模型。確實現(xiàn)在開源社區(qū)有很多成熟的人臉識別項目比如基于InsightFace思路訓(xùn)練的模型還有OpenCVSharp這類方便C#調(diào)用的封裝個人開發(fā)者做原型很快。但從工程化角度直接拿開源模型上生產(chǎn)設(shè)備會踩幾個坑。第一個坑是模型運(yùn)行環(huán)境。很多開源模型默認(rèn)在PC上跑部署到端側(cè)NPU需要做格式轉(zhuǎn)換和量化這一步對模型精度影響很大。同一個模型在GPU上跑準(zhǔn)確率95%量化到INT8上NPU跑可能掉到90%以下而這5個百分點的差距在門禁場景里就是“能用”和“總被投訴”的區(qū)別。第二個坑是活體檢測。開源模型往往只做人臉比對活體檢測需要另外集成。兩個模型疊加后設(shè)備的內(nèi)存和NPU負(fù)載直接翻倍低端主控根本扛不住。第三個坑是授權(quán)與商用。開源不等于免費(fèi)商用選型時必須逐字核對license條款特別是“開源免費(fèi)商用”這種說法很多項目的英文協(xié)議里都埋著雷。商用SDK的優(yōu)勢在于省心識別率、活體、并發(fā)都有保障但價格和授權(quán)模式需要談。云識客給客戶的做法是“算法可替換”他們不綁定某一家算法而是在設(shè)備端做了一套算法抽象層人臉檢測、特征提取、比對、活體判斷全部可以換成不同引擎。這個設(shè)計的價值在于甲方如果對識別率有特殊要求可以直接在云端或端側(cè)替換特定模塊不用整機(jī)更換。這種模塊化思想才是工程化選型最該看重的點。另外很多團(tuán)隊問“C#和OpenCVSharp能不能做鴻蒙人臉識別”。我的回答是如果團(tuán)隊只有C#背景可以先在Windows端做算法驗證但設(shè)備端跑鴻蒙技術(shù)棧通常會換成ArkTS或C推理引擎也要用鴻蒙端可用的版本。PC端驗證和端側(cè)部署之間存在一段遷移成本選型時要提前評估團(tuán)隊的技術(shù)儲備否則很容易在最后一公里卡住。3. 鴻蒙化落地從“能跑”到“能交付”3.1 應(yīng)用層ArkTS、Stage模型和門禁UI開發(fā)硬件選好之后接下來就是鴻蒙應(yīng)用開發(fā)。當(dāng)前鴻蒙應(yīng)用開發(fā)以DevEco Studio為工具鏈應(yīng)用模型是Stage模型開發(fā)語言是ArkTS。門禁設(shè)備應(yīng)用界面其實不復(fù)雜實時視頻預(yù)覽、人臉庫管理列表、通行記錄頁面、設(shè)置頁面。但恰恰因為界面簡單很多人低估了狀態(tài)管理的復(fù)雜度。人臉識別天然是異步過程攝像頭一幀一幀進(jìn)來識別結(jié)果、活體狀態(tài)、門鎖動作、語音播報都要同步更新到UI。在ArkTS里我建議用“狀態(tài)驅(qū)動UI”的思路把識別狀態(tài)定義成一個枚舉或狀態(tài)對象通過 State 或 Observed 綁定到界面。這樣做的好處是UI永遠(yuǎn)跟著狀態(tài)走不會出現(xiàn)“界面顯示通過門卻沒開”這種不一致的詭異問題。// 識別狀態(tài)定義 export enum IdentifyState { Idle 0, Detecting 1, LivenessChecking 2, Comparing 3, Passed 4, Rejected 5 } Entry Component struct FaceGatePage { State currentState: IdentifyState IdentifyState.Idle; build() { Column() { Text(this.getStateText(this.currentState)) .fontSize(28) .fontWeight(FontWeight.Bold) .fontColor(this.currentState IdentifyState.Passed ? #00A878 : #666666) } .width(100%) .height(100%) } getStateText(state: IdentifyState): string { // 按狀態(tài)返回提示文案實際工程里這里還會聯(lián)動語音播報、門鎖控制 return ; } }這段代碼本身不復(fù)雜但它代表工程里最容易出錯的一個點識別邏輯和UI更新之間的同步。如果狀態(tài)更新不及時用戶會感覺“刷了臉還要等一秒才開門”體驗很差。實際操作中識別邏輯應(yīng)該放在獨立線程通過事件回調(diào)更新UI同時保證開門指令的優(yōu)先級最高避免因為UI卡頓導(dǎo)致門鎖不響應(yīng)。另外人臉庫管理頁面經(jīng)常要做“多選刪除”操作ArkTS里列表的選中狀態(tài)、批量刪除、分頁加載這些功能都需要提前規(guī)劃好數(shù)據(jù)結(jié)構(gòu)不要等現(xiàn)場設(shè)備上線了再補(bǔ)。3.2 設(shè)備驅(qū)動HDF框架與門禁外設(shè)適配OpenHarmony提供了一套HDFHardware Driver Foundation驅(qū)動框架目的是統(tǒng)一設(shè)備驅(qū)動開發(fā)。門禁設(shè)備上涉及的驅(qū)動不少攝像頭、RFID模塊、繼電器鎖控、補(bǔ)光燈、網(wǎng)絡(luò)模塊、語音喇叭、看門狗每個外設(shè)都要有對應(yīng)的驅(qū)動才能在應(yīng)用層正常調(diào)用。如果每樣都自己寫驅(qū)動開發(fā)量非常大所以選型時必須確認(rèn)主控平臺的BSP里已經(jīng)適配了多少個外設(shè)。RFID這塊值得單獨說因為門禁行業(yè)里刷卡和刷臉往往是共存的。RFID門禁采用什么芯片卡工程上要提前確認(rèn)常見的IC卡走13.56MHz頻段讀卡器驅(qū)動相對成熟如果要兼容CPU卡或國密卡協(xié)議棧就復(fù)雜不少。鴻蒙化項目里RFID驅(qū)動通過HDF注冊后應(yīng)用層可以統(tǒng)一調(diào)用讀卡結(jié)果再和人臉識別結(jié)果合并成“雙因子鑒權(quán)”。這在財務(wù)室、機(jī)房等高安全級別區(qū)域是常見配置刷卡加刷臉都通過才開門。另一個容易被忽略的驅(qū)動是繼電器鎖控。開門動作最終是GPIO拉高拉低去控制繼電器這個動作必須非常穩(wěn)定還要有超時自動回鎖機(jī)制防止門開之后繼電器一直吸合。在HDF驅(qū)動層把鎖控封裝成標(biāo)準(zhǔn)化接口后應(yīng)用層只管調(diào)接口即使后期更換繼電器模塊驅(qū)動層的改動也不會影響業(yè)務(wù)功能。我們遇到過一次現(xiàn)場鎖控驅(qū)動時序沖突現(xiàn)象是門開了但鎖控信號沒釋放排查下來是驅(qū)動里中斷優(yōu)先級和應(yīng)用層開門任務(wù)的調(diào)度沖突最后調(diào)了驅(qū)動線程優(yōu)先級才解決。這種問題只有在真實部署中才會暴露所以選型時多問方案商的現(xiàn)場案例比看參數(shù)配置表有用得多。3.3 交付形態(tài)hap、hsp、har怎么拆才不翻車鴻蒙應(yīng)用的交付形態(tài)和安卓不一樣工程化選型時必須理解hap、hsp、har這些概念HAP應(yīng)用安裝包可獨立安裝運(yùn)行。HSP共享包多個HAP之間共享代碼和資源類似動態(tài)庫。HAR靜態(tài)共享庫編譯期打包進(jìn)HAP或HSP。在門禁這類設(shè)備上我建議這樣拆設(shè)備基礎(chǔ)能力包括相機(jī)、鎖控、讀卡放在HSP里作為整機(jī)固件的一部分統(tǒng)一升級人臉?biāo)惴ㄒ孀龀蒆AR方便后續(xù)單獨替換版本上層業(yè)務(wù)應(yīng)用如門禁管理、訪客、考勤按場景拆成多個HAP按需安裝。這種拆法最大的好處是升級靈活今天只想更新活體模型就不用重刷整機(jī)鏡像。這個坑我實際踩過。有一次圖省事把算法模型和業(yè)務(wù)代碼打到一個HAP里結(jié)果模型一更新整個應(yīng)用都要重新簽名、重新安裝現(xiàn)場幾十臺設(shè)備只能在下班后挨個升級非常痛苦。后來把模型和算法獨立成HAR配合模塊級差分升級問題才徹底解決。所以選型時一定要問清楚方案商的升級機(jī)制是整包OTA還是模塊級增量升級這直接決定后期的運(yùn)維成本。對于一個上百臺門禁機(jī)的園區(qū)升級方式不同人力投入能差出十倍。3.4 邊緣端的人臉庫與性能優(yōu)化園區(qū)門禁的人臉庫規(guī)模往往不是幾千張這種小數(shù)量級。一個上千人的園區(qū)加上訪客、施工人員、臨時人員人臉庫可能到幾萬甚至十萬級。這種“邊緣人臉識別 大量數(shù)據(jù)”的場景最怕設(shè)備檢索變慢、偶發(fā)漏識別、刷臉排隊。我在實際項目中總結(jié)了幾條工程化性能優(yōu)化手段第一人臉特征入庫時統(tǒng)一做質(zhì)量校驗?zāi)：?、過曝、低頭、遮擋的圖片直接拒絕入庫減少垃圾特征對檢索的干擾。第二特征預(yù)分桶按樓棟、部門、區(qū)域把人臉特征分組門禁機(jī)只加載本區(qū)域的人臉特征不用全量比對。第三熱點緩存高頻通行人員比如常駐員工的特征放在內(nèi)存訪客臨時特征放在磁盤內(nèi)存不夠時優(yōu)先淘汰訪客。第四異步批量注冊批量錄入幾千人時用消息隊列異步處理避免注冊過程中設(shè)備卡死。這些優(yōu)化不是堆硬件就能解決的它跟算法引擎、數(shù)據(jù)存儲結(jié)構(gòu)強(qiáng)相關(guān)。云識客的工程化經(jīng)驗里我最認(rèn)可的一句話是人臉庫管理要像數(shù)據(jù)庫一樣設(shè)計而不是像普通文件列表一樣堆。人臉特征、通行記錄、黑名單都要有索引、有分頁、有增量同步機(jī)制。很多門禁方案前期看著能用等數(shù)據(jù)量上來之后一塌糊涂就是因為在架構(gòu)設(shè)計時沒把人臉庫當(dāng)成“數(shù)據(jù)系統(tǒng)”來做。4. 上線以后現(xiàn)場問題、排查思路和避坑清單4.1 識別率時好時壞先從抓拍圖像查起很多項目上線后客戶反饋“白天識別還行傍晚就經(jīng)常失敗”。大多數(shù)情況下不是算法退化而是抓拍圖像質(zhì)量下降了。我排查這類問題的順序是固定的先抓幾張現(xiàn)場圖像看人臉區(qū)域是否清晰、亮度是否均勻、是否被逆光吃掉再看補(bǔ)光是否正常啟動光敏傳感器的閾值是否設(shè)置合理最后才考慮調(diào)識別閾值或換算法。逆光是門禁場景的頭號殺手。出入口朝西傍晚太陽直射人臉背光普通攝像頭拍出來就是一團(tuán)黑。解決辦法不是單純拉高曝光而是開啟寬動態(tài)WDR或直接換雙目近紅外方案?，F(xiàn)場安裝時攝像頭要盡量避免正對強(qiáng)光源實在避不開就加裝遮陽板。另外安裝高度和角度也非常講究門禁機(jī)攝像頭最佳安裝高度大約在1.4米到1.5米之間人臉在畫面中的占比大概三分之一到二分之一。裝高了拍的是頭頂裝低了拍的是下巴識別率肯定上不去。這個細(xì)節(jié)必須在選型階段就跟施工方講清楚不然后期返工成本很高。4.2 活體檢測偶爾誤殺閾值怎么調(diào)活體檢測的目的是防止照片和視頻攻擊但策略如果太激進(jìn)就會出現(xiàn)真人被拒的情況。我遇到過的誤殺場景主要有三類戴墨鏡時紅外活體下眼睛區(qū)域特征缺失側(cè)臉角度過大人臉關(guān)鍵點不全活體判斷猶豫快速路過時抓拍到的幀有運(yùn)動模糊活體打分偏低。每一類都在真實項目里出現(xiàn)過。處理經(jīng)驗是活體檢測策略最好做成多級可調(diào)不同點位用不同安全等級。比如員工通道人流密集、通行速度快活體可以適當(dāng)放寬優(yōu)先保證通行效率財務(wù)室、機(jī)房這類高安全區(qū)域活體開最高檔并配合刷卡雙因子驗證?！鞍袋c位配置安全等級”的思路是工程落地的關(guān)鍵而不是所有點位一把尺子。如果方案商不支持按點位調(diào)整活體策略后期運(yùn)維會非常被動。4.3 多設(shè)備運(yùn)維斷網(wǎng)自治和數(shù)據(jù)補(bǔ)傳園區(qū)幾十臺門禁機(jī)網(wǎng)絡(luò)不可能永遠(yuǎn)穩(wěn)定。工程化方案必須考慮斷網(wǎng)自治設(shè)備斷網(wǎng)后繼續(xù)本地識別、本地開門、本地記錄網(wǎng)絡(luò)恢復(fù)后自動補(bǔ)傳通行記錄到管理平臺。選型時要問清楚三件事斷網(wǎng)后本地最大支持多少人臉庫離線記錄能存多少條補(bǔ)傳是設(shè)備主動推還是平臺定期拉我們遇到過一次設(shè)備離線一周恢復(fù)后補(bǔ)傳數(shù)據(jù)把平臺接口打爆的情況。解決方法是平臺側(cè)對設(shè)備補(bǔ)傳做限流設(shè)備側(cè)也做分批上傳比如每次50條、間隔500毫秒。這套機(jī)制必須通過接口壓力測試來驗證熱詞里提到的jmeter測試人臉識別接口實際就是干這件事的——用壓測工具模擬大量并發(fā)補(bǔ)傳請求看平臺能不能扛住。如果沒有做過這個測試等上線被數(shù)據(jù)沖垮再救火就非常被動了。4.4 現(xiàn)場部署的“隱形”要求最后整理幾個容易被忽略、但上線后一定會遇到的點。設(shè)備要有硬件看門狗異常死機(jī)后能自動重啟否則園區(qū)運(yùn)維人員要天天跑現(xiàn)場。日志要能遠(yuǎn)程拉取不要等設(shè)備寄回來才分析問題。設(shè)備標(biāo)識要清晰批量部署時IP、設(shè)備號、安裝位置要在管理后臺一一對應(yīng)。施工時網(wǎng)線、電源線要做好防雷和接地室外門禁尤其重要。常見問題可能原因排查方法白天識別正常傍晚失敗逆光、補(bǔ)光未啟動檢查WDR開關(guān)、光敏閾值、抓拍圖質(zhì)量真人也無法通過活體策略過嚴(yán)、安裝角度差分檔調(diào)整活體等級調(diào)整安裝高度識別響應(yīng)慢人臉庫過大、內(nèi)存不足特征分桶、熱點緩存、升級硬件設(shè)備自動死機(jī)供電不穩(wěn)、內(nèi)存泄漏檢查電源、啟用看門狗、升級固件通行記錄丟失斷網(wǎng)離線記錄溢出擴(kuò)大存儲、配置上傳限流批量錄入卡死注冊任務(wù)無隊列異步處理、限制并發(fā)注冊數(shù)在整個選型過程中我最深的感觸是鴻蒙人臉識別門禁的選型參數(shù)表只能反映一半實力另一半要看落地團(tuán)隊對工程細(xì)節(jié)的理解。同樣一塊主控、同樣一個攝像頭有人能在兩周內(nèi)完成驅(qū)動適配和整機(jī)交付有人要拖兩個月差別就在于BSP熟不熟、現(xiàn)場坑踩得多不多。我也把文章里這些選型要點整理成了一張內(nèi)部檢查表每次評審設(shè)備方案時逐項過一遍基本不會出大方向上的問題。如果你也在做鴻蒙相關(guān)的門禁或IoT設(shè)備選型希望這篇能幫你少走一些彎路。