簡介本資源是一套完整的智能家居Android應(yīng)用開發(fā)實戰(zhàn)資料包面向計算機、物聯(lián)網(wǎng)、自動化、電子信息等專業(yè)的在校學生、教師及初級開發(fā)者適用于畢業(yè)設(shè)計、課程設(shè)計、項目立項演示及Android進階學習。壓縮包共220個文件含62個Java源碼文件實現(xiàn)設(shè)備控制、場景聯(lián)動、用戶管理等核心邏輯、82個XML布局與配置文件涵蓋UI界面、權(quán)限聲明及資源適配、53個PNG圖標資源支持多分辨率設(shè)備以及Gradle構(gòu)建腳本、APK安裝包、簽名配置等工程必需文件整體大小為6.84MB結(jié)構(gòu)規(guī)范、模塊清晰便于快速編譯運行與二次開發(fā)。已有54人下載學習項目源自高分實踐成果答辯評分95分所有代碼均經(jīng)實機測試驗證功能完整穩(wěn)定配套文檔詳盡覆蓋需求分析、架構(gòu)設(shè)計、接口說明與部署指南支持小白入門與中階開發(fā)者快速復(fù)用或拓展功能。1. 項目定位與現(xiàn)實需求1.1 為什么智能家居的終端要落在Android上今年這個時間節(jié)點再聊智能家居App開發(fā)其實已經(jīng)不是要不要做的問題而是怎么做才能做得順手。我接觸過不少從嵌入式轉(zhuǎn)過來做移動端的開發(fā)者也有從后端轉(zhuǎn)過來的大家第一個反應(yīng)都是智能家居系統(tǒng)里設(shè)備固件、網(wǎng)關(guān)協(xié)議都搞定了App不就是個遙控器嗎真做起來才發(fā)現(xiàn)這個遙控器恰恰是整個系統(tǒng)里最容易被用戶感知、也最容易翻車的一環(huán)。資料包和標題里反復(fù)出現(xiàn)的Android App本質(zhì)上是整個智能家居系統(tǒng)的三塊拼圖之一設(shè)備端傳感器、開關(guān)、門鎖、服務(wù)端云端API、消息中轉(zhuǎn)、用戶端Android/iOS App。而Android占了國內(nèi)智能家居用戶端的絕大多數(shù)份額原因很直接設(shè)備廠商的網(wǎng)關(guān)和傳感器大多走WiFi、藍牙、Zigbee這類協(xié)議Android在BLE開發(fā)上有完整API調(diào)試起來比iOS要靈活開放度完全不一樣。Android手機品牌分散、系統(tǒng)版本跨度大這意味著App寫出來之后要面對各種Rom的兼容性但反而鍛煉了代碼的健壯性工程上更有挑戰(zhàn)也更能積累經(jīng)驗。從成本角度考慮一套Android端的方案可以直接跑在幾百塊的低價平板和舊手機上用戶把舊手機掛墻上當控制面板體驗比買專用中控屏還好。1.2 這個全部資料詳細文檔項目到底覆蓋了什么從標題的字面信息來看這套項目資料包含的不只是源碼而是完整的工程化交付物Android客戶端工程、硬件端示例大概率包含ESP32、STM32的固件參考、通信協(xié)議文檔、以及UI設(shè)計規(guī)范。這類項目的價值不在于代碼能跑而在于它把智能家居App到底應(yīng)該長什么樣、踩過哪些坑都沉淀了下來。我見過太多人拿到一個類似項目之后第一件事就是把代碼塞進Android Studio編譯發(fā)現(xiàn)有報錯然后來來回回改依賴版本一整天過去了還在原地打轉(zhuǎn)。原因很簡單智能家居App不是寫幾個頁面調(diào)幾個接口就完了它涉及網(wǎng)絡(luò)連接、設(shè)備發(fā)現(xiàn)、狀態(tài)同步、離線消息、權(quán)限適配。如果只看代碼不看文檔遇到問題只能猜。所以這篇博文我不打算貼整包源碼來水篇幅因為畢竟你的硬件設(shè)備、云平臺可能和項目里不一樣。我更想基于這類項目的通用結(jié)構(gòu)和實施經(jīng)驗把拿到這套資料之后該怎么看、怎么做才能不踩坑講透。你手里有代碼文檔我這里教你方法論和實操路徑兩者結(jié)合才能真正把這套資料的價值榨干。2. 整體架構(gòu)設(shè)計拆解2.1 設(shè)備控制鏈路從手機到傳感器的完整路徑智能家居App最難講清楚但又最核心的是它和普通App在架構(gòu)上的本質(zhì)差異。普通App是用戶到服務(wù)器的單向或雙向請求而智能家居App處在一條很長的控制鏈路上手機App - 通信協(xié)議 - 路由器/網(wǎng)關(guān) - 智能設(shè)備(ESP32/STM32/傳感器) - 執(zhí)行動作 - 狀態(tài)上報 - App刷新看這個鏈路你就會發(fā)現(xiàn)任何一個環(huán)節(jié)斷了用戶的直觀感受就是App失靈了。而App開發(fā)者能掌控的其實只有第一環(huán)和最后一環(huán)中間的網(wǎng)絡(luò)和硬件穩(wěn)定性都不在控制范圍之內(nèi)。所以你在設(shè)計App架構(gòu)時不能假設(shè)網(wǎng)絡(luò)永遠是通的、設(shè)備永遠在線必須把異常情況當成正常情況來設(shè)計。以我經(jīng)手的WiFi方案為例設(shè)備連接家里的路由器App通過局域網(wǎng)或云端下發(fā)指令。局域網(wǎng)方案的延遲更低但要做設(shè)備發(fā)現(xiàn)比較常見的是UDP廣播加設(shè)備自報云端方案則要依賴服務(wù)器的穩(wěn)定性和設(shè)備長連接的?；顧C制。真正成熟的商用App都走雙通道局域網(wǎng)可用時優(yōu)先局域網(wǎng)斷網(wǎng)時自動切云端同時把指令的ACK和重發(fā)機制做進去。2.2 .zip項目里的標準分層結(jié)構(gòu)很多初學者拿到這類項目壓縮包先去找MainActivity和布局文件這是不對的思路。智能家居App的工程結(jié)構(gòu)通常遵循清晰的分層每個目錄都有自己的職責應(yīng)用層App層負責UI展示和用戶交互包括設(shè)備列表、控制面板、場景編輯頁面、個人中心。業(yè)務(wù)層Manager/Repository封裝設(shè)備管理、消息推送、場景聯(lián)動等業(yè)務(wù)邏輯。這一層不關(guān)心按鈕長什么樣只處理做什么。通信層Net/Protocol負責MQTT、TCP、BLE等協(xié)議的封裝對外提供統(tǒng)一的發(fā)送和監(jiān)聽接口。數(shù)據(jù)層Local/DB用數(shù)據(jù)庫或SharedPreferences緩存設(shè)備列表和用戶配置保證弱網(wǎng)環(huán)境下App仍能展示基本信息。這個分層的核心價值在于更換硬件方案或者云平臺時只需要替換通信層的數(shù)據(jù)源業(yè)務(wù)層和界面層可以完全復(fù)用。我見過太多項目把所有的邏輯全堆在Activity里一個頁面上千行最后運維和迭代成本高到離譜。所以拿到資料包之后建議先畫一張依賴關(guān)系圖理清各個模塊之間的依賴方向再動手改代碼。2.3 通信協(xié)議選型MQTT、TCP、藍牙與Zigbee網(wǎng)關(guān)智能家居的熱搜詞里頻繁出現(xiàn)esp32stm32zigbee這三類硬件決定了你項目里需要接入的通信協(xié)議不止一種。這里我按實際項目中出現(xiàn)頻率把協(xié)議選型說明一下協(xié)議類型典型硬件適用場景優(yōu)點缺點WiFi MQTTESP32、ESP8266家庭網(wǎng)關(guān)、智能插座云端可控、跨公網(wǎng)、生態(tài)成熟功耗偏高、依賴WiFi環(huán)境WiFi TCP攝像頭、門鎖實時性要求高的控制低延遲、可自定義協(xié)議需要做斷線重連和粘包處理BLE低功耗藍牙傳感器、手環(huán)、門鎖近距離控制、配網(wǎng)功耗極低、無需WiFi距離短、需要處理兼容性Zigbee網(wǎng)關(guān)海量低功耗節(jié)點全屋智能傳感器網(wǎng)絡(luò)自組網(wǎng)、低功耗、穩(wěn)定需要額外網(wǎng)關(guān)硬件App不直連設(shè)備這里面我特別想提一點很多新手以為App要直接跟每個設(shè)備通信其實在Zigbee方案里App根本不認識設(shè)備只認識網(wǎng)關(guān)所有指令都發(fā)給網(wǎng)關(guān)由網(wǎng)關(guān)下發(fā)給節(jié)點。這一點在設(shè)計App的數(shù)據(jù)模型時非常重要——你的設(shè)備概念必須是虛擬化的它可以是物理設(shè)備也可以是一個邏輯分組甚至是一個場景。3. 核心功能模塊與關(guān)鍵實現(xiàn)3.1 設(shè)備發(fā)現(xiàn)與配網(wǎng)所有智能家居App的第一道門檻如果給智能家居App的功能模塊做個重要性排序設(shè)備發(fā)現(xiàn)和配網(wǎng)排第一?？刂祈撁孀龅迷倨猎O(shè)備連不上網(wǎng)用戶第一時間就卸載了。配網(wǎng)的核心流程是這樣的設(shè)備上電后進入配網(wǎng)模式通常是長按按鍵或連續(xù)上電三次觸發(fā)此時設(shè)備會打開一個臨時的SoftAP熱點App先連接這個熱點把家庭WiFi的SSID和密碼通過特定協(xié)議發(fā)給設(shè)備設(shè)備再切換模式連上路由器最后App通過局域網(wǎng)廣播確認設(shè)備上線。在Android端實現(xiàn)這個流程需要處理兩個比較麻煩的點。第一個是跳WiFi的權(quán)限Android 10及以上版本跳轉(zhuǎn)到系統(tǒng)WiFi設(shè)置后App退到后臺再回來需要監(jiān)聽onResume并輪詢當前連接的WiFi是否已經(jīng)切換到設(shè)備的SoftAP熱點。第二個是Android 8.0之后App無法直接操作系統(tǒng)的WiFi連接只能引導用戶到設(shè)置界面手動連接體驗會多一步。另外配網(wǎng)過程一定要給足狀態(tài)反饋。用戶連上設(shè)備熱點后等待設(shè)備重啟再連路由器的過程往往需要10到30秒這段時間如果沒有進度提示用戶會以為App卡死了。實操中我會在UI上做三態(tài)切換等待連接設(shè)備熱點、正在下發(fā)配置、確認設(shè)備上線三步都配上倒計時和錯誤提示。這一小塊做好了App的專業(yè)感立刻就不一樣了。3.2 設(shè)備列表的狀態(tài)同步不要為了實時而實時App主頁面通常是設(shè)備列表顯示房間內(nèi)所有設(shè)備的工作狀態(tài)。這里的核心問題是設(shè)備狀態(tài)怎么同步很多項目圖省事輪詢接口每兩秒請求一次云端設(shè)備一多服務(wù)器壓力大手機電量也受不了。更合理的做法是雙模同步實時模式當一個設(shè)備狀態(tài)變化時設(shè)備端或云端通過MQTT消息推送給AppApp收到消息后只刷新對應(yīng)的設(shè)備卡片而不是全量刷新。定期全量App從后臺回前臺、或下拉刷新時主動拉一次全量設(shè)備狀態(tài)保證數(shù)據(jù)的一致性。這套方案的邏輯很簡單但落地的時候有幾個坑要提醒一下MQTT消息要帶設(shè)備ID、屬性名和值比如{deviceId:dev_001,attr:power,value:1}App端根據(jù)設(shè)備ID定位到列表里的position做局部刷新。如果在RecyclerView里直接notifyDataSetChanged列表會閃爍體驗很差。狀態(tài)同步一定要帶上時間戳否則設(shè)備離線期間積累的舊消息會覆蓋新狀態(tài)造成顯示臟數(shù)據(jù)。判斷規(guī)則是新消息的時間戳必須大于當前UI上記錄的狀態(tài)時間戳才允許更新。首次加載設(shè)備列表時如果設(shè)備比較多建議做成骨架屏加漸進加載。先把房間和設(shè)備名稱顯示出來再逐個填充狀態(tài)用戶的等待感知會小很多。3.3 控制指令下發(fā)可靠送達比什么都重要設(shè)備控制是用戶使用頻率最高的功能指令下發(fā)的可靠性直接決定用戶對App的信任度。我的經(jīng)驗是控制指令必須走發(fā)送-確認-反饋三步閉環(huán)缺一步都不行。以最簡單的開關(guān)燈為例用戶點擊開關(guān)按鈕App立即將按鈕置為正在執(zhí)行狀態(tài)本地UI先變過去給用戶即時反饋。App通過MQTT或TCP發(fā)送控制指令同時啟動一個超時定時器一般是3秒。如果3秒內(nèi)沒有收到設(shè)備回復(fù)的ACK就認定發(fā)送失敗。設(shè)備執(zhí)行成功后會回傳新的狀態(tài)App收到新狀態(tài)后再把按鈕狀態(tài)從正在執(zhí)行更新為確定狀態(tài)。如果回傳狀態(tài)和本地預(yù)期不一致說明指令沒被執(zhí)行或執(zhí)行異常此時要彈出提示并回滾UI。這條閉環(huán)里最容易被忽略的是超時處理。很多人只發(fā)指令不管結(jié)果設(shè)備離線時用戶點了開關(guān)毫無反應(yīng)體驗就是這個App壞了。加上超時和重試邏輯之后比如失敗后重試2次仍不成功則提示設(shè)備離線請檢查網(wǎng)絡(luò)可靠性的感受會完全不同。另外App往設(shè)備發(fā)指令的協(xié)議格式要盡量簡潔。一個開關(guān)控制指令沒必要搞成JSON大字符串最好是緊湊的二進制幀或者短JSON比如{cmd:set,did:dev_01,attr:{power:1}}字段越少越好解析出錯的可能性越低。3.4 場景聯(lián)動把控制設(shè)備升級為操控生活所謂場景就是把多個設(shè)備的狀態(tài)變化編排成一個動作序列。比如回家模式可以定義為打開客廳燈、打開空調(diào)并調(diào)到26度、打開電視。用戶只需要一個按鈕或者設(shè)定時間條件自動觸發(fā)就可以同時執(zhí)行一系列動作。從架構(gòu)上看場景功能包含兩部分場景編輯器和場景執(zhí)行引擎。編輯器負責把動作列表組裝成可配置的數(shù)據(jù)結(jié)構(gòu)核心字段包括場景名稱、觸發(fā)條件手動、定時、傳感器觸發(fā)、動作列表每個動作是哪個設(shè)備、設(shè)置為哪個狀態(tài)。執(zhí)行引擎在事件到來時檢查條件一旦滿足就按順序或并發(fā)下發(fā)動作指令。這里有一個Android實現(xiàn)上的經(jīng)驗場景執(zhí)行結(jié)果必須逐條回執(zhí)。設(shè)想一個場景包含5個動作第3個動作執(zhí)行失敗用戶需要知道是哪個失敗、為什么失敗。App端的做法是把每個動作封裝成獨立的任務(wù)各自維護狀態(tài)待執(zhí)行/執(zhí)行中/成功/失敗執(zhí)行完畢后以列表卡片的方式展示結(jié)果并對失敗動作提供重試單個動作的入口。Android的協(xié)程非常適合做這個編排每個動作起一個Coroutine超時和異常獨立捕獲。3.5 藍牙功能兼容Android歷史版本的老大難熱詞里的android藍牙藍牙app控制esp32指向的是同一件事在Android上通過BLE控制ESP32這類硬件時兼容性是最大的坑。我梳理幾個常見的雷區(qū)權(quán)限適配Android 6.0要動態(tài)申請定位權(quán)限才能掃BLEAndroid 12及以上要申請BLUETOOTH_SCAN和BLUETOOTH_CONNECT權(quán)限且這兩項是危險權(quán)限需要動態(tài)申請。如果漏掉掃描結(jié)果永遠是空。掃描回調(diào)舊版用LeScanCallback掃描新版推薦用ScanCallback。很多老項目的代碼在新系統(tǒng)上直接不回調(diào)問題就出在API版本差異上。寫兼容層時建議判斷SDK_INT版本大于等于21用ScanCallback否則用LeScanCallback。MTU協(xié)商ESP32的BLE服務(wù)一次能收的字節(jié)數(shù)有限默認MTU是23字節(jié)扣掉協(xié)議頭之后實際才20字節(jié)稍長一點的數(shù)據(jù)包就發(fā)不過去。Android 5.0以上可以通過requestMtu動態(tài)協(xié)商建議首次連接后主動請求一個較大的MTU比如247協(xié)商成功后再發(fā)送數(shù)據(jù)。重連機制BLE連接很容易因為距離、干擾等原因斷開App端必須在onConnectionStateChange里監(jiān)聽斷開事件自動發(fā)起重連并做好重連次數(shù)限制比如最多3次防止設(shè)備斷電時App無限重連耗電。4. 實操從編譯到運行把項目跑起來的完整流程4.1 環(huán)境準備Android Studio安裝與SDK配置拿到項目源碼后先別急著打開把環(huán)境確認一遍能省很多時間。這套資料對應(yīng)的開發(fā)工具是Android Studio安裝時需要注意幾個點JDK版本要匹配Gradle版本。現(xiàn)在新版Android Studio基本都內(nèi)置了JBRJetBrains Runtime但老項目的Gradle插件可能要求JDK 8或JDK 11。如果項目編譯報Unsupported class file major version這類錯誤先檢查JDK版本是否過高。SDK版本方面建議安裝Android SDK Platform 33和Android SDK Build-Tools 33.0.2。兼容寫法是compileSdkVersion用33minSdkVersion看項目支持的設(shè)備下限targetSdkVersion按當前市場要求設(shè)到33左右。如果項目里的gradle文件引用的compileSdkVersion版本還沒安裝Android Studio會提示自動安裝但國內(nèi)網(wǎng)絡(luò)環(huán)境下載SDK可能會卡住建議提前配好國內(nèi)鏡像源。下面是我常用的一份gradle依賴倉庫配置放在settings.gradle里pluginManagement { repositories { maven { url https://maven.aliyun.com/repository/google } maven { url https://maven.aliyun.com/repository/gradle-plugin } maven { url https://maven.aliyun.com/repository/public } google() mavenCentral() gradlePluginPortal() } } dependencyResolutionManagement { repositories { maven { url https://maven.aliyun.com/repository/google } maven { url https://maven.aliyun.com/repository/public } google() mavenCentral() } }另外提醒一件事項目里如果用了第三方MQTT庫例如Eclipse Paho需要確認依賴是否已經(jīng)正確拉到本地。編譯報Could not find org.eclipse.paho:org.eclipse.paho.client.mqttv3之類的錯誤多半是倉庫沒有配paho的maven源可以在repositories里加上maven { url https://repo.eclipse.org/content/repositories/paho-releases/ }。4.2 工程目錄結(jié)構(gòu)與AndroidManifest配置一個標準的智能家居App工程目錄結(jié)構(gòu)大致如下app/ ├── src/main/ │ ├── java/com/example/smarthome/ │ │ ├── activity/ # Activity頁面 │ │ ├── adapter/ # RecyclerView適配器 │ │ ├── model/ # 數(shù)據(jù)模型 │ │ ├── net/ # 網(wǎng)絡(luò)請求與MQTT封裝 │ │ ├── db/ # 本地數(shù)據(jù)庫 │ │ └── utils/ # 工具類 │ ├── res/ │ │ ├── layout/ # 布局文件 │ │ ├── values/ # 顏色、字符串、主題 │ │ └── drawable/ # 矢量圖標與背景 │ └── AndroidManifest.xml拿到源碼后第一步檢查AndroidManifest把權(quán)限聲明確認清楚。智能家居App最基本的權(quán)限集如下uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_NETWORK_STATE / uses-permission android:nameandroid.permission.ACCESS_WIFI_STATE / uses-permission android:nameandroid.permission.CHANGE_WIFI_STATE / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION / uses-permission android:nameandroid.permission.ACCESS_COARSE_LOCATION / !-- Android 12 藍牙權(quán)限 -- uses-permission android:nameandroid.permission.BLUETOOTH_SCAN / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT / !-- Android 12以下藍牙權(quán)限 -- uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_ADMIN android:maxSdkVersion30 /這里有個細節(jié)ACCESS_FINE_LOCATION之所以是必需項是因為Android系統(tǒng)規(guī)定掃描BLE必須要有定位權(quán)限雖然邏輯上看似無關(guān)但這是系統(tǒng)層面的強制要求不加就掃不到設(shè)備。4.3 MQTT通信模塊的代碼骨架網(wǎng)絡(luò)通信是智能家居App的心臟。下面這份代碼是我在多個項目里用下來的最小骨架直接參考它做本地調(diào)試可以省掉很多摸索時間public class MqttManager { private MqttAndroidClient client; private String brokerUrl tcp://192.168.1.100:1883; private String clientId android_ System.currentTimeMillis(); public MqttManager(Context context) { client new MqttAndroidClient(context, brokerUrl, clientId); } public void connect() { MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(false); options.setAutomaticReconnect(true); options.setConnectionTimeout(10); // 實際項目中一般會啟用用戶名密碼認證 // options.setUserName(user); // options.setPassword(pass.toCharArray()); try { client.connect(options, null, new IMqttActionListener() { Override public void onSuccess(IMqttToken asyncActionToken) { Log.d(MqttManager, connected); subscribeTopic(devices//status); } Override public void onFailure(IMqttToken asyncActionToken, Throwable exception) { Log.e(MqttManager, connect failed, exception); } }); } catch (MqttException e) { e.printStackTrace(); } } private void subscribeTopic(String topic) { try { client.subscribe(topic, 1); } catch (MqttException e) { e.printStackTrace(); } } public void publish(String topic, String payload) { try { MqttMessage message new MqttMessage(payload.getBytes()); message.setQos(1); client.publish(topic, message); } catch (MqttException e) { e.printStackTrace(); } } public void setCallback(MqttCallbackExtended callback) { client.setCallback(callback); } }這里解釋幾個關(guān)鍵參數(shù)的含義setCleanSession(false)的作用是讓服務(wù)端保留該客戶端的會話當App斷線重連后可以收到離線期間發(fā)布的消息。setAutomaticReconnect(true)是讓SDK自動處理斷線重連不用自己在業(yè)務(wù)層寫循環(huán)。QoS設(shè)為1的意思是消息至少送達一次兼顧了實時性和可靠性是智能家居場景下用得最多的等級。收到消息后的回調(diào)通常長這樣client.setCallback(new MqttCallbackExtended() { Override public void connectComplete(boolean reconnect, String serverURI) { // 重連成功后重新訂閱所需主題 } Override public void connectionLost(Throwable cause) { // 提示用戶設(shè)備離線 } Override public void messageArrived(String topic, MqttMessage message) { String payload new String(message.getPayload()); // 解析topic和payload更新對應(yīng)設(shè)備狀態(tài) updateDeviceStatus(topic, payload); } Override public void deliveryComplete(IMqttDeliveryToken token) { // 消息送達確認可用于刷新指令狀態(tài) } });注意connectComplete這個回調(diào)很多初學者會忽略它。當自動重連成功后SDK不會自動恢復(fù)之前訂閱的主題必須在這里重新subscribe否則設(shè)備狀態(tài)就斷了。4.4 藍牙掃描與連接ESP32的關(guān)鍵代碼如果你的項目里需要直接通過BLE控制ESP32不用WiFi網(wǎng)關(guān)我強烈建議封裝一個單獨的BleManager類把權(quán)限檢查、掃描、連接、收發(fā)數(shù)據(jù)全部收攏起來。以下是掃描部分的核心邏輯class BleManager(private val context: Context) { private val bluetoothAdapter: BluetoothAdapter? by lazy { val manager context.getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager manager.adapter } fun checkPermissions(): Boolean { return if (Build.VERSION.SDK_INT Build.VERSION_CODES.S) { ContextCompat.checkSelfPermission( context, Manifest.permission.BLUETOOTH_SCAN ) PackageManager.PERMISSION_GRANTED ContextCompat.checkSelfPermission( context, Manifest.permission.BLUETOOTH_CONNECT ) PackageManager.PERMISSION_GRANTED } else { ContextCompat.checkSelfPermission( context, Manifest.permission.ACCESS_FINE_LOCATION ) PackageManager.PERMISSION_GRANTED } } fun startScan(callback: (BluetoothDevice) - Unit) { val scanner bluetoothAdapter?.bluetoothLeScanner ?: return val scanCallback object : ScanCallback() { override fun onScanResult(callbackType: Int, result: ScanResult) { val device result.device if (device.name?.contains(ESP32) true) { callback(device) } } override fun onScanFailed(errorCode: Int) { // 錯誤碼1代表掃描啟動失敗需要檢查藍牙是否開啟 } } scanner.startScan(scanCallback) } }在連接設(shè)備之后需要動態(tài)協(xié)商MTU并查找服務(wù)UUID。ESP32上常見的BLE服務(wù)UUID可以在固件的代碼里找到App端要與它保持一致否則GATT通信會失敗。4.5 Android 9及以上強制啟用明文傳輸?shù)倪m配這是最容易踩的一個坑。從Android 9API 28開始系統(tǒng)默認禁止App使用明文HTTP請求而智能家居的局域網(wǎng)控制大部分走的是http://192.168.x.x:8080這類明文協(xié)議。如果你在調(diào)試時發(fā)現(xiàn)局域網(wǎng)請求直接報Cleartext HTTP traffic not permitted就是這個原因。解決方案有幾種第一種是在AndroidManifest.xml的application節(jié)點加上android:usesCleartextTraffictrue這是全局放行適合內(nèi)部項目或者工具類App。第二種是配置network security config只允許特定域名或IP走明文network-security-config base-config cleartextTrafficPermittedfalse / domain-config cleartextTrafficPermittedtrue domain includeSubdomainstrue192.168.1.100/domain domain includeSubdomainstruesmarthome.local/domain /domain-config /network-security-config然后在Manifest里引用application android:networkSecurityConfigxml/network_security_config ... /推薦使用第二種因為全局放行會帶來安全審計上的風險而上架應(yīng)用商店時審核人員對明文流量會重點檢查。定好一套白名單式的配置既能滿足開發(fā)調(diào)試也能保證上架安全。5. 從跑起來到用得住體驗優(yōu)化與避坑錦囊5.1 離線策略App斷網(wǎng)不能變成磚頭智能家居App有一個很特殊的場景用戶回到家里手機連著WiFi但外網(wǎng)斷線了這時候如果所有功能都依賴云端那App基本癱瘓用戶的家庭控制也跟著完蛋。這個體驗問題直接決定產(chǎn)品和競品之間的差距。我的建議是核心控制鏈路必須支持純局域網(wǎng)模式。具體做法是App在啟動時先嘗試連接云端同時啟動局域網(wǎng)設(shè)備發(fā)現(xiàn)UDP廣播或者掃描設(shè)備熱點。如果云端連接失敗但局域網(wǎng)設(shè)備發(fā)現(xiàn)成功App自動進入局域網(wǎng)模式此時所有控制指令直接走局域網(wǎng)IP下發(fā)。UI上可以加個小角標提示局域網(wǎng)模式。這里面有一個值得注意的數(shù)據(jù)存儲問題局域網(wǎng)模式下設(shè)備的名稱、房間位置、狀態(tài)這些數(shù)據(jù)要從本地緩存讀取不能依賴云端下發(fā)。所以App在首次從云端拉取設(shè)備列表之后務(wù)必將設(shè)備信息持久化到數(shù)據(jù)庫。我用的是Room簡單可靠數(shù)據(jù)模型長這樣Entity(tableName device) data class Device( PrimaryKey val deviceId: String, val name: String, val roomId: String, val ipAddress: String, val stateJson: String, val updateTime: Long )每次收到設(shè)備狀態(tài)更新時除了更新UI還要同步更新數(shù)據(jù)庫里的stateJson和updateTime。這樣即使完全離線用戶在列表頁也能看到最后一次的已知狀態(tài)。5.2 通知欄與快捷開關(guān)智能家居App的高頻入口設(shè)備放在App二級頁面里每次控制都要解鎖、開App、點菜單、再點設(shè)備繁瑣程度太高。成熟的智能家居App一般會做兩個高頻入口通知欄常駐控制面板和桌面快捷開關(guān)Widget。通知欄常駐面板的實現(xiàn)方式有兩種第一種是使用Notification的自定義RemoteViews把常用設(shè)備的開關(guān)按鈕直接做到通知欄但RemoteViews支持的控件有限點擊事件需要通過PendingIntent廣播回傳實現(xiàn)起來有一定復(fù)雜度第二種是使用懸浮窗或者通知欄大布局BigContentViewStyle可以承載更多控件。我建議第一版先做桌面快捷開關(guān)成本低見效快。Android提供了AppWidget框架可以放一個4x1的桌面小組件顯示客廳燈、空調(diào)、窗簾等常用設(shè)備的開關(guān)狀態(tài)。點擊按鈕時發(fā)送廣播到App的WidgetProvider在onReceive里解析action攜帶的設(shè)備ID和指令走已有的指令下發(fā)通道。需要注意Android 12之后桌面組件引入了動態(tài)顏色適配如果你希望小組件看起來不那么突?？梢宰x取系統(tǒng)壁紙顏色來設(shè)置背景色。這個功能不用也行但做了會明顯提升整體觀感。5.3 多家協(xié)議混用的兼容層Zigbee、Wifi、藍牙的歸一化處理很多智能家居項目越做越復(fù)雜就是因為接的設(shè)備種類太多傳感節(jié)點是Zigbee的插座是WiFi的門鎖是藍牙的。如果App里每種協(xié)議都寫一套接口上層頁面就要跟著寫分叉邏輯維護成本成倍增長。更好的做法是設(shè)計一層設(shè)備抽象層把不同協(xié)議的設(shè)備統(tǒng)一成同一個接口public interface IDeviceController { void turnOn(String deviceId); void turnOff(String deviceId); void setBrightness(String deviceId, int value); void setTemperature(String deviceId, int value); void queryStatus(String deviceId); }然后分別實現(xiàn)WifiDeviceController、ZigbeeDeviceController通過網(wǎng)關(guān)轉(zhuǎn)發(fā)、BleDeviceController。上層業(yè)務(wù)只依賴IDeviceController接口完全不關(guān)心底下是什么協(xié)議。當用戶編輯場景時也不需要區(qū)分設(shè)備的連接方式統(tǒng)一按動作列表處理。這個抽象層的價值在你拿到別人的資料包時最能體現(xiàn)項目里如果已經(jīng)把不同硬件方案封裝好了你換硬件平臺時只需要實現(xiàn)新的Controller界面代碼一行都不用改如果項目里沒有這層抽象你會發(fā)現(xiàn)頁面里全是if (device.type wifi)之類的分支判斷那就要小心重構(gòu)成本了。5.4 性能優(yōu)化設(shè)備數(shù)量多時列表和內(nèi)存都別崩全屋智能的設(shè)備數(shù)量輕松就到幾十上百個RecyclerView如果不做優(yōu)化滾動時會明顯掉幀。幾個關(guān)鍵優(yōu)化點ViewHolder復(fù)用。RecyclerView本身已經(jīng)做了復(fù)用機制但前提是不要在onBindViewHolder里做耗時操作比如不要在這里解析JSON、不要在這里創(chuàng)建新對象。設(shè)備圖標的加載。如果圖標是網(wǎng)絡(luò)圖片務(wù)必使用圖片加載庫Glide或Coil并設(shè)置合理的緩存策略。每次設(shè)備狀態(tài)變化導致圖標變化時要注意別讓同一張圖片重復(fù)加載。狀態(tài)更新時使用DiffUtil。拿到新設(shè)備列表后通過DiffUtil計算差異只刷新變化的那幾項避免整個列表閃爍。避免內(nèi)存泄漏。在Activity銷毀時一定要解綁MQTT回調(diào)、藍牙連接、以及定時任務(wù)。我見過最多的線上崩潰就是Activity已經(jīng)關(guān)閉了MQTT的消息還在往里面塞直接空指針。5.5 發(fā)布上架與多機型適配的實操經(jīng)驗項目進入發(fā)布階段又有幾個細節(jié)容易被忽略。第一是簽名文件調(diào)試簽名的App無法更新到生產(chǎn)簽名版本所以第一個正式版發(fā)布的時候就一定要用正式簽名并且備份好keystore文件和密碼。每年都能聽到開發(fā)者把簽名文件丟了導致App無法更新只能換包的悲劇。第二是混淆配置。如果項目里用了MQTT庫或BLE庫混淆規(guī)則要特別小心。常見的做法是在proguard-rules.pro里追加-keep class org.eclipse.paho.client.mqttv3.** { *; } -keep class com.example.smarthome.model.** { *; }模型類和外部庫都需要keep住否則Gson解析時字段被混淆后對不上運行期就會崩。第三是targetSdkVersion的適配。如果上架到應(yīng)用市場新版本要求targetSdkVersion必須到指定版本目前主流在33以上。從舊版本升上來的時候有一個地方特別容易出問題Android 13及以上外接設(shè)備時BLUETOOTH_CONNECT權(quán)限需要單獨申請并且不能在Manifest里把這個權(quán)限的maxSdkVersion限制住否則會導致運行時權(quán)限申請異常。6. 基于這套資料還能擴展什么方向做到這里你已經(jīng)擁有一個能跑通、能控制設(shè)備、能同步狀態(tài)、能聯(lián)動場景的智能家居Android App了。再往后走可以在這個基礎(chǔ)上做幾個高價值的方向一是語音控制集成。接入國內(nèi)主流的語音助手SDK通過語音命令觸發(fā)場景或控制設(shè)備這是目前智能家居體驗升級最快的方式。二是多用戶與家庭共享。支持家庭成員邀請和權(quán)限管理比如僅可控制客廳設(shè)備或可管理所有設(shè)備這就需要引入賬號體系和權(quán)限模型。三是自動化規(guī)則的圖形化編輯器。讓用戶在App里通過拖拽的方式配置當溫度高于30度且人在家時關(guān)閉窗簾并打開空調(diào)這背后是一個定時任務(wù)加規(guī)則引擎的組合數(shù)據(jù)模型做得好交互體驗的護城河會很高。四是設(shè)備固件的OTA升級。在App里通知用戶設(shè)備有新固件下載固件包后通過BLE或局域網(wǎng)下發(fā)到設(shè)備端這個功能需要和設(shè)備端深度配合但很能體現(xiàn)產(chǎn)品的專業(yè)度。回到標題里那份全部資料詳細文檔優(yōu)秀項目.zip我想用的方式是先看文檔里的通信協(xié)議再看源碼里的通信層封裝接著梳業(yè)務(wù)層最后才是界面。沿著這條路徑走你把項目吃透之后哪怕?lián)Q一套硬件平臺、換一個云服務(wù)商也能快速把App改造成自己的方案。我這里分享的架構(gòu)思路、代碼骨架、避坑清單都是基于這類項目的真實實施場景整理的。做智能家居App最考驗人的不完全是寫得漂亮的前端頁面而是把各種協(xié)議、各類硬件、各種異常情況都穩(wěn)穩(wěn)接住的能力。希望這些經(jīng)驗?zāi)軒湍闵僮咭欢螐澛?。本文還有配套的精品資源點擊獲取