1. 從一塊開發(fā)板到全屋智能我為什么選擇 Android Things 做智能家居中樞2017 年夏天我拿到第一塊 Raspberry Pi 3 的時候腦子里想的全是這玩意兒能不能當(dāng)家里的控制中心。當(dāng)時市面上主流的方案無非是樹莓派跑 Home Assistant、ESP8266 接繼電器、或者直接買小米/涂鴉的成品套裝。成品套裝省事但擴(kuò)展性差想加個自定義傳感器就得看廠商臉色ESP8266 方案便宜但每個節(jié)點(diǎn)都要單獨(dú)寫固件設(shè)備一多維護(hù)成本直線上升。后來接觸到 Android Things我才算找到了一個相對平衡的切入點(diǎn)——它既有 Android 成熟的開發(fā)工具鏈和 UI 框架又能直接操作 GPIO、I2C、SPI 這些硬件接口最關(guān)鍵的是我可以用寫 App 的思路去寫硬件邏輯這對一個 Android 開發(fā)者來說幾乎是零門檻。Android Things 是 Google 在 2015 年當(dāng)時叫 Brillo推出、2016 年正式更名的物聯(lián)網(wǎng)操作系統(tǒng)本質(zhì)上是裁剪過的 Android 系統(tǒng)專門跑在 Raspberry Pi 3、NXP i.MX7D、Intel Edison 這類開發(fā)板上。它的核心價值在于把 Android 的 Framework 層保留下來同時提供一套 Peripheral I/O API讓開發(fā)者用 Java/Kotlin 就能控制 GPIO 引腳、讀寫 I2C 傳感器、驅(qū)動 PWM 設(shè)備。換句話說你不需要懂 Linux 驅(qū)動開發(fā)也不需要寫 C 語言固件只要會寫 Android App就能做出一個能跑起來的智能家居網(wǎng)關(guān)。這篇文章適合誰看如果你是有 Android 開發(fā)基礎(chǔ)、想折騰智能家居但不想從零學(xué)嵌入式的人那這篇內(nèi)容基本就是為你寫的。如果你完全沒接觸過 Android 開發(fā)也沒關(guān)系我會把關(guān)鍵概念用生活化的方式講清楚你至少能理解整套系統(tǒng)的運(yùn)作邏輯。整篇內(nèi)容我會圍繞一個實際項目展開用 Raspberry Pi 3 Android Things 做一個智能家居中樞接入溫濕度傳感器、繼電器控制燈光、通過手機(jī) App 遠(yuǎn)程查看和控制。所有代碼和配置我都會給出可直接參考的版本踩過的坑也會一并說明。2. 整體方案設(shè)計與技術(shù)選型思路2.1 為什么不用 Home Assistant 或 ESP8266 方案在動手之前我先花了兩周時間對比了三種主流方案最后才確定用 Android Things。這個對比過程很有必要因為選型決定了后面所有的開發(fā)路徑。Home Assistant 方案的優(yōu)勢是生態(tài)成熟插件多幾乎支持市面上所有主流品牌的設(shè)備。但它的短板也很明顯配置全靠 YAML 文件邏輯稍微復(fù)雜一點(diǎn)就要寫 Python 腳本而且 UI 定制能力有限。我之前用 Home Assistant 接了一個自定義的土壤濕度傳感器光是調(diào)試 MQTT 通信就花了一個周末最后發(fā)現(xiàn)是 YAML 縮進(jìn)問題。對于想深度定制交互邏輯的人來說Home Assistant 更像是一個配置平臺而不是開發(fā)平臺。ESP8266/ESP32 方案的優(yōu)勢是成本低、功耗小一個節(jié)點(diǎn)十幾塊錢就能搞定。但問題在于每個節(jié)點(diǎn)都是獨(dú)立的固件你要么用 Arduino IDE 寫 C要么用 MicroPython。設(shè)備少的時候還好一旦超過 5 個節(jié)點(diǎn)固件版本管理、OTA 升級、設(shè)備間通信都會變成噩夢。我之前做過一個 8 節(jié)點(diǎn)的 ESP8266 方案光是統(tǒng)一固件版本就折騰了三天。Android Things 的定位剛好在兩者之間它比 Home Assistant 更靈活因為你可以完全自定義業(yè)務(wù)邏輯它比 ESP8266 方案更好維護(hù)因為所有設(shè)備可以共享一套 Android 代碼庫OTA 升級直接用 Android 的機(jī)制。當(dāng)然它的成本比 ESP8266 高一塊 Raspberry Pi 3 大概 200 多塊但作為中樞只需要一塊終端節(jié)點(diǎn)還是可以用便宜的 ESP8266 通過 MQTT 接入。2.2 系統(tǒng)架構(gòu)中樞 終端 手機(jī) App 三層結(jié)構(gòu)最終確定的架構(gòu)是三層中樞層Raspberry Pi 3 跑 Android Things負(fù)責(zé)設(shè)備管理、數(shù)據(jù)聚合、邏輯決策。它直接通過 GPIO/I2C 連接本地傳感器和執(zhí)行器同時通過 MQTT 或 HTTP 與遠(yuǎn)程終端節(jié)點(diǎn)通信。終端層ESP8266 節(jié)點(diǎn)負(fù)責(zé)分布式傳感和執(zhí)行比如臥室的溫濕度采集、客廳的燈光控制。它們通過 Wi-Fi 與中樞通信協(xié)議用 MQTT因為 MQTT 輕量、支持發(fā)布訂閱、斷線重連機(jī)制成熟。應(yīng)用層Android 手機(jī) App 通過 HTTP/WebSocket 與中樞交互查看數(shù)據(jù)、下發(fā)控制指令。App 本身也是 Android 項目可以復(fù)用一部分代碼邏輯。這個架構(gòu)的核心思路是集中決策、分布執(zhí)行。中樞負(fù)責(zé)所有邏輯判斷終端只做數(shù)據(jù)采集和指令執(zhí)行這樣終端固件可以做得非常簡單幾乎不需要改動。比如溫度高于 28 度自動開風(fēng)扇這個邏輯放在中樞里用 Kotlin 寫幾行代碼就行不需要在每個終端節(jié)點(diǎn)里重復(fù)實現(xiàn)。2.3 硬件選型與參數(shù)計算硬件清單如下設(shè)備型號數(shù)量用途參考價格開發(fā)板Raspberry Pi 3 Model B1中樞主機(jī)220 元溫濕度傳感器DHT111環(huán)境監(jiān)測8 元繼電器模塊5V 單路繼電器2燈光控制6 元/個電源5V 2.5A Micro USB1中樞供電25 元杜邦線母對母 20cm1 排接線5 元ESP8266 模塊NodeMCU2終端節(jié)點(diǎn)15 元/個這里重點(diǎn)說一下電源的選擇。Raspberry Pi 3 的峰值電流可以到 2.5A如果用手機(jī)充電器通常 1A 或 2A在 Wi-Fi 滿負(fù)荷 GPIO 驅(qū)動繼電器的時候會出現(xiàn)電壓跌落導(dǎo)致系統(tǒng)重啟。我一開始用了一個 5V 1A 的充電器結(jié)果每次繼電器吸合的瞬間樹莓派就重啟排查了半天才定位到是供電不足。后來換成 5V 2.5A 的專用電源問題徹底消失。所以電源這塊千萬別省寧可買大一點(diǎn)。DHT11 的精度是溫度 ±2°C、濕度 ±5%RH對于家居環(huán)境監(jiān)測夠用了。如果你需要更高精度可以換成 DHT22 或 SHT30但價格會貴一些而且 SHT30 是 I2C 接口接線方式不同。DHT11 用的是單總線協(xié)議Android Things 的 Peripheral I/O API 不直接支持這種協(xié)議需要自己用 GPIO 模擬時序這部分后面會詳細(xì)講。3. Android Things 核心開發(fā)細(xì)節(jié)與實操要點(diǎn)3.1 環(huán)境搭建從 Android Studio 到開發(fā)板燒錄Android Things 的開發(fā)環(huán)境搭建和普通 Android 開發(fā)差不多但有幾個關(guān)鍵區(qū)別。首先Android Studio 需要安裝 Android Things SDK。在 SDK Manager 里勾選 Android Things 相關(guān)的包主要是com.google.android.things這個庫。然后在build.gradle里添加依賴dependencies { implementation com.google.android.things:androidthings:1.0 }注意版本號1.0 是穩(wěn)定版0.8 之前的 API 有較大變動網(wǎng)上很多老教程用的是 0.5 或 0.6代碼直接拿過來會編譯不過。其次開發(fā)板需要燒錄 Android Things 鏡像。以 Raspberry Pi 3 為例去 Android Things 官網(wǎng)下載對應(yīng)版本的鏡像文件.img格式然后用 Etcher 或dd命令寫入 SD 卡。寫入完成后把 SD 卡插入樹莓派接上 HDMI 顯示器和網(wǎng)線上電啟動。第一次啟動會比較慢大概 2-3 分鐘屏幕上會顯示一個 Android Things 的 Logo 和 IP 地址。這里有個坑Android Things 默認(rèn)通過 ADB over Ethernet 連接但如果你沒有網(wǎng)線想用 Wi-Fi 連接需要先通過串口或 HDMI 鍵盤進(jìn)入系統(tǒng)設(shè)置。我當(dāng)時的做法是先用網(wǎng)線連上通過adb connect IP連上去然后用adb shell執(zhí)行 Wi-Fi 配置命令adb shell am startservice \ -n com.google.wifisetup/.WifiSetupService \ -a WifiSetupService.Connect \ -e ssid 你的WiFi名稱 \ -e passphrase 你的WiFi密碼配置成功后拔掉網(wǎng)線重啟樹莓派就會自動連上 Wi-Fi。之后每次連接只需要adb connect Wi-Fi IP就行。3.2 GPIO 控制用代碼點(diǎn)亮一盞燈Android Things 的 GPIO 操作非常直觀。核心類是PeripheralManagerService通過它獲取Gpio對象然后設(shè)置方向輸入或輸出和初始狀態(tài)。PeripheralManagerService manager new PeripheralManagerService(); Gpio ledPin manager.openGpio(BCM17); ledPin.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW); ledPin.setValue(true); // 點(diǎn)亮這里的BCM17是引腳名稱對應(yīng) Raspberry Pi 的 GPIO17。不同開發(fā)板的引腳名稱不一樣Raspberry Pi 用的是 BCM 編號NXP i.MX7D 用的是另一套命名。你可以在 Android Things 的官方文檔里查到對應(yīng)開發(fā)板的引腳映射表。實際接線的時候GPIO 輸出是 3.3V 邏輯電平而繼電器模塊通常是 5V 觸發(fā)的。這里有兩種處理方式一是用 3.3V 兼容的繼電器模塊市面上有專門為 3.3V 設(shè)計的二是加一個電平轉(zhuǎn)換模塊。我一開始用的是普通 5V 繼電器直接接 GPIO 發(fā)現(xiàn)繼電器不吸合用萬用表一量GPIO 輸出只有 3.3V達(dá)不到繼電器的觸發(fā)閾值。后來換了一個 3.3V 兼容的繼電器模塊問題解決。所以買繼電器的時候一定要看清楚觸發(fā)電壓。另外GPIO 引腳在系統(tǒng)啟動時的默認(rèn)狀態(tài)是不確定的可能會在初始化之前有一個短暫的高電平脈沖。如果你控制的是燈光這個脈沖會導(dǎo)致燈閃一下。解決辦法是在硬件上加一個下拉電阻或者在軟件里盡早初始化 GPIO。我在代碼里是在onCreate里第一時間就打開 GPIO 并設(shè)置為低電平這樣脈沖時間可以縮短到幾毫秒肉眼基本看不出來。3.3 I2C 與單總線DHT11 的驅(qū)動實現(xiàn)DHT11 用的是單總線協(xié)議Android Things 沒有現(xiàn)成的 API需要用 GPIO 手動模擬時序。這個協(xié)議的核心是主機(jī)拉低總線至少 18ms然后釋放等待傳感器響應(yīng)。傳感器會拉低 80us再拉高 80us然后開始傳輸 40 位數(shù)據(jù)8 位濕度整數(shù) 8 位濕度小數(shù) 8 位溫度整數(shù) 8 位溫度小數(shù) 8 位校驗和。用 Java 實現(xiàn)的時候最大的難點(diǎn)是時序精度。Android Things 跑在 Linux 上Java 的Thread.sleep()精度只有毫秒級而 DHT11 的時序要求是微秒級。我試過直接用System.nanoTime()做忙等待但 Java 的 JIT 編譯和 GC 會導(dǎo)致偶爾的延遲抖動讀取成功率只有 60% 左右。后來我換了一個思路用 Android Things 的Gpio回調(diào)機(jī)制來捕獲邊沿變化而不是主動輪詢。具體做法是設(shè)置setEdgeTriggerType(Gpio.EDGE_BOTH)然后注冊GpioCallback在回調(diào)里記錄時間戳。這樣雖然不能完全消除抖動但成功率能提高到 85% 以上。對于家居環(huán)境監(jiān)測來說這個成功率夠用了因為你可以每秒讀一次連續(xù)讀 3 次取有效值。如果你對精度要求更高建議直接用 I2C 接口的傳感器比如 SHT30 或 BME280。Android Things 對 I2C 的支持非常完善I2cDevice device manager.openI2cDevice(I2C1, 0x44); byte[] data new byte[6]; device.read(data, data.length); // 解析溫濕度數(shù)據(jù)I2C 的讀取是硬件級別的不受 Java 時序抖動影響穩(wěn)定性遠(yuǎn)超單總線方案。我后來把 DHT11 換成了 SHT30讀取成功率直接到 100%而且精度也更高。3.4 網(wǎng)絡(luò)通信MQTT 與 HTTP 的取舍中樞與終端節(jié)點(diǎn)的通信我選了 MQTT。原因有三第一MQTT 是發(fā)布訂閱模型終端節(jié)點(diǎn)只需要訂閱自己關(guān)心的主題不需要知道其他節(jié)點(diǎn)的存在第二MQTT 有 QoS 等級可以保證消息至少送達(dá)一次第三MQTT 的 Keep Alive 機(jī)制可以自動檢測斷線配合遺囑消息Last Will可以在節(jié)點(diǎn)離線時通知中樞。Android Things 上跑 MQTT 客戶端我用的是 Eclipse Paho 庫implementation org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.2.0連接代碼MqttClient client new MqttClient(tcp://192.168.1.100:1883, android-things-hub, new MemoryPersistence()); MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(true); options.setKeepAliveInterval(30); options.setAutomaticReconnect(true); client.connect(options); client.subscribe(home/sensor/#, (topic, message) - { // 處理傳感器數(shù)據(jù) });這里有個細(xì)節(jié)setAutomaticReconnect(true)是必須的因為 Wi-Fi 不穩(wěn)定的時候 MQTT 連接會斷自動重連可以省去很多手動處理的代碼。但自動重連有個問題重連后之前的訂閱會丟失如果cleanSession為 true所以需要在MqttCallback的connectComplete方法里重新訂閱。HTTP 主要用于手機(jī) App 與中樞的交互。我在中樞上跑了一個輕量級的 HTTP 服務(wù)器用的是 NanoHTTPD大概 50KB 的 jar 包足夠處理 REST 請求。手機(jī) App 通過GET /api/sensors獲取傳感器數(shù)據(jù)通過POST /api/control下發(fā)控制指令。WebSocket 用于實時推送比如溫度變化時主動通知 App 更新 UI。4. 完整實操流程從零搭建一個可運(yùn)行的系統(tǒng)4.1 硬件接線與檢查接線是整個過程里最容易出錯的一步。我按照以下順序操作第一步斷開所有電源把 Raspberry Pi 3 放在桌面上確認(rèn) GPIO 引腳編號。樹莓派的 GPIO 引腳有兩套編號物理引腳號1-40和 BCM 編號。Android Things 用的是 BCM 編號所以接線的時候要看 BCM 映射圖不能看物理引腳號。第二步連接 DHT11。DHT11 有三個引腳VCC、DATA、GND。VCC 接 3.3V物理引腳 1GND 接 GND物理引腳 6DATA 接 GPIO4物理引腳 7BCM 編號是 4。注意 DHT11 的 DATA 引腳需要接一個 4.7K 到 10K 的上拉電阻到 VCC否則信號不穩(wěn)定。我一開始沒加上拉電阻讀取成功率只有 30%加上之后提升到 85%。第三步連接繼電器模塊。繼電器的 VCC 接 5V物理引腳 2GND 接 GND物理引腳 9IN 接 GPIO17物理引腳 11。繼電器的輸出端接燈具的火線零線直連。這里涉及 220V 強(qiáng)電如果你沒有電工經(jīng)驗建議先用 LED 燈珠模擬等邏輯跑通了再接觸強(qiáng)電。安全第一。第四步上電檢查。先不插 SD 卡只接電源用萬用表測量各引腳電壓確認(rèn) 3.3V 和 5V 正常。然后斷電插上 SD 卡上電啟動。4.2 Android Things 項目結(jié)構(gòu)與關(guān)鍵代碼項目結(jié)構(gòu)如下app/ ├── src/main/ │ ├── java/com/example/smarthome/ │ │ ├── MainActivity.java // 主入口初始化 GPIO 和 MQTT │ │ ├── SensorManager.java // 傳感器讀取邏輯 │ │ ├── DeviceController.java // 繼電器控制邏輯 │ │ ├── MqttHandler.java // MQTT 通信 │ │ └── HttpServer.java // HTTP API │ ├── res/ │ └── AndroidManifest.xmlAndroidManifest.xml里需要聲明權(quán)限和特性uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_NETWORK_STATE / uses-feature android:nameandroid.hardware.type.embedded /uses-feature這一行很關(guān)鍵它告訴系統(tǒng)這是一個嵌入式設(shè)備應(yīng)用沒有它的話Android Things 可能不會在啟動時自動運(yùn)行你的 App。主入口MainActivity的核心邏輯public class MainActivity extends Activity { private Gpio ledPin; private SensorManager sensorManager; private MqttHandler mqttHandler; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); PeripheralManagerService manager new PeripheralManagerService(); try { ledPin manager.openGpio(BCM17); ledPin.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW); } catch (IOException e) { Log.e(TAG, GPIO init failed, e); } sensorManager new SensorManager(manager); mqttHandler new MqttHandler(this); mqttHandler.connect(); } Override protected void onDestroy() { super.onDestroy(); if (ledPin ! null) { try { ledPin.close(); } catch (IOException e) { } } mqttHandler.disconnect(); } }傳感器讀取的定時任務(wù)用ScheduledExecutorService每 5 秒讀一次ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() - { float temp sensorManager.readTemperature(); float humidity sensorManager.readHumidity(); mqttHandler.publish(home/sensor/bedroom, String.format({\temp\:%.1f,\humidity\:%.1f}, temp, humidity)); }, 0, 5, TimeUnit.SECONDS);4.3 手機(jī) App 與中樞的聯(lián)調(diào)手機(jī) App 我用的是 Kotlin Retrofit接口定義很簡單interface SmartHomeApi { GET(/api/sensors) suspend fun getSensors(): SensorData POST(/api/control) suspend fun controlDevice(Body command: ControlCommand): ResponseUnit }聯(lián)調(diào)的時候遇到一個典型問題Android Things 的 HTTP 服務(wù)器默認(rèn)監(jiān)聽 8080 端口但手機(jī) App 用 Retrofit 請求的時候一直超時。排查后發(fā)現(xiàn)是 Android Things 的防火墻默認(rèn)只開放了 ADB 端口5555其他端口需要手動開放。解決辦法是在adb shell里執(zhí)行adb shell iptables -A INPUT -p tcp --dport 8080 -j ACCEPT但這個命令重啟后會失效需要寫一個啟動腳本。我把命令放到了MainActivity的onCreate里用Runtime.getRuntime().exec()執(zhí)行這樣每次 App 啟動都會自動開放端口。另一個問題是 JSON 解析。Android Things 上跑的是完整 Android 系統(tǒng)可以用 Gson 或 Moshi但要注意混淆規(guī)則。我在proguard-rules.pro里加了-keep class com.example.smarthome.model.** { *; }否則 Release 版本會因為混淆導(dǎo)致 JSON 字段名被改解析失敗。4.4 自動化邏輯的實現(xiàn)智能家居的核心價值在于自動化。我實現(xiàn)了幾個基礎(chǔ)規(guī)則溫度高于 28°C 自動開風(fēng)扇繼電器 1濕度低于 40% 自動開加濕器繼電器 2晚上 10 點(diǎn)后自動關(guān)閉所有燈光這些規(guī)則用簡單的if-else就能實現(xiàn)但更好的方式是做一個規(guī)則引擎。我用了一個輕量級的方案把規(guī)則定義成 JSON存在 SD 卡里中樞啟動時加載{ rules: [ { name: 高溫開風(fēng)扇, condition: {sensor: temperature, operator: , value: 28}, action: {device: fan, command: on} } ] }然后寫一個RuleEngine類每次傳感器數(shù)據(jù)更新時遍歷規(guī)則匹配到就執(zhí)行動作。這樣做的好處是修改規(guī)則不需要重新編譯代碼直接改 JSON 文件重啟就行。5. 常見問題與排查技巧實錄5.1 系統(tǒng)啟動失敗與 ADB 連接問題問題現(xiàn)象樹莓派上電后 HDMI 無輸出或者卡在 Android Things Logo 不動。排查思路首先檢查電源用萬用表量一下電壓是否穩(wěn)定在 5V。如果電壓低于 4.8V系統(tǒng)會啟動失敗。其次檢查 SD 卡Android Things 對 SD 卡的速度有要求Class 10 以上比較穩(wěn)妥。我用過一張雜牌的 Class 4 卡寫入鏡像后啟動一直失敗換卡后正常。ADB 連接問題如果adb connect一直失敗先確認(rèn)樹莓派和電腦在同一個網(wǎng)段。然后檢查 ADB 版本Android Things 需要 ADB 1.0.39 以上。如果還是不行用adb kill-server adb start-server重啟 ADB 服務(wù)。5.2 GPIO 控制異常與電平匹配問題現(xiàn)象繼電器不吸合或者吸合后樹莓派重啟。排查思路繼電器不吸合先量 GPIO 輸出電壓如果是 3.3V 而繼電器需要 5V就需要電平轉(zhuǎn)換。吸合后重啟基本是電源功率不夠換大功率電源。另外繼電器線圈在斷電時會產(chǎn)生反向電動勢可能干擾樹莓派建議在繼電器線圈兩端并聯(lián)一個續(xù)流二極管1N4007。5.3 傳感器讀取不穩(wěn)定問題現(xiàn)象DHT11 讀取成功率低數(shù)據(jù)偶爾為 NaN。排查思路首先檢查上拉電阻4.7K 到 10K 都可以我用的 10K。其次檢查接線長度杜邦線太長會引入干擾建議不超過 20cm。如果還是不穩(wěn)定在代碼里加重試機(jī)制for (int i 0; i 3; i) { float temp sensorManager.readTemperature(); if (!Float.isNaN(temp)) return temp; Thread.sleep(100); } return Float.NaN;5.4 MQTT 斷線重連與消息丟失問題現(xiàn)象Wi-Fi 波動后 MQTT 連接斷開重連后收不到消息。排查思路確保setAutomaticReconnect(true)和setCleanSession(false)。cleanSession設(shè)為 false 時Broker 會保留訂閱關(guān)系和未送達(dá)的消息QoS 1 或 2。但要注意cleanSession為 false 時客戶端 ID 必須固定否則 Broker 會認(rèn)為是新客戶端。5.5 常見問題速查表問題可能原因解決方法系統(tǒng)啟動失敗電源不足 / SD 卡速度慢換 5V 2.5A 電源 / Class 10 SD 卡ADB 連不上網(wǎng)段不同 / ADB 版本低檢查網(wǎng)絡(luò) / 升級 ADB繼電器不吸合電平不匹配換 3.3V 繼電器或加電平轉(zhuǎn)換樹莓派重啟電源功率不夠換大功率電源DHT11 讀取失敗缺上拉電阻 / 線太長加上拉電阻 / 縮短線長MQTT 斷線Wi-Fi 不穩(wěn)定開啟自動重連 / 固定客戶端 IDHTTP 超時防火墻未開放端口iptables 開放端口JSON 解析失敗混淆規(guī)則缺失添加 keep 規(guī)則6. 系統(tǒng)擴(kuò)展與個人實操體會這套系統(tǒng)跑了大半年中間經(jīng)歷過幾次迭代。最開始只有溫濕度和燈光控制后來陸續(xù)加了人體紅外傳感器HC-SR501、門窗磁傳感器MC-38、以及一個簡單的語音控制模塊。每次加新設(shè)備核心邏輯幾乎不用改只需要在SensorManager里加一個讀取方法在RuleEngine里加一條規(guī)則。這種中樞集中決策的架構(gòu)擴(kuò)展性確實比分散式方案好很多。不過 Android Things 也有它的局限。首先是啟動速度從通電到 App 完全就緒大概需要 40 秒比 ESP8266 的 3 秒慢太多。如果你需要快速響應(yīng)的場景比如人體感應(yīng)開燈純 Android Things 方案會有明顯的延遲。我的做法是把人體感應(yīng)這種低延遲需求放到 ESP8266 終端節(jié)點(diǎn)上本地直接觸發(fā)繼電器同時通過 MQTT 通知中樞記錄狀態(tài)。這樣既保證了響應(yīng)速度又保留了中樞的數(shù)據(jù)聚合能力。其次是成本。一塊 Raspberry Pi 3 加上電源、SD 卡、外殼整套下來接近 300 塊。如果你只是想做一兩個燈的控制用 ESP8266 方案 30 塊就能搞定。Android Things 適合的是那種需要復(fù)雜邏輯、多設(shè)備協(xié)同、且你本身有 Android 開發(fā)經(jīng)驗的場景。如果你完全不懂 Android為了做智能家居去學(xué) Android 開發(fā)投入產(chǎn)出比可能不太劃算。最后分享一個我在調(diào)試過程中總結(jié)的小技巧Android Things 的日志可以通過adb logcat查看但默認(rèn)輸出量很大建議用標(biāo)簽過濾adb logcat -s SmartHome:V MqttHandler:V SensorManager:V這樣只看自己代碼的日志排查問題效率高很多。另外Android Things 支持遠(yuǎn)程調(diào)試你可以在 Android Studio 里直接對樹莓派上的 App 下斷點(diǎn)單步調(diào)試硬件邏輯這個體驗比串口打印日志好太多了。我第一次用遠(yuǎn)程調(diào)試定位到 DHT11 時序問題時感覺就像在調(diào)試一個普通的 Android App完全忘了自己是在操作硬件。