#研发解决方案#智慧的太空桥管理智慧设备_移动开发_编程开发_程序员俱乐部

郑昀 创建于2017/10/29

关键词：设备，远程管理，安全桌面，应用商店，远程控制，同屏映射，调用链分析，异常上报，卡顿上报

如果你要管理横跨 80 城的数以万计台商用设备，你会怎么做？

怎么保证设备不被滥用，比如看视频，打游戏？

怎么保证应用能快速分发？怎么做到几分钟之内大江南北都打了补丁？

某商户投诉新版本应用出现闪退，你做了一个测试版本，怎么投放到指定设备上运行并收集日志呢？

你全量发布了一个新版本应用，怎么在商户的大面积投诉之前，率先发现闪退趋势呢？

如果商户投诉设备运行缓慢，你怎么分析性能瓶颈呢？坐高铁到现场吗？

唯一的出路

唯一的出路就是这些设备接受云端系统的严格管控。

太空桥（SpaceBridge） 就是这样一款设备运维管理平台。

为什么叫太空桥？

太空桥是变形金刚里一种连通遥远区域的瞬时通道，以供塞伯坦人通行其间。这一计划是以在各个世界间通行为最终目的。

智慧设备

太空桥（含太空桥Agent，太空桥移动客户端）充分体现了我们技术团队一直以来奉行的哲学：

● Dont make me think：减少无谓的猜测和思索，用不会出错的机器智能来替代人工；

● 日拱一卒，功不唐捐：构建一套体系就可以一劳永逸，掌管现在和未来所有的设备、数据和客户。

我们所有未来的设备，都必须是智慧设备。

何谓智慧设备？接受我太空桥统一管理，能做安全桌面，远程控制，应用商店（应用分发），应用黑白名单，增量更新，热修复，灰度发布，性能监控，异常和卡顿上报，调用链分析等等。如果做不到这些，就不应该拿这种无法远程管理的设备给我们这些最终兜底的技术团队挖坑埋雷，因为我们不希望到全国80城出差做技术支持。

如何接受太空桥管理呢？

首先需要注册。

也就是把设备 SN 号和 GUID 号在云端报备。

可以由人扫码来报备。设备上会默认安装我们的太空桥 Agent，它默认界面上会展示一个二维码。项目实施工程师持太空桥 App 扫码，则将该设备报备到云端，与某个商户下的某个门店绑定。

其次设备连接云端首次发送心跳，就算是设备激活了。

由于保持了心跳，所以云端能知道设备是离线、在线还是关机。如下图所示，我们能准实时观测到不同管理区有多少台设备，分别处于什么状态，查看各项性能指标，如系统可用内存，CPU使用率，SD卡大小等。

图1 首页-设备监控大图

如何保证设备不被滥用呢？

在下双屏一体机（就是一台安卓设备）的初期，收到过设备越来越慢的投诉，调查发现，设备上被安装了优酷等视频和游戏 App，难怪速度越来越慢。

所以之后新设备发货时烧的ROM就是我们定制的ROM，没有我们签名的应用是会被自动拦截，无法安装的。我们还随系统下发了安全桌面，限定桌面上只出现我们的应用。

图2 应用商店-太空桥安全桌面

应用如何分发呢？

太空桥实现了一个应用商店，管理 App 以及它们的版本，如下图所示。凡是要部署到智慧设备上的应用，都要通过太空桥应用商店来分发。

应用商店这个概念大家都很熟悉。

创建了应用之后，就要管理版本了。首先上传包文件，填写版本描述，选择支持的设备型号（应用不一定能分发到各种安卓设备上）。其次系统会自动从包文件里读出版本号。

图4 版本管理-更新管理

有了版本，就要针对版本设置版本策略了。

什么是版本策略？你是要全量发布，还是灰度发布？它俩的区别如下图所示：

图5 设置策略

目前灰度发布允许两种范围：

class="list-paddingleft-2">

1. 按设备：选择具体的一批设备；

2. 按餐饮中心：选择具体的一批餐饮中心，整个餐饮中心的设备都会更新版本；

发布到设备是最小粒度。这样就可以做到，某个档口投诉新版本有闪退，我们给他单独提供一个测试版本来排查问题。

如何对设备远程控制？

目前设备层级的远程控制仅支持重启和关机，还将支持一些关键特性，比如同屏映射，即设备和太空桥页面操作上的同步显示，比如设备的目录浏览和文件读取，日志文件还是要说拿就拿的。

设备上的应用层级则支持卸载、打开和关闭。当然 agent 和安全桌面是禁止卸载的。

如何发现异常呢？

餐饮中心如果投诉“档口 A 刚才从点餐界面切到已售情况会卡一下，最近偶尔会遇到几次”、“档口 B 反馈点菜单切换卡了五六秒”、“档口 C反馈点击打印餐柜密码，App 退出了”。

这种投诉远程协助的话，跟进很难。第一，它可能不易重现，比如与当时的网络环境卡有关。第二，不定是哪儿出的问题，日志不一定打点了。

这时候就需要所有的应用都引入我们的性能 SDK，主动上报卡顿（对于安卓来说就是ANR（Application Not Response）了）、异常、崩溃了。

图9 异常上报-崩溃分析

我们可以看一下上图中的空指针异常，能看到这种异常分布在哪几个版本里，影响了多少个客户。

图10 崩溃分析-异常详情1

所有上报的设备的信息也能看到：

图11 崩溃分析-异常详情2

当然必不可少的是堆栈信息：

图12 崩溃分析-异常详情3

甚至可以看到崩溃那一刻的内存大小、存储空间大小、安卓系统版本号：

图13 崩溃分析-异常详情4

总的来说还是非常便于发现问题和排查问题的。

如何主动诊断异常呢？

现在正在做的是：

网络请求分析。主要是围绕着设备上应用的 HTTP 请求做分析，DNS 解析时间，远端响应时间，数据传输时间等等。别人说应用慢，你好歹让 ISV 知道慢在哪一段。

调用链分析。当系统出现问题时，我们可以迅速切入设备，调用链可视化，从而便于排查问题出在网络操作、文件读写还是什么函数上，指导 ISV 解决问题。

总结

总的来说，太空桥是一个非常优秀的设备运维管理平台，已经能很好地管控智慧设备了，太空桥的开发者们都非常厉害，在非常短的时间内攻克了一个又一个技术难点，大踏步挺进这个我们以往未曾涉足过的领域。

-EOF-

语录1枚：

公司大了，久攻不下的堡垒，确实需要来一次三板斧共创，跨团队组成战队，互相PK，高压态势下激荡心力脑力体力，最终逼出落地方案。