车载系统的多屏显示方法、装置、车载系统和存储介质与流程

[0001]
本申请涉及车载系统技术领域，具体涉及一种车载系统的多屏显示方法、装置、车载系统和存储介质。


背景技术：

[0002]
随着人们生活水平的提高，目前的汽车一般都配置有车载娱乐系统(in-vehicle infotainment，ivi)，ivi是采用车载专用中央处理器，基于车身总线系统和互联网服务，形成的车载综合信息处理系统。ivi能够实现包括三维导航、实时路况、辅助驾驶、故障检测、车辆信息、车身控制、移动办公、无线通讯以及基于在线的娱乐功能等一系列应用，提升车辆电子化、网络化和智能化水平。
[0003]
现阶段的汽车智能座舱设计中，驾驶员的座位正前方设置有仪表显示，用于显示汽车速率、油量、油温、车身状态，而用于娱乐的车载主机在驾驶员右侧并设置在中控屏上进行显示，驾驶员在使用中控屏上的导航或者音乐等功能时，仅能在中控屏上显示一个应用程序的一个界面，无法满足用户同时使用两个应用程序或者同时观看多个界面的需求。


技术实现要素：

[0004]
鉴于上述问题，提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的车载系统的多屏显示方法、装置、车载系统和存储介质。
[0005]
依据本申请的第一方面，提供一种车载系统的多屏显示方法，所述车载系统的中控屏包括主显示屏和从显示屏，所述方法包括：
[0006]
通过主显示屏接口接收第一界面内容，以及通过投屏接口接收第二界面内容；
[0007]
在所述主显示屏中显示所述第一界面内容，以及以投屏形式在所述从显示屏中显示第二界面内容；
[0008]
所述第一界面内容和所述第二界面内容来源于同一应用程序或来源于不同的应用程序。
[0009]
可选地，所述方法还包括：
[0010]
通过所述主显示屏和/或所述从显示屏接收应用程序交互请求；
[0011]
将所述应用程序交互请求发送至相应的应用程序，使相应的应用程序确定要发送的第一界面内容和/或第二界面内容。
[0012]
可选地，所述方法还包括：
[0013]
在多个应用程序需要使用所述从显示屏的情况下，根据预设的优先级确定各应用程序对所述从显示屏的使用权限。
[0014]
可选地，所述根据预设的优先级确定各应用程序对所述从显示屏的使用权限包括：
[0015]
接收到第一应用程序对从显示屏的使用请求；
[0016]
若第一应用程序的优先级不低于当前使用从显示屏的第二应用程序的优先级，则
告知第一应用程序具有对所述从显示屏的使用权限，以及告知第二应用程序不再具有对所述从显示屏的使用权限，以使第一应用程序发送第二界面内容，使第二应用程序不再发送第二界面内容；
[0017]
若第一应用程序的优先级低于当前使用从显示屏的第二应用程序的优先级，则告知第一应用程序不具有对所述从显示屏的使用权限，以继续接收第二应用程序发送的第二界面内容。
[0018]
可选地，所述根据预设的优先级确定各应用程序对所述从显示屏的使用权限还包括：
[0019]
根据接收到的应用程序对从显示屏的使用请求、应用程序的运行状态以及预设的优先级，维护从显示屏的需求表；
[0020]
若当前使用从显示屏的第二应用程序停止运行，则根据所述需求表确定具有从显示屏使用权限的应用程序。
[0021]
可选地，所述应用程序为部署在车载系统中的应用程序和/或部署在外部终端设备中的应用程序。
[0022]
可选地，所述方法还包括：
[0023]
与外部终端设备建立数据通道，通过所述数据通道接收部署在外部终端设备中的应用程序发送的第一界面内容和/或第二界面内容，以及通过所述数据通道向部署在外部终端设备中的应用程序反馈通过所述主显示屏和/或所述从显示屏接收的应用程序交互请求。
[0024]
依据本申请的第二方面，提供了一种车载系统的多屏显示装置，所述车载系统的中控屏包括主显示屏和从显示屏，所述装置包括：
[0025]
界面内容接收单元，用于通过主显示屏接口接收第一界面内容，以及通过投屏接口接收第二界面内容；
[0026]
界面内容显示单元，用于在所述主显示屏中显示所述第一界面内容，以及以投屏形式在所述从显示屏中显示第二界面内容；
[0027]
所述第一界面内容和所述第二界面内容来源于同一应用程序或来源于不同的应用程序。
[0028]
依据本申请的第三方面，提供了一种车载系统，包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行如上述任一所述的车载系统的多屏显示方法。
[0029]
依据本申请的第四方面，提供了一种计算机可读存储介质，其中，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被处理器执行时，实现如上述任一所述的车载系统的多屏显示方法。
[0030]
由上述可知，本申请的技术方案的有益效果是：传统的车载系统中的中控屏仅包括一个显示屏，即主显示屏，本申请实施例的车载系统的中控屏包括主显示屏和从显示屏，即额外增加了一个显示屏，作为从显示屏，主要用于投屏显示更多的扩展信息。本申请实施例的车载系统的多屏显示方法先通过主显示屏接口接收第一界面内容，通过投屏接口接收第二界面内容；然后在主显示屏中显示第一界面内容，并以投屏形式在从显示屏中显示第二界面内容；这里的第一界面内容和第二界面内容可以是来源于同一应用程序的界面内
容，也可以是来源于不同的应用程序的界面内容。本申请实施例的车载系统的多屏显示方法通过主显示屏接口和投屏接口可以分别在主显示屏和从显示屏上显示同一应用程序的不同界面，或者不同应用程序的不同界面，使得用户对于车载系统的使用更加方便和智能，大大提高用户的使用体验，同时该方法对于系统底层改动较小，改造复杂度和改造成本均较低。
[0031]
上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。
附图说明
[0032]
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
[0033]
图1示出了根据本申请一个实施例的车载系统的整体框架示意图；
[0034]
图2示出了根据本申请一个实施例的车载系统的多屏显示方法的流程示意图；
[0035]
图3示出了根据本申请一个实施例的车载系统的多屏显示方法的流程框图；
[0036]
图4示出了根据本申请另一个实施例的车载系统的多屏显示方法的流程框图；
[0037]
图5示出了根据本申请一个实施例的车载系统的多屏显示装置的结构示意图；
[0038]
图6示出了根据本申请一个实施例的车载系统的结构示意图；
[0039]
图7示出了根据本申请一个实施例的计算机可读存储介质的结构示意图。
具体实施方式
[0040]
下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。
[0041]
如图1所示，提供了本申请实施例的一种车载系统的整体框架示意图，本申请实施例的车载系统由上至下主要包括以下几层结构：屏幕显示层、多屏显示控制层、应用程序层、操作系统和底层驱动层，屏幕显示层主要包括主显示屏和从显示屏。现有的基于安卓系统的显示原理主要是应用程序层负责界面绘制，操作系统层负责界面渲染，通过进程间通信把应用程序层需要绘制的数据传递给操作系统层，操作系统层通过刷新机制把数据更新到屏幕上。本申请的多屏显示控制层通过对现有的车载系统的操作系统层进行适当改造就可以得到，具体方法是接收应用程序层传递过来的数据，并将数据显示到主显示屏和从显示屏上。该过程无需对系统层做出大量的改造就可以实现。
[0042]
传统的车载系统中的中控屏仅包括一个显示屏，即主显示屏，本申请在此基础上额外增加了一个显示屏，作为从显示屏，主要用于扩展信息的显示，主显示屏和从显示屏分别通过各自的接口与多屏显示控制层连接。屏幕显示层位于与用户交互的最前端，可以接收用户在主显示屏或从显示屏上的操作事件，然后发送至操作系统和底层驱动层，底层驱动层将用户的操作事件或者其它外部事件上报给应用程序层中对应的app，再由该app根据
操作事件以及app的内部逻辑确定或更新要显示的界面等，之后将要显示的界面发送至多屏显示控制层，多屏显示控制层设置有用于实现多屏显示的接口，通过多屏显示控制层的接口可以将要显示的界面显示在主显示屏和从显示屏上，整个流程形成一个闭环。
[0043]
一般的汽车操作系统按照对底层操作系统改造程度的不同，主要可以分为以下几种：
[0044]
1)基础型操作系统：打造全新底层操作系统和所有系统组件，如系统内核、底层驱动等，有的还包括虚拟机，如qnx、linux、wince等。因打造全新操作系统需要花费太大的人力、物力，目前基本不会全新开发底层操作系统。
[0045]
2)定制型操作系统：在基础型操作系统之上进行深度定制化开发，如修改内核、硬件驱动、运行时环境、应用程序框架等。
[0046]
3)rom(read-only memory，只读内存)型汽车操作系统：基于linux或安卓等基础型操作系统进行有限的定制化开发，不涉及系统内核更改，一般只修改更新操作系统自带的应用程序等。
[0047]
本申请的操作系统即主要基于rom型汽车操作系统来实现，对于操作系统的改造程度较小，改造复杂度和改造成本均较低。
[0048]
基于此，本申请实施例提供了一种车载系统的多屏显示方法，所述车载系统的中控屏包括主显示屏和从显示屏，如图2所示，本申请实施例的车载系统的多屏显示方法包括如下的步骤s210至步骤s220：
[0049]
步骤s210，通过主显示屏接口接收第一界面内容，以及通过投屏接口接收第二界面内容。
[0050]
本申请实施例首先针对主显示屏设计了主显示屏接口，针对从显示屏设计了投屏接口，进而可以为在主显示屏和从显示屏上显示界面内容提供一个传输通道，使得不同的应用程序均可以实现多屏显示的功能。这里针对主显示屏和从显示屏分别设置接口的目的是便于对主显示屏和从显示屏显示的界面内容进行单独控制和管理，进而可以满足用户更多更丰富的使用需求。
[0051]
步骤s220，在所述主显示屏中显示所述第一界面内容，以及以投屏形式在所述从显示屏中显示第二界面内容；所述第一界面内容和所述第二界面内容来源于同一应用程序或来源于不同的应用程序。
[0052]
如图3所示，提供了一种车载系统的多屏显示方法的流程框图。在通过主显示屏接口接收到第一界面内容，以及通过投屏接口接收到第二界面内容后，可以相应地在主显示屏中显示第一界面内容，以及以投屏形式在从显示屏中显示第二界面内容。这里的第一界面内容和第二界面内容可以是来源于同一应用程序的界面内容，也可以是来源于不同的应用程序的界面内容，即使是来源于同一应用程序，可以是同一应用程序的不同界面内容。投屏形式就是通过某种方式将一个终端设备a(如手机、平板、笔记本、电脑)的画面“实时地”显示到另一个终端设备b的屏幕上(如平板、笔记本、电脑、电视、一体机、投影仪)，输出的内容包括各类媒体信息和实时操作画面。本申请实施例由于采用投屏方式进行多屏显示，相比于现有的分屏显示方案来说，本身对于底层的操作系统改造程度就较小，因此可以在实现显示更多扩展信息的同时降低系统的改造复杂度和改成成本。
[0053]
在将第一界面内容显示在主显示屏上，以及以投屏形式将第二界面内容显示在从
显示屏上时，可以第一界面内容和第二界面内容进行区分，这里主要由应用程序本身根据其内部的业务逻辑确定要在哪个显示屏上显示哪些界面内容。具体地可以根据投屏的交互协议规定主显示屏id和从显示屏id，第一界面内容或第二界面内容等投屏数据在发送的时候会携带有包含主显示屏id和从显示屏id的协议字段，通过该协议字段中的主显示屏id和从显示屏id进而可以确定当前接收到的投屏数据是主显示屏的数据还是从显示屏的数据。
[0054]
举例说明，车载系统中通常配置有导航app等，当用户在主显示屏上打开导航app时，会在主显示屏上显示导航app的主界面，当用户在导航app的主界面上选好导航地点并开启导航后，导航app会基于其内置的逻辑生成带有导航路线的界面，然后将带有导航路线的界面通过投屏接口投屏到从显示屏上进行显示，这里主要是基于车载系统本身的自动投屏逻辑实现的。
[0055]
如前所述，主显示屏和从显示屏位于与用户交互的最前端，因此在本申请一个实施例中，用户可以通过在主显示屏和从显示屏上的操作事件触发对任意一个应用程序的交互请求，主显示屏和从显示屏在接收到应用程序交互请求后，会根据应用程序交互请求中携带的应用程序标识将该应用程序交互请求发送至对应的应用程序，这样可以使得应用程序可以根据其内部逻辑对用户的操作事件做出响应，进而确定要反馈的第一界面内容和第二界面内容。
[0056]
在实际的应用场景下，可能会存在用户在多个应用程序之间进行切换使用的情况，这样从显示屏就可能面临着要在多个应用程序中选择所要显示的应用程序的界面内容的问题。为了保证用户的使用体验，在本申请一个实施例中，事先设置了不同应用程序使用从显示屏的优先级，优先级越高，说明对从显示屏的使用权限越高，越可以优先使用从显示屏，反之则对从显示屏的使用权限越低。在出现多个应用程序都需要使用从显示屏的情况下，就可以根据设定好的优先级确定哪个应用程序当前拥有对从显示屏的使用权限。
[0057]
需要说明的是，上述设定好的优先级可以是用户根据自己的实际需求事先设置好的，也可以是车载系统根据用户日常对各应用程序的使用情况为用户推荐设置的优先级，本领域技术人员也可根据实际情况灵活设置优先级，在此不作具体限定。
[0058]
在本申请一个实施例中，在根据预设的优先级确定各应用程序对从显示屏的使用权限时，可以先接收第一应用程序对从显示屏的使用请求，这里的使用请求可以理解为是第一应用程序想要将其界面内容投屏显示到从显示屏上的请求。之后根据该使用请求中所携带的应用程序标识，将对应的第一应用程序与当前正在使用从显示屏的第二应用程序进行优先级的比较。
[0059]
如果第一应用程序的优先级不低于第二应用程序的优先级，则告知第一应用程序拥有对从显示屏的使用权限，同时告知第二应用程序不再具有对从显示屏的使用权限，这样可以使得第一应用程序可以通过投屏接口发送第二界面内容，使得第二应用程序不再发送第二界面内容；如果第一应用程序的优先级低于当前正在使用从显示屏的第二应用程序的优先级，则告知第一应用程序不具有对从显示屏的使用权限，以继续接收第二应用程序发送的第二界面内容。当然，需要说明的是，虽然第一应用程序不具有对从显示屏的使用权限，但并不影响用户在主显示屏上对第一用程序的正常使用。
[0060]
举例说明，假设当前正在使用从显示屏的应用程序为导航app，如果用户在主显示屏上将导航app退出到后台运行，启动了本地音乐app，此时就会触发本地音乐app对从显示
屏的使用请求，这时需要判断是否要将从显示屏上显示的导航app的导航路线界面切换为本地音乐app的界面内容。通过调用预设的优先级发现，本地音乐app对从显示屏使用的优先级低于导航app对从显示屏使用的优先级，说明本地音乐app的界面内容当前不能投屏到从显示屏上，从显示屏仍然保留对导航app的导航路线界面的显示，以保证用户能够正常查看导航路线。当然，需要说明的是，虽然本地音乐app不具有对从显示屏的使用权限，但并不影响用户在主显示屏上对本地音乐app的正常使用。
[0061]
在实际的应用场景下，用户在车载系统中可能会使用到多个应用程序，为了便于管理以及提高多屏显示的效率，在本申请的一个实施例中，可以事先配置一个需求表来维护不同应用程序对从显示屏的使用。具体可以从以下三个维度来维护：一是是否有接收到应用程序对从显示屏的使用请求，这里主要针对的情况是当前已经有一个应用程序正在使用从显示屏，如果用户在主显示屏上又开启另一个应用程序，这时就不再是直接自动投屏的方式，而是会先触发后开启的这个应用程序对从显示屏的使用请求，再进一步判断这个后开启的应用程序是否可以使用从显示屏；二是该应用程序的运行状态，应用程序的运行状态可以包括应用程序在主显示屏或者从显示屏上是正在运行的状态还是停止运行的状态等，如果应用程序在主显示屏上是正在运行的状态，还进一步包括应用程序在主显示屏上是在前台运行的状态还是在后台运行的状态。三是针对各应用程序对从显示屏的使用权限而设置的优先级。
[0062]
如果当前使用从显示屏的第二应用程序停止运行，说明当前没有应用程序占用从显示屏，此时可以根据上述需求表来确定对从显示屏具有使用权限的其他应用程序，以接收将该应用程序的界面内容，并在从显示屏上进行显示。
[0063]
举例说明，假设当前使用从显示屏为导航app，导航路线结束后，导航路线的界面会从从显示屏上自动退出，或者用户也可以随时手动关闭从显示屏上的导航路线界面(前提是从显示屏上的导航路线界面本身提供了关闭按钮)，需要说明的是，导航路线的界面在从显示屏上的退出或关闭并不会影响用户在主显示屏上对导航app的正常使用。导航路线的界面退出或关闭后，此时从显示屏的使用状态处于空缺的状态，因此可以从需求表中确定接下来要投屏显示的应用程序的界面内容，如果需求表中显示有接收到本地音乐app以及其他app对从显示屏的使用请求，且本地音乐app相比于其他发起对从显示屏的使用请求的应用程序来说，具有更高的优先级，则可以在从显示屏上对本地音乐app的界面内容进行投屏显示。当然，如果此时仅接收到本地音乐app对从显示屏的使用请求，则可以不用进行优先级的比较。
[0064]
在本申请一个实施例中，上述第一应用程序和第二应用程序可以均为部署在车载系统中的内置的应用程序，也可以均为部署在外部终端设备中的应用程序，或者也可以一个为部署在车载系统中的内置的应用程序，另一个为部署在外部终端设备中的应用程序。
[0065]
需要说明的是，如果应用程序为部署在外部终端设备中的应用程序，默认该外部终端设备中的应用程序支持多屏显示。
[0066]
也就是说，本申请实施例的车载系统的多屏显示方法不局限于将车载系统本身的内置app进行投屏显示，还可以将其它的外部终端设备如手机、平板电脑等设备中的app与车载系统进行连接，以将外部终端设备中的app的界面投屏显示到车载系统的显示屏上，为用户提供了更丰富的投屏选择，大大提高了用户对车载系统的使用体验。
[0067]
在本申请一个实施例中，如果应用程序为部署在外部终端设备中的应用程序，可以先与外部终端设备建立一个用于数据传输和交互的数据通道，通过该数据通道可以接收到部署在外部终端设备中的应用程序发送的第一界面内容和/或第二界面内容，通过该数据通道还可以向部署在外部终端设备中的应用程序反馈通过主显示屏和从显示屏接收的应用程序交互请求。外部终端设备中的应用程序在向车载终端传送第一界面内容和/或第二界面内容时，可以根据外部终端设备中的投屏交互协议确定主显示屏id和从显示屏id，第一界面内容或第二界面内容等投屏数据在发送的时候会携带有包含主显示屏id和从显示屏id的协议字段，进而可以通过该协议字段中的主显示屏id和从显示屏id确定当前接收到的投屏数据是主显示屏的数据还是从显示屏的数据。
[0068]
具体实施时，本申请实施例的数据通道可以看作是由多个分担不同功能的接口所组成的通道，例如，可以包括部署在车载系统中的与外部终端设备的连接交互服务接口，还可以包括部署在外部终端设备中的与车载系统的连接交互服务接口。
[0069]
如图4所示，提供了一种车载系统与外部终端设备进行多屏交互的流程框图。对于车载系统来说，在与外部终端设备进行多屏交互时，可以利用上述与外部终端设备的连接交互服务接口来实现，与外部终端设备的连接交互服务接口主要用于实现对外部终端设备的发现、连接和控制管理，以及投屏数据的通信等功能。
[0070]
上述对外部终端设备的发现主要是指发现可连接的外部终端设备，只有在发现有可连接的外部终端设备的情况下，才能将该外部终端设备与车载系统进行连接，因此可以通过一套设备发现协议来实现交互。
[0071]
对外部终端设备的连接主要是指将外部终端设备和车载系统直接进行连接，建立起外部终端设备和车载系统之间进行数据通信的通道。具体地，在发现外部终端设备之后，可以向外部终端设备发送连接请求，将外部终端设备和车载系统建立多个音视频的socket(端口)连接。连接的方式可以包括无线和有线两种，有线连接可以采用usb接口，然后通过aoa(android open accessory protocol，一种用于实现android设备与外围设备之间usb通信的协议)或ncm(network control model，网络控制模型)等协议将usb接口转换成网络接口；无线连接是在车载系统启动wifi的ap(access point，接入点)模式下，外部终端设备可以接入车载系统的网络，从而形成一个局域网。
[0072]
对外部终端设备的交互主要是指在外部终端设备和车载系统连接成功之后，实现二者之间的交互通信，比如操作事件的交互，投屏数据的接收和反馈等。
[0073]
对于外部终端设备来说，在与车载系统进行多屏交互时，可以利用上述与车载系统的连接交互服务接口来实现，用于与车载系统实现通信，负责连接、控制以及投屏数据的收发，还可以与外部终端设备中支持多屏显示的应用程序实现交互，将外部终端设备中的应用程序的投屏数据，通过与车载系统的连接交互服务接口传输给车载终端，从而实现车载系统的多屏显示。也就是说，外部终端设备中的应用程序能否支持多屏显示的功能，主要依赖于外部终端设备中的与车载系统的连接交互服务接口。
[0074]
需要说明的是，本申请实施例的从显示屏的数量不限于一个，可以有两个或者两个以上的从显示屏进行扩展内容的显示，不同的从显示屏均有自己唯一的id标识，在进行投屏显示时，可以根据投屏数据中携带的id标识确定在哪一个从显示屏上显示相应的界面内容。
[0075]
本申请实施例提供了一种车载系统的多屏显示装置500，所述车载系统的中控屏包括主显示屏和从显示屏，如图5所示，所述车载系统的多屏显示装置500包括：界面内容接收单元510和界面内容显示单元520，其中：
[0076]
界面内容接收单元510，用于通过主显示屏接口接收第一界面内容，以及通过投屏接口接收第二界面内容；
[0077]
界面内容显示单元520，用于在所述主显示屏中显示所述第一界面内容，以及以投屏形式在所述从显示屏中显示第二界面内容；
[0078]
所述第一界面内容和所述第二界面内容来源于同一应用程序或来源于不同的应用程序。
[0079]
在本申请一个实施例中，所述装置还包括：交互请求接收单元，用于通过所述主显示屏和/或所述从显示屏接收应用程序交互请求；交互请求发送单元，用于将所述应用程序交互请求发送至相应的应用程序，使相应的应用程序确定要发送的第一界面内容和/或第二界面内容。
[0080]
在本申请一个实施例中，所述装置还包括：使用权限确定单元，用于在多个应用程序需要使用所述从显示屏的情况下，根据预设的优先级确定各应用程序对所述从显示屏的使用权限。
[0081]
在本申请一个实施例中，所述使用权限确定单元具体用于：接收到第一应用程序对从显示屏的使用请求；若第一应用程序的优先级不低于当前使用从显示屏的第二应用程序的优先级，则告知第一应用程序具有对所述从显示屏的使用权限，以及告知第二应用程序不再具有对所述从显示屏的使用权限，以使第一应用程序发送第二界面内容，使第二应用程序不再发送第二界面内容；若第一应用程序的优先级低于当前使用从显示屏的第二应用程序的优先级，则告知第一应用程序不具有对所述从显示屏的使用权限，以继续接收第二应用程序发送的第二界面内容。
[0082]
在本申请一个实施例中，所述使用权限确定单元具体用于：根据接收到的应用程序对从显示屏的使用请求、应用程序的运行状态以及预设的优先级，维护从显示屏的需求表；若当前使用从显示屏的第二应用程序停止运行，则根据所述需求表确定具有从显示屏使用权限的应用程序。
[0083]
在本申请一个实施例中，所述装置还包括：外部连接单元，用于与外部终端设备建立数据通道，通过所述数据通道接收部署在外部终端设备中的应用程序发送的第一界面内容和/或第二界面内容，以及通过所述数据通道向部署在外部终端设备中的应用程序反馈通过所述主显示屏和/或所述从显示屏接收的应用程序交互请求。
[0084]
需要说明的是，上述各装置实施例的具体实施方式可以参照前述对应方法实施例的具体实施方式进行，在此不再赘述。
[0085]
需要说明的是：
[0086]
在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。
[0087]
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0088]
类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。
[0089]
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0090]
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0091]
本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本申请实施例的远程交互方法中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0092]
例如，图6示出了根据本申请一个实施例的车载系统的结构示意图。该车载系统600包括处理器610和被安排成存储计算机可执行指令(计算机可读程序代码)的存储器620。存储器620可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。存储器620具有存储用于执行上述方法中的任何方法步骤的计算机可读程序代码631的存储空间630。例如，用于存储计算机可读程序代码的存储空间630可以包括分别用于实现上面的方法中的各种步骤的各个计算机可读程序代码631。计算机可读程序代码631可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(cd)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为例如图7所示的计算机可读存储介质。图7示出了根据本申请一个实施例的一种计算机可读存储介质的结构示意图。该计算机可读存储介
质700存储有用于执行根据本申请的方法步骤的计算机可读程序代码631，可以被车载系统600的处理器610读取，当计算机可读程序代码631由车载系统600运行时，导致该车载系统600执行上面所描述的方法中的各个步骤，具体来说，该计算机可读存储介质存储的计算机可读程序代码631可以执行上述任一实施例中示出的方法。计算机可读程序代码631可以以适当形式进行压缩。
[0093]
应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。