小智這個(gè)項(xiàng)目我一直覺得最難的從來不是把Demo跑起來而是你手里真的捏著三五十臺設(shè)備、準(zhǔn)備把它們一次性放出去的那一刻。硬件接線、固件編譯這些問題只要照著文檔耐心弄總能搞定真正讓我半夜從床上彈起來的是接入名單怎么設(shè)計(jì)、設(shè)備故障之后該先恢復(fù)什么。這篇文章不聊理論就聊我從“小智首批設(shè)備放量”這個(gè)過程中踩出來的路從名單怎么給設(shè)備上戶口到故障恢復(fù)時(shí)我做的幾個(gè)決定再到設(shè)備側(cè)看門狗的三層兜底。如果你正準(zhǔn)備把手里的幾臺小智原型機(jī)擴(kuò)到幾十上百臺這篇應(yīng)該能幫你少走幾段彎路。1. 放量瓶頸不在產(chǎn)能而在你給不給設(shè)備“戶口”1.1 先分清兩種名單入網(wǎng)名單和功能名單很多人在準(zhǔn)備放量時(shí)第一反應(yīng)是去找更多開發(fā)板、更多電源、更多喇叭但我這批設(shè)備真正卡住進(jìn)度的是接入名單。小智設(shè)備不是插上電就能用的它要連接你自建的服務(wù)器端、要找大模型對話、要能播放音樂這里每一步都涉及一個(gè)判斷這臺設(shè)備有沒有資格。我建議你把“接入名單”拆成兩層。第一層叫入網(wǎng)名單簡單說就是哪些硬件設(shè)備能連到你的小智后臺。第二層叫功能名單解決的是這個(gè)設(shè)備能被允許做什么事比如能不能聽音樂、能不能調(diào)用某個(gè)大模型接口、能不能執(zhí)行某些敏感操作。很多固件文檔里只給了你設(shè)備ID和密鑰的生成方式但沒告訴你這兩層名單如果不分開管理放量之后會非常痛苦。我自己一開始就是把它們混在一起結(jié)果某一臺設(shè)備的音樂權(quán)限要單獨(dú)關(guān)掉時(shí)我只能去改設(shè)備密鑰搞得其他服務(wù)也跟著出問題。1.2 接入名單里不只有 MAC還要有會話層標(biāo)記我看到不少做硬件接入的朋友設(shè)計(jì)名單時(shí)第一時(shí)間想到的就是MAC地址白名單。MAC地址確實(shí)是一個(gè)很自然的設(shè)備指紋但小智這種設(shè)備在實(shí)際使用中有個(gè)問題用戶可能換路由器、可能用熱點(diǎn)、可能在多個(gè)環(huán)境下移動。一旦設(shè)備處在不同局域網(wǎng)里MAC地址雖然不變但它對應(yīng)的網(wǎng)絡(luò)路徑、IP、會話狀態(tài)都在變。你在接入名單里只存一個(gè)MAC是不夠的必須有會話層標(biāo)記比如設(shè)備首次注冊時(shí)生成的一次性Token再配合設(shè)備類型和固件版本號。我在這批設(shè)備上用的是“MAC前綴 Token 固件版本”的三元組。MAC前綴負(fù)責(zé)硬件出廠階段的粗篩Token負(fù)責(zé)運(yùn)行時(shí)鑒權(quán)固件版本則讓后臺能識別出哪些設(shè)備還在跑舊固件方便后續(xù)做灰度升級。這樣設(shè)計(jì)的直接好處是當(dāng)某臺設(shè)備上報(bào)故障時(shí)我能很快定位它是哪一批硬件、哪個(gè)固件版本、有沒有權(quán)限做某些操作而不是對著一個(gè)孤零零的MAC地址發(fā)呆。1.3 第一次放量時(shí)我對名單的粗放理解后來全是坑坦白說我第一次放量時(shí)對名單的理解特別粗放——感覺就是拿個(gè)數(shù)組把設(shè)備ID存進(jìn)去反正設(shè)備不多手動加就行。結(jié)果十幾臺設(shè)備之后問題就出來了。有人在群里說設(shè)備連不上我以為是固件問題折騰半天才發(fā)現(xiàn)是設(shè)備ID在名單里少寫了一位又有人說音樂功能時(shí)好時(shí)壞查到最后是功能名單里沒區(qū)分“音樂服務(wù)”和“語音服務(wù)”的權(quán)限粒度導(dǎo)致部分請求被后臺誤攔截。這些小問題單獨(dú)看都不致命但在放量階段會成倍放大你的排查時(shí)間。所以一定要在第一批設(shè)備上線前就把名單從“一個(gè)數(shù)組”變成“一個(gè)帶狀態(tài)的數(shù)據(jù)結(jié)構(gòu)”。哪怕初期只有十臺設(shè)備也值得用數(shù)據(jù)庫表或者至少是格式化的JSON來維護(hù)字段至少包含設(shè)備MAC、注冊Token、固件版本、入網(wǎng)狀態(tài)、功能權(quán)限列表、最后心跳時(shí)間。不要懶這個(gè)基礎(chǔ)不打牢后面每一批設(shè)備都是災(zāi)難。2. 從燒錄到注冊小智固件里真正卡量產(chǎn)的三個(gè)點(diǎn)2.1 設(shè)備身份注入一次燒錄和逐臺燒錄差的不是時(shí)間小智設(shè)備放量時(shí)燒錄是繞不開的第一道工序。很多人覺得燒錄就是拿USB線連上電腦點(diǎn)一下下載固件然后下一臺。但當(dāng)你開始批量燒錄時(shí)就會發(fā)現(xiàn)真正的瓶頸是“設(shè)備身份”怎么進(jìn)去。如果固件里寫死了一個(gè)設(shè)備ID那所有燒出來的設(shè)備都是同一個(gè)身份接入名單根本沒法區(qū)分誰是誰。我在這個(gè)階段嘗試過兩種方案。第一種是編譯時(shí)注入也就是每臺設(shè)備編譯前改一下配置頭文件里的設(shè)備ID再單獨(dú)燒錄。這個(gè)方案最直接但效率極低燒錄十臺設(shè)備就得編譯十次而且容易在人工改配置時(shí)出錯(cuò)。第二種是運(yùn)行時(shí)注冊也就是所有設(shè)備燒錄同一個(gè)固件首次開機(jī)時(shí)通過配網(wǎng)流程向服務(wù)器端發(fā)起注冊請求服務(wù)器下發(fā)一個(gè)唯一設(shè)備ID和Token。這個(gè)方案對用戶更友好也適合批量生產(chǎn)但前提是你的服務(wù)器在設(shè)備首次開機(jī)那一刻必須在線而且注冊接口要做好防刷。我最后用的是折中方案燒錄統(tǒng)一固件但燒錄工具在燒錄完成后會把一個(gè)“燒錄序號”寫進(jìn)設(shè)備的NVS存儲區(qū)設(shè)備首次連接小智后臺時(shí)用這個(gè)序號申請正式身份。這樣既不會讓生產(chǎn)流程太慢也不會讓所有設(shè)備共用身份。2.2 播放音樂功能對固件側(cè)的內(nèi)存和 Flash 壓力小智的“能聽音樂”這個(gè)功能從宣傳上很吸引人但它在放量時(shí)是實(shí)打?qū)嵉馁Y源消耗大戶。ESP32系列本身內(nèi)存就有限如果你在固件里同時(shí)跑語音喚醒、麥克風(fēng)采集、編解碼、網(wǎng)絡(luò)協(xié)議棧再疊加音樂播放的音頻解碼和緩沖區(qū)很容易出現(xiàn)內(nèi)存碎片或者崩潰。以我用過的ESP32-S3為例它在運(yùn)行小智固件時(shí)可用堆內(nèi)存通常只有幾百KB。語音交互本身要預(yù)留一部分內(nèi)存給音頻緩沖音樂播放又要額外申請解碼緩沖。如果緩沖區(qū)分配不合理播放音樂時(shí)系統(tǒng)響應(yīng)會變得非常遲鈍嚴(yán)重的時(shí)候直接看門狗復(fù)位。我的建議是在固件里把音樂播放和語音交互拆成兩個(gè)獨(dú)立任務(wù)給音樂播放一個(gè)固定大小的音頻緩沖區(qū)同時(shí)在接入名單的功能權(quán)限里增加“音樂”開關(guān)。對于首批設(shè)備默認(rèn)可以關(guān)掉音樂功能只開放語音對話等設(shè)備硬件和網(wǎng)絡(luò)環(huán)境穩(wěn)定了再分批打開音樂功能。這樣做的另一個(gè)好處是當(dāng)你排查某個(gè)故障時(shí)可以先排除音樂流對系統(tǒng)資源的干擾。2.3 MQTT/WebSocket 連接參數(shù)放量后最先暴露的問題小智設(shè)備一般通過WebSocket或者M(jìn)QTT跟服務(wù)器保持長連接。在只有三五臺設(shè)備時(shí)這個(gè)連接隨便配都不會出問題一旦設(shè)備超過一定數(shù)量服務(wù)器端的連接數(shù)、心跳頻率、消息超時(shí)時(shí)間全都變成了瓶頸。我第一批設(shè)備放量時(shí)最先踩坑的是心跳間隔。原來測試時(shí)心跳間隔設(shè)得比較短比如每15秒一次設(shè)備少時(shí)服務(wù)器毫無壓力。但設(shè)備多了以后服務(wù)器每秒鐘要處理大量心跳包消息隊(duì)列經(jīng)常積壓最終導(dǎo)致后臺分發(fā)指令延遲用戶那邊表現(xiàn)為“喊了半天沒反應(yīng)”。后來我把心跳間隔調(diào)整到30到60秒同時(shí)讓設(shè)備在真正有請求時(shí)才上報(bào)狀態(tài)服務(wù)器壓力立刻降下來了。另外要注意的是連接參數(shù)里的“超時(shí)斷線重連”邏輯不要寫得過于激進(jìn)。有的固件在斷網(wǎng)后會立即重連連續(xù)失敗幾次就把自己鎖死。我建議在設(shè)備端加一個(gè)退避邏輯第一次重連等5秒第二次等10秒然后逐步遞增到最多5分鐘一次。這個(gè)邏輯在小批量測試時(shí)看不出來但放量后能明顯降低服務(wù)器端的連接風(fēng)暴風(fēng)險(xiǎn)。3. 故障后的恢復(fù)決定我按什么順序做取舍3.1 分類故障而不是急著修故障放量后你會遇到各種故障如果一上來就急著修很容易顧此失彼。我的習(xí)慣是把故障先分成三類設(shè)備端故障、服務(wù)器端故障、網(wǎng)絡(luò)鏈路故障。每一類的恢復(fù)策略不一樣。設(shè)備端故障的表現(xiàn)是某臺或某批設(shè)備離線、重啟、無法喚醒處理思路是看固件日志和看門狗復(fù)位記錄。服務(wù)器端故障的表現(xiàn)是大量設(shè)備同時(shí)超時(shí)、請求排隊(duì)、語音回復(fù)延遲這時(shí)候要先看服務(wù)端的連接數(shù)和隊(duì)列長度。網(wǎng)絡(luò)鏈路故障則通常出現(xiàn)在用戶更換網(wǎng)絡(luò)環(huán)境或者路由器重啟之后表現(xiàn)是設(shè)備能連上Wi-Fi但連不上服務(wù)器或者時(shí)連時(shí)斷。我之所以強(qiáng)調(diào)先分類是因?yàn)椴煌悇e的故障恢復(fù)決定完全不同。比如設(shè)備端故障往往只需要遠(yuǎn)程重啟或OTA修復(fù)服務(wù)器端故障可能需要切流或降級功能而網(wǎng)絡(luò)鏈路故障很多時(shí)候讓用戶重啟路由器就能解決。分類不清你就容易在錯(cuò)誤的方向上浪費(fèi)半小時(shí)。3.2 首批設(shè)備的典型故障表及處理優(yōu)先級我把首批設(shè)備放量時(shí)遇到過的典型故障整理成一個(gè)表方便大家參考。注意這里的優(yōu)先級是我的個(gè)人取舍不是標(biāo)準(zhǔn)答案但至少是一套經(jīng)過驗(yàn)證的思路。故障現(xiàn)象可能根因我的恢復(fù)優(yōu)先級處理方式單臺設(shè)備離線其他正常設(shè)備網(wǎng)絡(luò)掉線或固件崩潰低先觀察是否自動重連不干預(yù)多臺設(shè)備同時(shí)離線服務(wù)器端連接數(shù)超限或斷網(wǎng)切換高先恢復(fù)服務(wù)器連接再逐個(gè)檢查設(shè)備設(shè)備能連Wi-Fi但連不上后臺Token失效或接入名單被誤改中檢查后臺名單狀態(tài)重置設(shè)備會話語音喚醒正常但回復(fù)緩慢大模型接口超時(shí)或隊(duì)列堆積高先切換備用大模型通道再查隊(duì)列播放音樂時(shí)設(shè)備死機(jī)內(nèi)存不足或音頻解碼緩沖區(qū)溢出中先關(guān)閉該設(shè)備音樂權(quán)限再升級固件OTA升級后無法啟動固件分區(qū)損壞或升級包不完整高觸發(fā)回滾分區(qū)恢復(fù)上一版本固件這個(gè)表給我的最大啟發(fā)是恢復(fù)決定不能只看故障的嚴(yán)重程度還要看影響范圍。單臺設(shè)備離線再嚴(yán)重也只是影響一個(gè)用戶但服務(wù)器端連接數(shù)超限會拖垮一大片所以必須先處理后者。3.3 恢復(fù)決定里的限定兵力別把整個(gè)服務(wù)端拖下水故障恢復(fù)時(shí)最容易犯的錯(cuò)是“全局動作”。比如有一批設(shè)備因?yàn)門oken過期連不上你可能想著干脆清空所有設(shè)備的Token讓它們重新注冊。這個(gè)動作會讓所有在線設(shè)備瞬間掉線重連服務(wù)器端連接數(shù)暴漲本來只是小范圍故障結(jié)果變成全量故障。我的經(jīng)驗(yàn)是要做“限定兵力”的恢復(fù)先定位故障設(shè)備的分組范圍再對這個(gè)分組做操作。比如Token過期問題可以通過接入名單里的批量篩選功能只重置那批固件版本過舊或者注冊時(shí)間異常的設(shè)備。小智后臺如果支持設(shè)備分組標(biāo)簽?zāi)蔷透昧宋乙话銜础坝布尉W(wǎng)絡(luò)環(huán)境功能權(quán)限”三個(gè)維度打標(biāo)簽這樣恢復(fù)時(shí)就能精準(zhǔn)操作。另一個(gè)值得做的決定是“降級優(yōu)先于修復(fù)”。當(dāng)某臺設(shè)備反復(fù)崩潰時(shí)與其花時(shí)間遠(yuǎn)程排查不如先在功能名單里把它的音樂和多媒體功能停掉只保留語音對話。這樣設(shè)備大概率能穩(wěn)定運(yùn)行用戶還能繼續(xù)用核心功能你再慢慢查崩潰原因。放量階段保住大部分設(shè)備的可用性比追求每一臺設(shè)備的完美狀態(tài)重要得多。4. 設(shè)備側(cè)三層看門狗從斷網(wǎng)到 OTA 失敗的兜底4.1 網(wǎng)絡(luò)層看門狗為什么不能只靠服務(wù)器重連很多小智固件里默認(rèn)帶斷線重連的邏輯但這不等于設(shè)備端不需要看門狗。網(wǎng)絡(luò)層看門狗要做的事是定時(shí)檢查設(shè)備是否還保持著有效的網(wǎng)絡(luò)連接如果發(fā)現(xiàn)異常不等應(yīng)用層報(bào)錯(cuò)直接執(zhí)行網(wǎng)絡(luò)重連流程。我用的是一個(gè)簡單的思路在固件里維護(hù)一個(gè)網(wǎng)絡(luò)心跳計(jì)數(shù)器MCU每30秒檢查一次物理網(wǎng)卡狀態(tài)如果連續(xù)三次檢查都失敗就把Wi-Fi模塊重新初始化。這個(gè)流程跟應(yīng)用層的WebSocket心跳是分開的。因?yàn)橛袝r(shí)候WebSocket連接還在但底層網(wǎng)絡(luò)已經(jīng)斷了數(shù)據(jù)包根本發(fā)不出去。如果只看應(yīng)用層連接狀態(tài)你永遠(yuǎn)不知道網(wǎng)絡(luò)已經(jīng)“假死”了。這里有個(gè)經(jīng)驗(yàn)別把網(wǎng)絡(luò)層看門狗的動作設(shè)置得太頻繁。我在初期把檢查間隔設(shè)為10秒結(jié)果設(shè)備在Wi-Fi信號較弱的環(huán)境里反復(fù)重啟網(wǎng)絡(luò)模塊反而造成不穩(wěn)定。后來調(diào)整為30秒檢查、連續(xù)3次失敗才動作情況就好了很多。4.2 業(yè)務(wù)層看門狗會話卡死比斷網(wǎng)更隱蔽比網(wǎng)絡(luò)斷線更讓人頭疼的是網(wǎng)絡(luò)正常但業(yè)務(wù)卡死。典型場景是設(shè)備連著服務(wù)器語音喚醒也能觸發(fā)但發(fā)給后臺后遲遲得不到響應(yīng)于是設(shè)備一直停在“等待回復(fù)”的狀態(tài)。這個(gè)狀態(tài)如果沒人管可能持續(xù)到用戶斷電。業(yè)務(wù)層看門狗就是用來解決這個(gè)問題的。我在固件里設(shè)置了一個(gè)業(yè)務(wù)超時(shí)計(jì)時(shí)器從設(shè)備發(fā)出請求開始計(jì)時(shí)如果在規(guī)定時(shí)間內(nèi)沒有得到完整響應(yīng)就自動結(jié)束當(dāng)前會話并釋放內(nèi)存。這個(gè)超時(shí)時(shí)間要根據(jù)你所用大模型的響應(yīng)速度來定不能太短。我一開始設(shè)的是5秒結(jié)果稍微慢一點(diǎn)的模型服務(wù)就頻繁觸發(fā)超時(shí)用戶體驗(yàn)很差后來調(diào)整為10秒到15秒。除了超時(shí)業(yè)務(wù)層看門狗還要監(jiān)控會話棧深度。有些設(shè)備在異常場景下會不斷堆疊會話內(nèi)存消耗越來越大。我會在每次會話開始時(shí)記錄堆水位超過閾值就強(qiáng)制重置整個(gè)應(yīng)用狀態(tài)。這個(gè)過程不能影響網(wǎng)絡(luò)層和系統(tǒng)層否則會連正常設(shè)備也一起打斷。4.3 OTA 失敗回滾放量設(shè)備最怕固件變磚放量之后你肯定要通過OTA遠(yuǎn)程升級固件。OTA本身不復(fù)雜但一旦升級失敗設(shè)備很可能變磚。小智設(shè)備用的是ESP32平臺通常把固件放在兩個(gè)分區(qū)里。A/B分區(qū)方案是最穩(wěn)的當(dāng)前運(yùn)行分區(qū)是AOTA寫入B寫入完成并校驗(yàn)通過后切換啟動分區(qū)。我在這批設(shè)備上啟用了A/B分區(qū)同時(shí)在OTA升級前會把當(dāng)前固件版本和配置備份到專門的配置分區(qū)。升級完成后設(shè)備會先啟動到新分區(qū)做一次自檢自檢內(nèi)容包括網(wǎng)絡(luò)連接、麥克風(fēng)設(shè)備初始化、音頻輸出初始化。如果這些核心組件任何一個(gè)失敗設(shè)備就自動回滾到舊分區(qū)然后上報(bào)回滾事件。這里有個(gè)很容易忽略的點(diǎn)OTA回滾事件要即時(shí)上報(bào)到后臺而不是等下次啟動再上報(bào)。因?yàn)槲覀兛赡軙瑫r(shí)給一批設(shè)備推送升級如果很多臺設(shè)備都回滾了后臺要立刻知道才能停止繼續(xù)推送。我一開始沒做即時(shí)上報(bào)結(jié)果幾十臺設(shè)備同時(shí)在升級時(shí)回滾我還以為升級很順利直到用戶反饋設(shè)備還是舊版本才知道出大事了。5. 恢復(fù)之后接入名單的閉環(huán)補(bǔ)全5.1 清理無效名單和灰度放量的關(guān)系故障恢復(fù)只是一個(gè)臨時(shí)動作真正要讓下一批設(shè)備平穩(wěn)放量你需要在恢復(fù)之后把接入名單做一次清理和補(bǔ)全。什么叫無效名單就是那些已經(jīng)不再使用、重復(fù)注冊、或者被手動禁用但沒刪除的設(shè)備條目。它們在名單里占著位置會讓后臺統(tǒng)計(jì)變得不準(zhǔn)確也會讓你在故障定位時(shí)多出很多干擾項(xiàng)。我一般會在大規(guī)模故障處理之后的24小時(shí)內(nèi)導(dǎo)出全部接入名單按最后心跳時(shí)間排序把超過一周沒有心跳的設(shè)備標(biāo)記為“疑似離線”而不是直接刪除。等確認(rèn)這些設(shè)備確實(shí)無法恢復(fù)再手動清理。這個(gè)過程不能全自動因?yàn)橛行┰O(shè)備可能只是用戶暫時(shí)沒通電你直接刪了會讓它在下次開機(jī)時(shí)重新注冊反而制造新問題。5.2 名單狀態(tài)機(jī)與可視化接入名單想放量最好給每臺設(shè)備定義一個(gè)清晰的狀態(tài)而不是只有“在線”和“離線”。我使用的是這樣的狀態(tài)機(jī)出廠未注冊、已注冊待激活、正常運(yùn)行、功能受限、離線超時(shí)、故障待修、已注銷。每個(gè)狀態(tài)對應(yīng)一個(gè)后臺的可視化顏色和后續(xù)動作。比如“功能受限”狀態(tài)的設(shè)備說明它因?yàn)閮?nèi)存或網(wǎng)絡(luò)問題被暫時(shí)關(guān)閉了部分功能后臺可以配置自動監(jiān)控一旦設(shè)備連續(xù)穩(wěn)定運(yùn)行24小時(shí)就自動恢復(fù)到“正常運(yùn)行”。狀態(tài)機(jī)的好處是當(dāng)設(shè)備出現(xiàn)問題時(shí)后臺不是只能給你一堆日志而是能直接告訴你這臺設(shè)備當(dāng)前處于什么階段、為什么處于這個(gè)階段、下一步該做什么。5.3 下批設(shè)備放量時(shí)可以直接復(fù)用的幾項(xiàng)配置如果下一批設(shè)備馬上就要放量我建議你把幾項(xiàng)配置直接固化下來不用每次重新摸索。一是設(shè)備分組策略。按“硬件批次網(wǎng)絡(luò)環(huán)境功能權(quán)限”打標(biāo)簽同一批硬件、相同網(wǎng)絡(luò)條件的設(shè)備放在一個(gè)組方便做灰度推送和定向故障排查。二是心跳和超時(shí)參數(shù)。網(wǎng)絡(luò)層檢查間隔30秒、業(yè)務(wù)層超時(shí)10到15秒、重連退避從5秒遞增到5分鐘這些參數(shù)我建議默認(rèn)寫進(jìn)固件配置模板而不是每次放量都臨時(shí)調(diào)。三是后臺接口的限流熔斷閾值。小智后臺在設(shè)備數(shù)增加后很容易被瞬時(shí)請求打滿。我建議在接入名單校驗(yàn)接口、設(shè)備注冊接口和日志上報(bào)接口上各自設(shè)置獨(dú)立的限流閾值避免某一個(gè)接口出問題拖垮整個(gè)服務(wù)端。四是恢復(fù)預(yù)案文檔。把上面的故障分類表和處理優(yōu)先級整理成一頁紙放在你和團(tuán)隊(duì)成員都能看到的地方。故障發(fā)生的時(shí)候在緊張狀態(tài)下靠記憶去決策遠(yuǎn)不如直接看預(yù)案來得可靠。小智設(shè)備放量這件事本質(zhì)上并沒有太深?yuàn)W的技術(shù)壁壘但它非?？简?yàn)?zāi)阍谠O(shè)備數(shù)量增加之后對細(xì)節(jié)的把控。接入名單不是上線前寫一次就完事的它需要跟著設(shè)備的生命周期不斷更新。故障恢復(fù)也不是每次都在緊急救火而是要在恢復(fù)之后把冗余的邏輯清掉讓名單狀態(tài)閉環(huán)轉(zhuǎn)起來。我個(gè)人的體會是首批設(shè)備放量的節(jié)奏寧可慢一點(diǎn)也要讓名單、狀態(tài)、恢復(fù)預(yù)案這三樣?xùn)|西先齊整。后面你會發(fā)現(xiàn)前期這些看似繁瑣的準(zhǔn)備工作會在每一批新設(shè)備接入時(shí)成倍地給你節(jié)省時(shí)間。