7.3.1 软件流程介绍
用户数据监控流程是本系统最为关键的基础功能，为整个系统的开发和优化奠定了基础。根据图7.5，此部分可以分为多个模块同时进行开发而互不影响，分别是：
(1)读取MAX30102数据
按照芯片手册的指引，我们可以得出它读取一次数据的流程，如图7.6所示。
图7.5 监控流程图
图7.6 MAX30102数据读取流程
其中，发送重新开始命令是因为传输过程较长，怕被其他设备夺取总线，数据得不到一次性传输。
(2)读取其他传感器数据
将此部分一起写在本节中，是因为它们单独的模块没有丰富到可以单独成章。由于这些传感器读取数据的协议超级简单，所以很大的工作量在于完成通信协议的软件模拟，读出来的数据也简单易懂，具有明显的实际意义。此部分包括MLX90614传感器以及DHT11传感器数据的读取。MLX90614用的是SMBus协议进行数据传输的，它跟IIC协议有着很大的相似性，因此在软件模拟的时候就可以直接参考IIC 的内容，稍作修改就可以使用；DHT11则是一个非常简单的操作，在需要测量的时候直接拉低信号引脚一段时间就可以等待获取测量数据了。(https://www.daowen.com)
(3)读取API数据
这个系统的天气功能是靠网络服务提供商的接口得到的。此部分的复杂之处在于网络传输一般使用JSON，JSON是一种极其轻量级的数据信息交换格式，由于附加信息少，便于信息传输、易于理解、能够高效率地析取出有效信息。JSON是一种新的数据组织形式，它采取键值对的形式对所需要存储和传输的数据进行格式化，让所有的编程语言可以无差别地使用这种格式，正是因为它的这个好处，它迅速占领了数据传输领域的半壁江山；更重要的是它结构简单，适合用于突发的、少量的数据传输，这也非常适用于网络数据传输。著者采用了开源项目cJSON进行JSON数据的构建和解析。
(4)TTS(Text To Speech)[21]
本部分虽然没有在流程图中画出来，但是它渗透在了程序执行的各个环节，用流程图表示稍微复杂。正如其全名的含义，TTS就是一个文字转语音的服务，但是它里面包含了很多的机器学习的内容，比如用什么样的声音说出来、用什么样的语速说出来以及用什么样的语调说出来等，其复杂程度导致开发者在短期开发一个项目需要繁重的工作量。
所以我们选用了开源的TTS 引擎，在初期试用了Espeak、Ekho、iSpeech等，但是事实证明它们的英文发音标准、吐字清晰，但是对于汉语这种语言就显得有些无能为力，表现最为突出的缺点就是断句不准确、无法根据现有的语境选择正确的多音字发音等。继而找到了讯飞科技，他们在自己的官网上开源了一份TTS的程序，在经过试用之后，发现他们现在的语音合成已经可以说是炉火纯青了，比不少人的普通话说得还要标准。但是这份程序仅仅有32位和64位电脑的安装和执行环境，无法在嵌入式环境中编译安装。“天无绝人之路”，我们发现它曾经的历史版本中正好保留了树莓派这个安装平台，就采用了此版本的讯飞科技的开源TTS引擎。
(5)数据同步
客观来说，此部分如若作为网页端进行开发，那么这个工作根本不值一提，因为太简单了。可是对于C这样一个直接跟内存打交道并且多用于硬件开发的语言来说，这个工作确实显得后劲不足，因为它一旦使用不当很容易造成内存泄漏，长时间的内存泄漏往往导致系统崩溃。所以著者用了C++进行开发这一部分，用C++而不用其他语言的原因是C++兼容C语言，这样能在不改变其他代码的情况下使用新开发的内容，更为重要的是C++在一定程度上克服了C语言内存泄漏的短板，使用C++之后仅需要更改工程的MAKEFILE[22]之后重新编译工程即可正常运行。
下面即将介绍团队开发的基于网页端和APP的后台服务程序，对于数据同步这样一个简单的需求为其单独开发一个服务后台是不划算的、也是不明智的、不可取的，所以著者直接将数据同步的后台写在了网页的后台里面，正是因为如此，就需要在数据同步的时候遵循浏览器通信的标准，在通信的时候首先要声明通信类型，空格之后紧接着就是需要请求的网址，接下来就是HTTP的版本，换行之后就是消息类型，再次换行之后追加消息的长度并进行两次换行就可以完成代码模仿浏览器通信。著者在此选用的是GET方法、HTTP/1.1[23]版本、application/x-www-form-urlencoded类型，其余的均由程序计算得出。
需要额外说明的就是TTS，因为其他模块间的调用已经在流程图中表现出来。TTS提供基础服务，也就是一个机器对用户的提醒功能，设定它可以在测完温度、湿度、体温，获取到天气之后播报提醒用户，还有一个作用就是当用户在网页端/APP上进行按摩操作时可以提醒用户按摩模式。这也方便了调试，当用户执行完操作之后，如果听到有正确的提示声音，那就说明大部分代码没有问题，只需要排查剩下的一小部分代码即可。
