17年的时候我入职了一家做智能家居的公司，终于写完了对这个项目进行复盘。

复盘主要还是宏观层面上的思考，并且挑选了部分模块的案例。

智能硬件产品的形态是智能时钟，这个idea是出自老板在两年前早上洗漱时候觉得如果在这段时间希望能自动提醒今天的天气、新闻甚至车辆限号的情况。

这个场景其实在家居中目前还没有成熟的产品能够实现，原因有两点：

做智能硬件比单一的软件在难度上要高很多，因为要考虑到硬件的很多的模块，比如底层系统架构，wifi模块，显示模块，扬声器模块，外观等等因素，以及与手机之间的交互。

其二是由于技术不成熟目前的智能家居还未细化到对单一场景进行智能优化。

项目启动之初，首先是要考虑的是产品形态，以什么样的消费升级来做这个概念。

经过头脑风暴后，老板最终拍板决定使用时钟。

硬件组成

接下来需要分析的是硬件方面的组成。

首先作为一个智能硬件，必要的是CPU，WiFi模块，蓝牙模块。

而从概念来讲那么一块屏幕和扬声器也是必要的。

那么作为一款“电器”，还需要考虑的是，使用蓄电池还是使用插电式的方式，这就需要综合产品形态来考量。

既然是时钟，那么必然是挂在墙上几乎不会移动的，所以从能耗的出发点，我们摒弃了电池以追求不必充电的效果，所以在时钟下部坠了一根电源线，而在线上参考手机耳机设置了调节音量的按钮。

在操作上来讲，首先是需要手机app进行远程交互，另外在硬件上也需要一些简单的按钮进行操作。而设计之初由于成本的把控和技术的实现，没有加入语音控制系统，那么也就不需要麦克风。

在场景的考虑上，一款家居类硬件我们需要它除了使用网络获取外界的信息，之外还需要有相应的传感器检测整个家的一些情况，所以在这里我们加入了温湿度传感器。 

在硬件上的模块清单大致如上。

设备设置

设备联网

软件这里也需要分成两个部分来进行设计，一个是设备上的另一个是手机app。

软硬件交互，是最基本的一个功能，首先面临的问题是关联手机和如何让硬件联网。

时钟的屏幕由于不是触摸屏，所以需要用户在手机上进行联网操作。

登录后手机联网引导界面

设备联网为了友好显示，做了分步骤进行： 

开机之后语音提示用户扫描屏幕上的二维码去应用商店下载手机应用，下载之后手机进行登录操作，此时按照手机上的说明让设备进入了等待蓝牙连接的状态。

手机与设备蓝牙连接之后，手机上输入WiFi的信息会通过蓝牙传给设备，从而进行设备联网。

设备成功联网之后，进入新手引导环节。

操作引导

由于设备是自定义的操作模式，所以用户需要引导进行使用从而培养习惯。

设备上语音+动画的形式帮助说明：

音量控制、切换应用、唤起菜单、播放/暂停、选择 等的简单操作。

手机应用设计

手机上的应用采用了常规的底栏按钮分页面设计。

首页：是对于设备中插件的一些操作（类似我们在手机或电脑的桌面，或者可以理解为遥控器），也包含了一些常用的设备快捷操作及增删设备上的插件（功能）。

插件商店（精选）：用户可以在商店中下载需要的一些插件（功能）。

*插件：

为避免和应用这一名词的混淆（如微信、淘宝等），我们将设备上的应用定义为插件。

也就是说，在App Store或Google Play下载下来的是应用（即在应用商店下载了“时钟应用”），而在我们时钟应用中的插件商店可以下载到插件对设备进行安装使用。

所以在设计插件时不仅需要做手机端的插件，还需要做设备端的插件，并且保证双方版本号一致，才能够进行正常使用。

在这里的插件下载不需要手机端应用的升级和更新（只有ROM/Launcher有修改时，手机端应用或设备需要推送升级）。

个人中心：包括了账号设置、不常用的设备操作以及设备基本设置，如解绑设备、添加设备、添加用户、切换设备等。

智能播报

在我入职之前，大部分基础功能已经做好了，比如设备设置、账号系统、以及部分插件如时钟、电台、蓝牙音乐。

我需要做的是各个部分的优化以及新插件。

在做智能播报之前，我发现设备似乎少了点什么。

设备总是需要被动的去唤起某一项功能，比如看天气时需要手动切换到天气插件，需要听电台时又需要手动切换至电台插件。

基于这个思路，结合现在已有的功能，我想到了让设备主动去推信息流。也就是说当用户预设好了场景后，就可以收听信息。

再回到idea的阶段，用户的需求是在洗漱的时间收听时间、天气、限行及路况。

那么一旦洗漱时间固定，我们就可把这个信息流做进闹钟里，时间到了就自动序列去播放内容。

而这样一个功能联动了不同的插件，同时也不适合做成新插件，就需要在launcher中加入一个提醒状态，可以类似手机中闹钟响了桌面会覆盖一个图层显示当前闹钟状态，用户可以进行手动关闭。同样的，我们在设备上也设置了手动关闭的操作。

自动播报

我们可以让用户在手机上设置好播放内容、时间等并该播报处于开启状态，到时间时就可以进行播报。

手机端智能播报页面

而设备端会暂停当前音频，进入‘智能播报顺序流’，跳转至对应插件页面。

播报顺序：

铃声:20秒音乐，第15秒开始减弱。

叮咚音效（选择铃声时，该音效不播放；未选择铃声时播放该音效）

时间tts：{{早上（4：00-12：00]/下午（12：00-18：00]/晚上（18：00-4：00]}}好，现在是{{19}}点{{17}}分，桔猫为您准备了{{起床播报}}。

日历tts：今天是{{2018}}年{{1}}月{{1}}日，星期二，农历{{冬}}月{{十五}}。（设备端显示日历页面）

天气tts：当前为您播报的是{{西安}}的天气，今日{{雨夹雪}}，最高气温{{1}}度，最低气温{{零下3}}度，PM2.5为{{400}}，{{重度污染，外出请戴好防霾口罩}}。{{易发感冒}}，{{今天不适宜洗车}}。（设备端显示天气页面）

新闻tts：现在为您播报桔猫{{国内}}新闻：{{……}}（设备端显示新闻页面）

mozik：现在为您播报的是mozik精选音乐（设备端显示mozik页面）

手动播报

而定时播报几乎仅限类似于时间规律的场景，那如果我们也想让用户在不固定的时间听到播报推送要怎么做？

时间不固定的场景最典型的的是下班回家，由于下班的时间以及路上所花费的时间导致下班回家不是固定的时间，那么首先要考虑的是如何获得用户回家的信息。

一开始我想到了一回家用户的手机会自动连上家里的WiFi，通过这一信息联动传递，设备获知了用户连上WiFi了就等同于下班了。但对此，开发也进行了技术预研，发现并不能从路由器或手机系统获得相关数据。

关键词是“快捷”“用户想听”，从这两点出发，我想到了在设备上设置一个快捷唤醒智能播报的操作。

同时在错过了“想听”的时候不会再去推，这样也就需要时效性。比如说用户下班已经是晚上11点，回到家只想倒床就睡，那么设备一旦过了“播报有效期”就默认今天不需要播报，提示也会在设备屏幕上消失。

这样一来就有了“手动播报”的定义：在预设好的某一时间段内，手动拉动拉绳开始进行播报。

手动播报

当到达用户所设置的手动播报时间段内，设备端底部弹出如图弹框；

[已为您准备好今日的{{播报名}} 下拉拉绳开始收听]

下拉拉绳后进入自动播报；

当过了有效时间时，底部弹框消失，手动播报不会被触发。

编辑播报页面

手机端新增播报页面

‘重复’与当前闹钟选择【重复页面】一致，点击跳转【重复页面】；

‘播报内容’显示当前已选序列流内容名，点击进入【播报内容页面】；

点击‘播报时长’跳转至【播报时长页面】，可选项有：5 分钟 10分钟 15分钟 20分钟 30分钟 自定义，点击自定义弹框弹出[0-12]小时[0-59]分钟选项，点击确定后，‘对勾标记’停留在‘自定义’一栏，点击确定，【编辑播报页面】显示播放时间为 {{分钟}}分钟；

显示：

0小时X分钟显示 X分钟

X小时0分钟显示X小时

点击‘手动播报’可进行切换开启/关闭，时长选择范围与播报时长一致；

点击右上角‘确定’为保存，该播报开关依然保持之前的状态；

点击左上角‘返回箭头’视为取消操作（未保存）。

插件设计

新闻播报插件

新闻模块最简单的方式是接入了第三方的API，我们在后台设置定时的拉流接口就可以了。

新闻播报这个插件在我入职之前就已经上线了，但由于硬件设备与手机不同，会出现一些因为设备关闭/断网的状态导致的一些问题，这个就算是一个逻辑优化。

问题：之前新闻播放到A，过了几天之后进入新闻界面，设备端显示A的标题，手机端底部不显示播放进度bar，设备端点击中键后不能播放。

原因：进入新闻界面后：手机端的播放记录是从服务器拉取，这个时候服务器返回空，所以底部播放记录的bar不展示；设备端的播放记录是读的本地，所以显示A，点击播放的时候请求服务端，由于A已经被删掉所以点击中键后不能播放。

优化：

每次更新新闻之后，设备端显示当前所选频道的（最新更新的）第一条新闻，不显示上次的播放记录（早上6：50-7：00之间用户打开新闻应用，需要设备端主动拉取新闻内容，检查该新闻是不是今天的新闻）；

判断历史记录是不是当天的；

每天只删除一次新闻内容，删除时间点是每天早上6：50，设备端保持一致；

新闻更新失败要有重试逻辑，播放后台已经删除的新闻BUG解决；

流程图

测试用例

倒计时插件

作为时间类的设备，常用的功能必然是与时间相关。

在一次头脑风暴中，同事们提到有时候经常会用到提醒工具，比如提示敷面膜的倒计时，以防时间过长。

那么此类的工具在家的场景下使用设备操作更为方便，于是构思了在移动端设置常用的倒计时，在设备上进行使用。

计时器通常的设置需要名称及时长，所以在手机端添加只有这两个字段。

手机端添加计时器

而在设备上呈现的需要三种状态：未开始-进行中-已结束。

同时也需要展示倒计时名称，倒计时所剩时间。

操作上有切换倒计时及开始/结束倒计时。

倒计时结束tts：

[【音效】您设置的计时器{{煮鸡蛋}}已结束]；

异常情况的处理是每一个设计都需要考虑到的部分，在设计倒计时的时候，异常情况大概会有以下几条：

主从用户是否需要同步‘倒计时信息’；

设备关闭/断电等原因关机，如何处理；

闹钟/提醒来时，声音是否会重复；

正在进行倒计时，手机端添加一条倒计时，设备端是否需要刷新，及倒计时的顺序；

这里给出解决方案：

（当前倒计时结束后顺序重置，如：有倒计时ABC，A为第一个倒计时，显示：CAB，当前进行倒计时A，此时手机端添加倒计时D，按下键则显示DAB（A被选中）

设备端倒计时正在进行，手机端管理倒计时，当前倒计时不受影响。该倒计时结束时，同步手机端信息；）

其他

升级更新

硬件设备比较难的一点是ROM升级，在研发状态时候可以随时打开设备插上数据线更换ROM包，而对于测试阶段多个设备情况下就需要批量统一升级，这里就必须要使用OTA进行升级。

交互流程如泳道图

强制更新：

后台推送之后，会使用第三方OTA推送至设备，设备处于非离线的状态就可以立即进入更新；

设备重新联网时需要主动请求当前版本是否与后台版本一致，如果不一致会立即进入更新。

非强制更新：

用户在手机端确认更新后，设备开始下载更新安装包，下载完成后，设备则自动开始进入更新状态。