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