簡介《(完整word版)百度IOT平臺——平臺使用手冊》面向物聯(lián)網(wǎng)初學者與設(shè)備端開發(fā)人員圍繞百度IoT云平臺的產(chǎn)品創(chuàng)建、設(shè)備接入與云端管理流程展開幫助梳理從開發(fā)者中心注冊到批量生產(chǎn)的完整鏈路。壓縮包內(nèi)僅含1個doc文檔約1.35MB為可編輯的Word版本便于標注與整理。內(nèi)容覆蓋研發(fā)與管理、數(shù)據(jù)分析、服務(wù)與應(yīng)用三大板塊產(chǎn)品類別、型號與聯(lián)網(wǎng)方式的設(shè)定CA與Profile文件的燒錄心跳檢測的排查思路數(shù)據(jù)點定義與測試批量生產(chǎn)單批次最多10000個Profile以及OTA固件升級上限10MB、zip格式與靜默、強弱提醒模式。數(shù)據(jù)統(tǒng)計部分給出新增設(shè)備、存活、活躍與在網(wǎng)時長的口徑應(yīng)用側(cè)說明API Key、Secret Key及Android包名、iOS Bundle ID的配置要點。已有384人學習適合接入調(diào)試時對照查閱。1. 設(shè)備連上了卻不認賬問題往往不在代碼做過物聯(lián)網(wǎng) IoT 基礎(chǔ)平臺接入的人都遇到過這種場面設(shè)備端的 Wi-Fi 圖標是綠的串口日志里 TLS 握手也打出來了可控制臺上那個心跳檢測按鈕點下去轉(zhuǎn)兩圈彈出來的還是失敗。代碼沒改配置沒動換一臺設(shè)備就好了——這種玄學最耗時間。這份平臺使用手冊的價值就在于它把從新建產(chǎn)品到OTA 升級的七步流程釘死了每一步該點哪個按鈕、該下載什么文件、字段在哪填寫得比散落在各處的接口文檔清楚。它適合兩類人一類是第一次把硬件接進公有云 IoT 平臺的嵌入式工程師照著走能少踩一半坑另一類是已經(jīng)把設(shè)備跑通、準備量產(chǎn)的項目負責人批量生產(chǎn)和 OTA 那兩章才是真正的重點。2. 產(chǎn)品創(chuàng)建與 CA/Profile設(shè)備上云的第一公里設(shè)備接云這件事拆開看只有三個動作平臺側(cè)登記身份、設(shè)備側(cè)拿到憑證、雙方握手成功。手冊把這三件事壓在了前三個步驟里但每一步背后都有一層需要你自己決定的選型選錯了后面全得返工。2.1 產(chǎn)品三要素類別、型號、聯(lián)網(wǎng)方式到底怎么填新建產(chǎn)品時要填的東西不少真正影響后續(xù)流程的只有三個字段。產(chǎn)品類別決定控制臺給你推薦哪些模板和服務(wù)、默認數(shù)據(jù)點長什么樣產(chǎn)品型號是批量生產(chǎn)的最小單位一個型號對應(yīng)一套 Profile 生成規(guī)則聯(lián)網(wǎng)方式只作為元數(shù)據(jù)記錄參與少數(shù)統(tǒng)計口徑和 OTA 下發(fā)策略不參與鑒權(quán)。字段常見誤填建議做法影響面產(chǎn)品類別隨便選一個最像的按最終交付形態(tài)選不要按當前硬件形態(tài)選決定推薦模板、服務(wù)列表展示產(chǎn)品型號用中文或帶空格產(chǎn)品線縮寫 硬件版本 序號如acv2-01批量生產(chǎn)、OTA 固件綁定聯(lián)網(wǎng)方式全選只選實際出貨的通道部分統(tǒng)計口徑、下發(fā)策略產(chǎn)品型號這一項最容易被輕視。我一般會把它當成硬件 BOM 的一部分來管PCB 改版、射頻模組換料、Flash 分區(qū)調(diào)整只要影響固件兼容性就必須開新型號。理由很直接——OTA 是按型號推的型號混在一起等于把不兼容的固件推到別人的設(shè)備上。型號命名還要避開中文和空格有些工具鏈在拼路徑時會把空格吃掉這屬于典型的血淚經(jīng)驗。另外產(chǎn)品創(chuàng)建完成之后不要急著往下走。先確認列表里產(chǎn)品的狀態(tài)是正常、能看到 ProductKey 一類的標識再去下載憑證。如果產(chǎn)品狀態(tài)異常后面下載下來的 Profile 大概率也是無效的燒進去只會得到一個無限重連的設(shè)備。2.2 CA 與 Profile 的職責邊界一個管加密一個管身份這兩個文件經(jīng)常被混為一談實際上它們解決的是完全不同的問題。CA 是證書體系的根負責 TLS 鏈路上的身份校驗和加密缺了它設(shè)備連不上任何 HTTPS/MQTT over TLS 的端口Profile 是設(shè)備自己的身份憑證包常見做法是里面打包了產(chǎn)品標識、設(shè)備名、設(shè)備密鑰外加服務(wù)器地址和端口。文件承載什么少了會怎樣換了會怎樣CA根證書/設(shè)備證書鏈TLS 握手失敗日志里反復重連一般不用換跟環(huán)境綁定Profile設(shè)備身份三元組 接入地址平臺側(cè)看不到設(shè)備或認成別的設(shè)備等于換了一臺設(shè)備歷史數(shù)據(jù)斷檔手冊里寫的是下載 Profile 和 CA參考設(shè)備端開發(fā)者手冊燒錄至設(shè)備沒寫燒到哪、怎么燒。常見做法是 CA 燒到只讀的信任區(qū)Profile 燒到可覆蓋的參數(shù)區(qū)兩者分開因為前者基本不變、后者在返修和換板時要重寫。如果條件允許Profile 走安全芯片或加密分區(qū)明文存在外部 Flash 里被讀出來就等于設(shè)備被克隆。注意Profile 里通常包含服務(wù)器地址。測試環(huán)境和生產(chǎn)環(huán)境各有一套地址拿測試環(huán)境的 Profile 去連生產(chǎn)環(huán)境現(xiàn)象就是心跳永遠檢測不到但設(shè)備日志看起來一切正常。這是排查時第一個要確認的點。還有一個容易被忽略的點下載下來的 CA 和 Profile 要跟產(chǎn)品、批次對應(yīng)上。多產(chǎn)品并行開發(fā)時瀏覽器下載目錄里會堆一堆同名文件靠文件名根本分不清。我一般會在下載后立刻重命名成產(chǎn)品型號_批次_日期的形式再歸檔省得三天后回來找不到。2.3 燒錄、聯(lián)網(wǎng)、心跳三段式驗證順序不能亂手冊里檢測心跳這一步寫得很輕——點按鈕、等彈窗。但它能成功的前提是前面兩段都對了。所以驗證一定要按順序來不能跳步。第一步燒錄后先做本地自檢設(shè)備能不能正常啟動、能不能讀到 Profile、讀到的內(nèi)容長度對不對。這一步在串口里打幾行日志就能確認比事后在平臺上猜要快得多。第二步聯(lián)網(wǎng)階段看的是鏈路層。設(shè)備連上 AP、拿到 IP、DNS 解析成功、TCP 建連成功、TLS 握手成功這五件事要分開打日志。很多人把Wi-Fi 連上了當成網(wǎng)絡(luò)通了實際上 TLS 握手失敗的原因里證書時間不對、設(shè)備 RTC 沒校準占了相當比例。第三步才是平臺側(cè)的心跳檢測。它的本質(zhì)是平臺從數(shù)據(jù)面去看這臺設(shè)備有沒有按約定周期上報不是發(fā)個 ping 過去探活。檢測成功彈窗出現(xiàn)說明身份、證書、鏈路、數(shù)據(jù)點四件事里最基礎(chǔ)的幾件都對了。批量場景下第三步之前我會先把下載下來的憑證文件過一遍用腳本生成一份清單。import os, csv, hashlib PROFILE_DIR ./profiles # Profile 下載目錄 EXT .bin # 按實際文件后綴改 manifest [] for name in sorted(os.listdir(PROFILE_DIR)): if not name.lower().endswith(EXT): continue path os.path.join(PROFILE_DIR, name) with open(path, rb) as f: digest hashlib.sha256(f.read()).hexdigest() manifest.append({ device: os.path.splitext(name)[0], size: os.path.getsize(path), sha256_16: digest[:16], # 前 16 位足夠做產(chǎn)線比對 file: name, }) # 同一產(chǎn)品型號下Profile 體積應(yīng)當完全一致不一致說明下載不完整 sizes {m[size] for m in manifest} if len(sizes) 1: print(警告Profile 體積不一致 -, sizes) with open(profile_manifest.csv, w, newline, encodingutf-8) as f: w csv.DictWriter(f, fieldnames[device, size, sha256_16, file]) w.writeheader() w.writerows(manifest) print(共校驗, len(manifest), 個 Profile)這段腳本做三件事把文件名還原成設(shè)備名建立索引、把文件體積的一致性當作完整性校驗、把哈希前 16 位留給產(chǎn)線做燒錄后的回讀比對。參數(shù)就兩個目錄和擴展名按你實際下載下來的格式改。它不解決業(yè)務(wù)問題但能在批量下載出現(xiàn)截斷、重名、漏下的時候第一時間攔下來——這類問題如果拖到產(chǎn)線上才發(fā)現(xiàn)返工成本是按千臺算的。3. 數(shù)據(jù)點建模從能連上到能對話心跳通了只代表設(shè)備在平臺上活著離能用還差一步設(shè)備上報的字節(jié)流平臺得知道哪幾個字節(jié)是溫度、哪幾個是電量。數(shù)據(jù)點就是這個翻譯詞典手冊里把它放在第四步實際上它應(yīng)該是整個項目里最需要提前設(shè)計的東西。3.1 數(shù)據(jù)點三元組標識符、名稱、數(shù)據(jù)類型新建數(shù)據(jù)點時界面上的字段不多但每個都有講究。標識符是代碼里真正用的 key一旦設(shè)備燒錄了描述文件改標識符就等于改協(xié)議必須重燒名稱是給人看的隨時能改數(shù)據(jù)類型決定序列化方式改類型同樣要重燒。所以標識符和數(shù)據(jù)類型的組合應(yīng)當在第一次測試之前就凍結(jié)。數(shù)據(jù)類型典型用途容易翻車的地方布爾開關(guān)狀態(tài)、在線標志用 0/1 上報平臺按 bool 解析時可能報類型錯整型計數(shù)值、檔位、時間戳32 位有符號存秒級時間戳2038 年溢出浮點溫度、濕度、電壓精度不統(tǒng)一設(shè)備端保留 2 位、平臺端按 6 位展示字符串序列號、固件版本長度上限沒對齊超長部分被截斷枚舉模式、故障碼后期增刪枚舉值A(chǔ)PP 端不同步導致顯示空白我踩得最深的是浮點精度。設(shè)備端為了省 Flash把溫度乘 10 轉(zhuǎn)成整數(shù)再上報平臺側(cè)按浮點解析于是 23.5 變成了 235。這種錯誤不會報錯只會讓看板上出現(xiàn)一條明顯不合理的曲線而且往往要等業(yè)務(wù)方來問才會被發(fā)現(xiàn)。解決辦法是在數(shù)據(jù)點里明確寫清楚量綱和縮放系數(shù)別指望下一個人能從字段名猜出來。枚舉類型是另一個隱雷。枚舉值本身是好的可讀性比裸數(shù)字強但它的語義分散在三處設(shè)備固件、數(shù)據(jù)點定義、APP 展示層。任何一處改了另外兩處沒跟上就會顯示出空白或者錯位。所以枚舉我只用在真正穩(wěn)定的狀態(tài)機上業(yè)務(wù)字段一律走整型加映射表。3.2 設(shè)備描述文件的導出與集成順序手冊里寫產(chǎn)品創(chuàng)建完數(shù)據(jù)點后需導出為設(shè)備描述文件之后將其與 CA 集成燒入設(shè)備。這句話的順序很關(guān)鍵但容易被讀成三個文件一起燒進去就行。實際上正確的順序是數(shù)據(jù)點先定型再導出描述文件然后把描述文件、CA、Profile 三樣一起燒錄最后才做數(shù)據(jù)點測試。描述文件的結(jié)構(gòu)通常是 JSON形態(tài)大致如下。這里給的是通用形態(tài)實際字段名以設(shè)備端開發(fā)者手冊為準。{ product: acv2-01, version: 1.0.3, properties: [ { id: temperature, name: 溫度, type: float, mode: r, unit: C }, { id: humidity, name: 濕度, type: float, mode: r, unit: %RH }, { id: power, name: 開關(guān), type: bool, mode: rw }, { id: mode, name: 工作模式, type: enum, mode: rw, values: { 0: 待機, 1: 制冷, 2: 制熱 } } ] }mode里的r表示只上報、w表示只下發(fā)、rw表示雙向可控。這個字段經(jīng)常被寫反導致下發(fā)指令過去設(shè)備沒反應(yīng)或者設(shè)備上報上來平臺不接收。version不是擺設(shè)它應(yīng)該跟固件版本一起管理——出了現(xiàn)場問題第一件事就是確認設(shè)備上跑的描述文件版本和平臺上配的是不是同一版。提示描述文件一旦燒進設(shè)備平臺上再改數(shù)據(jù)點就只影響新燒錄的設(shè)備存量設(shè)備不會自動同步。所以數(shù)據(jù)點改動要當成一次固件變更來走流程別在控制臺上順手改。3.3 Demo APP 掃碼測試的完整閉環(huán)手冊里這一步就兩句話點數(shù)據(jù)點測試、用 Demo APP 掃二維碼。聽起來很簡單但它是整個接入流程里唯一一次端到端驗證值得認真做。我一般分三輪走。第一輪單點驗證一次只測一個數(shù)據(jù)點確認上報值和設(shè)備本地顯示屏或串口日志一致別一上來就測全部。第二輪組合驗證所有數(shù)據(jù)點同時上報看有沒有丟包、有沒有互相覆蓋。第三輪是邊界值布爾值兩邊都發(fā)一遍浮點發(fā)最大值和最小值字符串發(fā)到長度上限枚舉發(fā)一個未定義的值。第三輪最容易被跳過也最容易出問題。枚舉發(fā)未定義值時APP 端崩不崩、平臺側(cè)記不記異常、設(shè)備端會不會卡死這三件事在實驗室里測出來是零成本在現(xiàn)場測出來就是一次故障。測試通過之后再往下走批量生產(chǎn)這個順序不能反。4. 批量生產(chǎn)與 OTA把一臺設(shè)備的成功復制成一萬臺單臺設(shè)備跑通只證明技術(shù)路線可行能不能量產(chǎn)、能不能遠程升級才決定這個方案能不能交付。手冊在這兩塊給了明確的硬約束讀懂這些約束背后的意圖比記住數(shù)字更重要。4.1 批次化 Profile 生成10000 條上限背后是分配問題批量的邏輯是選產(chǎn)品型號、新建批次、填批次信息、生成 Profile、下載。手冊特別標注了Profile 數(shù)量最多為 10000 個這個數(shù)字不是隨便定的它意味著一個批次對應(yīng)一張生產(chǎn)工單超過一萬臺就要拆批次。拆批次的時候有個細節(jié)批次號要有遞增語義別用日期做唯一標識。同一天開兩條產(chǎn)線是很常見的事用日期做批次號必然撞車撞車之后 Profile 和設(shè)備就對應(yīng)不上了。真正難的是 Profile 和實物設(shè)備的映射關(guān)系。Profile 文件名通常是設(shè)備名而產(chǎn)線認的是 SN 或者 MAC。這兩套命名一旦錯位燒錄出來的設(shè)備要么互相搶線要么誰也連不上。我用的方式是產(chǎn)線提供 SN 清單腳本按設(shè)備名做 join生成燒錄映射表。import os, csv, hashlib BATCH B0001 # 批次號 PROFILE_DIR f./profiles/{BATCH} SN_MAP ./sn_map.csv # 兩列device_name,sn # 讀入設(shè)備名 - SN 的映射 with open(SN_MAP, encodingutf-8) as f: dev2sn {r[device_name]: r[sn] for r in csv.DictReader(f)} rows [] for fn in sorted(os.listdir(PROFILE_DIR)): if not fn.lower().endswith(.bin): continue dev os.path.splitext(fn)[0] sn dev2sn.get(dev) if sn is None: # 映射缺失直接中斷不要靜默跳過 raise SystemExit(f缺少 SN 映射: {dev}) with open(os.path.join(PROFILE_DIR, fn), rb) as f: h hashlib.sha256(f.read()).hexdigest()[:16] rows.append({sn: sn, device: dev, batch: BATCH, sha256_16: h, file: fn}) with open(fburn_map_{BATCH}.csv, w, newline, encodingutf-8) as f: w csv.DictWriter(f, fieldnames[sn, device, batch, sha256_16, file]) w.writeheader() w.writerows(rows) print(本批次生成燒錄映射, len(rows), 條)關(guān)鍵在映射缺失直接中斷這一行。批量腳本最忌諱的是遇到異常數(shù)據(jù)默默跳過產(chǎn)出看起來正常、實際少了幾十臺等到上線激活率不對才發(fā)現(xiàn)。參數(shù)上BATCH和目錄要保持一致SN_MAP必須是產(chǎn)線源頭給的數(shù)據(jù)不要手工維護。哈希值留在表里產(chǎn)線燒錄后回讀一次做比對這是防止燒錯片的最后一道閘。4.2 OTA 固件的 10MB 與 zip格式約束比大小更致命固件上傳的硬約束是最大 10MB、格式為 zip。10MB 對現(xiàn)在的 MCU 固件來說其實挺寬裕真正讓人翻車的是 zip 的打包方式。最常見的失敗是打成套娃包在父目錄里選中文件夾右鍵壓縮解出來是firmware/xxx.bin平臺解包后找不到根目錄下的固件文件直接判格式錯誤。第二種是 macOS 打包帶進來的__MACOSX和.DS_StoreWindows 側(cè)解出來一堆垃圾文件同樣報錯。cd firmware_build # 先進到固件產(chǎn)出的根目錄 rm -f ../ota_acv2-01_1.2.3.zip # -X 去掉額外的文件屬性-x 排除隱藏文件和系統(tǒng)垃圾 zip -r -X ../ota_acv2-01_1.2.3.zip . -x .* -x __MACOSX/* unzip -l ../ota_acv2-01_1.2.3.zip # 上傳前必須看一眼目錄結(jié)構(gòu)cd進去再打包是關(guān)鍵保證 zip 的根就是固件根。unzip -l這步別省兩秒鐘的事能省掉一次上傳失敗后的重新走流程。文件名里帶上型號和版本號OTA 記錄里對得上事后追問題方便。另外10MB 這個上限要留余量。固件 9.8MB 的時候下一次加個日志模塊就超了。我的習慣是把 8MB 當作實際紅線超過就開始拆分固件或者裁剪功能而不是等撞墻。4.3 四種通知方式怎么選靜默、強提醒、弱提醒、被動提醒手冊把升級規(guī)則分成四種靜默是直接升級、無提醒、無需用戶干預強提醒、弱提醒、被動提醒則是推送到 APP 端由用戶在 APP 里操作。這四種不是隨便挑的它跟設(shè)備形態(tài)強綁定。模式適合的設(shè)備風險靜默無屏、無人值守、傳感器類升級中被斷電可能變磚必須有回滾強提醒有屏、用戶每天使用用戶點稍后會一直拖著不升弱提醒有屏但使用頻次低提醒容易被忽略長期停留在舊版本被動提醒用戶主動進設(shè)置頁才看到覆蓋率最低適合小版本無屏設(shè)備選靜默是合理的但前提是你做了雙分區(qū)和回滾。單分區(qū)靜默升級一旦新固件啟動失敗設(shè)備就徹底失聯(lián)只能派人上門。這個后悔藥必須提前準備不是出事之后再補。有屏設(shè)備我更傾向弱提醒加一個升級后才生效的策略用戶不點功能照常但新特性不可用慢慢把版本推上去。強提醒點多了會被投訴尤其對消費級產(chǎn)品。4.4 版本號規(guī)劃與回滾OTA 的后悔藥要提前熬固件版本號建議走三段式主版本.次版本.修訂號。主版本改通信協(xié)議或描述文件結(jié)構(gòu)次版本加功能修訂號修 bug。這個規(guī)則的價值在于它能讓你一眼看出這次升級會不會導致設(shè)備必須重新燒錄描述文件——會就升主版本?；貪L的策略是任何一個版本上線平臺上始終保留上一個可用版本的固件包。發(fā)現(xiàn)異常先停推、再回滾不要在新版本上打補丁式地連發(fā)三個修訂版現(xiàn)場會亂成一鍋粥。注意平臺只負責把固件推下去不負責判斷升級是否成功。升級結(jié)果的確認要靠設(shè)備端在新固件啟動后上報一次版本號數(shù)據(jù)點平臺側(cè)用固件版本分布來看覆蓋率。5. 常見問題排查五條踩坑記錄與定位路徑前面四步走完理論上設(shè)備已經(jīng)能跑通了。但實際項目里真正消耗時間的是那些看起來都對、就是不工作的狀態(tài)。下面這五條是我在不同項目里反復遇到的按現(xiàn)象、原因、解決拆開寫。5.1 設(shè)備側(cè)心跳檢測一直失敗但串口日志顯示已連上現(xiàn)象設(shè)備串口里能看到 TCP 建連成功、TLS 握手完成甚至能看到上報的數(shù)據(jù)包發(fā)出去了但平臺上點心跳檢測轉(zhuǎn)兩圈還是失敗。原因通常有兩個。一是 Profile 里的服務(wù)器地址跟當前環(huán)境不匹配設(shè)備連的是測試環(huán)境你在生產(chǎn)控制臺上查。二是設(shè)備名重復——同一份 Profile 被燒到了兩臺設(shè)備上后上線的那臺把前一臺頂?shù)魞膳_互相踢平臺上看到的是連接時斷時續(xù)。解決先在設(shè)備端把 Profile 里的接入地址打印出來跟控制臺當前環(huán)境核對再查平臺上這臺設(shè)備名的連接記錄如果出現(xiàn)頻繁上下線基本可以斷定是 Profile 重復。批量場景下用 4.1 里的映射腳本先跑一遍重復設(shè)備名在腳本里就能攔住。5.2 設(shè)備側(cè)數(shù)據(jù)點測試掃碼后APP 一直沒有數(shù)據(jù)現(xiàn)象心跳檢測通過設(shè)備也在正常上報但用 Demo APP 掃碼進入數(shù)據(jù)點測試后頁面上一個值都沒有。原因幾乎都是描述文件版本不一致。改了數(shù)據(jù)點之后沒有重新導出描述文件、沒有重新燒錄設(shè)備還在按舊的協(xié)議上報平臺按新的定義解析字段對不上就整包丟棄。另一種情況是導出后只燒了描述文件忘了重新集成 CA導致簽名校驗不通過。解決把數(shù)據(jù)點定義、描述文件版本、固件版本三者對齊重新導出、重新燒錄、重新測試。這類問題很難從現(xiàn)象上直接看出來所以我在項目里強制要求描述文件版本號跟著固件版本號一起展示在設(shè)備信息里一眼就能比對。5.3 設(shè)備側(cè)批量生產(chǎn)后一部分設(shè)備無法激活現(xiàn)象同一個批次兩百臺設(shè)備一百八十臺正常二十臺怎么都激活不了。原因有兩種。一是批次 Profile 下載不完整文件被截斷燒進去是壞數(shù)據(jù)二是產(chǎn)線燒錄時順序錯位同一份 Profile 燒到了兩個片子或者 Profile 和 SN 的對應(yīng)關(guān)系整個錯開。解決先跑 2.3 里的清單腳本看文件體積是否一致、數(shù)量對不對再跑 4.1 的映射腳本確認 SN 和設(shè)備名一一對應(yīng)。如果還定位不到就取一臺異常設(shè)備回讀 Profile 的哈希跟映射表里的哈希比對能直接判斷是燒錯了還是文件本身壞了。5.4 平臺側(cè)OTA 上傳固件報格式錯誤現(xiàn)象zip 包本地解壓完全正常大小也沒超上傳就是報格式錯誤。原因基本鎖定在包結(jié)構(gòu)。要么是壓縮時多套了一層目錄要么是帶了系統(tǒng)垃圾文件要么是擴展名寫成.ZIP大寫導致校驗失敗。解決按 4.2 的命令重打一次包cd到固件目錄內(nèi)部再壓縮用unzip -l確認根目錄下直接就是固件文件。上傳前順手檢查一下文件大小寫和擴展名。5.5 統(tǒng)計口徑活躍設(shè)備數(shù)遠小于存活設(shè)備數(shù)現(xiàn)象數(shù)據(jù)統(tǒng)計頁面上設(shè)備存活數(shù)有八百多活躍設(shè)備數(shù)只有一百出頭業(yè)務(wù)方拿著這個數(shù)字來問是不是設(shè)備大面積故障。原因不是故障是口徑。手冊里的定義很清楚存活是有數(shù)據(jù)上報心跳也算活躍是有非心跳數(shù)據(jù)上報只發(fā)心跳不算。大量設(shè)備處于只保活、沒人操作的狀態(tài)這個差值天然存在。解決做設(shè)備健康度看板的時候用存活率看在線情況用活躍率看使用情況兩者不要混。想判斷設(shè)備是不是真的壞了看新增設(shè)備和在網(wǎng)時長分布更準。這里最容易犯的錯是拿活躍率當在線率匯報數(shù)字一低就被當成事故。6. 應(yīng)用側(cè)聯(lián)調(diào)與上線自檢把手冊走成一張可勾選的清單設(shè)備通了、固件推了最后一步是 APP 側(cè)。手冊里這塊寫得很簡略創(chuàng)建應(yīng)用、拿到 API Key 和 Secret Key、按平臺填包名或 Bundle ID。但正是這幾個字段在上線前最容易出問題。6.1 AK/SK 與平臺差異別把 Secret Key 塞進客戶端創(chuàng)建應(yīng)用之后能拿到兩個東西API Key 和 Secret Key。前者的定位是公開標識可以放在客戶端后者的定位是密鑰只能放在你自己的服務(wù)端。把 Secret Key 打進 APK 或 IPA等于把整個應(yīng)用的權(quán)限公開反編譯一次就能拿到。平臺差異這塊Android 要填包名和應(yīng)用簽名iOS 要填 Bundle ID。有兩個坑值得單獨說。Android 的簽名一定要用 release 簽名不要用 debug 簽名因為兩者指紋完全不同用 debug 簽名聯(lián)調(diào)通過、換成 release 就鑒權(quán)失敗的情況太常見了。iOS 的 Bundle ID 區(qū)分大小寫控制臺里填com.example.app、工程里配com.example.App看起來一樣實際不匹配。6.2 上線前的一張自檢表手冊里提到的服務(wù)列表和服務(wù)管理主要用來查看基礎(chǔ)數(shù)據(jù)和跳轉(zhuǎn)文檔聯(lián)調(diào)階段不需要動。真正需要逐項確認的是下面這張表。檢查項通過標準產(chǎn)品型號與固件型號與固件版本嚴格對應(yīng)無跨型號混推CA 與 Profile來源批次可追溯設(shè)備側(cè)回讀哈希與映射表一致數(shù)據(jù)點定義標識符和數(shù)據(jù)類型已凍結(jié)描述文件版本隨固件記錄數(shù)據(jù)點測試單點、組合、邊界值三輪全部通過批量映射每個 SN 都能在映射表里找到唯一 ProfileOTA 固件包根目錄結(jié)構(gòu)正確體積低于實際上限保留上一版本通知方式按設(shè)備形態(tài)選定無屏設(shè)備已具備回滾能力應(yīng)用配置release 簽名或 Bundle ID 與后臺完全一致統(tǒng)計口徑存活率與活躍率分開解讀有明確定義文檔這張表不是走形式用的。我現(xiàn)在的習慣是任何一次設(shè)備接入交付都強制從上到下走一遍哪怕項目再小、哪怕這套流程已經(jīng)跑過十次。因為翻車的往往不是最難的那一步而是上次好好的這次應(yīng)該也沒問題的那一步——一個批次號寫錯、一份 Profile 燒重、一個 debug 簽名混進 release 包都足夠讓上線推遲一周。希望這份拆解能幫你在第一次接入時少繞幾個彎。本文還有配套的精品資源點擊獲取