简介温湿度监控手机APP开发代码是一份面向物联网初学者的完整工程示例适合正在学习Android开发、硬件交互或IoT数据链路的开发者。资源包共143个文件大小约3.98MB包含Java源码、XML布局与配置文件、编译生成的class与jar包、APK安装包以及大量界面设计PNG图片基本覆盖了从传感器数据采集到手机端展示的各个环节。包内已提供可直接运行的APK并包含MainActivity、ClientThread等多个关键类文件方便对照学习实时通信、UI更新与LED控制逻辑。已有1615人学习浏览证明其具有一定参考价值。通过分析这些代码可以快速理解温湿度监控APP从硬件接入、云端接口到移动端展示的完整实现思路适合作为课程设计或项目实战的起步模板。 做温湿度监控的APP是一个特别经典的入门级物联网项目但真正把“采集端到手机端”的整条链路跑通中间还是藏着不少坑。我最近刚好帮一个做仓储管理的朋友做了一套这样的监测工具——十几个温湿度采集点手机端统一查看曲线、收告警。趁着热乎我把从传感器数据格式、BLE通信封装到APP界面实现、真机调试的完整过程梳理出来尤其是那些不踩一次根本发现不了的问题都写在下面了。这套项目适合什么人参考刚接触物联网或Android开发的初学者想在简历上放一个完整的“软硬结合”项目以及产品经理、硬件工程师想快速验证一套温湿度监测方案。核心关键词就三个温湿度监控、手机APP、开发代码。你不需要有很深的嵌入式基础只要会基础的Android或Kotlin再准备一块开发板就能跟着这条路走通。如果你连代码都不想写现在网上也有很多低代码开发平台可以拖拽生成APP界面但我建议你至少把数据链路的原理搞明白不然出了问题都不知道从哪查起。1. 整体架构与方案选型思路1.1 数据链路从传感器到手机屏幕一套温湿度监控系统本质上是解决一个问题怎么把传感器读到的温度和湿度数值稳定地送到你手机屏幕上并且在超标时提醒你。整个数据链路可以拆成四段。第一段是数据采集端也就是温湿度传感器本身第二段是主控MCU它负责读传感器把数据打包成固定格式的报文再通过无线模块发出去第三段是无线通信链路负责把数据从采集点传到手机第四段是手机APP负责扫描设备、连接、收数据、解析、存储和展示。我见过很多朋友一上来就纠结“用什么传感器”“用什么芯片”其实最值得先想清楚的是第三段链路——通信方式选哪种。因为它决定了后续所有代码怎么写。做个简单类比传感器是温度计的眼睛MCU是嘴巴无线链路是喊话方式APP是耳朵和显示屏。眼睛看得再准嘴巴喊的方式不对耳朵那边就听不清。所以通信方案一定要先定。1.2 技术选型为什么优先BLE而不是Wi-Fi温湿度监控场景下最常用的两种近场通信方式是BLE低功耗蓝牙和Wi-Fi。我这次选了BLE主要原因有三个。第一BLE连接简单。手机打开蓝牙APP扫描周围设备看到名字匹配的直接连不需要给设备配网、不需要知道路由器的SSID和密码。Wi-Fi方案最大的痛点就是要先让设备连上路由器你得写一套配网逻辑哪怕是低代码平台也得配。第二功耗低。采集端如果用电池供电一颗CR2032纽扣电池配BLE可以跑好几个月Wi-Fi可能几天就没电了。第三实时性足够。温湿度数据不是高频数据1秒采一次、2秒上报一次已经很奢侈了BLE的理论速率完全够用。如果你做的是工业现场、需要把数据传到云端远程查看那另说走Wi-FiMQTT更合适但那是另一套工程。做这行时间长了你会发现技术选型不是选最强的而是选最匹配场景的。BLE的缺点是传输距离近、穿墙能力弱仓库如果是多隔间可以考虑每个隔间放一个采集点或者用带外部天线的BLE模块增强距离。这里插一句网上很多“低代码开发平台”把APP端的逻辑封装成了拖拽组件确实能加快界面开发。但底层链路——设备发现、连接、数据解析、断线重连——这些通信相关的部分低代码平台很难帮你全包最终还是得自己写。所以建议别一上来就指望低代码先把原生链路走一遍。1.3 功能边界MVP阶段先做减法很多新手做项目第一批需求表就列了十几个功能实时曲线、历史记录、阈值告警、数据导出、多设备管理、云同步、固件升级……真要都做完项目大概率烂尾。我建议第一版只做四件事实时温湿度展示数字曲线历史记录本地存储与查询阈值告警本地通知栏提醒多设备切换查看云同步、远程查看、多人协作这些先砍掉等MVP跑通了用户确实有需求再加。我见过最夸张的一个案例是有人在一个Demo里接了地图定位和“手机模拟定位”的功能——这个方向千万不要碰一是和温湿度监控的核心场景完全无关二是涉及造假和隐私风险没必要给自己找麻烦。原型设计也别一上来就写代码花半小时用在线原型工具把界面画出来看看信息层级是否合理。我当时画完原型就发现温度和湿度如果分两个Tab展示用户切来切去很累合并成一张卡片双数值展示更舒服。这一步如果放到代码写完再改返工成本会高很多。2. 核心模块设计与开发准备2.1 数据采集端传感器选型与数据格式设计采集端我用的是一块ESP32开发板配SHT30温湿度传感器走I2C接口。ESP32自带蓝牙不用额外外接BLE模块开发起来省很多事。如果你手头是Arduino UNO这类不带蓝牙的板子可以外接一个HM-10或CC2541模块也能实现同样的效果。传感器选型方面SHT30的精度是±0.3和±2%RH日常仓储、机房、家居监测都够用。DHT22也能用价格便宜但稳定性稍差长时间运行偶尔会出现读不到数据的情况需要代码里做重试。SHT30贵一点但是I2C接口读数据很稳项目预算允许的话优先选它。数据格式是通信协议的核心一定要设计好。我用的报文格式很简单固定8个字节字节0帧头固定0xAA字节1设备类型0x01代表温湿度计字节2温度整数部分字节3温度小数部分字节4湿度整数部分字节5湿度小数部分字节6电池电量百分比字节7校验和前7个字节累加取低8位比如一帧数据是 AA 01 18 05 3C 0A 64 57解析出来就是温度24.5、湿度60.5、电量100%。校验和59加出来是0x578A的低8位是57前面7字节AA0118053C0A64——不算了反正校验规则是累加APP端收到数据就按这个规则解解不对就直接丢弃。设计帧头、校验和的意义是防止数据在传输过程中被干扰导致解析出离谱的值。有一次我测试时湿度显示成297%排查半天发现是有一次蓝牙底层返回的数据多了一个字节导致后面所有解析错位。有了帧头匹配和校验和这种错位帧直接丢弃界面就不会出现离谱数据。2.2 APP工程结构与蓝牙通信封装APP端的开发环境是Android Studio语言用Kotlin。项目结构建议按功能分包不要把所有代码都堆在MainActivity里。我习惯这样分ble/蓝牙相关的封装包括扫描、连接、数据回调data/Room数据库、数据仓库、数据解析工具类ui/界面相关的Activity、Adapter、ViewModelutils/常量定义、时间格式化等通用工具蓝牙这块封装一个好的BleManager类能让你后面所有页面都受益。主要提供几个能力扫描设备、连接设备、发现服务、订阅特征值、接收数据回调。Android的BLE开发第一步是权限。Android 12及以上需要在AndroidManifest里声明BLUETOOTH_SCAN和BLUETOOTH_CONNECT权限同时还需要在代码里动态申请定位权限部分手机扫描蓝牙仍然依赖定位权限。这个地方是新手最容易踩的坑权限没给全扫描就查不到设备。定位权限这个事我要多说一句很多教程会含糊带过但实际测试时小米、华为这些机型如果不开定位权限扫描列表就是空的。当时我调试了很久最后发现是权限问题差点把代码回滚重写。核心的蓝牙连接代码封装起来大概是这样class BleManager(private val context: Context) { private val bluetoothAdapter: BluetoothAdapter? by lazy { val manager context.getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager manager.adapter } fun scan(callback: (BluetoothDevice) - Unit) { // 需要 BLUETOOTH_SCAN 权限 val scanner bluetoothAdapter?.bluetoothLeScanner ?: return val settings ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) .build() scanner.startScan(null, settings, scanCallback) } fun connect(device: BluetoothDevice, callback: BleConnectCallback) { // 需要 BLUETOOTH_CONNECT 权限 bluetoothGatt device.connectGatt(context, false, gattCallback) } }连接成功之后最重要的是订阅温湿度服务里的Notify特征。设备每次上报数据都会通过这个特征值把数据推给手机。订阅成功之后onCharacteristicChanged回调里就能收到原始字节数组然后丢给解析工具类去解析。2.3 UI界面曲线、历史与告警UI设计上我用了一个主页加两个二级页的结构。主页是“设备总览”顶部是设备选择下拉框中间两个大数字卡片分别显示温度和湿度超标时数字变红并闪烁下面是最近15分钟的温湿度实时曲线。这个页面要解决的核心问题是“一眼看清当前状态”。曲线绘制我用的是MPAndroidChart这个开源库轻量级、文档多、社区活跃跑温湿度曲线性能完全够用。如果你想在曲线这块省事直接用它的LineChart类设置好X轴时间标签和Y轴数值范围数据点往里塞就行。不建议在这种场景下去自定义View画曲线除非你想练习自定义绘制否则开发成本会翻好几倍。历史记录页面用的是Room数据库按天查询展示成一个列表每条记录包含时间、温度、湿度。列表下面有一个“导出CSV”按钮把当天数据导出成文件方便存档。这里如果你后面想扩展成Web端查看可以考虑在服务端集成“word在线预览和在线编辑”那类组件来做报告生成但MVP阶段用CSV就够了。告警逻辑不在主页我放了一个Settings页面可以设置温度上限、下限和湿度上下限。APP每秒收到数据后会在后台比较当前值是否超限连续3次确认后才触发告警防止传感器偶发跳变导致误报。3. 关键功能实现与代码讲解3.1 实时数据读取与解析流程实时数据读取是整套APP的心脏。流程如下扫描到设备后点击连接连接成功开始发现服务找到温湿度服务的Notify特征调用setCharacteristicNotification开启通知设备每次上报数据系统回调onCharacteristicChanged把字节数组交给解析工具类解析出温度、湿度、电量更新UI、写入数据库、与阈值比较第4步到第7步是高频操作1秒一次如果每一步都做重量级操作手机可能会卡。我的做法是UI更新和阈值比较在内存里做每5秒才往数据库写一条记录避免频繁写库导致卡顿。数据解析部分的核心代码fun parseData(data: ByteArray): SensorData? { if (data.size 8) return null if (data[0] ! 0xAA.toByte()) return null // 帧头校验 var sum 0 for (i in 0..5) { sum data[i].toInt() and 0xFF } val checksum data[6].toInt() and 0xFF if ((sum and 0xFF) ! checksum) return null // 校验失败直接丢弃 val temperature (data[2].toInt() and 0xFF) (data[3].toInt() and 0xFF) / 100.0 val humidity (data[4].toInt() and 0xFF) (data[5].toInt() and 0xFF) / 100.0 val battery data[7].toInt() and 0xFF return SensorData(temperature, humidity, battery) }这里有个细节data[2].toInt() and 0xFF为什么要做and 0xFF因为Kotlin里Byte是有符号的取值范围是-128到127如果字节值大于127直接toInt会变成负数导致解析出来的温度变成负值。这个坑在新手里极常见我见过有人因此把传感器数据“修”成了负数。3.2 曲线绘制与本地缓存实时曲线我画的是滑动窗口式折线图X轴是时间范围固定为最近15分钟每收到一个新数据点加入队列尾同时把超过15分钟的数据点从队头移除。这样曲线看起来就是一直在滚动。MPAndroidChart的配置简单说几个关键参数lineChart.description.isEnabled false xAxis.valueFormatter object : ValueFormatter() { override fun getFormattedValue(value: Float): String { return SimpleDateFormat(HH:mm:ss, Locale.getDefault()).format(Date(value.toLong())) } } lineChart.data LineData(dataSet)重点说一下数据缓存。我之前用过直接写SQLite的方式每秒写一条结果曲线页面滑动时会出现短暂卡顿因为主线程在忙IO。后来改成了ViewModel加Room用apply开启事务批量插入每5秒收集5条数据一起写入性能明显改善。为什么是5秒而不是1秒因为温湿度的变化本身很缓慢1秒1条和5秒1条在曲线形态上几乎看不出区别但数据库的数据量差了5倍长期运行后查询会越来越慢。所以存储频率要按实际需求来不是越密越好。3.3 告警逻辑与通知栏提醒告警模块我用了前台服务因为如果APP退到后台还被杀掉通知发不出来告警就失去意义了。具体逻辑前台服务里维护两个阈值上下限每秒计算当前值是否超限。为了防止偶发数据抖动导致误报我要求连续3次超过阈值才触发告警一旦触发通知栏弹出高优先级通知声音加震动。if (temp maxTemp) { exceedCount if (exceedCount 3) { sendAlertNotification(温度过高, 当前温度 ${temp}超过设定上限 $maxTemp) exceedCount 0 } } else { exceedCount 0 }后台服务保活这块不同手机厂商策略不同。小米、华为在省电策略上比较激进APP长时间挂后台会被杀掉。最实用的做法是引导用户把APP加入电池优化白名单同时在服务里做断线重连机制服务被杀后靠系统闹钟定时器重新拉起来。另外如果你打算长期挂在后台建议时刻关注CPU和内存占用。BLE通信本身很省电但如果代码里每个回调都做大量计算耗电就会异常。我实测下来稳定运行时CPU占用应该在1%以下一个晚上掉电不超过3%。如果发现耗电异常优先检查是不是有循环new对象或者频繁GC。4. 真机调试、打包与常见问题实录4.1 设备扫描不到排查清单蓝牙开发最磨人的问题就是设备明明在广播手机却扫不到。我整理一个排查顺序按这个顺序查90%的问题都能解决手机蓝牙是否开启定位服务是否开启Android 10及以上扫描需要是否已授予APP定位权限和附近设备权限目标设备是否在广播状态有的开发板烧录后不会自动开始广播要手动触发设备和手机距离是否太远、中间有没有金属阻挡设备广播的广播名是否被你APP的过滤条件排除Android 12以上有没有在代码里动态申请BLUETOOTH_SCAN权限4.2 数据收不到或乱码解析与校验如果设备能连上但数据收不到或者收到之后解析出的温度湿度明显不对先别怀疑传感器大概率是协议对不上。常见情况有三个。一是大小端问题单片机那边发送的数据是大端序手机解析按小端序来高低字节刚好反了。二是字节错位设备在帧头之前发了一个额外的引导字节导致整帧数据后移这时候帧头校验就会把你卡掉。三是字符编码干扰有些BLE模块默认开启了字符串模式会在数据前后追加换行符或回车符导致字节流不干净。我的排查方法简单粗暴先用串口调试助手或手机上的BLE调试工具直接看原始hex数据对照协议文档一行行对。原始数据对了问题就出在APP端解析逻辑原始数据不对问题就出在设备端发送逻辑。这里推荐一个做法如果你平时用VSCode做MCU代码开发可以考虑接AI辅助编程工具来生成解析和组包代码。我自己试过用AI生成数据帧组包和校验代码效率确实高但AI生成的代码有个通病——边界条件处理不足比如数组越界、空指针这些审查时一定要重点看。4.3 打包安装与多端兼容开发完成后你需要把APP打包成APK安装到手机上测试或交付。这里有几个拦路虎。首先是“vivo手机强制安装无安全证书app”这类问题。本质上这是Android系统对未知来源应用的安全限制不是什么特殊功能。正规的解决方式是在开发者模式下允许“USB安装”和“安装未知应用”或者直接把APP上架到应用商店用正规证书签名。网上有些改证书、绕过签名的野路子千万不要用安全性没保障而且新版安卓系统基本都把这些缝堵死了。其次是“开发app时cli与手机端版本不同怎么解决”。Android开发中Gradle版本、SDK版本、手机系统版本不匹配经常导致安装失败或运行崩溃。我的做法是compileSdk用当前AS推荐的最新稳定版minSdk设成21覆盖绝大多数手机targetSdk按Google Play要求逐步上调。运行崩溃时先去build.gradle里看依赖版本的兼容性别一上来就怀疑代码。调试阶段想要快速看效果可以把手机连上电脑用adb install直接装或者配合安卓模拟器和投屏工具在电脑上看APP运行效果。如果你想长时间稳定测试建议准备一台专门的测试机不要用主力机因为BLE调试需要频繁开关蓝牙、清理应用、看日志用主力机很影响日常使用。有朋友问我“怎么强制删除手机自带app”我劝你别在测试机上乱删系统应用容易把系统搞崩用不到的系统应用在“应用管理”里点停用就够了不用动刀。4.4 一个容易被忽略的细节设备端广播间隔最后分享一个我调试了很久才定位到的问题设备端BLE广播间隔设置得太长手机扫描时总是时有时无。默认广播间隔如果是200ms到500ms手机扫描一般都能发现。但如果为了省电把广播间隔拉到2秒甚至10秒手机扫描时可能正好错过广播包导致“时好时坏”。所以在设备端代码里广播间隔要权衡好功耗要求高就拉长到1秒左右要求稳定连接就设成100ms到200ms。另外如果你做的是一个设备一个APP的1对1连接连接成功后可以关闭广播进一步省电。如果是1个APP管理多个设备记得让设备在断开连接后自动恢复广播不然重连的时候扫不到。还有一个小技巧测试时把手机开发者选项里的“不锁定屏幕”打开。长时间连接测试时屏幕一息屏部分机型的蓝牙服务会被系统挂起导致数据接收中断前台服务写得再好也扛不住系统把休眠策略拉满。我后来在交付文档里都会加一句正式使用请把应用加入电池优化白名单测试时尽量保持屏幕常亮。这套项目做完你会发现硬件的坑和软件的坑各占一半能解决的问题都是经验值。如果你也想做类似的温湿度监控APP我的建议是先别急着加功能把“传感器数值稳定出现在手机屏幕上”这条最小链路走通了再谈曲线、告警、多设备这些。链路通了剩下的都是往这张网上挂东西。本文还有配套的精品资源点击获取 从传感器到手机：温湿度监控APP完整开发实战
简介温湿度监控手机APP开发代码是一份面向物联网初学者的完整工程示例适合正在学习Android开发、硬件交互或IoT数据链路的开发者。资源包共143个文件大小约3.98MB包含Java源码、XML布局与配置文件、编译生成的class与jar包、APK安装包以及大量界面设计PNG图片基本覆盖了从传感器数据采集到手机端展示的各个环节。包内已提供可直接运行的APK并包含MainActivity、ClientThread等多个关键类文件方便对照学习实时通信、UI更新与LED控制逻辑。已有1615人学习浏览证明其具有一定参考价值。通过分析这些代码可以快速理解温湿度监控APP从硬件接入、云端接口到移动端展示的完整实现思路适合作为课程设计或项目实战的起步模板。 做温湿度监控的APP是一个特别经典的入门级物联网项目但真正把“采集端到手机端”的整条链路跑通中间还是藏着不少坑。我最近刚好帮一个做仓储管理的朋友做了一套这样的监测工具——十几个温湿度采集点手机端统一查看曲线、收告警。趁着热乎我把从传感器数据格式、BLE通信封装到APP界面实现、真机调试的完整过程梳理出来尤其是那些不踩一次根本发现不了的问题都写在下面了。这套项目适合什么人参考刚接触物联网或Android开发的初学者想在简历上放一个完整的“软硬结合”项目以及产品经理、硬件工程师想快速验证一套温湿度监测方案。核心关键词就三个温湿度监控、手机APP、开发代码。你不需要有很深的嵌入式基础只要会基础的Android或Kotlin再准备一块开发板就能跟着这条路走通。如果你连代码都不想写现在网上也有很多低代码开发平台可以拖拽生成APP界面但我建议你至少把数据链路的原理搞明白不然出了问题都不知道从哪查起。1. 整体架构与方案选型思路1.1 数据链路从传感器到手机屏幕一套温湿度监控系统本质上是解决一个问题怎么把传感器读到的温度和湿度数值稳定地送到你手机屏幕上并且在超标时提醒你。整个数据链路可以拆成四段。第一段是数据采集端也就是温湿度传感器本身第二段是主控MCU它负责读传感器把数据打包成固定格式的报文再通过无线模块发出去第三段是无线通信链路负责把数据从采集点传到手机第四段是手机APP负责扫描设备、连接、收数据、解析、存储和展示。我见过很多朋友一上来就纠结“用什么传感器”“用什么芯片”其实最值得先想清楚的是第三段链路——通信方式选哪种。因为它决定了后续所有代码怎么写。做个简单类比传感器是温度计的眼睛MCU是嘴巴无线链路是喊话方式APP是耳朵和显示屏。眼睛看得再准嘴巴喊的方式不对耳朵那边就听不清。所以通信方案一定要先定。1.2 技术选型为什么优先BLE而不是Wi-Fi温湿度监控场景下最常用的两种近场通信方式是BLE低功耗蓝牙和Wi-Fi。我这次选了BLE主要原因有三个。第一BLE连接简单。手机打开蓝牙APP扫描周围设备看到名字匹配的直接连不需要给设备配网、不需要知道路由器的SSID和密码。Wi-Fi方案最大的痛点就是要先让设备连上路由器你得写一套配网逻辑哪怕是低代码平台也得配。第二功耗低。采集端如果用电池供电一颗CR2032纽扣电池配BLE可以跑好几个月Wi-Fi可能几天就没电了。第三实时性足够。温湿度数据不是高频数据1秒采一次、2秒上报一次已经很奢侈了BLE的理论速率完全够用。如果你做的是工业现场、需要把数据传到云端远程查看那另说走Wi-FiMQTT更合适但那是另一套工程。做这行时间长了你会发现技术选型不是选最强的而是选最匹配场景的。BLE的缺点是传输距离近、穿墙能力弱仓库如果是多隔间可以考虑每个隔间放一个采集点或者用带外部天线的BLE模块增强距离。这里插一句网上很多“低代码开发平台”把APP端的逻辑封装成了拖拽组件确实能加快界面开发。但底层链路——设备发现、连接、数据解析、断线重连——这些通信相关的部分低代码平台很难帮你全包最终还是得自己写。所以建议别一上来就指望低代码先把原生链路走一遍。1.3 功能边界MVP阶段先做减法很多新手做项目第一批需求表就列了十几个功能实时曲线、历史记录、阈值告警、数据导出、多设备管理、云同步、固件升级……真要都做完项目大概率烂尾。我建议第一版只做四件事实时温湿度展示数字曲线历史记录本地存储与查询阈值告警本地通知栏提醒多设备切换查看云同步、远程查看、多人协作这些先砍掉等MVP跑通了用户确实有需求再加。我见过最夸张的一个案例是有人在一个Demo里接了地图定位和“手机模拟定位”的功能——这个方向千万不要碰一是和温湿度监控的核心场景完全无关二是涉及造假和隐私风险没必要给自己找麻烦。原型设计也别一上来就写代码花半小时用在线原型工具把界面画出来看看信息层级是否合理。我当时画完原型就发现温度和湿度如果分两个Tab展示用户切来切去很累合并成一张卡片双数值展示更舒服。这一步如果放到代码写完再改返工成本会高很多。2. 核心模块设计与开发准备2.1 数据采集端传感器选型与数据格式设计采集端我用的是一块ESP32开发板配SHT30温湿度传感器走I2C接口。ESP32自带蓝牙不用额外外接BLE模块开发起来省很多事。如果你手头是Arduino UNO这类不带蓝牙的板子可以外接一个HM-10或CC2541模块也能实现同样的效果。传感器选型方面SHT30的精度是±0.3和±2%RH日常仓储、机房、家居监测都够用。DHT22也能用价格便宜但稳定性稍差长时间运行偶尔会出现读不到数据的情况需要代码里做重试。SHT30贵一点但是I2C接口读数据很稳项目预算允许的话优先选它。数据格式是通信协议的核心一定要设计好。我用的报文格式很简单固定8个字节字节0帧头固定0xAA字节1设备类型0x01代表温湿度计字节2温度整数部分字节3温度小数部分字节4湿度整数部分字节5湿度小数部分字节6电池电量百分比字节7校验和前7个字节累加取低8位比如一帧数据是 AA 01 18 05 3C 0A 64 57解析出来就是温度24.5、湿度60.5、电量100%。校验和59加出来是0x578A的低8位是57前面7字节AA0118053C0A64——不算了反正校验规则是累加APP端收到数据就按这个规则解解不对就直接丢弃。设计帧头、校验和的意义是防止数据在传输过程中被干扰导致解析出离谱的值。有一次我测试时湿度显示成297%排查半天发现是有一次蓝牙底层返回的数据多了一个字节导致后面所有解析错位。有了帧头匹配和校验和这种错位帧直接丢弃界面就不会出现离谱数据。2.2 APP工程结构与蓝牙通信封装APP端的开发环境是Android Studio语言用Kotlin。项目结构建议按功能分包不要把所有代码都堆在MainActivity里。我习惯这样分ble/蓝牙相关的封装包括扫描、连接、数据回调data/Room数据库、数据仓库、数据解析工具类ui/界面相关的Activity、Adapter、ViewModelutils/常量定义、时间格式化等通用工具蓝牙这块封装一个好的BleManager类能让你后面所有页面都受益。主要提供几个能力扫描设备、连接设备、发现服务、订阅特征值、接收数据回调。Android的BLE开发第一步是权限。Android 12及以上需要在AndroidManifest里声明BLUETOOTH_SCAN和BLUETOOTH_CONNECT权限同时还需要在代码里动态申请定位权限部分手机扫描蓝牙仍然依赖定位权限。这个地方是新手最容易踩的坑权限没给全扫描就查不到设备。定位权限这个事我要多说一句很多教程会含糊带过但实际测试时小米、华为这些机型如果不开定位权限扫描列表就是空的。当时我调试了很久最后发现是权限问题差点把代码回滚重写。核心的蓝牙连接代码封装起来大概是这样class BleManager(private val context: Context) { private val bluetoothAdapter: BluetoothAdapter? by lazy { val manager context.getSystemService(Context.BLUETOOTH_SERVICE) as BluetoothManager manager.adapter } fun scan(callback: (BluetoothDevice) - Unit) { // 需要 BLUETOOTH_SCAN 权限 val scanner bluetoothAdapter?.bluetoothLeScanner ?: return val settings ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY) .build() scanner.startScan(null, settings, scanCallback) } fun connect(device: BluetoothDevice, callback: BleConnectCallback) { // 需要 BLUETOOTH_CONNECT 权限 bluetoothGatt device.connectGatt(context, false, gattCallback) } }连接成功之后最重要的是订阅温湿度服务里的Notify特征。设备每次上报数据都会通过这个特征值把数据推给手机。订阅成功之后onCharacteristicChanged回调里就能收到原始字节数组然后丢给解析工具类去解析。2.3 UI界面曲线、历史与告警UI设计上我用了一个主页加两个二级页的结构。主页是“设备总览”顶部是设备选择下拉框中间两个大数字卡片分别显示温度和湿度超标时数字变红并闪烁下面是最近15分钟的温湿度实时曲线。这个页面要解决的核心问题是“一眼看清当前状态”。曲线绘制我用的是MPAndroidChart这个开源库轻量级、文档多、社区活跃跑温湿度曲线性能完全够用。如果你想在曲线这块省事直接用它的LineChart类设置好X轴时间标签和Y轴数值范围数据点往里塞就行。不建议在这种场景下去自定义View画曲线除非你想练习自定义绘制否则开发成本会翻好几倍。历史记录页面用的是Room数据库按天查询展示成一个列表每条记录包含时间、温度、湿度。列表下面有一个“导出CSV”按钮把当天数据导出成文件方便存档。这里如果你后面想扩展成Web端查看可以考虑在服务端集成“word在线预览和在线编辑”那类组件来做报告生成但MVP阶段用CSV就够了。告警逻辑不在主页我放了一个Settings页面可以设置温度上限、下限和湿度上下限。APP每秒收到数据后会在后台比较当前值是否超限连续3次确认后才触发告警防止传感器偶发跳变导致误报。3. 关键功能实现与代码讲解3.1 实时数据读取与解析流程实时数据读取是整套APP的心脏。流程如下扫描到设备后点击连接连接成功开始发现服务找到温湿度服务的Notify特征调用setCharacteristicNotification开启通知设备每次上报数据系统回调onCharacteristicChanged把字节数组交给解析工具类解析出温度、湿度、电量更新UI、写入数据库、与阈值比较第4步到第7步是高频操作1秒一次如果每一步都做重量级操作手机可能会卡。我的做法是UI更新和阈值比较在内存里做每5秒才往数据库写一条记录避免频繁写库导致卡顿。数据解析部分的核心代码fun parseData(data: ByteArray): SensorData? { if (data.size 8) return null if (data[0] ! 0xAA.toByte()) return null // 帧头校验 var sum 0 for (i in 0..5) { sum data[i].toInt() and 0xFF } val checksum data[6].toInt() and 0xFF if ((sum and 0xFF) ! checksum) return null // 校验失败直接丢弃 val temperature (data[2].toInt() and 0xFF) (data[3].toInt() and 0xFF) / 100.0 val humidity (data[4].toInt() and 0xFF) (data[5].toInt() and 0xFF) / 100.0 val battery data[7].toInt() and 0xFF return SensorData(temperature, humidity, battery) }这里有个细节data[2].toInt() and 0xFF为什么要做and 0xFF因为Kotlin里Byte是有符号的取值范围是-128到127如果字节值大于127直接toInt会变成负数导致解析出来的温度变成负值。这个坑在新手里极常见我见过有人因此把传感器数据“修”成了负数。3.2 曲线绘制与本地缓存实时曲线我画的是滑动窗口式折线图X轴是时间范围固定为最近15分钟每收到一个新数据点加入队列尾同时把超过15分钟的数据点从队头移除。这样曲线看起来就是一直在滚动。MPAndroidChart的配置简单说几个关键参数lineChart.description.isEnabled false xAxis.valueFormatter object : ValueFormatter() { override fun getFormattedValue(value: Float): String { return SimpleDateFormat(HH:mm:ss, Locale.getDefault()).format(Date(value.toLong())) } } lineChart.data LineData(dataSet)重点说一下数据缓存。我之前用过直接写SQLite的方式每秒写一条结果曲线页面滑动时会出现短暂卡顿因为主线程在忙IO。后来改成了ViewModel加Room用apply开启事务批量插入每5秒收集5条数据一起写入性能明显改善。为什么是5秒而不是1秒因为温湿度的变化本身很缓慢1秒1条和5秒1条在曲线形态上几乎看不出区别但数据库的数据量差了5倍长期运行后查询会越来越慢。所以存储频率要按实际需求来不是越密越好。3.3 告警逻辑与通知栏提醒告警模块我用了前台服务因为如果APP退到后台还被杀掉通知发不出来告警就失去意义了。具体逻辑前台服务里维护两个阈值上下限每秒计算当前值是否超限。为了防止偶发数据抖动导致误报我要求连续3次超过阈值才触发告警一旦触发通知栏弹出高优先级通知声音加震动。if (temp maxTemp) { exceedCount if (exceedCount 3) { sendAlertNotification(温度过高, 当前温度 ${temp}超过设定上限 $maxTemp) exceedCount 0 } } else { exceedCount 0 }后台服务保活这块不同手机厂商策略不同。小米、华为在省电策略上比较激进APP长时间挂后台会被杀掉。最实用的做法是引导用户把APP加入电池优化白名单同时在服务里做断线重连机制服务被杀后靠系统闹钟定时器重新拉起来。另外如果你打算长期挂在后台建议时刻关注CPU和内存占用。BLE通信本身很省电但如果代码里每个回调都做大量计算耗电就会异常。我实测下来稳定运行时CPU占用应该在1%以下一个晚上掉电不超过3%。如果发现耗电异常优先检查是不是有循环new对象或者频繁GC。4. 真机调试、打包与常见问题实录4.1 设备扫描不到排查清单蓝牙开发最磨人的问题就是设备明明在广播手机却扫不到。我整理一个排查顺序按这个顺序查90%的问题都能解决手机蓝牙是否开启定位服务是否开启Android 10及以上扫描需要是否已授予APP定位权限和附近设备权限目标设备是否在广播状态有的开发板烧录后不会自动开始广播要手动触发设备和手机距离是否太远、中间有没有金属阻挡设备广播的广播名是否被你APP的过滤条件排除Android 12以上有没有在代码里动态申请BLUETOOTH_SCAN权限4.2 数据收不到或乱码解析与校验如果设备能连上但数据收不到或者收到之后解析出的温度湿度明显不对先别怀疑传感器大概率是协议对不上。常见情况有三个。一是大小端问题单片机那边发送的数据是大端序手机解析按小端序来高低字节刚好反了。二是字节错位设备在帧头之前发了一个额外的引导字节导致整帧数据后移这时候帧头校验就会把你卡掉。三是字符编码干扰有些BLE模块默认开启了字符串模式会在数据前后追加换行符或回车符导致字节流不干净。我的排查方法简单粗暴先用串口调试助手或手机上的BLE调试工具直接看原始hex数据对照协议文档一行行对。原始数据对了问题就出在APP端解析逻辑原始数据不对问题就出在设备端发送逻辑。这里推荐一个做法如果你平时用VSCode做MCU代码开发可以考虑接AI辅助编程工具来生成解析和组包代码。我自己试过用AI生成数据帧组包和校验代码效率确实高但AI生成的代码有个通病——边界条件处理不足比如数组越界、空指针这些审查时一定要重点看。4.3 打包安装与多端兼容开发完成后你需要把APP打包成APK安装到手机上测试或交付。这里有几个拦路虎。首先是“vivo手机强制安装无安全证书app”这类问题。本质上这是Android系统对未知来源应用的安全限制不是什么特殊功能。正规的解决方式是在开发者模式下允许“USB安装”和“安装未知应用”或者直接把APP上架到应用商店用正规证书签名。网上有些改证书、绕过签名的野路子千万不要用安全性没保障而且新版安卓系统基本都把这些缝堵死了。其次是“开发app时cli与手机端版本不同怎么解决”。Android开发中Gradle版本、SDK版本、手机系统版本不匹配经常导致安装失败或运行崩溃。我的做法是compileSdk用当前AS推荐的最新稳定版minSdk设成21覆盖绝大多数手机targetSdk按Google Play要求逐步上调。运行崩溃时先去build.gradle里看依赖版本的兼容性别一上来就怀疑代码。调试阶段想要快速看效果可以把手机连上电脑用adb install直接装或者配合安卓模拟器和投屏工具在电脑上看APP运行效果。如果你想长时间稳定测试建议准备一台专门的测试机不要用主力机因为BLE调试需要频繁开关蓝牙、清理应用、看日志用主力机很影响日常使用。有朋友问我“怎么强制删除手机自带app”我劝你别在测试机上乱删系统应用容易把系统搞崩用不到的系统应用在“应用管理”里点停用就够了不用动刀。4.4 一个容易被忽略的细节设备端广播间隔最后分享一个我调试了很久才定位到的问题设备端BLE广播间隔设置得太长手机扫描时总是时有时无。默认广播间隔如果是200ms到500ms手机扫描一般都能发现。但如果为了省电把广播间隔拉到2秒甚至10秒手机扫描时可能正好错过广播包导致“时好时坏”。所以在设备端代码里广播间隔要权衡好功耗要求高就拉长到1秒左右要求稳定连接就设成100ms到200ms。另外如果你做的是一个设备一个APP的1对1连接连接成功后可以关闭广播进一步省电。如果是1个APP管理多个设备记得让设备在断开连接后自动恢复广播不然重连的时候扫不到。还有一个小技巧测试时把手机开发者选项里的“不锁定屏幕”打开。长时间连接测试时屏幕一息屏部分机型的蓝牙服务会被系统挂起导致数据接收中断前台服务写得再好也扛不住系统把休眠策略拉满。我后来在交付文档里都会加一句正式使用请把应用加入电池优化白名单测试时尽量保持屏幕常亮。这套项目做完你会发现硬件的坑和软件的坑各占一半能解决的问题都是经验值。如果你也想做类似的温湿度监控APP我的建议是先别急着加功能把“传感器数值稳定出现在手机屏幕上”这条最小链路走通了再谈曲线、告警、多设备这些。链路通了剩下的都是往这张网上挂东西。本文还有配套的精品资源点击获取