如何基于 Android Things 构建一个智能家居系统？

前言

2012 年 6 月，由 IoT-GSI（Global Standards Initiative on Internet of Things）发布的白皮书“ITU-T Y.4000/Y.2060”[1]中明确定义了物联 的概念。从技术标准化的角度来讲，物联 可以看作是信息 会中，基于现有或将来产生的信息通讯技术，对物体进行互联（物理或虚拟）的全球基础设施。

物联 融合了现有和将有的信息通信技术、数据处理技术，这些技术包括但不限于机器到机器的通信、自主 络、数据的挖掘和决策、安全和隐私保护、云计算以及先进的传感和驱动技术。而当前现有的物联 相关技术的研发，要么基于平台，要么基于设备。一般来说，硬件厂商会着力于传感器，还有物联 节点的开发，或是支持一些常见的通信协议；系统及软件开发厂商，会基于操作系统、云端做一些相应的技术开发。

解析 Android Things 技术原理

Android Things 主要运用于物联 及嵌入式设备，可以说是 Android 平台的扩展，它和手机（Android Mobile）、电视（Android TV）、汽车（Android Auto）、穿戴式设备（Android Wear）一起组成了 Android 大家庭。

比起其他 Android 系统，它又有一些与众不同的特点，譬如物联 设备会带来一些软件资源的限制。但相对于移动端 Android 开发，Android Things 没有较为复杂的 UI 布局，开发周期能大大缩短。

同时，Android Things 为安全连接到云端的设备提供了强大的技术支持，比如我们需要搜集大量的传感器数据到云端，通过 Android Things 可以很方便地进行采集并将其发送至云端。由于 Android Things 可以借助云端处理音视频、图片、传感器数据等信息，我们可以用这个系统来做出库存控制、互动广告、自动售货机、智能电表等产品。

另一方面，Android Things 本身就属于 Android 生态系统，所以我们在所熟悉的 Android 开发环境中可以直接进行开发。其完全支持 Android SDK/NDK，以及 Android 中的第三方库，并完美集成了诸如 Google Play Services、Firebase、Google Cloud Platform 等的 Google Services。

其中，Firebase 和 Google Cloud Platform（简称 GCP）就是为云端服务而准备的。GCP 拥有如 Identity&Security、Machine Learning 等八大类功能，完全涵盖了数据的存储与分析的所有环节。但这些数据处理是异步的，为了完善同步的数据服务，便有了 Firebase 来做实时的 络数据库。而物联 的数据，很大程度上依赖于云才能将数据的性能发挥至最大化。目前，Android Things 官方相关的 Demo 已经完成了云端的基本连接，但功能才刚刚开始。

另外，如果需要对数据的处理做进一步扩展，还有 TensorFlow 做后援。

现在，我们拥有了数据相关的平台，完成了数据相关的各种处理，就完全解决了数据的存储及处理问题。接下来，便要解决数据的获取，以及数据传输的问题了。

数据传输

提到物联 的数据传输协议，我们都数不过来，各大门派，各大路数，全汇集在一起。

• 有线协议：包括各种串行、并行通信协议，以及强大的有线 络；
• 无线协议：从低频到高频，数不胜数，2G 至 4G 的 络协议、蓝牙、红外、ZigBee 等等，以及现在的业界新宠 NB-IoT 和 LoRa。

有这么多的协议传输，就会依赖各自的硬件。各种数据协议组成了战国时代，没有胜负，只有哪些协议适合哪些场景。

而现在我们对协议的要求通常是，延时最短（即反应最快）、稳定性好、安全性高，且功耗要特别小。理想状况当然是想要马儿快点跑，又要马儿不吃草。但现实只能努力接近理想，我们总会在协议的各种性能上有失有得。特别是现在 2.4G 频段处于拥堵的状态，所以从低频到高频，增加了许多频段的选择。

对于物联 的操作系统来说，一个关键的考量，便是其数据传输方式要灵活、适配性强、便于开发。现在有两条路可走，要么是做个统一的协议，去包揽其他的所有协议；要么是提供一个更通用、更灵活的方法，让用户去适配协议。对于前者，Google 推出了 Weave 协议用以统一蓝牙、ZigBee 等，它独立于物联 操作系统，致力于解决各种数据传输协议的统一性问题（ 上有相关文章，读者可自行阅览）。而另一种让用户去适配的办法，就是 Android Things 关于数据传输协议的处理。

对于数据传输，USB、蓝牙、Wi-Fi 可以说是最常用的方法，但还有许多模块以及专用的数据传输是不匹配的。对于这一类数据传输，该如何搞定呢ndroid Things 提供了一个万能的通道，支持 I2C、SPI 和 UART 的数据传输。可别小瞧这三种数据传输方式，从通用角度来说，这三种串行接口，可以直接外接各种传感设备。同时，又能外接各种数据传输协议的模块，极大地加快了产品原型设计。这三种接口，既可用来捕获数据，又可以用来支持数据传输，可谓一举两得。

上手 Android Things

经过上面的分析，我们才发现，Android Things 只是代表物联 中的一个环节，它并不是物联 的全部。Android Things 对于云端和传感器，起着至关重要的连接作用，并且规定了数据的采集及传输的规则。

接下来，我们就以在树莓派 3 上运行 Android Things 为例，来具体看看 Android Things 的 ROM 相关信息。

从官 上下载下来 Android Things 在树莓派 3 上的镜像之后，我们可以看到，SD 卡被划分多达 16 个分区，这些分区里，有一部分是树莓派的文件信息，有一部分是 Android Things 中的相关分区。

我们用 mount 命令查看开发板的分区，发现总共挂载了 5 个分区，其中 gapps、 _type、oem、data 主要是 Android Things 使用 PRIBOOT 用于树莓派 3 启动时的一些运行和配置文件的分区。

用 ADB Shell 命令进入终端之后，我们可以看到，整个根文件系统与 Android 的根文件系统没有太大的区别。如果想知道系统运行时，启用了哪些服务，一般先会去看/etc 文件夹下的内容。通过了解/etc 下面的文件，我们可以看到，Android Things 对于音视频、蓝牙、Wi-Fi、蜂窝 络等都有支持。另外一部分，便是安全以及升级的管理了，包括事件日志、崩溃日志等。值得一提的是，与音频相关的配置文件/etc/audio_policy.conf 是支持 USB 声卡的输入输出的。关于 ROM 的文件构成，可以用此方法查看，如果熟悉 Android 的 ROM，会更省事地把 Android Things 的功能厘清。

Android Things 是完全支持 Android 调试工具的，而 Android Studio 也是开发 Android Things 应用最好的工具。需要注意的一点是，Android Things 只支持单应用，所以在调试时，要保证系统中只有一个应用在运行。这时可以用 ADB Uninstall 命令卸载掉原来留存的安装包，然后再加载新的应用。

搭建物联 解决方案

当我们了解了 Android Things 本身，以及与之相关的技术后，搭建一个物联 系统的技术路线，也变得十分明确了。这回我们挑一个复杂的系统去构建，比如提出这样一个需求——上班一族的智能家居。
基本的功能如下：

• 门口有一个摄像头，用于捕捉是否有可疑人出入，进行动态识别；
• 出门后，自动关闭微波炉等家用电器的电源；
• 如果室温低于 5℃，远程设定打开热风；温度高于 26℃，远程设定打开冷风；
• 如果室内有烟雾，发出 警；
• 晚上睡觉时，关闭所有的灯光，夜间起身上卫生间时，点亮卫生间的灯。

首先，根据产品需求进行分析，需要的硬件如下：

• 摄像头，用于图像捕捉及图像识别；
• 红外感应器，检测房间是否有人，如果人离开，检测大门是否关好；
• 温度感应器，需要 2-3 个，放在不同位置，从而综合出室内的温度；
• 智能空调，可以远程设置冷风、热风及开机时间；
• 烟雾探测器；
• 触摸板，一个用于卫生间的灯，一个用于关闭所有灯；
• 智能锁，检测大门是否关闭；
• 树莓派 3，用作控制中心，与云端连接，保存一些数据，以及日常生活行为的优化。

软件需求：

• Google Cloud，云端的数据存储及优化；
• Firebase，实时数据的保存；
• Android Things 及其应用，物联 系统的组建，以及各模块的自组 ；
• 手机客户端，完成一些状态及控制操作。

络形态组成，对于树莓派 3 到云端的数据传输，可以用家用 络直接传输数据。但对于各个节点，一般来说，用 ZigBee、蓝牙 Mesh 或 Wi-Fi 模块。其中控制中心完成数据的搜集及转发工作，根据物联 络的不同，所选的硬件，最好带 络模块，有自组 设备。系统的整体框架如图 1 所示。