CN107766094A - 控制应用程序间相互启动的方法、装置、设备 - Google Patents

Abstract

本申请公开了控制应用程序间相互启动的方法、应用程序间相互启动的方法及装置、设备，控制应用程序间相互启动的方法中，在第一应用程序运行时，唤起控制模块响应所述第一应用程序的调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；如果判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。本申请能够降低对系统资源的消耗。

Description

控制应用程序间相互启动的方法、装置、设备

技术领域

本申请涉及应用程序自启动技术，尤其涉及控制应用程序间相互启动的方法、应用程序间相互启动的方法及装置、设备。

背景技术

许多应用程序之间会发生相互启动(即通过应用程序A唤起应用程序B启动)的动作。通常应用程序A在执行启动应用程序B的动作时，应用程序A需要调用操作系统的API(Application Programming Interface，应用程序接口)来唤起应用程序B。API是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的API而使操作系统去执行应用程序的命令(动作)。通常应用程序A与所调用的API在同一个进程中，而负责拦截检查的校验服务进程在另一个独立的进程中，因此调用API时所启动的进程会通过IPC(Inter-Process Communication，进程间通信)通知校验服务进程进行拦截检查。校验服务进程基于控制策略进行拦截检查的结果如果是允许启动应用程序B，则应用程序B被唤起；相反，如果校验服务进程的拦截检查结果是不允许启动应用程序B，则应用程序B将不被唤起。

由于每次拦截检查均需要经过IPC调用，而在每个时刻均可能发生很多次通过IPC调用校验服务进程的情况，因此应用程序间相互启动的拦截检查不仅占用很多系统资源而且拦截检查的耗时长。

发明内容

本申请提供一种控制应用程序间相互启动的方法、装置、设备，能够降低对系统资源的消耗。

根据本申请实施例的第一方面，提供一种控制应用程序间相互启动的方法，所述方法包括步骤：

在第一应用程序运行时，唤起控制模块响应所述第一应用程序的调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；如果判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

根据本申请实施例的第二方面，提供一种应用程序间相互启动的方法，所述方法包括步骤：

第一应用程序向唤起控制模块发起调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；并在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

根据本申请实施例的第三方面，提供一种控制应用程序间相互启动的装置，所述装置耦合于所述第一应用程序中，该装置包括：

判定模块，用于在第一应用程序运行时，响应所述第一应用程序的调用请求，判断是否允许启动第二应用程序；

处理模块，用于在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

根据本申请实施例的第四方面，提供一种应用程序，包括：

调用模块，用于在第一应用程序运行时，向唤起控制模块发出调用请求，以启动第二应用程序；

唤起控制模块，用于判断是否允许启动第二应用程序；如果所判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

根据本申请实施例的第五方面，提供一种设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

在第一应用程序运行时，唤起控制模块响应所述第一应用程序的调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；如果判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

本申请扩展了第一应用程序的功能，通过唤起控制模块对是否允许启动另一应用程序的调用请求进行过滤，如果不允许启动另一应用程序，则将调用请求过滤。唤起控制模块包含于第一应用程序中，响应第一应用程序的调用请求无需经过IPC调用，由于唤起控制模块已经过滤掉一些调用请求，因此，对于未过滤的调用请求，无论如何处理，均会比传统技术调用IPC的次数降低，因此可以降低系统资源的消耗(例如CPU时间片、内存、电量等资源的消耗)，提高系统性能。

附图说明

图1为本申请实施例中设备的一种逻辑架构图；

图2a为本申请实施例中控制应用程序间相互启动的方法的部分流程图；

图2b为本申请实施例中应用程序间相互启动的方法的部分流程图；

图3a为本申请实施例中设备的另一种逻辑架构图；

图3b为本申请实施例中控制应用程序间相互启动的方法的部分流程图；

图3c为本申请实施例中控制应用程序间相互启动的方法的部分流程图；

图4a为一应用场景中设备的界面状态切换图；

图4b为一应用场景中控制应用程序间相互启动的方法的部分流程图；

图5为本申请实施例中控制应用程序间相互启动的装置的硬件架构图；

图6为本申请实施例中控制应用程序间相互启动的装置的部分逻辑框图；

图7为本申请实施例中应用程序的部分逻辑框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请针对设备上应用程序之间互相启动的过程提出解决方案。在一些实施例中，设备可以是台式计算机，在一些实施例中，设备可以是便携式的(例如笔记本计算机、平板计算机或手持设备)。在一些实施例中，设备可以是可穿戴的(例如智能手表、智能眼镜等)，在一些实施例中，设备可以是安装于其他设备上的(例如车载终端、导航仪等)。

本申请中，设备具有操作系统，操作系统(Operating System，OS)的类型在本申请中不作限定，例如可以是Windows OS、iOS、MacOS、AndroidOS等。操作系统提供API，设备上的应用程序可以通过调用API使用操作系统提供的各种服务，例如使应用程序可以开启视窗、描绘图形、使用周边设备等。

在某些例子中，操作系统的API的文件可以通过软件开发工具包(SoftwareDevelopment Kit，SDK)提供。SDK一般是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用程序软件时的开发工具的集合。由于设备上的应用程序的来源很多，为了安全性的保障，操作系统通过框架(Framework)基于安全策略对各个应用程序进行校验，过滤对敏感信息的不适当的访问，或避免将设备暴露给恶意的应用程序或甚至是有平常错误的应用程序。操作系统的API可以是操作系统框架提供的标准API库。

图1描述了一个设备100的逻辑架构图。

设备100上装有多个应用程序130(APP1、APPAPP3…)。应用程序130上装有SDK120，SDK 120提供操作系统的各个API，SDK120可以是OS框架110提供的标准API库。SDK作为应用程序130与操作系统的桥梁，使应用程序130调用API使用操作系统所提供的服务。其中一个应用程序在启动后的运行过程中可能需要启动其他应用程序，此时，这个应用程序需要通过调用操作系统的API来唤起其他应用程序。

图2a是实施例中控制应用程序间相互启动的方法的部分流程图。以第一应用程序启动第二应用程序为例，当第一应用程序在电子设备上运行时，第一应用程序可能需要唤起第二应用程序，第一应用程序触发请求唤起第二应用程序的流程后，可以通过唤起控制模块执行以下动作：

S201a，唤起控制模块响应所述第一应用程序的调用请求，判断是否允许启动第二应用程序，唤起控制模块耦合于第一应用程序中；

S202a，如果判断结果为不允许启动第二应用程序，则过滤第一应用程序的此调用请求。

图2b相应的描述了第一应用程序通过唤起控制模块启动第二应用程序的方法的部分流程图。

S201b，第一应用程序向唤起控制模块发起调用请求，所述唤起控制模块耦合于所述第一应用程序中；

S202b，唤起控制模块判断是否允许启动第二应用程序；并在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

本申请中，唤起控制模块耦合于第一应用程序中，可以是唤起控制模块作为应用程序的一部分，也可以是指唤起控制模块独立于应用程序。在某些例子中，唤起控制模块可以通过软件开发工具包(Software Development Kit，SDK)提供。唤起控制模块具有操作系统框架提供的相关API的功能，另外，唤起控制模块还可以具有验证第二应用程序是否可以被启动的逻辑。

当唤起控制模块被调用时，第一应用程序与所调用的唤起控制模块可以同处于一个进程中，因此可以看出，由唤起控制模块检查是否启动第二应用程序的动作是同一个进程中进行的，因此无需调用IPC通信，而是通过函数间调用便可执行此判断过程，由于减少了IPC调用的次数，因此可以降低内存占用，提高系统性能。

需要说明，某些例子中，唤起控制模块判断是否允许启动第二应用程序时所依据的控制策略可以与传统方案中校验服务进程所依据的控制策略相同；在另外的例子中，可以从传统方案中校验服务进程所依据的控制策略中选取部分控制策略来作为唤起控制模块的判断依据，例如，可以对传统方案中的控制策略进行分析，依据每种控制策略的特性从中选取部分控制策略作为唤起控制模块的控制策略等等。

过滤调用请求可以是指执行拒绝调用请求的动作，例如，在一些例子中，执行过滤调用请求的过程可以是向第一应用程序发送返回值或者请求响应，以使第一应用程序获知处理结果。

图2a和图2b是针对判断结果为不允许启动第二应用程序的执行动作，对于判断结果为允许启动第二应用程序的情况，在不同的例子中可能存在不同的处理方式，以下列举了其中几种可能的过程。

一些例子的处理过程可以是：如果唤起控制模块的判断结果为允许启动第二应用程序，则可通过OS框架的相关的流程唤起第二应用程序。

在一些例子中，设备的逻辑框架还可以如3a所示，可以看出，在OS框架中还可以存在校验服务进程140，结合图3b描述启动第二应用程序的过程：启动第二应用程序可以需要通过两次的判断过程，且两次判断过程所依据的控制策略不同，为描述方便，分别称为第一控制策略和第二控制策略。如果唤起控制模块依据第一控制策略判断结果为允许启动第二应用程序，则调用IPC通知校验服务进程，并可以将校验服务进程所需要的相关信息(例如第二应用程序的包标识(包标识可以作为区分不同的应用程序的唯一标识)、第一应用程序的用户标识等信息)发给校验服务进程，校验服务进程再根据第二控制策略进一步判断是否允许启动第二应用程序，如果允许启动，则通知操作系统的框架启动第二应用程序；如果校验服务进程不允许启动第二应用程序，则过滤此调用请求(图3b中未示出)。

图3c描述了另一些例子的部分处理过程。与图3b的差别在于两次判断过程所依据的控制策略相同。图3c所描述的过程也可适用于图3a的设备的逻辑框架中。在控制策略相同时仍然需要双重过滤，是因为申请人考虑到由于启动第二应用程序的方式很多，在某些例子中是通过调用唤起控制模块启动(例如图1所描述的过程)，在某些例子中一些应用可以通过替换操作系统的API或在本地应用上定制标准的SDK API列表的方式来唤起第二应用程序，因此该些应用可能无法按照图2a和图2b所提供的流程来进行调用请求的过滤，而需要调用IPC通过校验服务进程来进行过滤，因此考虑操作系统框架的设计难度以及通用性，对于第一次未过滤的调用请求可以经过校验服务进程进行第二次的过滤。

容易得出结论，由于在S202阶段已经过滤掉一些调用请求，因此，在判断结果为允许启动第二应用程序时，无论如何处理，均会比传统技术调用IPC的次数降低，因此可以降低系统资源的消耗(例如CPU时间片、内存、电量等资源的消耗)，提高系统性能。

图4a描述一个应用场景中界面的状态切换过程。参见状态1，移动终端设备上装有多个APP；用户启动其中一个APP后的界面状态可以参见图中状态2的图示，用户可以通过此APP阅读一篇文章，并且可通过点击右上角的按钮进入图中状态3的界面；在状态3的界面中，当用户选择通过另一种APP来分享此文章时，将会产生通过当前APP自动启动另一APP的过程。图4b显示了此过程中的部分流程。

当前APP在接收到用户的指令后，调用唤起控制模块触发启动另一APP的动作。

在S401阶段，当前APP通过SDK中唤起控制模块进行首次验证，判断是否允许启动另一APP；

在S402阶段在如果判断结果为不允许启动另一APP，则过滤此调用请求(图4b中未示出)；

S403阶段，如果判断结果允许启动另一APP，则调用IPC通知校验服务进程第一控制策略验证通过，请求校验服务进程进行二次验证；

在S404阶段，校验服务进程判断是否允许启动另一APP；

S405阶段，如果校验服务进程的判断结果为不允许启动另一APP，则过滤此调用请求(图4b中未示出)；S406阶段、S407阶段，如果允许启动另一APP，则通知OS框架唤起另一APP，另一APP启动后的界面可呈现图4a的状态4的效果。

与前述控制应用程序间相互启动的方法的实施例相对应，本申请还提供了控制应用程序间相互启动的装置的实施例。

本申请控制应用程序间相互启动的装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请控制应用程序间相互启动的装置所在电子设备的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。处理器被配置为执行控制应用程序间相互启动的相关动作。

请参考图6，控制应用程序间相互启动的装置600耦合于所述第一应用程序中，该装置包括：

判定模块601，用于在第一应用程序运行时，响应所述第一应用程序的调用请求，判断是否允许启动第二应用程序；

处理模块602，用于在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

作为例子，处理模块602还可以用于在判断结果允许启动第二应用程序时，调用校验服务模块判断是否允许启动所述第二应用程序。作为例子，如果所述校验服务进程的判断结果为允许启动所述第二应用程序，则可以通知操作系统启动所述第二应用程序，如果判断结果不允许启动所述第二应用程序，则过滤所述调用请求。

另外，在某些情况下，处理模块602还可以用于在判断结果允许启动第二应用程序时，通知操作系统启动第二应用程序。

判定模块601和所述校验服务模块判断是否允许启动所述第二应用程序所依据的控制策略可以相同，也可以不同，可参见上文相关描述。

所述处理模块602可以通过进程间通信IPC调用所述校验服务进程。

装置600可以通过软件开发工具包SDK提供。

图7是一种应用程序700的部分逻辑结构的框图，包括：

调用模块701，用于在第一应用程序运行时，向唤起控制模块701发出调用请求，以启动第二应用程序；

唤起控制模块702，用于判断是否允许启动第二应用程序；如果所判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

某些例子中，所述唤起控制模块702还可以在判断结果允许启动第二应用程序时，通知校验服务进程判断是否允许启动所述第二应用程序。作为例子，如果所述校验服务进程的判断结果为允许启动所述第二应用程序，则通知操作系统启动所述第二应用程序，如果判断结果不允许启动所述第二应用程序，则过滤所述调用请求。

某些例子中，如果判断结果允许启动第二应用程序，则所述唤起控制模块702可以通知操作系统启动第二应用程序。

所述唤起控制模块702和所述校验服务进程判断是否允许启动所述第二应用程序所依据的控制策略可以相同，也可以不同。

所述唤起控制模块702可以通过进程间通信IPC调用所述校验服务进程。

某些例子中，所述唤起控制模块702可以通过软件开发工具包SDK提供。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (25)

1.一种控制应用程序间相互启动的方法，其特征在于，所述方法包括步骤：

在第一应用程序运行时，唤起控制模块响应所述第一应用程序的调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；如果判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括步骤：

如果判断结果允许启动第二应用程序，则所述唤起控制模块调用校验服务进程判断是否允许启动所述第二应用程序。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

如果所述校验服务进程的判断结果为允许启动所述第二应用程序，则通知操作系统启动所述第二应用程序，如果判断结果不允许启动所述第二应用程序，则过滤所述调用请求。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括步骤：

如果判断结果允许启动第二应用程序，则所述唤起控制模块通知所述操作系统启动第二应用程序。

5.根据权利要求2所述的方法，其特征在于，所述唤起控制模块和所述校验服务进程判断是否允许启动所述第二应用程序所依据的控制策略相同。

6.根据权利要求2所述的方法，其特征在于，所述唤起控制模块通过进程间通信IPC调用所述校验服务进程。

7.根据权利要求1所述的方法，其特征在于，所述唤起控制模块通过软件开发工具包SDK提供。

8.一种应用程序间相互启动的方法，其特征在于，所述方法包括步骤：

第一应用程序向唤起控制模块发起调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；并在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括步骤：

如果所述唤起控制模块的判断结果允许启动第二应用程序，则所述唤起控制模块通知校验服务进程判断是否允许启动所述第二应用程序。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

所述校验服务进程在判断结果为允许启动所述第二应用程序时，通知操作系统启动所述第二应用程序，在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

11.根据权利要求8所述的方法，其特征在于，所述方法还包括步骤：

如果判断结果允许启动第二应用程序，则所述唤起控制模块通知操作系统启动第二应用程序。

12.根据权利要求9所述的方法，其特征在于，所述唤起控制模块和所述校验服务进程判断是否允许启动所述第二应用程序所依据的控制策略相同。

13.根据权利要求9所述的方法，其特征在于，所述唤起控制模块通过进程间通信IPC调用所述校验服务进程。

14.根据权利要求8所述的方法，其特征在于，所述唤起控制模块通过软件开发工具包SDK提供。

15.一种控制应用程序间相互启动的装置，其特征在于，所述装置耦合于所述第一应用程序中，该装置包括：

判定模块，用于在第一应用程序运行时，响应所述第一应用程序的调用请求，判断是否允许启动第二应用程序；

处理模块，用于在判断结果为不允许启动所述第二应用程序时，过滤所述调用请求。

16.根据权利要求15所述的装置，其特征在于，所述处理模块还用于在判断结果允许启动第二应用程序时，调用校验服务模块判断是否允许启动所述第二应用程序。

17.根据权利要求15所述的装置，其特征在于，所述处理模块还用于在判断结果允许启动第二应用程序时，通知操作系统启动第二应用程序。

18.根据权利要求16所述的装置，其特征在于，所述判定模块和所述校验服务模块判断是否允许启动所述第二应用程序所依据的控制策略相同。

19.根据权利要求16所述的装置，其特征在于，所述处理模块通过进程间通信IPC调用所述校验服务进程。

20.根据权利要求15所述的装置，其特征在于，所述装置通过软件开发工具包SDK提供。

21.一种应用程序，其特征在于，包括：

调用模块，用于在第一应用程序运行时，向唤起控制模块发出调用请求，以启动第二应用程序；

唤起控制模块，用于判断是否允许启动第二应用程序；如果所述判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。

22.根据权利要求21所述的应用程序，其特征在于，所述唤起控制模块还用于在判断结果允许启动第二应用程序时，通知校验服务进程判断是否允许启动所述第二应用程序。

23.根据权利要求22所述的应用程序，其特征在于，

如果判断结果允许启动第二应用程序，则所述唤起控制模块通知操作系统启动第二应用程序。

24.根据权利要求1所述的应用程序，其特征在于，所述唤起控制模块通过软件开发工具包SDK提供。

25.一种设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

在第一应用程序运行时，唤起控制模块响应所述第一应用程序的调用请求，所述唤起控制模块耦合于所述第一应用程序中；所述唤起控制模块判断是否允许启动第二应用程序；如果判断结果为不允许启动所述第二应用程序，则过滤所述调用请求。