应用程序请求的处理方法和装置与流程

文档序号:13804647阅读:241来源:国知局
应用程序请求的处理方法和装置与流程

本公开涉及终端技术领域,尤其涉及一种应用程序请求的处理方法和装置。



背景技术:

终端上的操作系统例如miui系统的app(application,应用)会有互相访问的需求。比如在文件夹打开一个mp3文件,或者在金融软件打开一个链接。我们希望能把这些流量内部转化给自己的应用而不是第三方app。目前除非知道想要转化的app的具体activity(活动),否则不能准确转化。需要系统去处理,会带来一些不想要的副作用。

在framework(系统框架)里对发来的intent(请求)做处理。比如intent是一个http(hypertexttransferprotocol,超文本传输协议)开头的uri(uniformresourceidentifier,统一资源标识符),系统查询所有能响应这个intent的app,优先找出系统的app去响应。

因此,系统里需要大量的判断代码,而且无法准确判断这个请求是否应该被拦截,可能会影响用户的使用体验。比如用户点击了一个“知乎”的链接,这时系统不应该去拦截,而应该让用户去通过“知乎”打开。



技术实现要素:

为克服相关技术中存在的问题,本公开提供一种。

根据本公开实施例的第一方面,提供一种应用程序请求的处理方法,包括:

软件开发工具包sdk接收来自第一应用程序app的第一请求;

所述sdk将能够执行所述第一请求的第二app的信息与所述第一请求一起封装;

所述sdk将封装后的第二请求发送给系统框架,由所述系统框架将所述第一请求发送给所述第二app进行处理。

在一种可能的实现方式中,所述sdk将能够执行所述第一请求的第二app的信息与所述第一请求一起封装,包括:

所述sdk查询能够执行所述第一请求的第二app;

将第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,所述sdk将能够执行所述第一请求的第二app的信息与所述第一请求一起封装,包括:

所述sdk查询能够执行所述第一请求的多个第二app;

将从多个第二app中选择的一个第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,将从多个第二app中选择的一个第二app的活动组件名称与所述第一请求一起封装,包括:

从多个第二app中选择系统自带的第二app;

将系统自带的第二app的活动组件名称与所述第一请求一起封装。

根据本公开实施例的第二方面,提供一种应用程序请求的处理装置,应用于软件开发工具包sdk,所述装置包括:

接收模块,用于接收来自第一应用程序app的第一请求;

封装模块,用于将能够执行所述第一请求的第二app的信息与所述第一请求一起封装;

发送模块,用于将封装后的第二请求发送给系统框架,由所述系统框架将所述第一请求发送给所述第二app进行处理。

在一种可能的实现方式中,所述封装模块包括:

第一查询子模块,用于查询能够执行所述第一请求的第二app;

第一封装子模块,用于将第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,所述封装模块还包括:

第二查询子模块,用于查询能够执行所述第一请求的多个第二app;

第二封装子模块,用于将从多个第二app中选择的一个第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,所述第二封装子模块包括:

选择子模块,用于从多个第二app中选择系统自带的第二app;

第三封装子模块,用于将系统自带的第二app的活动组件名称与所述第一请求一起封装。

根据本公开实施例的第三方面,提供一种应用程序请求的处理装置,包括:

处理器;

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

其中,所述处理器被配置为:执行根据本公开任一实施例所述的方法。

根据本公开实施例的第四方面,提供一种非临时性计算机可读存储介质,当所述存储介质中的指令由处理器执行时,使得处理器能够执行根据本公开任一实施例所述的方法。

本公开的实施例提供的技术方案可以包括以下有益效果:采用sdk在封装时指明执行第一请求的app,后续系统框架(framework)收到封装的请求后,可以直接将该第一请求发送给指明的第二app进行处理。因此,framework不需要再进行查询、判断等处理,有利于减轻系统的压力。

应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种应用程序请求的处理方法的流程图。

图2是根据另一示例性实施例示出的一种应用程序请求的处理方法的流程图。

图3是根据另一示例性实施例示出的一种应用程序请求的处理方法的流程图。

图4是根据一示例性实施例示出的一种应用程序请求的处理装置的框图。

图5是根据另一示例性实施例示出的一种应用程序请求的处理装置的框图。

图6是根据另一示例性实施例示出的一种应用程序请求的处理装置的框图。

具体实施方式

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

图1是根据一示例性实施例示出的一种应用程序请求的处理方法的流程图,如图1所示,该方法用于终端中,包括以下步骤。

在步骤101中,sdk(softwaredevelopmentkit,软件开发工具包)接收来自第一应用程序app的第一请求。

在步骤102中,sdk将能够执行所述第一请求的第二app的信息与所述第一请求一起封装。

在步骤103中,sdk将封装后的第二请求发送给系统框架,由所述系统框架将所述第一请求发送给所述第二app进行处理。

在本实施例中,将app向sdk发送的待处理的请求称为第一请求,将第一请求增加第二app的信息封装后得到的请求称为第二请求。例如,app在发起待处理的intent(请求)时,先将intent交给sdk做一次封装,再发出。sdk在封装时会查询出应该转给哪个app去响应这个intent。然后在封装intent时指明对应的app的activitycomponentname(活动组件名称),相当于把framework的拦截提前到sdk封装过程。同时app也不需要关心具体逻辑。只需要在发出之前调用一次sdk的封装接口。第三方app也可以接入sdk来达到同样的目地。

例如,用户在社交工具app中点击了一个链接,该社交工具app向sdk发送该链接。sdk查询到系统中有浏览器可以处理该链接,则可以将该连接和该浏览器的信息封装到一起发送给framework。framework收到封装后的第二请求后,根据其中的浏览器的信息,将该链接发送至该浏览器,从而在该浏览器中打开该链接。

本公开采用sdk在封装时指明执行第一请求的app,后续系统框架(framework)收到封装的请求后,可以直接将该第一请求发送给指明的第二app进行处理。因此,framework不需要再进行查询、判断等处理,有利于减轻系统的压力。

此外,sdk根据所封装的第二app的信息,可以灵活的选择执行第一请求的app,达到准确导流的目的,还可以避免误拦截,并且扩展性强。例如,通过sdk对第一请求的转化,能简单准确的保证系统内部的流量的转化,同时不会误拦截第三方的正常intent。

图2是根据另一示例性实施例示出的一种应用程序请求的处理方法的流程图。与上述实施例不同之处在于,如图2所示,该方法的步骤102包括。

步骤201、sdk查询能够执行所述第一请求的第二app。

步骤202、sdk将第二app的活动组件名称与所述第一请求一起封装。

如果sdk查询到有一个app能够执行该第一请求,则可以将该第一请求与该app的活动组件名称一起封装后,发送给framework。

图3是根据另一示例性实施例示出的一种应用程序请求的处理方法的流程图。与上述实施例不同之处在于,如图3所示,该方法的步骤102包括。

步骤301、sdk查询能够执行所述第一请求的多个第二app。

步骤302、sdk将从多个第二app中选择的一个第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,步骤302包括:从多个第二app中选择系统自带的第二app;将系统自带的第二app的活动组件名称与所述第一请求一起封装。

如果sdk查询到有多个app能够执行该第一请求,则可以从多个app中选择出一个,来执行该第一请求。选择的方法可以有多种,例如,优先选择系统自带的app,或者优先选择执行效率最高的app,或者优先选择排名靠前的app等,当然也可以随机选择。

然后,sdk将该第一请求与所选择的app的活动组件名称一起封装后,发送给framework。

本公开通过sdk对第一请求的转化,能简单准确的保证系统内部的流量的转化,达到准确导流,同时又避免了误拦截,还减轻了系统的压力,增加了可扩展性。因此,本公开的应用程序请求的处理方法不依赖于系统,更加准确,灵活,扩展性更高。

图4是根据一示例性实施例示出的一种应用程序请求的处理装置的框图。参照图4,该装置可以应用于终端的sdk,所述装置包括:

接收模块41,用于接收来自第一应用程序app的第一请求;

封装模块43,用于将能够执行所述第一请求的第二app的信息与所述第一请求一起封装;

发送模块45,用于将封装后的第二请求发送给系统框架,由所述系统框架将所述第一请求发送给所述第二app进行处理。

图5是根据另一示例性实施例示出的一种应用程序请求的处理装置的框图。参照图5,该装置可以应用于终端的sdk,与上述实施例的不同之处在于,所述装置包括的封装模块43包括:

第一查询子模块51,用于查询能够执行所述第一请求的第二app;

第一封装子模块53,用于将第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,所述封装模块43还包括:

第二查询子模块55,用于查询能够执行所述第一请求的多个第二app;

第二封装子模块57,用于将从多个第二app中选择的一个第二app的活动组件名称与所述第一请求一起封装。

在一种可能的实现方式中,所述第二封装子模块57包括:

选择子模块,用于从多个第二app中选择系统自带的第二app;

第三封装子模块,用于将系统自带的第二app的活动组件名称与所述第一请求一起封装。

关于上述实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。

图6是根据另一示例性实施例示出的一种应用程序请求的处理装置的框图。例如,装置800可以是移动电话,计算机,数字广播终端,消息收发设备,游戏控制台,平板设备,医疗设备,健身设备,个人数字助理等。

参照图6,装置800可以包括以下一个或多个组件:处理组件802,存储器804,电源组件806,多媒体组件808,音频组件810,输入/输出(i/o)的接口812,传感器组件814,以及通信组件816。

处理组件802通常控制装置800的整体操作,诸如与显示,电话呼叫,数据通信,相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令,以完成上述的方法的全部或部分步骤。此外,处理组件802可以包括一个或多个模块,便于处理组件802和其他组件之间的交互。例如,处理组件802可以包括多媒体模块,以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(sram),电可擦除可编程只读存储器(eeprom),可擦除可编程只读存储器(eprom),可编程只读存储器(prom),只读存储器(rom),磁存储器,快闪存储器,磁盘或光盘。

电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统,一个或多个电源,及其他与为装置800生成、管理和分配电力相关联的组件。

多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中,屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中,多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式,如拍摄模式或视频模式时,前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件810被配置为输出和/或输入音频信号。例如,音频组件810包括一个麦克风(mic),当装置800处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中,音频组件810还包括一个扬声器,用于输出音频信号。

i/o接口812为处理组件802和外围接口模块之间提供接口,上述外围接口模块可以是键盘,点击轮,按钮等。这些按钮可包括但不限于:主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器,用于为装置800提供各个方面的状态评估。例如,传感器组件814可以检测到装置800的打开/关闭状态,组件的相对定位,例如所述组件为装置800的显示器和小键盘,传感器组件814还可以检测装置800或装置800一个组件的位置改变,用户与装置800接触的存在或不存在,装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器,被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器,如cmos或ccd图像传感器,用于在成像应用中使用。在一些实施例中,该传感器组件814还可以包括加速度传感器,陀螺仪传感器,磁传感器,压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络,如wifi,2g或3g,或它们的组合。在一个示例性实施例中,通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,所述通信组件816还包括近场通信(nfc)模块,以促进短程通信。例如,在nfc模块可基于射频识别(rfid)技术,红外数据协会(irda)技术,超宽带(uwb)技术,蓝牙(bt)技术和其他技术来实现。

在示例性实施例中,装置800可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现,用于执行上述方法。

在示例性实施例中,还提供了一种包括指令的非临时性计算机可读存储介质,例如包括指令的存储器804,上述指令可由装置800的处理器820执行以完成上述方法。例如,所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本公开的真正范围和精神由下面的权利要求指出。

应当理解的是,本公开并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

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