本申请涉及计算机技术领域，尤其涉及一种应用运行方法及装置。
背景技术：
随着移动通信技术的飞速发展和移动多媒体时代的到来，手机作为人们必备的移动通信工具，已从简单的通话工具向智能化发展，演变成一个移动的个人信息收集和处理平台。借助操作系统和丰富的应用软件，智能手机成了一台移动终端。
为了方便用户使用，将一些应用进行外化，比如在智能手机的操作界面上展示一些应用的相关数据(比如天气情况等)，是目前业界关注的问题。
申请内容
本申请实施例提供了一种应用运行方法及装置。
本申请实施例提供的应用运行方法，包括：
第一应用触发第二应用；
所述第一应用接收运行中的所述第二应用发送的数据；
所述第一应用将所述数据展示在所述第一应用的用户界面中设定的可视化区域。
本申请实施例提供的应用运行装置，所述应用运行装置用于实现第一应用的功能，包括：处理模块和接口模块，所述处理模块中包括触发单元和展示单元；
所述触发单元，用于触发第二应用；
所述接口模块，用于接收运行中的所述第二应用发送的数据；
所述展示单元，用于将所述数据展示在所述第一应用的用户界面中设定的可视化区域。
本申请实施例提供的通信装置，包括：
存储器，用于存储计算机程序指令；
处理器，耦合到所述存储器，用于读取所述存储器存储的计算机程序指令，并作为响应，执行前述实施例提供的方法。
本申请实施例提供的通信装置，包括：一个或多个处理器；以及一个或多个计算机可读介质，所述可读介质上存储有指令，所述指令被所述一个或多个处理器执行时，使得所述通信装置执行前述实施例提供的方法。
本申请另一实施例提供的应用运行方法中，第一应用提供有用户界面，所述用户界面中包括第一可视化区域以及第二可视化区域，所述第一可视化区域用于显示第一应用的数据；所述应用运行方法包括：
所述第一应用触发第二应用，并接收运行中的所述第二应用发送的数据；
所述第一应用刷新所述第一应用的用户界面，所述第二应用的数据被展示在所述用户界面的第二可视化区域。
本申请另一实施例提供的应用运行装置，所述应用运行装置用于实现第一应用的功能，第一应用提供有用户界面，所述用户界面中包括第一可视化区域以及第二可视化区域，所述第一可视化区域用于显示第一应用的数据；所述应用运行装置包括：
逻辑处理单元，用于触发第二应用，并接收运行中的所述第二应用发送的数据；
界面处理单元，用于刷新所述第一应用的用户界面，所述第二应用的数据被展示在所述用户界面的第二可视化区域。
本申请另一实施例提供的通信装置，包括：
存储器，用于存储计算机程序指令；
处理器，耦合到所述存储器，用于读取所述存储器存储的计算机程序指令，并作为响应，执行前述实施例提供的方法。
本申请另一实施例提供的通信装置，包括：一个或多个处理器；以及一个或多个计算机可读介质，所述可读介质上存储有指令，所述指令被所述一个或多个处理器执行时，使得所述通信装置执行前述实施例提供的方法。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例中的page间信息传递的示意图；
图2为本申请实施例中第一应用的ui中的可视化区域的示意图；
图3为本申请实施例中的应用触发流程示意图；
图4为本申请实施例中卡片模式示意图；
图5为本申请实施例中widget模式示意图；
图6为本申请实施例中超级widget模式示意图；
图7为本申请实施例中的第二应用生命周期示意图；
图8为本申请实施例提供的应用运行装置的结构示意图；
图9为本申请另一实施例提供的应用运行装置的结构示意图；
图10为本申请实施例提供的通信设备的结构示意图。
具体实施方式
虽然本申请的概念易于进行各种修改和替代形式，但是其具体实施例已经通过附图中的示例示出并且将在本文中详细描述。然而，应当理解，没有意图将本申请的概念限制为所公开的特定形式，而是相反，意图是覆盖与本申请以及所附权利要求一致的所有修改、等同物和替代物。
说明书中对“一个实施例”、“实施例”、“说明性实施例”等的引用，指示所描述的实施例可包括特定特征、结构或特性，但是每个实施例可以或可以不必包括特定特征、结构或特性。此外，这样的短语不一定指的是相同的实施例。进一步地，认为在本领域技术人员的知识范围内，当结合实施例描述特定特征、结构或特性时，结合无论是否明确描述的其它实施例影响这样的特征，结构或特性。另外，应当理解，以“a，b和c中的至少一个”的形式包括在列表中的项目可以表示(a)；(b)；(c)；(a和b)；(a和c)；(b和c)；或(a，b和c)。类似地，以“a，b或c中的至少一个”的形式列出的项目可以表示(a)；(b)；(c)；(a和b)；(a和c)；(b和c)或(a，b和c)。
在一些情况下，所公开的实施例可以在硬件、固件、软件或其任何组合中实现。所公开的实施例还可以被实现为由一个或多个暂时性或非暂时性机器可读(例如，计算机可读)存储介质携带或存储的指令，其可以由一个或多个处理器读取和执行。机器可读存储介质可以体现为用于以机器可读形式(例如，易失性或非易失性存储器、介质盘或其他介质)存储或传输信息的任何存储设备，机制或其他物理结构的设备)。
在附图中，一些结构或方法特征可以以特定布置和/或顺序示出。然而，应当理解，可能不需要这样的具体布置和/或排序。相反，在一些实施例中，这些特征可以以与说明性附图中所示不同的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示这种特征在所有实施例中都是需要的，并且在一些实施例中可以不包括或可以与其他特征组合。
本申请实施例中的“应用”，可以理解为能够实现一定功能的程序，具体可包括应用程序或组件等。其中，应用程序可包括系统应用程序、可下载安装的应用程序(比如第三方应用程序)、前台程序或后台服务等。组件是指对数据和方法的封装，一个应用程序通常由多个组件组成，各个组件协同合作，共同组成一个完整的应用程序的功能。也就是说，组件是比应用程序粒度更小的运行单位。
本申请实施例中，为了让用户直观地了解应用的内容或便捷地使用该应用提供的服务，为该应用提供了可以借助其他应用展现其概要内容的能力。例如，应用a可触发应用b，从而将应用b的相关信息(比如应用b的数据)在应用a的用户界面(userinterface，ui)中展示。为了描述方便，本申请实施例中，用于触发其他应用的应用被称为第一应用，相对应地，其他可被第一应用触发的应用(比如上述例子中的应用b)被称为第二应用。
其中，“第一应用触发第二应用”可包括多种情况。比如，第二应用可能尚未运行(即尚未有第二应用的实例(instance))，第二应用也可能已经创建有一个或多个实例。如果第二应用尚未创建有实例，则第一应用可创建第二应用的实例，从而触发第二应用运行；如果第二应用已经创建有实例，则第一应用可与第二应用的实例进行交互，以获取第二应用的数据，当然第一应用也可以再创建一个第二应用的实例，通过与该实例进行交互以获取第二应用的数据。
本申请实施例可应用于多种操作系统，比如移动操作系统，尤其是云操作系统(yunos)。在云操作系统中，page称为服务组件，是对本地服务和远程服务的抽象，也即服务的基本单元，通过对数据和方法的封装，可以提供各种服务。运行态page称为page实例，是本地服务或远程服务的运行载体，可由动态page管理服务(dynamicpagemanagerservice，dpms)创建(比如dpms收到pagea发送的指向pageb的pagelink后可创建pageb的实例)、调度、管理，dpms可维护page实例的生命周期。一个page可以在云操作系统中被唯一标识，比如可以使用唯一资源标识符(uniformresourceidentifier，uri)对page进行标识。不同的page可属于同一域，也可属于不同的域。page之间可以传递事件和/或数据，page可以通过用户界面(userinterface，ui)与用户进行交互，以提供服务。如图1所示，pagea和pageb为两个不同的page，pagea可以提供服务a，pageb可以提供服务b。pagea可以以ui方式向用户提供用户界面，通过该用户界面为用户展示服务以及接收用户的各种输入，pageb可以主要在后台运行，可以为其他page提供服务支持。pagea可以向pageb发送事件(event)，并从pageb获取返回的数据(data)，pagea可以通过ui与用户交互。
当然，本申请实施例也可以应用于非云操作系统，这种情况下，第一应用和第二应用可以是符合应用规范的非云操作系统的应用，比如android系统中的activity。
第一应用可以通过ui与用户进行交互，比如以ui方式向用户提供用户界面，通过该用户界面为用户展示服务以及接收用户的各种输入。第一应用可包括多种类型，比如智能移动终端中的锁屏应用、搜索应用分别为两种不同的第一应用。不同的第一应用可在不同场景下启动。作为一个例子，锁屏应用可在智能移动终端在锁屏状态下启动，锁屏应用可触发用于显示时钟的第二应用以及用于显示天气情况的第二应用，这样，在锁屏应用的ui上可展示时间以及天气情况信息。作为另一个例子，搜索应用可在用户选择打开相应应用(比如信息搜索应用)时被启动，在对应的ui中可包括搜索输入框以及搜索按钮，当用户在搜索输入框中输入搜索关键字后，搜索应用可触发与该搜索关键字相关的第二应用，这样，搜索应用的ui上可展示所触发的第二应用相关的信息(比如该第二应用从网络侧服务器获取到的数据)。
本申请实施例中，第一应用可对第二应用进行管理，比如，第一应用可确定在何种时机触发何种第二应用，第一应用还可触发对第二应用的生命周期(比如创建、销毁)进行管理。第二应用可基于自身的逻辑将数据传递给第一应用进行展示。一个第一应用可触发一个或多个第二应用。
为了在第一应用的ui中展示所触发的第二应用的数据，在第一应用的ui中可包括第二应用对应的可视化区域，用于展示第二应用的数据。当一个第一应用可触发多个第二应用时，第一应用的ui中，针对每个第二应用均设置有对应的可视化区域，用于展示相应第二应用的数据。在一个第一应用可触发多个第二应用的情况下，在第一应用的ui上，不同的第二应用所对应的可视化区域可以彼此不同，这样，当第一应用触发多个第二应用运行的情况下，每个被触发的第二应用的数据可在第一ui的不同可视化区域进行展示，不会造成冲突。在另外的例子中，第一应用可触发多个第二应用，但不会出现多个第二应用同时运行的情况，这种情况下，这些不会同时运行的第二应用可共享使用第一应用的ui中的同一个可视化显示区域。
图2示例性地示出了一种第一应用的ui中的可视化区域的示意图。如图2所示，第一应用的ui中包括可视化区域201和可视化区域202。该第一应用中触发用于提供时间信息和天气情况的第二应用1以及用于提供搜索到的快递订单信息的第二应用2。其中，可视化区域201可显示第二应用1所提供的时间信息和天气情况的数据，可视化区域202可显示搜索到的快递订单信息。当第一应用被启动时，第二应用1被触发运行，可视化区域201中显示第二应用1提供的时间信息和天气情况信息；当用户在搜索输入框203输入“快递单”后，第二应用2被触发运行，可视化区域202中显示第二应用2提供的快递订单信息。当然，第一应用的ui中也可包括用于展示第一应用的数据的可视化区域。
在本申请的一些实施例中，第二应用可包括以下组成部分：
-显示模板：用于定义数据的显示方式以及样式。比如，第二应用获取到的数据以文本方式显示还是以动画方式显示；再比如，在第一应用的ui中的可视化区域中，所显示的文本的字体大小、颜色，该可视化区域的背景色等。
-数据：第二应用的显示内容，可由第二应用提供，也可由服务端提供。作为由第二应用提供数据的例子，终端本地的时钟组件可被作为第二应用被第一应用触发，为第一应用提供时间信息，并在第一应用的ui中展示；作为由服务端提供数据的例子，用于提供快递订单信息的第二应用可根据用户账户等信息查询网络侧的服务器，获取对应的快递订单信息并提供给第一应用，以在第一应用的ui中展示。
-逻辑：即逻辑代码(或称程序代码)，用于定义第二应用的逻辑处理过程，具体可定义第二应用的数据的生成过程，与用户交互的行为等。第二应用的逻辑可运行在第二应用端，也支持在第一应用中运行一些受限的程序代码。
图3示例性地示出了本申请实施例提供的一种应用使用流程。图3描述了第一应用触发第二应用，并在第一应用的ui中展示第二应用的数据的过程。在图3所示的s301中，第一应用确定第二应用。在s302中，第一应用触发s301中确定出的第二应用。应用程序可存在不同的状态(比如启动状态(有的例子中也称创建状态)、运行状态(有的例子中也称刷新状态)、暂停状态等)，但通常只有在运行中(即处于运行状态)才能够执行该应用程序的逻辑，比如获取数据、与ui交互等。在s303中，第一应用接收运行中的第二应用的数据。在s304中，第一应用将该数据展示在第一应用的ui中设定的可视化区域。
作为一个例子，第一应用提供信息搜索功能，其ui上包括用于信息搜索的搜索关键字输入框。当用户在该ui中的搜索关键字输入框中输入“天气”后，第一应用确定与该关键字匹配的第二应用为用于获取天气情况信息的第二应用，则第一应用触发该第二应用。该第二应用根据第一应用所在的终端的ip地址，从网络侧服务器获得当前与该ip地址匹配的地区的天气情况信息，并将获取到的天气情况信息发送给第一应用。第一应用将该天气情况信息在其ui中展示。通过该过程，可避免用户输入关键字“天气”后点击搜索按钮以跳转到相应的用于查询天气情况的页面，并基于该页面进行天气情况查询，方便了用户操作，提高了用户感受。
作为另一个例子，当终端内的传感器检测到有用户接近该终端，第一应用被启动。第一应用触发用于对终端进行控制的第二应用a和第二应用b。第二应用a基于操作系统提供的系统服务获取该终端的剩余电量，并将获取到的剩余电量信息发送给第一应用。第二应用b将包含有音量设置、屏幕亮度设置的功能按钮的ui信息发送给第一应用。第一应用根据接收到的数据在其ui上进行展示，其中包括当前剩余电量以及用于音量设置和屏幕亮度设置的功能按钮，从而方便用户对该终端进行设置或控制。
作为另一个例子，当终端内的传感器检测到用户正在运动，且该终端当前处于锁屏状态时，操作系统向锁屏应用(锁屏应用为一种第一应用)发送相应事件。锁屏应用确定在该场景下触发用于获取和显示用户生理参数的第二应用，则锁屏应用触发该第二应用。该第二应用获取用户的生理参数，并发送给第一应用。第一应用在锁屏ui上展示获取到的该用户的生理参数。
进一步地，在一些实施例中，第一应用还可根据获取到的用于刷新数据的事件，触发第二应用重新获取数据，并将第二应用重新获取的数据展示在第一应用的ui中。
进一步地，在一些实施例中，第一应用还可根据获取到的用于暂停第二应用的事件，触发第二应用暂停运行。进一步地，还可以根据获取到的用于恢复暂停第二应用的事件，触发第二应用恢复运行。
进一步地，在一些实施例中，第一应用可根据获取到的用于销毁第二应用的事件，销毁第二应用。
在一些实施例中，在图3所示的s301中，第一应用可在确定满足设定条件时，确定与该设定条件匹配的第二应用，从而可根据实际场景自适应地确定与实际场景匹配的第二应用进行触发。
所述设定条件可包括以下中的一种或多种组合：
-设定的时间到达时，第一应用触发第二应用。例如，在每天早上的7点钟，手机中的操作系统应用触发用于获取天气情况信息的应用，并将天气情况信息显示在操作系统主ui中。
-设定的事件发生时，第一应用触发第二应用。其中，所述设定的事件可包括但不限于：根据用户操作行为生成的事件，比如根据用户在第一应用的ui上的操作行为生成的事件。所述设定的事件还可包括根据第一应用所在的终端的设备状态改变所生成的事件，比如终端进入锁屏状态或者终端进入低电量状态。所述设定的事件还可包括可以根据第一应用所在的终端中的传感器检测的数据生成的事件，比如前述例子中，当传感器检测到有人靠近终端时所生成的事件。
-设定的用户行为习惯。
比如，在设定事件发生时第一应用触发第二应用的一个例子中，第一应用为搜索应用，当所述设定的事件为用户在第一应用的ui上的操作行为所生成的事件。当用户在搜索应用的ui上输入搜索关键字时，搜索应用获取该搜索应用的ui上输入的搜索关键字，并根据该关键字确定与该关键字匹配的第二应用。例如在前述的例子中，当用户在搜索应用的ui中进行了界面操作，比如输入搜索关键字“快递单”，则该搜索应用可触发用于获取并显示快递订单信息的第二应用进行触发。
再例如，在设定事件发生时根据用户行为习惯，第一应用触发第二应用的一个例子中，第一应用为锁屏应用，所述设定的事件为终端的耳机插入事件。当耳机插入终端时，锁屏应用获取耳机插入事件，并可进一步获取用户行为习惯信息，根据获取到的用户行为习惯信息确定在耳机插入事件发生的情况下，符合对应的用户行为习惯的第二应用。比如，当终端的耳机孔插入耳机且终端的传感器检测到终端的使用者正在进行运动时，根据该用户的行为习惯(在运动时播放音乐)，第一应用触发用于播放音乐的第二应用。
当然，上述用于确定需要触发的第二应用的方式可以相互结合使用。上述例子仅示例性地列举了几种可能的用于确定需要触发的第二应用的因素，本申请实施例并不仅限于上述几种例子。
在一些实施例中，可预先设置能够被第一应用触发的第二应用，比如以配置信息或配置文件方式设置可被第一应用触发的第二应用，配置信息或配置文件中可包括可被第一应用触发的第二应用的uri。当然，也可在第一应用的程序代码中定义可被触发的第二应用，比如在第一应用的程序代码中规定在终端的屏幕切换到操作系统主界面时触发显示天气情况的第二应用。这样，上述流程的s301中，第一应用可根据预先的设置确定可触发的第二应用。
本申请实施例中，第一应用可采用多种方式触发第二应用。本申请实施例定义了几种触发模式，触发模式中定义了第二应用的数据在第一应用的ui中的显示方式，以及第二应用的运行方式(比如第二应用是否与第一应用运行于同一进程)。举例来说，本申请实施例定义了以下三种触发模式：
(1)第一触发模式，或称为卡片模式
在卡片模式下，第二应用的显示和逻辑都运行在第一应用中，具体来说，第二应用与第一应用运行于同一进程，并且第二应用的数据显示在第一应用的ui中的主窗口中。为了保证第一应用的安全性，第一应用通常只运行无安全风险的函数(方法)，因此与第一应用运行在同一进程中的第二应用可利用这些资源进行该第二应用的逻辑(比如获取数据的逻辑)，从而保证了第二应用的安全性。另一方面，第二应用的数据所使用的显示模板由描述文件生成，因此第二应用的数据的显示方式可采用该描述文件所支持的控件和动画效果。
对于卡片模式，数据显示是根据卡片规范的描述文件生成，可以执行的javascript代码只包括某些没有安全风险的函数，因此不会对第一应用造成安全漏洞。另外，在卡片模式下，第二应用的逻辑运行在第一应用中，没有进程间通信((inter-processcommunication，ipc)消耗，显示操作也运行在第一应用中，没有额外消耗，因此卡片模式的性能较好。
图4示例性地示出了卡片模式的示意图。其中，第二应用运行在第一应用所在的进程中，与第一应用使用相同的资源，共享相同的运行环境。第二应用的数据显示在第一应用的主窗口中。
(2)第二触发模式，或称为widget模式
在widget模式下，第二应用的数据显示在第一应用的ui的主窗口中，逻辑运行在独立的进程中。具体来说，第二应用与第一应用运行在不同的进程，但第二应用的数据显示在第一应用的ui中的主窗口中。第二应用与第一应用运行在不同的进程，可使用第一应用进程所使用的资源之外的资源，因此可使第二应用的运行更加灵活、逻辑处理功能更强，比如第二应用可从服务器获取数据。另一方面，第二应用的数据所使用的显示模板由描述文件生成，因此第二应用的数据的显示方式可采用该描述文件支持控件和动画效果。
对于widget模式，可以执行的javascript代码不受第一应用的限制，可实现完整的javascript能力。逻辑全部运行在独立的第二应用进程中，第一应用中不会运行任何第二应用的逻辑代码，因此没有安全风险。
图5示例性地示出了widget模式的示意图。其中，第二应用与第一应用运行在不同的进程中，且第二应用的数据显示在第一应用的主窗口中。
(3)第三触发模式，或称超级widget模式
在超级widget模式下，第二应用显示在第一应用中的子窗口中，该子窗口所使用的显示模板可以不基于描述文件生成，比如可以根据需要的显示效果设置显示模板，逻辑运行在独立的进程中。具体来说，第二应用与第一应用运行在不同的进程，并且第二应用的数据显示在第一应用的ui中的子窗口中。第二应用与第一应用运行在不同的进程，可使用第一应用进程所使用的资源之外的资源，因此可避免第一应用的限制，使第二应用的运行更加灵活、逻辑处理功能更强，比如第二应用可从服务器获取数据。另一方面，第二应用的数据的显示由第二应用进程完全控制，因而可以支持所有控件和动画效果，使第二应用的显示方式更加灵活。
对于超级widget模式，可以执行的javascript代码不受第一应用的限制，可实现完整的javascript能力。逻辑全部运行在独立的第二应用进程中，第一应用中不会运行任何第二应用的逻辑代码，因此没有安全风险。在显示能力方面，超级widget模式支持所有控件类型。
图6示例性地示出了超级widget模式的示意图。其中，第二应用与第一应用运行在不同的进程中，且第二应用的数据显示在第一应用的子窗口中。
基于以上几种触发方式的比较结果，可以看出上述几种触发结果在安全性、显示和逻辑能力、性能和资源开销上存在差异，第一应用可根据实际需要选择上述触发方式中的一种进行第二应用的触发和运行。具体实施时，第一应用可在触发第二应用前，确定第二应用的触发方式，然后按照该触发方式对第二应用进行触发。具体地，第一应用可根据以下之一或任意组合确定第二应用的触发模式：
-预设的触发模式：可预先设置第二应用的触发模式，这样，第一应用可根据预设的触发模式对第二应用进行触发。具体实施时，可针对一些类型的第二应用预先设置触发模式。
-第二应用所支持的触发模式：第一应用可根据第二应用所支持的触发模式对该第二应用进行触发。不同的第二应用所支持的触发能力不同，这样，第一应用可采用与第二应用能力相适配的触发模式触发第二应用。如果第二应用支持多种触发模式，则可以预先约定选择触发模式的策略，比如可按照资源开销最小的原则选取。
-第二应用所要求的逻辑能力：第一应用可根据第二应用所要求的逻辑能力来确定第二应用的触发模式。比如，如果需要从网络侧服务器获取数据，则可采用wdget模式或超级widget模式。
-第二应用的数据所要求的显示效果：第一应用可根据第二应用的数据所要求的显示效果，确定第二应用的触发模式。比如，如果对显示效果要求较高(更丰富的显示方式)，则可采用超级widget模式。
-第二应用的数据的显示资源开销要求：第一应用可根据第二应用的数据的显示资源开销的要求，确定第二应用的触发方式。比如，如果要求显示资源开销较小，则采用卡片模式。
基于上述确定触发模式的依据，第一应用在触发第二应用之前可以获取第二应用所支持的能力，然后根据自己的实际情况选择触发模式，举例如下：
例子1：第二应用a支持卡片模式和widget模式，第一应用需要同时触发包括第二应用a在内的多个第二应用，第一应用基于性能的考虑，使用卡片模式来触发第二应用a。
例子2：第二应用b支持widget模式和超级widget模式，第一应用由特定事件触发需要触发第二应用b，第一应用基于显示效果考虑，使用超级widget模式来触发第二应用b。
例子3：第二应用c只支持超级widget模式，但是第一应用期望的模式是卡片模式，这种情况下，第一应用拒绝触发第二应用c。
如前所述，第一应用可触发对第二应用的生命周期进行管理。图7示例性地示出了第二应用生命周期中的各种状态以及状态间的转换示意图。如图所示，第二应用的生命周期可包括：创建(created)状态、刷新(resumed)状态、暂停(paused)状态和销毁(destroyed)状态。可由第一应用触发第二应用的状态切换，应用cover可将状态切换的结果通过事件通知给第一应用。
创建(created)状态：第一应用可通过调用创建应用cover的方法创建第二应用的实例。可选地，如果创建成功，第二应用会自动跳转到刷新(resumed)状态，并将当前状态通过事件通知给第一应用。具体实施时，第一应用可在接收到用于触发触发第二应用的事件后，调用创建第二应用的方法创建第二应用的实例。例如，当用户在搜索应用的ui中的搜索框输入“快递单”时，操作系统生成相应事件并发送给搜索应用，搜索应用根据该事件创建用于获取和显示快递订单信息的第二应用。
刷新(resumed)状态：是第二应用正常工作状态。第一应用可通过调用更新(update)方法来触发第二应用跳转到刷新(resumed)状态。第二应用也可以在第二应用创建成功后自动跳转到刷新(resumed)状态。在具体实施时，第一应用可定时调用更新(update)方法来触发第二应用跳转到刷新(resumed)状态，第一应用也可在接收到用于刷新数据的事件时，调用更新(update)方法来触发第二应用跳转到刷新(resumed)状态。在另外的例子中，刷新(resumed)状态下的第二应用也可以按照自身的逻辑进行刷新，并将刷新(refresh)事件以及刷新得到的数据发送给第一应用，以触发第一应用刷新其ui中该第二应用的数据。
暂停(paused)状态：表现为停止显示刷新和逻辑处理，第一应用可通过调用暂停(pause)方法触发第二应用跳转到暂停(paused)状态。暂停(paused)状态下的第二应用也可被第一应用通过调用恢复暂停的方法跳转到其他状态，比如跳转到刷新(resumed)状态。具体实施时，第一应用可在执行隐藏ui的操作时，调用暂停(pause)方法触发第二应用跳转到暂停(paused)状态。
销毁(destroyed)状态：第一应用可通过调用销毁(destroy)方法触发第二应用跳转到销毁(destroyed)状态。具体实施时，第一应用可在第二应用的逻辑执行完成后，通过调用销毁(destroy)方法触发第二应用跳转到销毁(destroyed)状态。
通过以上描述可以看出，本申请实施例中，第一应用可触发第二应用，以使第二应用的数据在第一应用的ui中展示。进一步地，第一应用可自适应确定需要触发的第二应用，以使所触发的第二应用与实际场景相匹配。
上述各实施例中的第二应用的运行实体可以为应用，也可以支持其他类型的应用接入，只要按照第二应用的生命周期和接口规范实现，被触发的第二应用的数据可在第一应用的ui中显示。
基于相同的技术构思，本申请实施例还提供了一种应用运行装置。参见图8，为本申请实施例提供的应用运行装置的结构示意图。该装置用于实现第一应用的功能，该装置可包括处理模块810、接口模块820，其中，处理模块810中包括触发单元811和展示单元812。
触发单元811用于触发第二应用；接口模块820用于接收运行中的所述第二应用发送的数据；展示单元812用于将所述数据展示在所述第一应用的用户界面中设定的可视化区域。
可选地，触发单元811具体用于：确定满足设定条件时，确定与所述设定条件匹配的第二应用，并触发所述第二应用。
可选地，所述设定条件包括以下中的一种或多种组合：
设定的时间到达；
设定的事件发生；
设定的用户行为习惯。
可选地，所述设定的事件，包括：
根据用户操作行为生成的事件；
根据所述第一应用所在的终端的设备状态改变所生成的事件；
根据所述第一应用所在的终端中的传感器检测的数据生成的事件。
可选地，所述根据用户操作行为生成的事件，包括：根据用户在所述第一应用的用户界面上的操作行为生成的事件。
可选地，触发单元811具体用于：确定所述第二应用的触发模式，根据确定出的触发模式触发所述第二应用。
可选地，所述触发模式包括：
第一触发模式，在所述第一触发模式下，所述第二应用与所述第一应用运行于同一进程，所述数据展示在所述第一应用的主窗口中；
第二触发模式，在所述第二触发模式下，所述第二应用与所述第一应用运行于不同的进程，所述数据展示在所述第一应用的主窗口中；
第三触发模式，在所述第三触发模式下，所述第二应用与所述第一应用运行于不同的进程，所述数据展示在所述第一应用的子窗口中。
可选地，所述第二应用的数量为一个或多个；所述第二应用的数量为多个时，所述第一应用的用户界面中针对每个第二应用设置有可视化区域，一个可视化区域用于展示对应的第二应用获取到的数据。
可选地，不同的第二应用所对应的可视化区域彼此不同；或者，不同时运行的第二应用所对应的可视化区域彼此相同。
基于相同的技术构思，本申请实施例还提供了一种应用运行装置。参见图9，为本申请实施例提供的应用运行装置的结构示意图。所述第一应用提供有用户界面，所述用户界面中包括第一可视化区域以及第二可视化区域，所述第一可视化区域用于显示第一应用的数据；该装置用于实现第一应用的功能，该装置可包括：逻辑处理单元901、展示处理单元902。
逻辑处理单元901，用于触发第二应用，并接收运行中的所述第二应用发送的数据；展示处理单元902，用于刷新所述第一应用的用户界面，所述第二应用的数据被展示在所述用户界面的第二可视化区域。
可选地，逻辑处理单元901具体用于：确定满足设定条件时，确定与所述设定条件匹配的第二应用，并触发所述第二应用。
可选地，所述设定条件包括以下中的一种或多种组合：
设定的时间到达；
设定的事件发生；
设定的用户行为习惯。
可选地，逻辑处理单元901具体用于：确定所述第二应用的触发模式，并根据确定出的触发模式触发所述第二应用，其中，所述触发模式包括：
第一触发模式，在所述第一触发模式下，所述第二应用与所述第一应用运行于同一进程，所述数据展示在所述第一应用的主窗口中；
第二触发模式，在所述第二触发模式下，所述第二应用与所述第一应用运行于不同的进程，所述数据展示在所述第一应用的主窗口中；
第三触发模式，在所述第三触发模式下，所述第二应用与所述第一应用运行于不同的进程，所述数据展示在所述第一应用的子窗口中。
可选地，不同的第二应用所对应的第二可视化区域彼此不同；或者，不同时运行的第二应用所对应的可视化区域彼此相同。
基于相同的技术构思，本申请实施例还提供了一种通信设备1000，该装置1000可实现前述实施例描述的流程。图10示例性地示出了根据各种实施例的示例装置1000。装置1000可包括一个或多个处理器1002，系统控制逻辑1001耦合于至少一个处理器1002，非易失性存储器(non-volatilememory，nmv)/存储器1004耦合于系统控制逻辑1001，网络接口1006耦合于系统控制逻辑1001。
处理器1002可包括一个或多个单核处理器或多核处理器。处理器1002可包括任何一般用途处理器或专用处理器(如图像处理器、应用处理器基带处理器等)的组合。
一个实施例中的系统控制逻辑1001，可包括任何适当的接口控制器，以提供到处理器1002中的至少一个的任何合适的接口，和/或提供到与系统控制逻辑1001通信的任何合适的设备或组件的任何合适的接口。
一个实施例中的系统控制逻辑1001，可包括一个或多个内存控制器，以提供到系统内存1003的接口。系统内存1003用来触发以及存储数据和/或指令。例如，对应装置1000，在一个实施例中，系统内存1003可包括任何合适的易失性存储器。
nvm/存储器1004可包括一个或多个有形的非暂时的计算机可读介质，用于存储数据和/或指令。例如，nvm/存储器1004可包括任何合适的非易失性存储装置，如一个或多个硬盘(harddiskdevice，hdd)，一个或多个光盘(compactdisk，cd)，和/或一个或多个数字通用盘(digitalversatiledisk，dvd)。
nvm/存储器1004可包括存储资源，该存储资源物理上是该系统所安装的或者可以被访问的设备的一部分，但不一定是设备的一部分。例如，nvm/存储器1004可经由网络接口1006被网络访问。
系统内存1003以及nvm/存储器1004可分别包括临时的或持久的指令1010的副本。指令1010可包括当由处理器1002中的至少一个执行时导致装置1000实现图2至图7描述的方法之一或组合的指令。各实施例中，指令1010或硬件、固件，和/或软件组件可另外地/可替换地被置于系统控制逻辑1001，网络接口1006和/或处理器1002。
网络接口1006可包括一个接收器来为装置1000提供无线接口来与一个或多个网络和/或任何合适的设备进行通信。网络接口1006可包括任何合适的硬件和/或固件。网络接口1006可包括多个天线来提供多输入多输出无线接口。在一个实施例中，网络接口1006可包括一个网络适配器、一个无线网络适配器、一个电话调制解调器，和/或无线调制解调器。
在一个实施例中，处理器1002中的至少一个可以与用于系统控制逻辑的一个或多个控制器的逻辑一起封装。在一个实施例中，处理器中的至少一个可以与用于系统控制逻辑的一个或多个控制器的逻辑一起封装以形成系统级封装。在一个实施例中，处理器中的至少一个可以与用于系统控制逻辑的一个或多个控制器的逻辑集成在相同的管芯上。在一个实施例中，处理器中的至少一个可以与用于系统控制逻辑的一个或多个控制器的逻辑集成在相同的管芯上以形成系统芯片。
装置1000可进一步包括输入/输出装置1005,。输入/输出装置1005可包括用户接口旨在使用户与装置1000进行交互，可包括外围组件接口，其被设计为使得外围组件能够与系统交互，和/或，可包括传感器，旨在确定环境条件和/或有关装置1000的位置信息。
本申请实施例还提供了一种通信装置，包括：一个或多个处理器；以及，一个或多个计算机可读介质，所述可读介质上存储有指令，所述指令被所述一个或多个处理器执行时，使得所述通信装置执行前述实施例描述的方法。