1. 业务背景及产品需求

目前的机器人生产线，清洁机器人都有手机app开发需求，考虑到未来产品线的扩大，不同的产品类型和产品版本在逐渐增多（比如消毒机器人1代，消毒机器人1.5代，消毒机器人2代，送餐机器人，清洁机器人，小型割草机等），而业务方需要手机app成为平台型的应用，支持不同类型的产品和不同型号的硬件产品并提供相应的功能支持。

业务方主要的需求有：

1.节省人力，减少工作量，降低开发成本；

2、支持各类型、型号的终端产品设备（消毒、送餐、清洗、送药、小切等）的控制及接入；

3、手机App支持WiFi AP模式直连，支持手机与终端设备直接进行数据通讯（Tcp、自定义协议、传输二进制数据流），通常用于手机无网络的场景；

4、支持设备协议和指令的动态更新发布（包括新产品、协议变更引起的交互、UI、功能变化），无需应用程序更新；

5.减少使用包裹的频率和次数。

2. 技术选择

在使用原生开发的前提下，开发移动端APP需要一名开发人员和一名iOS开发人员。如果想节省人力，目前移动端主流做法是采用跨平台方案。如果想动态更新应用功能，方案主要为开发，或者iOS插件化方案。

最优的解决方案是移动终端跨平台的解决方案，既可以节省人力，又可以动态获取应用功能。

主流的跨平台应用解决方案包括、、和Web容器。

3. 方案对比

1.

使用RN编写应用程序，然后调用原生组件进行页面渲染操作，在保留用户体验的同时提升了开发效率。

RN方案可以满足支持多类型产品、WiFi AP模式直连、动态发布等需求。

缺点是RN方案对原生和iOS都有一些开发工作（相对纯原生开发来说成本较低），而且有一部分需要前端同事的介入。考虑到多一个端的开发带来的沟通协作成本增加，整体来说应该满足不了节省人力的需求。另外市场上具备RN开发能力的工程师很少，补充人力不方便。

2.

相比于RN、Weex等采用作为编程语言、平台自带引擎来渲染界面而言，其直接选择2D绘图引擎库skia来渲染界面，性能无限接近原生。

RN方案是目前跨平台方案中最为均衡的方案，性能和效率都非常优秀，一套代码就可以为iOS和iOS平台生成两个应用，原生工作量大大减少，可以满足节省人力的需求。

但是它的缺陷也是致命的，开发成本比较高，UI库是不适合国情的风格。

最致命的问题是没有动态能力，不支持动态更新协议和功能，无法满足上面的4、5要求。

3.

uni-app是一个使用Vue.js开发所有前端应用的框架，开发者编写一套代码，即可发布到iOS、H5、各类小程序（微信/支付宝/百度/今日头条//钉钉）等多个平台。

优势极其明显，仅需一名前端同事即可完成iOS所有功能的开发，且具备动态能力，在机器人流水线业务需求上，支持WiFi AP模式直连和MQTT连接两种方式。

缺陷基本可以理解为BS模式，对网络依赖性很强，没有网络就无法打开接口，所以使用WiFi直连时，怎么做都存在一定的风险。

另外，后续的机器人平台应用如果需要支持消毒平板应用的各项功能，比如地图的构建、编辑、视频监控等，实现起来也会非常困难。

如果机器人线下产品针对海外，在海外影响力很低，弱网情况下功能体验极差，在手机系统兼容性方面，表现也较差，会出现图标变形、界面卡顿、加载不上、功能点击失效等问题，解决和定位非常麻烦。

4.Web容器，H5

原生应用通过嵌入浏览器控件（iOS 或 ）来渲染页面，并定义与原生代码交互的协议，将一些原生系统能力暴露给 ，从而拓展 的边界。这种交互协议就是我们通常所说的 JS（）。

从不同角度来看，三个时代的跨平台框架代表在开发效率、渲染性能、维护成本、社区生态等方面各有优缺点，如下图所示：

综合分析之后，从满足业务方需求的角度来说，匹配度最高（需要动态功能，通过H5实现），其次是第二，第三。

4.竞争产品研究

1.米家

米家App作为智能硬件领域的领先应用，通过体验其App以及破解Apk包，我们可以初步得出以下几点结论。

a.米家apk大小为134M，混合开发，部分接口为原生，部分接口使用Weex实现；

b.支持产品类型的动态获取，设备、产品、场景三大功能模块均采用非原生方式实现，是否使用Weex实现，有待进一步破解确认。

c.应用引入的lib库包含混合技术方案及weex、跨平台排版引擎yoga、高德SDK、银联支付SDK、腾讯云短视频SDK、MMKV等实现方案；

2.涂鸦

涂鸦智能具备向外部开发者提供解决方案的能力，根据目前了解到的信息，涂鸦内部针对移动端的技术选型也在发生着变化。

a.涂鸦 apk 大小为 147M，大部分功能采用非原生接口实现，且对网络依赖较大，首页、智能版块四大功能模块采用 JS 实现，场景、我的两大功能版块采用 实现。

b.涂鸦智能apk集成了and，根据涂鸦内部开发情况来看，涂鸦整个团队已经砍掉了，使用RN，现在慢慢往小程序方向发展，砍掉的原因是因为涂鸦的产品是开放给外部开发者的，开发者的技术栈比较依赖涂鸦的技术栈，这主要是因为外部开发者用的比较少，导致接入成本比较高。

c. 涂鸦内部跨端开发目前主要以小程序+前端+手机原生端联动的方式进行，前端负责需要动态化的功能，原生端主要写插件、和OS交互、调用系统服务等。

d.从破解的apk中我们可以看到涂鸦跨端解决方案使用了以下lib库：、跨平台排版引擎yoga、高德SDK、视频处理。

3.石头

关于 的研究比较少，通过工具分析发现的apk也采用了使页面跨终端的方案。

五、关于技术选择的初步结论

总体来说，可以把页面做跨平台，原生应用中，一些不涉及原生能力（系统能力）的接口和功能，是可以跨平台的，RN 就可以做到，性能最高，可以做单端开发，跟 iOS 共用，节省人力。但是相对缺乏动态能力，新的功能、新的协议、新的交互都要开发发布后才能被用户使用，不过动态能力可以通过 H5 来实现，相对容易控制。

相对成熟，动态能力强，可以满足WiFi直连功能点。但需要前端同事介入开发，项目上线后需要维护三套代码（原生代码 Java or, iOS原生代码 OC or, RN代码），需求开发和代码维护复杂度会增加。

相对于跨平台的页面和解决方案来说，是真正的跨平台应用解决方案，可以实现功能的动态发布，满足一套代码，多端使用的需求，减少人力需求，而且社区活跃，开源库丰富。

缺点是该方案对网络依赖性强，体验不如原生，需要系统服务时需要依赖插件，另外手机系统兼容性差，无法适应各种环境使用。

最终结论：第一选择+H5，第二选择，第三选择

5. 产品痛点、难点解决方案

需要确认的要点：

1. 是否支持TCP连接、通讯、二进制数据解析？ ——是的

2. 是否支持MQTT服务创建及数据发送接收？ ——是的

3.使用或者直连模式连接机器人热点时，手机无网络，页面如何加载，如何显示？需要产品设计相应功能细节。如果无法处理，也可以通过原生接口解决。

4、多协议问题：协议部分的更新涉及需要原生支持的功能变更，原生代码的变更需要发布新版本，升级后才能使用。

5、该方案支持节省人力，以及需要动态更新的功能，可根据实际情况采用web容器的H5方案实现。

需要确认的点：是否需要考虑将产品的技术能力和标准输出，向外部开发者开放接口和服务？

六、限制和风险

1. 关于热更新

Play 和 iOS App 目前对于热更新的限制非常严格，基本不允许应用通过热更新进行功能更新。而且还有很多未解决的热更新方案，容易出现未知问题。

2. iOS 审核、上架和更新问题

a. 应用动态更新：原生应用的热更新方案在 iOS 应用上可能会被禁用。和前面一样，一些原有方案可能随着时间的推移会被禁用。项目评估热更新方案时，需要考虑时效性。iOS 应用的策略也存在一些问题。另外，应用不能长时间不更新，不能完全考虑热更新方案。有些应用更新还是需要的。

b.对于iOS应用，官方要求定期更新发布新功能，以消灭僵尸应用，基本每个月都会提交一个新版本进行审核发布。

3.人员技术储备与招聘

考虑完技术方案后，公司现有的人力资源中是否有人可以支撑项目的需求开发？如果没有，是否需要开始招聘？招聘的难度和周期是怎样的？

4.软件开发流程

在选定解决方案之后，开发的流程、各方协作、代码构建、发布以及后期运维、线上问题跟踪等诸多流程和职责分工也需要进行相应的调整。

参考：

应用审核指南

#

如何在

、RN、uni-app 比较

中国通信