点击上方“云加社区”，选择“置顶或星标”

学习技术干货 提升自我能力

腾讯车载小程序，是一种智慧出行场景化的落地方案，可以为用户提供便捷的出行服务，并可以通过语音进行操控。兼容微信小程序，开发者通过简单适配，就可以让微信小程序运行在车机上。

本次演讲将会分享如何让小程序开发者为用户开发适合智慧出行场景的内容和服务。

（在公众号对话框回复：车载，获取本文PPT文件）

提到小程序，大家不可避免地会想到微信小程序。微信小程序经过这几年的发展，现在生态已经非常繁荣了。微信上面活跃的小程序数以百万计，更可贵的是有数以百万计的小程序开发者。除了这么多的小程序和开发者以外，小程序有什么特点呢，这里还是直接拿张小龙总结的特点来看，无需安装、触手可及、用完即走、无需卸载。

小程序的这些特点，可以看到非常适用于在车载场景里面使用。比如说无需安装，现在手机里面经常会不断安装一些程序、卸载一些程序，大家会觉得很烦。但是大家可以想象一下，在汽车车机上安装一个程序、管理一个程序会是多么痛苦，就以我个人为例，我的车上到现在为止没有自己装过一个应用程序。所以App这种形式的管理成本会非常高，如果我们能够有一种无需安装、无需卸载的形式，来提供车载的服务，很显然会给整个车载的生态带来很大的便利。现在大家在车上主要是使用导航、听听音乐，很少使用其他服务。

为什么会这样？

因为很多常规的服务没法通过一种APP的形式来很好地给用户提供服务，导致这里面的服务非常匮乏。如果有这样一种触手可及，用完即走的提供服务的方式，我相信给整个车载市场会带来很大的改变。

所以基于这样的考虑，我们可以看到不仅仅是说小程序这样的一种应用服务提供形式非常适合车载场景，同时微信小程序的生态非常繁荣，有大量的微信小程序和小程序开发者，我们认为用小程序的形式在智慧出行场景下，通过小程序来提供服务会非常合适和便捷。

其实现在微信小程序里面有很多的小程序是针对或者适用于车载场景的。

比如微信小程序里有ETCP停车、无感高速等。也有视听服务类的，比如喜马拉雅、腾讯视频等。还有大众点评、京东购物，这些生活服务类小程序。现在这些小程序大家只能通过手机来使用，大家应该有一个体会，在车上通过手机使用服务不是特别方便。人的本性都是懒惰的，懒惰是推动人类进步的第一动力。能少做一步事情的时候，大家都希望少做一步。

所以如果能够直接在车机上为用户提供服务，无疑是给司机和乘客带来更大的便利。基于这样的考虑，我们想把小程序的内容直接从微信小程序的生态里边放到车载的场景下，其实是可以给整个车载场带来很大的便利。

那是不是直接把整个微信小程序搬到车上面就可以给车载小程序来用了呢？

并不是这样的。因为手机和车机是两个完全不同的终端设备，直接把微信小程序搬到车机上，体验并不是很好。针对车机这样的特殊场景，我们做了很多适配车载场景的工作，这里是整个车载小程序的整体框架。左边可以把车载小程序分为三层，最底层是腾讯浏览服务TBS，TBS提供了一个JS的运行环境和渲染引擎，可以用来执行和渲染小程序。

再上层是小程序框架，这个跟微信小程序框架类似，但是和微信小程序不一样的地方，在于这一层加了TAIS语音交互能力。这里大家可以理解，在手机上大家比较常用的交互方式还是触摸屏的方式来做，像刚才说的触手可及。但是在车机情况下，特别是司机在开车的情况下，如果用手去触控交互，这里面其实是蛮危险的。所以更自然的一种车机的交互方式，我们认为还是语音交互。所以我们引入了语音交互的形式，能够让小程序具有语音交互的能力。这个框架之上就是很多的小程序应用。

从客户端和云端两个层次来看，在客户端除了刚才提到的有小程序的运行框架和管理框架之外，增加的是语音的一些能力，包含录音数据上传、降噪等等功能。同时，我们也和车联系统紧密关联，因为我们需要知道车辆的状态，通过车联提供的Push通道来提供服务，同时还有车辆的账号、安全策略，这都是在手机上微信小程序不会考虑的，但是在车载场景下我们必须要考虑。

除了客户端，在云端我们同样有小程序的管理后台，也包含语音的后台，因为语音也会涉及到语音识别和语义的处理，同时会涉及到推荐的后台。涉及到语音交互的时候，我们会在不同的场景有不同的小程序来提供服务，这里面我们推荐用哪些小程序服务，里面需要一个后台。这是整个车载小程序大体的一个整体架构图。

经过这样的设计，基本上我们将整个车载小程序分为三层。最底下的一层就是整个的基础能力，它包含提到的TBS的框架适配、小程序的冲突管理。这里面冲突管理像刚才提到的，当用户需要一个服务的时候，这个服务的提供方会有多个小程序，也可能会是一个APP，也可能是一个语音服务，我们怎么样来管理冲突？同时也有语音交互的控制，还有语音播报、登录、更新基础能力，特别是更新升级的能力，传统的车机App升级会非常痛苦，因为整个车厂对安全和稳定性的要求，整个系统的更新周期非常长。

我们用了小程序以后，大家看到其实微信里面的小程序其实是在不停地更新的，但是大家没有任何的感知。所以这里面我们也利用了小程序的这种更新升级的能力，使得在车载小程序上可以实时更新你的服务，让用户没有任何感知地去更新。在这之上就是智能推荐和管理，包括小程序的管理，以及包的管理，和整个小程序包的上传，以及更多的设置管理，还有推荐策略和安全检测。安全检测是在手机里面不会有的，但是在车机里面必不可少。

比如一个用户，他正在开车的时候突然想看视频，这个要播视频。但是从安全侧的角度来讲不一定能满足它的需求，这就是能够深度地和车载系统绑定，检测到这样的一个状态下，用户不适合使用这样的小程序的时候，我们可能会给他一些提示。

在这之上就是真正的用户可以感知到的小程序的交互展示这一层，现在我们重点是在三类服务上面提供各种小程序的服务，一类是出行服务类，包括停车、加油、过高速之类。第二是视听服务类，像刚才提到的有声的内容和视频。另外是生活资讯类，比如你去开车的时候，到了某个地方，想要看哪个餐馆好，我们可以直接在车机上提供一些服务。

做到了这几点以后，我们希望看到一个比较丰富多彩、非常智能的车载小程序的生态。首先第一我们就会有轻量的非常丰富的服务平台，因为整个车载小程序完全兼容微信小程序，所以基于微信小程序，做一些比较轻量的适配就可以上车，在后面我会给大家具体讲一下要做哪些适配，可以在车机上有比较好的体验。

同时，不仅仅是现有的几百万的微信小程序可以让它便捷上车，几百万的微信小程序的开发者也是一个非常强大的资源，因为现在很多为车机去开发应用程序或者服务的开发者相对比较少，因为一来是这个市场的需求，因为整个车机端不是很多，特别是车机的这种碎片化非常严重，所以有一些车机SP，它要开发一个服务必须要开发很多端，这样成本很大。如果量不大，其实这里面的收益是有限的，所以这种情况下是阻碍了大家为车机开发服务。

现在我们有了这样一个庞大的小程序开发队伍，大家可以看到整个小程序的开发成本，相对于APP开发来说低很多。所以不仅是微信上现有的这些小程序，小程序的开发者也是我们整个车载生态的庞大的资源。

除了这个服务平台以外，我们刚才提到有安全便捷的语音交互，包含我们可以用很便捷的方式来唤起小程序。因为在车机上输入是一个很大的问题，车机上不是特别方便输入，所以我们可以用语音代替输入。包含有些列表选择用语音来选，还有小程序的原生控件直接用语音来操控，不需要用户用手触碰它控制它。同时有语音播报，我们可以全部用语音来控制，通过这种方式就给用户一种更安全、更顺畅的交互的方式。

同时，车载小程序可以做到基于智能化、场景化的推荐。其实微信小程序最早的一个概念就是在合适的时候，我自然就会有小程序提供服务，在手机上现在好像还没有做到，需要用户主动做，但是现在在车机上可以非常自然地做到。

比如基于地理推荐的小程序，某一个地方有了交通事故，当你的车快要进入到这个区域的时候，整个车联的后台可以把这些信息推送过来，让你通过小程序知道整个交通的情况以及事故发生的情况；也可以基于车辆的信息来进行推荐小程序，比如说如果你的这个车子的保养周期快到了，你开车要经过一个4S店的时候，正好是这个品牌的4S店，它也推荐你用4S店的小程序进行保养等等，我们可以做到非常场景化的智能推荐。也包含你要路线规划的时候，要到某一个地方去，我们也可以看到有没有其他人要到相同的地方去，以及在去的路途上有没有一些好玩的地方，好吃的东西，可以通过这种方式推荐给你。

所以这是我们期望做到的整个车载小程序的生态，是非常轻量丰富的服务，安全便捷的交互，同时有智能场景化的推荐。

刚才提到整个小程序上车还需要做一些适配，我们尽量减少这里面适配的工作量。

第一，UI的适配。现在的小程序，特别是微信的小程序，在手机上的小程序，它更多是为手机屏幕分辨率设计的，当然后面因为微信小程序也要支持iPad版，所以它也有一些针对Pad的设计。但是现在大部分的小程序还是针对手机竖屏设计。如果在车机上，大部分是横屏的系统，如果要在车机上用全屏的方式展示小程序，就需要有一定的适配。

经过我们的实验，发现这种适配的成本是非常低的。首先第一步，我们在框架层可以做一些适配，不需要小程序开发者做任何工作。比如像微信小程序里的导航栏，大家可以看到，在手机上导航栏一般在顶部，或者在底部。但是因为在车机里面，它比较宽、比较窄，所以如果是这样的布局，这里面的导航栏会占很大的空间，导致整个的内容区域比较小，所以我们可以有一个设置，让你的导航栏放在这个旁边，这样让整个内容展示区域变得更大。

另外在整个内容展示区域，你不做任何适配也能够运行，只是有些时候这些图片会有一些拉伸效果，不是特别美观。我们做过一些简单的适配实验，大家知道整个小程序的排版引擎其实是遵循前端CSS规范的，前端的响应式开发是非常常用的一种技术手段，透过这样的方法来适配车机的屏幕就非常方便。像同样一个页面，可以用来适配电脑屏幕和手机屏幕一样，同样这种响应式开发来适配车机屏幕，工作量也很小。

同时除了全屏的展示以外，我们也提供另外一种展示形式，这种情况很多时候是用在这种场景，比如你正在导航，在导航的过程中你可能需要一些服务，比如说要加油或者是你想听歌，唤起一个小程序。这时候其实你并不希望它盖住整个导航，只是我现在临时唤起这个小程序，提供完服务的时候这个小程序马上隐藏。所以这个时候我们让小程序浮在导航上面。如果我们小程序依托的服务是以这种模式服务，你的UI根本不需要做任何的适配。现在整个车载小程序的框架是提供全屏和浮层这两种模式。

这是UI，刚才提到整个车机的小程序更多希望用语音交互。我们现在可以做到小程序的开发，不做任何的开发动作，已经可以支持一定的语音交互能力，当然如果要做到更自然的语音交互的体验，我们也提供了一个语音交互能力的语法扩展，这里面的扩展非常简单，大家一看就明白。

在整个小程序，我们可以为一些控件加一些语音命令。第一个你有一个支付Button的时候，可以给它一个属性，就是一个字符串数组，包括支付、结账等等字符串，就是语音命令的触发词。当用户说了这个数组里面的某一个词，就会触发命令。这里面很简单，你看到小程序的按钮说出触发词，就可以执行这个命令，不需要手按。所以通过这个方式，可以让整个小程序的界面可见即可说，你看到了什么就可以说出来，就OK了。如果你不想去做任何的适配，我们也可以把你对应控件的一些文本填到这里面去，所以你直接拿着微信小程序放上去，它也自然有这样的语音交互能力，这是我们在框架上做的。

除了语音的命令，我们也可以添加语义的命令，你可以设定一些技能，在触发技能的时候执行相应的命令。同时在逻辑层我们也可以添加一些命令，同样就是有一些关键的语音触发词或者语义的技能，对应着一个函数，通过这种方式可以很方便地让整个车载小程序具有了语音交互的能力。

做了这个之后，整个的交互能力是什么样的呢？

我们介绍一下两个流程。一个是基于TAIS语音唤起小程序。用户说出语音命令后，车机中控会把语音信息传递到车机后台，车机后台通过语音识别和语义解析后，获取用户意图，比如用户说“我要买矿泉水”，车机后台解析出用户的意图是“购买”，意图的参数是“矿泉水”。然后到达小程序管理后台，去查询哪些小程序能够满足用户意图，这时候可能就找到了京东小程序，在京东小程序某一个购买矿泉水的页面返回给车机的中控，通过车机的中控可以调起小程序，并且直接到他那个购买矿泉水的页面，这是通过语音来唤起小程序的流程。

另外一个是智能推荐调起小程序的流程，首先车联的系统会同步整个车联的状态到后台，后台通过地址围栏信息，检查有没有事件触发。如果有事件触发，可以看小程序管理后台有没有对应的小程序来处理这样的事件，获取相应的信息。同时把这个小程序信息直接推送到屏幕上，就会有一个弹窗。用户通过语音或者点击就可以直接拉起小程序。

当然，这里面也会涉及到安全的考虑，所以整个调用的过程中，我们通过整个车机安全的系统能够判断调起这个小程序是否有安全问题，如果有安全问题，我们会推送给用户当前不能使用。这是整个小程序怎么应用的。

这样做下来以后，我们可以看到开发者可以用非常低的成本把整个微信小程序里面适合车机的服务让它上车，同时有大量的小程序开发人员也可以针对，即使没有微信小程序，他也可以根据车载的场景开发符合车载的小程序。

更大的好处，在于整个的小程序，大家可以看到微信小程序，它是跨平台，手机上只是安卓和IOS，但是车载系统里面整个车机碎片化非常严重，所以我们现在支持了安卓里的车载小程序，现在近期就会和车机厂商推出上市，同时我们也在和厂商开发Linux车机小程序，未来也会做QNX。这样对车机软件服务开发厂商来说，他只要开发一款小程序，就可以服务于不同的车机类型。对于整个车机小程序开发人员来说会有更大的收益。

做了这些以后，对应的微信小程序，我们希望整个车载小程序是什么样的形态呢？

无需安装，招之即来，挥之即去，用完即走，并且整个小程序无处不在，不管在哪一个系统车机里面，我们为整个出行的场景提供很大的便利。

推荐阅读：

都40岁了还在敲代码，想哭！

腾讯云是如何做原生Devops的？

人人都能看懂的云计算知识科普！

程序员如何从菜鸟工程师到高级架构师？

关注云加社区，回复 3 加读者群

（在公众号对话框回复：车载，获取本文PPT文件）

好文！给你“好看”