程序包调用方法、系统、终端设备及计算机可读存储介质与流程

文档序号:23091199发布日期:2020-11-27 12:44阅读:135来源:国知局
程序包调用方法、系统、终端设备及计算机可读存储介质与流程

本公开涉及通信技术领域,尤其涉及一种程序包调用方法、一种程序包调用系统、一种终端设备以及一种计算机可读存储介质。



背景技术:

随着通信技术的不断发展,应用场景也逐渐复杂化和多样化,不同领域的应用交叉、组合应用成为必然,而随着终端上的业务种类和数量大幅增加,应用间的调用访问频度大幅提高,调用关系也趋于复杂化,同一应用程序包(applicationpackage,简称apk)被重复调用的情况时有发生,往往导致大量系统资源被占用,进程吊死无响应,极大的影响应用使用情况,进而降低了用户的使用体验。



技术实现要素:

本公开提供了一种程序包调用方法、系统、终端设备及计算机可读存储介质,以至少解决上述问题。

根据本公开实施例的一方面,提供一种程序包调用方法,包括:

接收第一应用程序发送的程序包调用请求;

判断所述程序包是否已被第二应用程序调用;

若所述程序包未被第二应用程序调用,则判断所述第一应用程序是否具备调用所述程序包的权限;

若所述第一应用程序具备调用所述程序包的权限,则响应所述第一应用程序的程序包调用请求。

在一种实施方式中,所述方法还包括:

建立程序包调用列表;以及,

将具备调用所述程序包权限的若干应用程序存储在所述程序包调用列表中;

所述判断所述第一应用程序是否具备调用所述程序包的权限,具体为:

判断所述第一应用程序是否在所述程序包调用列表中,若所述第一应用程序在所述程序包调用列表中,则判定为所述第一应用程序具备调用所述程序包的权限。

在一种实施方式中,所述方法还包括:

为具备调用所述程序包权限的若干应用程序分配调用优先级;

所述判断所述程序包是否已被第二应用程序调用之后,还包括:

若所述程序包已被第二应用程序调用,则判断在接收到所述第一应用程序发送的程序包调用请求之前,是否接收了除所述第一应用程序和第二应用程序之外的其它应用程序发送的程序包调用请求;

若没有接收到其它应用程序发送的程序包调用请求,则在所述第二应用程序完成对所述程序包的调用后,响应所述第一应用程序的程序包调用请求;

若接收了其它应用程序发送的程序包调用请求,则在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应所述第一应用程序和所述其它应用程序的程序包调用请求。

在一种实施方式中,在根据所述调用优先级依次响应所述第一应用程序和所述其它应用程序的程序包调用请求之前,还包括:

获取接收到的其它应用程序发送的程序包调用请求的数量;

判断接收到的所述其它应用程序的程序包调用请求的数量是否少于预设数量;

若少于预设数量,则执行在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应所述第一应用程序和所述其它应用程序的程序包调用请求的步骤。

在一种实施方式中,所述响应所述第一应用程序的程序包调用请求,包括:

判断所述程序包调用请求是否为嵌套调用请求;

若不是嵌套调用请求,则向所述第一应用程序发送响应通知,以使所述第一应用程序基于预设的调用配置运行所述程序包;

若是嵌套调用请求,则从本地嵌套配置数据中获取上级程序包嵌套信息;以及,

向所述第一应用程序发送响应通知,所述响应通知中携带所述上级程序包嵌套信息,以使所述第一应用程序根据所述上级程序包嵌套信息按照预设的调用配置在所述上级程序包中运行所述程序包。

根据本公开实施例的第二方面,提供一种程序包调用系统,包括:

接收模块,其设置为接收第一应用程序发送的程序包调用请求;

第一判断模块,其设置为判断所述程序包是否已被第二应用程序调用;

第二判断模块,其设置为在所述第一判断模块判断为所述程序包未被第二应用程序调用时,判断所述第一应用程序是否具备调用所述程序包的权限;

响应模块,其设置为在所述第二判断模块判断为所述第一应用程序具备调用所述程序包的权限时,响应所述第一应程序的程序包调用请求。

在一种实施方式中,所述系统还包括:

列表建立模块,其设置为建立程序包调用列表;以及,

存储模块,其设置为将具备调用所述程序包权限的若干应用程序存储在所述程序包调用列表中;

所述第二判断模块具体设置为,判断所述第一应用程序是否在所述程序包调用列表中,若所述第一应用程序在所述程序包调用列表中,则判定为所述第一应用程序具备调用所述程序包的权限。

在一种实施方式中,所述系统还包括:

优先级分配模块,其设置为为具备调用所述程序包权限的若干应用程序分配调用优先级;

第三判断模块,其设置为在所述第一判断模块判断为所述程序包已被第二应用程序调用时,判断在接收到所述第一应用程序发送的程序包调用请求之前,是否接收了除所述第一应用程序和第二应用程序之外的其它应用程序发送的程序包调用请求;

所述响应模块还设置为,在所述第三判断模块判断为没有接收到其它应用程序发送的程序包调用请求时,在所述第二应用程序完成对所述程序包的调用后,响应所述第一应用程序的程序包调用请求;

所述响应模块还设置为,在所述第三判断模块判断为接收了其它应用程序发送的程序包调用请求时,在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应第一应用程序和其它应用程序的程序包调用请求。

根据本公开实施例的又一方面,提供一种终端设备,包括存储器和处理器,所述存储器中存储有计算机程序,当所述处理器运行所述存储器存储的计算机程序时,所述处理器执行所述的程序包调用方法。

根据本公开实施例的再一方面,提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时,所述处理器执行所述的程序包调用方法。

本公开的实施例提供的技术方案可以包括以下有益效果:

本公开实施例提供的程序包调用方法,通过在接收到第一应用程序发送的程序包调用请求后,判断所述程序包是否已被第二应用程序调用,若所述程序包未被第二应用程序调用,则判断所述第一应用程序是否具备调用所述程序包的权限,若所述第一应用程序具备调用所述程序包的权限,则响应所述第一应用程序的程序包调用请求。本公开实施例至少可以有效解决应用间的程序包重复调用所导致的进程吊死、反复重启等问题。

本公开的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本公开而了解。本公开的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本公开技术方案的进一步理解,并且构成说明书的一部分,与本公开的实施例一起用于解释本公开的技术方案,并不构成对本公开技术方案的限制。

图1为本公开实施例提供的一种程序包调用方法的流程示意图;

图2为图1中步骤s103的流程示意图;

图3为本公开另一实施例提供的一种程序包调用方法的流程示意图;

图4为本公开又一实施例提供的一种程序包调用方法的流程示意图;

图5为本公开实施例提供的一种程序包调用系统的结构示意图;

图6为本公开实施例提供的一种终端设备的结构示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚,以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是,此处所描述的具体实施方式仅用于说明和解释本公开,并不用于限制本公开。

需要说明的是,本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序;并且,在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互任意组合。

其中,在本公开实施例中使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本公开。在本公开实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。

在后续的描述中,使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本公开的说明,其本身没有特定的意义。因此,“模块”、“部件”或“单元”可以混合地使用。

目前主要依赖于用户手动操作关闭重复的程序包调用(以下简称apk调用),或由系统关闭进行中的调用来响应新的调用请求,这样往往导致进行中的应用意外中断,已调用进程被kill,或apk后台隐匿运行用户无感知,导致重复操作或长时间等待,无法对apk的实际调用情况以及应用的调用需求进行差异化控制和响应。

针对上述问题,本公开实施例提出一种程序包调用方法,根据约定的apk调用关系和调用配置,结合apk的运行情况,采取适当的响应措施;并且,还适用于多级嵌套调用场景,能够根据约定的嵌套关系和嵌套路径,实现多级嵌套的调用响应,可有效避免重复调用导致的进程吊死、反复重启等问题,以及并发调用带来的应用间调用冲突、等待超时等问题。

本实施例中,首先配置策略,配置主要有apk、主应用、调用列表、等待列表、调用优先级、启动标志、嵌套标志、调用配置等。

apk,被请求调用的apk程序包,其表现形式不限,可能为ui、url、后台apk、插件等。

主应用,请求调用apk的应用程序,形式不限,可以为app、社区、网站等。一般的,与apk位于同一操作系统或终端。

程序包调用列表,用于记录与apk之间有调用关系的主应用。一个apk可能对应多个主应用,反之亦然。一般的,一个apk同一时间只响应一个主应用的调用。

调用优先级,用于描述当多个调用请求并发(如:apk忙碌、多调用并发)时,对各主应用响应优先级次序。优先级可按时间排序、或按预设应用调用级别排序,级别高的优先响应。此外,本公开实施例可基于apk建立等待列表,用于记录(如,apk忙碌、多调用并发)需等待的调用请求,列表内按调用优先级排序;以及设置启动标志和嵌套标志,用于描述所述调用是否已启动,即是否重复的调用请求。默认为0,已调用或已等待,标志置为1,不再启动新的调用请求,避免重复调用;嵌套标志用于描述本apk调用的嵌套情况,1为有嵌套,表示apk有上级嵌套(应用、控件等),0为无嵌套,表示apk与应用间直接调用,无多级嵌套。一个apk可能对应多个嵌套关系,一个嵌套关系(嵌套标志、上级嵌套)只在特定的调用关系中生效。本公开以二级嵌套为例,对于多级嵌套场景依次类推。

调用配置,基于特定的调用关系(某apk和某主应用)设置,对于有调用关系的某apk和主应用来说,可以预设调用时默认的启动配置,该配置只在此关系调用中生效,调用完毕,恢复apk原有配置。可以理解的是,无论是直接调用还是嵌套调用,调用配置是基于apk和第一应用程序之间的设定的。

请参照图1,图1为本公开实施例提供的一种程序包调用方法的流程示意图,所述方法包括步骤s101-s103。

在步骤s101中,接收第一应用程序发送的程序包调用请求,

在步骤s102中,判断所述程序包是否已被第二应用程序调用,若未被第二应用程序调用,则执行步骤s103,否则结束流程。

具体地,在接收到主应用的调用请求之后,首先获取请求中的主应用信息,例如aid(applicationidentifier,应用标识)等,请求调用的程序包信息,并判断该程序包是否已经被其它主应用调用,即,该程序包正在运行中,为避免程序包当前已在运行,引起重复调用等情况,本实施例首先判断请求调用的程序包是否被其它程序调用,如果已经被其它应用程序调用,则结束流程,可以理解的是,该其它应用程序可以是程序包自身应用程序或除所述第一应用程序外的其它程序,程序包自身应用程序为对程序包的自运行,此处统称为调用。在一些实施例中,在判断为程序包被其它应用程序调用后,可以进入等待中,等待程序包调用结束,然后根据调用优先级对程序包响应调用请求。

在目前的程序包调用方案中,程序包的调用通常在后台隐藏,也就是说,该程序包可能已被该第一程序调用因其在后台隐藏而未能发现,在这种情况下,本实施例还可以检测该程序包是否已被所述第一应用程序调用,如果已被第一应用程序调用,则在第一应用程序和程序包之间的标记调用启动标志,例如,启动标志为“1”,说明调用关系已启动,启动标志为“0”说明调用关系暂未启动,将其标志为“1”,然后将程序包从后台调至前台的界面进行显示,直接完成对第一应用程序的响应。

在步骤s103中,判断所述第一应用程序是否具备调用所述程序包的权限,若具备权限,则执行步骤s104,否则结束流程。

具体地,在程序包进行调用之前,系统会对程序包的调用权限进行预配置,可以通过建立程序包调用列表,并将可以调用该程序包的应用程勋存储在该程序包调用列表中,在接收到第一应用程序的程序包调用请求时,查询该第一应用程序是否在该列表中,如果在该列表中,说明第一应用程序具备该程序包的调用权限,并执行后续步骤完成对该请求的响应,否则,说明第一应用程序不具备该程序包的调用权限,拒绝该请求并结束流程。

在步骤s104中,响应所述第一应用程序的程序包调用请求。

具体地,根据所述程序包调用请求向所述第一应用程序发送响应通知,第一应用程序查询调用配置直接运行该程序包,执行本调用。

进一步地,请参照图2,为了同时满足应用程序的嵌套调用及非嵌套调用,本实施例将步骤s103进一步划分为步骤s103a-s103d。

在步骤s103a中,判断所述程序包调用请求是否为嵌套调用请求,若是,则执行步骤s103c,否则,执行步骤s103b;

在步骤s103b中,向所述第一应用程序发送响应通知,以使所述第一应用程序基于预设的调用配置运行所述程序包;

在步骤s103c中,从本地嵌套配置数据中获取上级程序包嵌套信息;以及,

在步骤s103d中,向所述第一应用程序发送响应通知,所述响应通知中携带所述上级程序包嵌套信息,以使所述第一应用程序根据所述上级程序包嵌套信息按照预设的调用配置在所述上级程序包中运行所述程序包。

具体地,对于嵌套调用,也可以将其设置嵌套标志位,例如,将其设置为“1”,不是嵌套调用,则标志为“0”,当收到第一应用程序的程序包调用请求,首先可以根据apk及第一应用程序的应用信息,获取该调用关系对应的调用配置,然后读取嵌套标志,对于直接调用(嵌套标志为0)的请求,按照调用配置直接运行所述apk,执行本调用。对于嵌套调用(嵌套标志为1),获取上级嵌套信息,使第一应用程序在上级apk中进行嵌套调用,在上级嵌套apk中按照调用配置运行所述apk,执行本调用。进一步的,当apk结束调用(状态转为空闲),若该apk的调用等待序列非空,则向相应的应用程序发送响应通知,具体响应过程如上,否则,结束任务。

请参照图3,图3为本公开另一实施例提供的一种程序包调用方法的流程示意图,相较于上一实施例,本实施例通过建立程序包调用列表,明确apk调用关系,并进一步示例了请求调用程序包的应用程序的权限判定方案,具体地,本实施例还包括步骤s301和步骤s302,并将步骤s102进一步划分为s102b。

在步骤s301中,建立程序包调用列表;

在步骤s302中,将具备调用所述程序包权限的若干应用程序存储在所述程序包调用列表中;

在步骤s102b中,判断所述第一应用程序是否在所述程序包调用列表中,若所述第一应用程序在所述程序包调用列表中,则判定为所述第一应用程序具备调用所述程序包的权限。

请参照图4,图4为本公开又一实施例提供的一种程序包调用方法的流程示意图,相较于上一实施例,本实施例通过为具备调用权限的应用程序分配调用优先级,并在多个调用请求条件下,基于调用优先级依次响应调用请求,实现程序包在应用间的有序、高效调用,具体地,所述方法还包括步骤s401-s406。

在步骤s401中,为具备调用所述程序包权限的若干应用程序分配调用优先级。

所述步骤s101之后,还包括步骤s402-s406。

在步骤s402中,若所述程序包已被第二应用程序调用,则判断在接收到所述第一应用程序发送的程序包调用请求之前,是否接收了除所述第一应用程序和第二应用程序之外的其它应用程序发送的程序包调用请求,若是,则执行步骤s404,否则,执行步骤s403。

在步骤s403中,在所述第二应用程序完成对所述程序包的调用后,响应所述第一应用程序的程序包调用请求;

在步骤s404中,获取接收到的其它应用程序发送的程序包调用请求的数量;

在步骤s405中,判断接收到的所述其它应用程序的程序包调用请求的数量是否少于预设数量,若是,则执行步骤s406,否则,拒绝响应该请求并结束流程。

在步骤s406中,在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应所述第一应用程序和所述其它应用程序的程序包调用请求。

本实施例中,系统预先设置调用请求数量上限,避免应用程序等待时间过长,影响调用效率,具体地,可以在接收到新的调用请求时,获取被请求的apk信息,查看所述apk调用列表,将等待请求数(即,其它应用的程序包请求数量)与预设数量进行比对,如果等于或大于预设数量,说明如列表已饱和(超预设等待阈值),拒绝该请求;如列表为空或未饱和,对于已在等待序列的重复请求,根据新的请求时间更新等待列表排序,等待响应通知;对于新应用的调用请求,根据请求中apk与主应用信息,查找所述apk调用列表,获取所述主应用优先级排序,将新请求加入等待列表。在一些实施例中,可以仅对一部分应用程序分配调用优先级,那么对于未设优先级排序的,按请求时间排序,等待响应通知。

基于相同的技术构思,本公开实施例相应还提供一种程序包调用系统,如图5所示,所述系统包括接收模块51、第一判断模块52、第二判断模块53及响应模块54,其中,

所述接收模块51,其设置为接收第一应用程序发送的程序包调用请求;

所述第一判断模块51,其设置为判断所述程序包是否已被第二应用程序调用;

所述第二判断模块52,其设置为在所述第一判断模块判断为所述程序包未被第二应用程序调用时,判断所述第一应用程序是否具备调用所述程序包的权限;

所述响应模块53,其设置为在所述第二判断模块判断为所述第一应用程序具备调用所述程序包的权限时,响应所述第一应用程序的程序包调用请求。

在一种实施方式中,所述系统还包括:

列表建立模块,其设置为建立程序包调用列表;以及,

存储模块,其设置为将具备调用所述程序包权限的若干应用程序存储在所述程序包调用列表中;

所述第二判断模块具体设置为,判断所述第一应用程序是否在所述程序包调用列表中,若所述第一应用程序在所述程序包调用列表中,则判定为所述第一应用程序具备调用所述程序包的权限。

在一种实施方式中,所述系统还包括:

优先级分配模块,其设置为为具备调用所述程序包权限的若干应用程序分配调用优先级;

第三判断模块,其设置为在所述第一判断模块判断为所述程序包已被第二应用程序调用时,判断在接收到所述第一应用程序发送的程序包调用请求之前,是否接收了除所述第一应用程序和第二应用程序之外的其它应用程序发送的程序包调用请求;

所述响应模块还设置为,在所述第三判断模块判断为没有接收到其它应用程序发送的程序包调用请求时,在所述第二应用程序完成对所述程序包的调用后,响应所述第一应用程序的程序包调用请求;

所述响应模块还设置为,在所述第三判断模块判断为接收了其它应用程序发送的程序包调用请求时,在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应第一应用程序和其它应用程序的程序包调用请求。

在一种实施方式中,还包括:

获取模块,其设置为在所述响应模块响应所述第一应用程序和所述其它应用程序的程序包调用请求之前,获取接收到的其它应用程序发送的程序包调用请求的数量;

第四判断模块,其设置为判断接收到的所述其它应用程序的程序包调用请求的数量是否少于预设数量;

所述响应模块还设置为,在第四判断模块判断为少于预设数量时,在所述第二应用程序完成对所述程序包的调用后,根据所述调用优先级依次响应所述第一应用程序和所述其它应用程序的程序包调用请求;

所述响应模块还设置为,在第四判断模块判断为多于或等于预设数量时,拒绝响应所述第一应用程序的程序包调用请求。

在一种实施方式中,所述响应模块,包括:

判断单元,其设置为判断所述程序包调用请求是否为嵌套调用请求;

第一响应单元,其设置为在所述判断单元判断为不是嵌套调用请求时,向所述第一应用程序发送响应通知,以使所述第一应用程序基于预设的调用配置运行所述程序包;

第二响应单元,其设置为在所述判断单元判断为是嵌套调用请求时,从本地嵌套配置数据中获取上级程序包嵌套信息;以及,向所述第一应用程序发送响应通知,所述响应通知中携带所述上级程序包嵌套信息,以使所述第一应用程序根据所述上级程序包嵌套信息按照预设的调用配置在所述上级程序包中运行所述程序包。

基于相同的技术构思,本公开实施例相应还提供一种终端设备,如图6所示,所述终端设备包括存储器61和处理器62,所述存储器61中存储有计算机程序,当所述处理器62运行所述存储器存储的计算机程序时,所述处理器执行所述的程序包调用方法。

基于相同的技术构思,本公开实施例相应还提供一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时,所述处理器执行所述的程序包调用方法。

本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其他存储器技术、cd-rom、数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。

最后应说明的是:以上各实施例仅用以说明本公开的技术方案,而非对其限制;尽管参照前述各实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本公开各实施例技术方案的范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1