解析 Android Things 技术原理

　　2012 年 6 月，由 IoT-GSI（Global Standards Initiative on Internet of Things）发布的白皮书“ITU-T Y.4000/Y.2060”[1]中明确定义了物联网的概念。从技术标准化的角度来讲，物联网可以看作是信息社会中，基于现有或将来产生的信息通讯技术，对物体进行互联（物理或虚拟）的全球基础设施。
　　
　　物联网融合了现有和将有的信息通信技术、数据处理技术，这些技术包括但不限于机器到机器的通信、自主网络、数据的挖掘和决策、安全和隐私保护、云计算以及先进的传感和驱动技术。而当前现有的物联网相关技术的研发，要么基于平台，要么基于设备。一般来说，硬件厂商会着力于传感器，还有物联网节点的开发，或是支持一些常见的通信协议；系统及软件开发厂商，会基于操作系统、云端做一些相应的技术开发。
　　
　　而在此之中，Google 对于物联网相关技术的研发包括了云端、数据通信模型建立、数据搜集及处理的相关技术，基本完成了除硬件设计外的各个技术环节。因此，本文将从 Android Things 入手，具体来看如何构建一个完整的智能家居系统。
　　
　　解析 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 可以说是最常用的方法，但还有许多模块以及专用的数据传输是不匹配的。对于这一类数据传输，该如何搞定呢？Android 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 所示。
　　
　　图 1 系统框架
　　
　　智能家居中，家用网关连接 Google Cloud，同时 Android Things 成为智能家居的控制中心，并通过室内局域网连接所有的智能电器。在室内的局域网中，两个触摸板可以用来控制智能灯泡。其它的电器传送状态至服务器，然后服务器下发控制命令给电器，手机客户端可以查看室内的各个电器的状态。
　　
　　关键技术及解决
　　
　　网络组建：树莓派有线网和 Wi-Fi 接口，其中有线接口连接外部网络，Wi-Fi 完成室内网络组建。如果不考虑功耗，在当前的室内网络布局下，Wi-Fi 的连接还是最简单的。那么 Android Things 上的应用，在网络管理这一个模块，应具有自组网、网络状态查询与管理、不同节点之间的数据包的发送与接收，以及简单的数据处理功能。
　　
　　人像识别：主要识别门外是否有陌生人出没，可以由摄像头每隔一段时间拍摄照片，然后利用 TensorFlow 识别人像，把照片保存并记录在云端。利用 Google Cloud 的云端存储技术，通过人像记录时间、次数等信息，判断这个人是否可疑并记录。
　　
　　人是否在房检测：利用红外感应，检测房间是否有人，如果不在房间，且摄像头检测人确实离开，则检测门是否完全关闭。如果没有关闭，控制智能锁自动关门。用红外传感器，去检测人是否在家。一般来说，有人是短时间出门，不需要关一些电器，所以关电器的时间很重要。一般来说，个人居家，会有定时的出门习惯，所以 Android Things 对于这一部分代码的处理，可以利用机器学习，从而分析出适合个体的开关门时间，再结合传感器数据做处理。
　　
　　人离开房间，关闭电器，利用智能插座关闭电器。
　　
　　空调自动打开，场景用于人回家前 30 分钟。如果有打开空调的命令，则检测房间的温度是否需要开空调，如果需要，下发命令到智能空调。
　　
　　烟雾报警，一旦检测到烟雾，便把状态记录到 Firebase 数据库中，然后手机获得报警的通知。
　　
　　晚间灯光，这里有两个功能，一是床头触摸，关闭所有灯光的触摸板，可装在床头稍远的位置。另一功能是打开卫生间灯光的触摸板，可以放在床头。当人起身或夜间上卫生间时，触碰相应的触摸板，即可以完成灯光关闭。由于数据是实时的，也需要用 Firebase 的实时数据存储功能。
　　
　　那么，我们把这些功能需求转化为技术点之后，怎么在 Android Things 中实现呢？
　　
　　通过之前的结构图，我们可以看到，控制中心做完设备及网络的初始化后，后续时间是被动接受等待消息，除了摄像头是主动触发操作，给手机端发消息报警之外，其它都是被动触发，需要用户主动去点手机 App，或点击触摸板才完成操作，我们可以着重分析一两个触发条件的例子，来看看 Android Things 怎么去完成相应的功能。
　　
　　值得补充的是，对于摄像头去识别人的脸，产生报警这个模块，完全可以参考它告诉了我们怎样把 image 传到云端，然后用 TensorFlow 解析图片。
　　
　　对于 Android Things 的应用，在开机硬件诊断结束，正常运行程序后，需要完成以下几个方面的事情：
　　
　　Wi-Fi 的家用自组网上的网络节点正常连接。这一部分可以参考 Android 应用中，对网络的管理来完成。
　　
　　网络状态及结点状态管理，异常日志记录。如果网络状态不正常，在 Android Things 上要有日志记录，等待网络连接好，然后再把日志存入云端，这一部分功能来源重点要考虑数据的安全性和程序的健壮性。
　　
　　各个节点的数据同步和异步收集。所以在本地要区别哪几类结点为同步数据，哪几类为异步数据。对于这个项目来说，触摸板去关闭所有灯，或是去打开卫生间的灯，为同步数据，这一部分 Android Things 只需要做一个纪录即可。摄像头如果监测出异常情况，那么消息就必须实时发送到用户手机应用上。其它的几类应用，属于异步消息。
　　
　　消息机制。这一部分内容需要在软件层面上做一层自主网协议，包括协议内容和数据校验。做这一层协议的原因有两个，一是保证数据可靠传递，二是为了安全，防止恶意数据包通过 Wi-Fi 来控制节点。值得注意的是，数据方向不一样，比如摄像头的数据是往云端发送的，而灯光的开头是接收数据的，从局域网的组网角度来说，要隔一定时间产生心跳包，去维持消息的传递。节点之间的消息传递，这一部分功能主要来源于触摸板去控制卫生间的灯光打开。对于如此多的消息，我们会在 Android Things 这个控制中心上设置一个消息池。对于下发消息，每个节点通过心跳包带回是否有可取消息的信息，最后再完成消息的传输；对于上传消息，则由节点主要向控制中心发送消息传递请求，然后控制中心返回后，再发送消息。
　　
　　云端的数据包括 Andorid Things 应用的各种日志维护，各个节点的状态以及消息传输情况、异常情况分析等，这一部分数据可以留作以后进行大数据分析使用。
　　
　　手机端的应用功能会特别简单，就是室内智能节点的状态查看，还有空调节点启动控制，以及灯光的关闭控制。由于这部分消息是直接从云端获取的，所以云端只提供简单的消息服务即可。
　　
　　总结
　　
　　解决方案的环境搭建中，通过利用 Android Things 以及 Google 的云端服务，从硬件开发角度来说，我们只需要解决室内自组网的模块问题即可。大大方便了智能家居方案的开发，非常利于快速原型的实现。
　　
　　从软件开发角度来说，除了产品的一些关键技术分析之外，我们更注重系统的容错性、稳定性以及可扩展性。因为设计之初，这些特性没有在代码中加以强化，后续功能的修改，会带来很大的麻烦。
　　
　　项目需求调研完成之后，我们会经过如下的几个步骤完成项目的各个阶段：
　　
　　硬件模块选型及基于硬件的测试：这一部分工作主要是确认基于 Wi-Fi 的自组网络如何才能方便、稳定地连接，连接后的测试方法以基于硬件的稳定测试为主；
　　
　　最小化应用开发：主要完成家庭自组网的软件管理，完成基于软件的网络数据稳定测试。其中网络收发数据主要基于控制中心是否能跟每个节点进行稳定的数据交互，节点之间能否进行稳定的数据交互；
　　
　　应用模块的开发及测试：由于 Android Things 是单应用开发，整个系统以消息机制运行会更为方便。除了上面一节消息机制的管理，这里还需做一下补充，自己需要在消息上做一个协议栈，保证消息按时发送出去。然后对于不同类型的消息，按照响应速度排序，完成相关的消息处理过程。按照消息处理来区分，不同的节点会被分成不同的任务加以处理。所以这里的应用模块会在 Android Things 中用任务加以细分；每一个任务表示一个独立的模块；
　　
　　整体功能测试：除了测试整个流程的运行状况之外，还要测试每个节点的任务是否按需求响应并执行。这一部分测试有助于了解每个模块的作用，以及模块间的交互是否正常，非常有机率发现单个模块的稳定性问题，然后去做 BugFix；
　　
　　基于产品需求的功能修改及开发：这一部分是产品的研发细化工作，适用于无需修改框架而用户更容易使用的产品需求。
　　
　　除了开发步骤的规范外，开发中的代码库管理，还有开发环境的一致性也很重要。如果不止一个人做开发，在代码库中，应设立不同的分支，然后在一段时间内合并分支，确定一个时间之后，再进行分支的开发。这种方式有助于开发过程中的同步，以及功能、接口不一致时的快速解决。
　　
　　当然，在开发一个项目时，会碰到很多其它问题。但根据经验来说，让团队里的每一个人，都清楚这个项目要完成的内容，以及自己在项目中的作用，是非常有作用的。它有助于发挥出每一个人的潜能，从而带动团队方案的优化，以及工作积极性。
　　
　　参考文档
　　
　　[1] http://www.xinhuoyule88.com /ITU-T/recommendations/rec.aspx?rec=y.2060
　　
　　作者：王玉成，供职于清华大学移动计算研究中心。多年嵌入式系统及物联网项目经验，熟悉数个物联网通信协议，同时是中国唯一的物联网 GDE（Google Developers Experts），主要负责 Android Things 在国内的技术普及与推广工作。
　　
　　责编：唐小引，欢迎技术投稿、约稿、给文章纠错，请发送邮件至 tangxy@csdn.NET。