通过移动浏览器唤醒APP应用的方法及装置与流程

本申请涉及通信领域，尤其涉及一种通过移动浏览器唤醒APP应用的方法及装置。

背景技术：

在Android移动端的业务中，有一种常见的应用场景是用户在发起方的应用或者浏览器中进行一个业务流程，这个业务流程需要调用第三方APP应用的一些功能；例如，第三方支付，第三方登录，等等。

当用户在发起方的APP应用或者移动浏览器中跳转到第三方APP，并应用完成相应的业务流程后，用户通常会具有返回发起方的APP应用或者移动浏览器中继续完成相应的业务流程的需求。

在实际应用中，当发起方为用户移动终端上的APP应用时，通常可以基于Android系统中APP应用之间的跳转机制来返回至发起方的APP应用。然后，当发起方为用户移动终端上的移动浏览器时，通常会存在第三方APP应用完成相应的业务后，无法自动返回至移动浏览器的问题。

技术实现要素：

本申请提出一种通过移动浏览器唤醒APP应用的方法，该方法包括：

接收移动浏览器在发起针对目标APP的业务调用时提交的第一调用数据；所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

基于所述自定义参数唤醒所述目标APP执行相应的目标业务，并将所述移动浏览器的标识信息传递至所述目标APP；

当所述目标业务执行完毕后，响应于所述目标APP提交的携带所述移动浏览器的包名信息的第二调用数据，返回所述移动浏览器。

可选的，所述移动浏览器的标识信息还包括移动浏览器的User Agent信息；

其中，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

可选的，所述第二调用数据为所述目标APP基于所述移动浏览器的包名信息构建的用于唤醒所述移动浏览器的Intent；

所述响应于所述目标APP提交的携带所述移动浏览器的包名信息的第二调用数据，返回所述移动浏览器包括：

接收所述目标APP提交的基于所述移动浏览器的包名信息构建的Intent；

向系统服务器查询与所述移动浏览器的包名信息对应的Activity组件；

调用与所述移动浏览器对应的Activity组件，以返回所述移动浏览器。

本申请还提出一种通过移动浏览器唤醒APP应用的方法，该方法包括：

在发起针对目标APP的业务调用时，获取移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

向系统提交针对所述目标APP的第一调用数据；其中，所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息，以使得所述系统基于所述自定义参数唤醒所述目标APP，并在所述目标APP完成对应的目标业务时响应于所述目标APP提交的携带所述移动浏览器的包名信息的Intent返回所述移动浏览器。

可选的，所述在发起针对目标APP的业务调用时，获取移动浏览器的标识信息包括：

获取所述移动浏览器的User Agent信息；

基于所述移动浏览器的User Agent信息向系统服务器查询所述移动浏览器的包名信息。

可选的，所述移动浏览器的标识信息还包括所述移动浏览器的User Agent信息；

其中，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

可选的，所述第一调用数据包括基于Schema协议定义的url；

所述在发起针对目标APP的业务调用时，向系统提交针对所述目标APP的第一调用数据包括：

在发起针对目标APP的业务调用时，基于Schema协议定义url；

将用于唤起所述目标APP的目标业务界面的自定义参数，以及所述移动浏览器的标识信息封装至定义的所述url；

调用系统接口，向系统提交所述url。

本申请还提出一种通过移动浏览器唤醒APP应用的装置，该装置包括：

接收模块，用于接收移动浏览器在发起针对目标APP的业务调用时提交的第一调用数据；所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

唤醒模块，用于基于所述自定义参数唤醒所述目标APP执行相应的目标业务，并将所述移动浏览器的标识信息传递至所述目标APP；

响应模块，用于在所述目标业务执行完毕后，响应于所述目标APP提交的携带所述移动浏览器的包名信息的第二调用数据，返回所述移动浏览器。

可选的，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

可选的，所述第二调用数据为所述目标APP基于所述移动浏览器的包名信息构建的用于唤醒所述移动浏览器的Intent；

所述响应模块具体用于：

接收所述目标APP提交的基于所述移动浏览器的包名信息构建的Intent；

向系统服务器查询与所述移动浏览器的包名信息对应的Activity组件；

调用与所述移动浏览器对应的Activity组件，以返回所述移动浏览器。

本申请还提出一种通过移动浏览器唤醒APP应用的装置，该装置包括：

获取模块，用于在发起针对目标APP的业务调用时，获取移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

提交模块，用于向系统提交针对所述目标APP的第一调用数据；其中，所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息，以使得所述系统基于所述自定义参数唤醒所述目标APP，并在所述目标APP完成对应的目标业务时响应于所述目标APP提交的携带所述移动浏览器的包名信息的Intent返回所述移动浏览器。

可选的，所述获取模块具体用于：

获取所述移动浏览器的User Agent信息；

基于所述移动浏览器的User Agent信息向系统服务器查询所述移动浏览器的包名信息。

可选的，所述移动浏览器的标识信息还包括所述移动浏览器的User Agent信息；

其中，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

可选的，所述第一调用数据包括基于Schema协议定义的url；

所述提交模块具体用于：

在发起针对目标APP的业务调用时，基于Schema协议定义url；

将用于唤起所述目标APP的目标业务界面的自定义参数，以及所述移动浏览器的标识信息封装至定义的所述url；

调用系统接口，向系统提交所述url。

本申请中，业务发起方的移动浏览器在发起针对目标APP的业务调用时，通过在调用数据中携带移动浏览器的包名信息，并通过系统将该包名信息传递给目标APP，使得目标APP在完成相应的目标业务后，可以向系统提交携带包名信息的Intent，以由系统响应该Intent返回至业务发起方的移动浏览器，实现了用户在通过调用第三方的目标APP完成业务后，可以自动返回发起方的移动浏览器，而不需要由用户手动选择返回的移动浏览器，从而可以提升用户体验。

附图说明

图1是本申请一实施例提供的一种通过移动浏览器唤醒APP应用的方法的流程图；

图2是本申请一实施例示出的业务前置页面获取移动浏览器的User Agent信息的JavaScript代码示例；

图3是本申请一实施例示出的系统服务器上维护的服务器列表的存储示意图；

图4是本申请一实施例示出的基于Schema协议定义的url唤醒支付宝钱包APP的JavaScript代码示例；

图5是本申请一实施例示出的目标APP基于业务发起方的移动浏览器的Package Name构建的Intent的Java代码示例

图6是本申请一实施例提供的一种通过移动浏览器唤醒APP应用的装置的逻辑框图；

图7是本申请一实施例提供的承载所述一种通过移动浏览器唤醒APP应用的装置的移动终端的硬件结构图；

图8是本申请一实施例提供的另一种通过移动浏览器唤醒APP应用的装置的逻辑框图；

图9是本申请一实施例提供的承载所述另一种通过移动浏览器唤醒APP应用的装置的移动终端的硬件结构图。

具体实施方式

在Android系统中，业务发起方的移动浏览器在针对第三方APP进行业务调用时，通常可以基于Schema协议定义url(Uniform Resoure Locator，统一资源定位器)，通过定义的该url来唤醒该第三方APP的业务界面来执行相应的业务流程。

其中，Schema协议，是一种Android系统兼容的协议。

移动浏览器在针对第三方APP进行业务调用时，可以基于Schema协议定义用于唤醒该APP的url，并在该url中封装用于唤起该APP指定的业务界面的自定义参数，然后通过系统API接口将该url提交至Android系统。Android系统在收到该url后，可以解析Schema协议，通过该url中封装的自定义参数来唤醒该APP指定的业务界面来执行业务调用。

当用户通过业务发起方的移动浏览器发起针对第三方APP的业务调用，并在唤起的该APP的指定业务界面中完成相应的业务流程后，用户通常会具有返回业务发起方的移动浏览器中继续完成其原有的业务流程的需求。

例如，假设用户通过移动浏览器中的购物界面发起针对第三方的支付APP的业务调用，并在唤起的APP的支付界面中完成支付后，用户通常需要返回移动浏览器的购物完成的界面中继续后续的流程。

在现有的Android平台中，在实现APP应用之间的跳转时，通常是通过构建Intent(意图)来实现的。

其中，Intent是Android系统中定义的一种用于负责Android应用的各项组件之间的通讯的方法。Intent负责对两个组件在执行一次操作的动作、动作涉及的数据、附加数据进行描述，用于提供组件互相调用的相关信息。

当用户通过业务发起方的移动浏览器发起针对第三方APP的业务调用，并在唤起的该APP的指定业务界面中完成相应的业务流程后，该APP可以向android系统提交用于跳转至移动浏览器的Intent；android系统则可以解析该Intent中携带的参数进行Intent匹配，调用与匹配到的Intent对应的其它APP的Activity组件，以跳转至其它APP的指定页面。

然而，由于移动浏览器基于Schema协议定义的url中，通常并不支持携带应用的来源信息，因此android系统在基于APP提交的Intent中携带的参数进行Intent匹配时，可能会由于该移动浏览器的信息不足，无法精准的匹配到业务发起方的移动浏览器。

在这种情况下，android系统通常会将系统中所有的移动浏览器全部唤醒，并面向用户弹出一个浏览器选择窗口，由用户手动选择需要返回的移动浏览器。

可见，在以上方案中至少存在以下不足：

第一方面，由于android系统无法自动返回至业务发起方的移动浏览器，需要用户进行手动选择，因此操作繁琐，用户体验不佳。

第二方面，由于android系统中的移动浏览器种类繁多(比如，系统默认的原声浏览器，QQ浏览器，UC浏览器，360浏览器，等等)，而用户并非熟知这些浏览器，因此用户手动选择的移动浏览器可能并不是原有的业务发起方的移动浏览器。

第三方便：移动浏览器等web应用中，通常会通过cookie记录用户操作的状态(比如，用户的登录状态，安全控件校验状态，等等)，若用户选择的移动浏览器并非原有的业务发起方的移动浏览器，在另外一个移动浏览器中继续业务流程时，用户需要重新通过额外的操作来恢复这些状态，从而会进一步增加用户的操作流程，影响用户体验。

有鉴于此，本申请提出一种通过移动浏览器唤醒APP应用的方法，业务发起方的移动浏览器在发起针对目标APP的业务调用时，通过在调用数据中携带移动浏览器的包名信息，并通过系统将该包名信息传递给目标APP，使得目标APP在完成相应的目标业务后，可以向系统提交携带包名信息的Intent，以由系统响应该Intent返回至业务发起方的移动浏览器，实现了用户在通过调用第三方的目标APP完成业务后，可以自动返回发起方的移动浏览器，而不需要由用户手动选择返回的移动浏览器，从而可以提升用户体验。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1，图1是本申请一实施例提供的一种通过移动浏览器唤醒APP应用的方法，应用于移动终端，其中所述移动终端可以搭载android系统，并在android系统中安装了移动浏览器和至少一个目标APP应用，移动浏览器与android系统进行交互，执行以下步骤：

步骤101，移动浏览器在发起针对目标APP的业务调用时，获取移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

在本例中，移动浏览器针对目标APP的业务调用，可以由用户在该移动浏览器本地的业务界面中进行手动触发。

在示出的一种实施方式中，在移动浏览器本地的业务界面中，可以预先提供一可供用户进行操作的用户选项；其中，该用户选项具体可以是一交互按钮，也可以是一链接；例如，以用户通过移动浏览器本地的购物界面，发起针对支付宝钱包APP的业务调用执行支付流程的场景为例，上述用户选项可以是上述购物界面中提供的一个“使用支付宝支付”的交互按钮，也可以是一可以触发跳转至支付宝钱包APP的支付界面的链接。

用户可以通过在上述业务界面中针对上述用户选项执行触摸操作，来触发移动浏览器发起针对第三方的目标APP应用的业务调用。当移动浏览器在后台监听到用户针对上述用户选项的触摸事件后，可以立即通过android系统发起针对该目标APP应用的业务接口调用。

该目标APP应用在收到针对本地业务接口的调用请求后，可以向移动浏览器返回相应的业务前置界面的url，业务浏览器在收到该url后，可以跳转到相应的业务前置界面。

其中，上述业务前置界面，具体是指加载在移动浏览器上的，用于执行第三方的目标APP应用中的业务的web页面。在实际应用中，该业务前置界面的具体功能，可以由移动浏览器的供应商与第三方的目标APP的供应商相互合作联合开发。

例如，仍以用户通过移动浏览器本地的购物界面，发起针对支付宝钱包APP的业务调用执行支付流程的场景为例，上述业务前置页面可以是移动浏览器的供应商与支付宝钱包APP的供应商联合开发的一个用于调用支付宝钱包APP执行支付的业务入口界面。在该业务入口界面中，可以显示本次支付的金额、购买的物品的详情等信息，用户可以通过该界面中显示的信息对本次支付进行核对。

在本例中，当移动浏览器跳转至上述业务前置页面后，此时该业务前置页面作为业务执行的前端，可以获取作为业务发起方的该移动浏览器的标识信息。

其中，在实现时，上述移动浏览器的标识信息可以包括该移动浏览器的Package Name(包名信息)或者User Agent(用户代理)信息。Package Name是android系统为系统中每一个APP定义的唯一标识。User Agent信息通常记录了浏览器的名称以及版本等信息。移动浏览器的版本信息通常包含该移动浏览器的搭载的系统环境等信息，

在示出的一种实施方式中，当上述移动浏览器的标识信息为User Agent信息时，上述业务前置页面可以通过执行该业务前置页面中加载的JavaScript代码直接获取上述移动浏览器的User Agent信息即可。

例如，请参见图2，图2为本例示出的业务前置页面获取移动浏览器的User Agent信息的JavaScript代码示例。

在图2示出的代码示例中，ua＝navigator.userAgent用于返回移动浏览器的名称；version＝navigator.appVersion用于返回移动浏览器搭载的系统环境信息。

在示出的另一种实施方式中，当上述移动浏览器的标识信息为Package Name时，上述业务前置页面在获取当前的移动浏览器的Package Name时，可以将获取到的该User Agent信息作为索引向android系统的系统服务器查询该移动浏览器的Package Name。

在上述系统服务器上可以预先维护一存储了移动浏览器的User Agent信息、移动浏览器的Package Name以及移动浏览器的主用Activity组件映射关系的服务列表。

上述业务前置页面在获取到当前的移动浏览器的User Agent信息后，可以将该移动浏览器的User Agent信息发送至上述系统服务器。

其中，上述业务前置页面在将该移动浏览器的User Agent信息发送至上述系统服务器时，可以通过与上述系统服务器之间的AJAX接口，将上述移动浏览器的User Agent信息以请求的形式上传至上述系统服务器。

当上述系统服务器收到上述业务前置页面发送的User Agent信息后，可以将该User Agent信息作为索引在上述服务列表中查询对应的Package Name，然后将查询到的Package Name返回至上述业务前置页面。

例如，请参见图3，图3为本例示出的上述系统服务器上维护的上述服务器列表的存储示意图。

上述系统服务器在基于User Agent信息查询对应的Package Name时，首先可以从该User Agent信息中读取移动浏览器的版本信息；该移动浏览器的版本信息通常包含该移动浏览器的版本以及搭载的系统环境等信息，上述系统服务器可以基于读取到的上述搭载的系统环境等信息在上述服务列表中确定该移动浏览器的类别，比如确定该移动浏览器的底层搭载环境是基于android系统还是Ios系统，当确定了该移动浏览器的类别后，可以进一步根据上述User Agent信息中的移动浏览器名称来查询对应的Package Name，此时查询到的该Package Name即为该移动浏览器在android系统中的唯一标识，上述系统服务器可以将该Package Name返回至上述业务前置页面。

步骤102，向系统提交针对所述目标APP的第一调用数据；其中，所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息；

步骤103，系统接收移动浏览器在发起针对目标APP的业务调用时提交的第一调用数据；

在示出的一种实施方式中，上述第一调用数据可以是上述业务前置页面基于Schema协议定义的url。

上述业务前置页面在发起针对上述目标APP应用的业务调用时：

一方面，上述业务前置页面可以基于Schema协议定义一个用于唤醒上述目标APP的url，并将预先定义的用于唤起上述目标APP的目标业务界面的自定义参数封装至该url中。

另一方面，上述业务前置页面还可以将获取到的当前的移动浏览器的标识信息，作为需要传递至上述目标APP应用的额外参数也一并封装至上述url中。当然，在实际应用中，也可以对android系统支持的Schema协议进行改进，使得Schema协议支持自带业务发起方应用的诸如package name等来源信息，从而通过这种方式，基于Schema协议定义的url中默认会自带业务发起方的移动浏览器的package name，而不再需要将package name作为额外参数封装至上述url中。

例如，以用户通过移动浏览器通过Intent协议发起针对支付包钱包APP的业务调用，以及上述移动浏览器的标识信息为package name为例，上述业务前置页面基于Schema协议定义的上述用于唤醒支付宝钱包APP的url可以是如下所示：

url＝intent：//schemeapi/startapp？+patams+#Intent；scheme＝+

encodeURIComponent(zmverify)+；package＝com.mobile.android；

其中，在上述url中，“intent：//schemeapi/startapp”为基于scheme定义的协议头。参数标识符？后的“+patams+#Intent；scheme＝+

encodeURIComponent(zmverify)”为用于唤起支付宝钱包APP中与支付页面对应的Activity组件的自定义参数，android系统可以通过将以上各参数与注册在系统配置文件中的与支付宝钱包APP的Activity组件对应的Intent进行匹配，来定位需要唤起的Activity组件。“package＝com.mobile.android；”为需要传递给支付宝钱包APP的上述移动浏览器的package name。

在本例中，上述业务前置页面基于Schema协议定义的上述url，可以由上述业务前置页面通过调用API系统接口以请求的形式提交至android系统。

其中，上述业务前置页面在向android系统提交上述目标APP的业务调用时，可以由用户在该业务前置页面中进行手动触发。

在示出的一种实施方式中，在该业务前置页面中，可以预先提供一可供用户进行操作的用户按钮，用户可以针对该用户按钮进行触摸操作，来触发该业务前置页面将上述url以请求的形式提交至android系统。

例如，仍以用户通过移动浏览器本地的购物界面，发起针对支付宝钱包APP的业务调用执行支付流程的场景，以及业务发起方的移动浏览器的标识信息为package name为例，上述业务前置页面中可以提供的一“使用支付宝支付”的用户按钮，该用户按钮可以预先绑定如图4所示出的JavaScript代码中定义的执行方法。

用户可以通过“点击”该用户按钮，触发上述业务前置页面调用与该用户按钮绑定的上述执行方法，调用API系统接口将该url以请求的形式提交至android系统。

其中，在图4所示出的JavaScript代码中，zmVerifyUrl为上述业务前置页面基于Schema协议定义的用于唤醒支付宝钱包APP的url；标签“a”对应上述用户按钮，“openIntentLink.dispatchEvent(ZmVerify.customClickEvent())”表示为标签“a”绑定一个用户点击事件(custom Click Event)，当监听到针对与标签“a”对应上述用户按钮的用户点击事件时，则将上述url以请求的形式提交至android系统。

当android系统接收到上述业务前置页面提交的url后，可以通过解析上述业务前置页面提交的url，获取到该url中携带的上述自定义参数，以及业务发起方的移动浏览器的标识信息。

步骤104，基于所述自定义参数唤醒所述目标APP执行相应的目标业务，并将所述移动浏览器的标识信息传递至所述目标APP。

在本例中，当android系统通过解析上述业务前置页面提交的url，获取到该url中上述自定义参数，以及业务发起方的移动浏览器的标识信息后：

一方面，android系统可以将该url中的自定义参数，与注册在系统配置文件(比如，该系统配置文件可以是android系统中的AndroidManifest.xml文件)中的与支付宝钱包APP的Activity组件对应的Intent进行匹配，来定位需要唤起的Activity组件。当匹配到系统文件中注册的任一Intent时，此时android系统可以立即调用与该Intent对应的Activity组件，以跳转至上述目标APP应用的目标业务界面。

另一方面，当android系统调用了与匹配到的Intent对应的上述目标APP应用的Activity组件后，还可以将上述url中封装的业务发起方的移动浏览器的标识信息传递至上述目标APP应用。

其中，需要说明的是，如果上述业务前置页面提交给android系统的业务发起方的移动浏览器的标识信息为User Agent信息时，此时上述目标APP应用，可以将接收到的该User Agent信息发送至android系统的系统服务器，由该系统服务器将该User Agent信息作为索引，在其本地维护的存储了移动浏览器的User Agent信息、移动浏览器的Package Name以及移动浏览器的主用Activity组件映射关系的服务列表中查询对应的Package Name，并将查询到的Package Name返回至上述目标APP应用。

步骤105，当所述目标业务执行完毕后，响应于所述目标APP提交的携带所述移动浏览器的包名信息的第二调用数据，返回所述移动浏览器。

在示出的一种实施方式中，上述第二调用数据可以是上述目标APP应用基于移动浏览器的包名信息构建的用于唤醒业务发起方的移动浏览器的Intent。

当android系统通过调用与匹配到的Intent对应的Activity组件，跳转至上述目标APP应用的目标业务界面后，此时用户可以在该目标业务界面中执行后续的业务流程。

例如，当上述目标APP应用为支付宝钱包APP时，上述目标业务界面可以是支付宝钱包APP的支付界面，用户可以在该支付界面中输入支付密码来完成支付。

当用户在跳转后的上述目标业务界面中完成目标业务的业务流程后：

一方面，上述目标APP应用可以将业务执行结果推送给业务发起方的移动浏览器，以触发上述移动浏览器跳转至业务结束页面。

另一方面，上述目标APP应用可以基于由android系统传递的该业务发起方的移动浏览器的Package Name，或者通过系统服务查询到的该业务发起方的移动浏览器的Package Name，来构建Intent，并通过向android系统提交该Intent来触发android系统基于该Intent调用发起方的移动浏览器的主用Activity组件，以返回业务发起方的移动浏览器。

例如，图5为本例示出的上述目标APP基于业务发起方的移动浏览器的Package Name构建的Intent的Java代码示例。在如图5所示出的代码示例中，“new ComponentName(Package Name，appName)”为构建的该Intent的完整名称；“android.intent.action.View”，为android系统支持的标准intent，表示打开浏览器程序并显示url；“intent.FLAG_ACTIVITY_NEW_TASK”，也是android系统支持的标准intent，表示调用与上述Package Name对应的Activity组件，将该Activity组件压入android系统维护的Activity堆栈顶部(Activity组件是指系统显示的交互窗口，将Activity压入堆栈顶部是指将与该Activity对应的交互窗口移动到android系统桌面的最上层)。

在图5所示出的代码示例中，由于在ComponentName中指定了业务发起方浏览器的Package Name，android系统可以基于Package Name精确定位到需要调用的Activity组件，因此此时android系统将进行Intent显示调用(Intent调用划分为显式调用和隐式调用，明确了被调用方的Activity组件称之为显示调用；反之，为明确被调用方的Activity组件，通过Intent中定义的属性参数进行匹配来定位并调用Activity组件称之为隐式调用)。

在本例中，当android系统接收到上述目标APP在完成目标业务的业务流程后提交的Intent后，可以解析该Intent，获取该Intent中携带的业务发起方的移动浏览器的Package Name，并将该Package Name上传至系统服务器，由于系统服务器将该Package Name作为索引，在其本地维护的存储了移动浏览器的User Agent信息、移动浏览器的Package Name以及移动浏览器的主用Activity组件映射关系的服务列表中查询该移动浏览器的主用Activity组件，然后将查询到的主用Activity组件名称返回至上述android系统。

上述android系统在查询到业务发起方的移动浏览器的主用Activity组件后，可以响应上述目标APP应用提交的Intent，调用移动浏览器的主用Activity组件，将该移动浏览器的主用Activity组件压入android系统维护的Activity堆栈顶部，以返回业务发起方的移动浏览器。此时该移动浏览器的交互窗口将显示在系统桌面的最上层，用户在上述目标APP应用的目标业务界面中完成第三方的业务流程后，系统将会返回至业务发起方的移动浏览器的业务结束页面。

由于android系统在响应目标APP应用提交的Intent时，可以通过Package Name精确定位到需要调用的业务发起方的移动浏览器的主用Activity，因此可以执行Intent的显示调用，自动跳转至业务发起方的移动浏览器的业务结束页面，在整个过程中，不再需要通过系统弹出浏览器选择窗口，由用户手动选择需要返回的移动浏览器，从而可以提升用户体验。

在以上实施例中，业务发起方的移动浏览器在发起针对目标APP的业务调用时，通过在调用数据中携带移动浏览器的包名信息，并通过系统将该包名信息传递给目标APP，使得目标APP在完成相应的目标业务后，可以向系统提交携带包名信息的Intent，以由系统响应该Intent返回至业务发起方的移动浏览器；

由于目标APP提交的Intent中携带业务发起方的移动浏览器的包名信息，使得android系统可以基于包名信息精确定位到需要调用的Activity，因而android系统在响应该Intent可以执行Intent的显示调用，自动返回至业务发起方的移动浏览器，而不需要弹出浏览器选择窗口，由用户手动选择需要返回的移动浏览器，可以降低操作繁琐；同时还可以避免用户在手动选择了与业务发起方的移动浏览器不同的其它浏览器时，用户需要重新通过额外的操作来恢复浏览器记录的用户操作的状态的问题，可以提升用户体验。

与上述方法实施例相对应，本申请还提供了装置的实施例。

请参见图6，本申请提出一种通过移动浏览器唤醒APP应用的装置60，应用于android系统；其中，请参见图7，作为搭载所述android系统的移动终端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述通过移动浏览器唤醒APP应用的装置60通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置60包括：

接收模块601，用于接收移动浏览器在发起针对目标APP的业务调用时提交的第一调用数据；所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

唤醒模块602，用于基于所述自定义参数唤醒所述目标APP执行相应的目标业务，并将所述移动浏览器的标识信息传递至所述目标APP；

响应模块603，用于在所述目标业务执行完毕后，响应于所述目标APP提交的携带所述移动浏览器的包名信息的第二调用数据，返回所述移动浏览器。

在本例中，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

在本例中，所述第二调用数据为所述目标APP基于所述移动浏览器的包名信息构建的用于唤醒所述移动浏览器的Intent；

所述响应模块603具体用于：

接收所述目标APP提交的基于所述移动浏览器的包名信息构建的Intent；

向系统服务器查询与所述移动浏览器的包名信息对应的Activity组件；

调用与所述移动浏览器对应的Activity组件，以返回所述移动浏览器。

请参见图8，本申请提出一种通过移动浏览器唤醒APP应用的装置80，应用于移动浏览器；其中，请参见图9，作为搭载所述移动浏览器的移动终端所涉及的硬件架构中，通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等；以软件实现为例，所述通过移动浏览器唤醒APP应用的装置90通常可以理解为加载在内存中的计算机程序，通过CPU运行之后形成的软硬件相结合的逻辑装置，所述装置90包括：

获取模块801，用于在发起针对目标APP的业务调用时，获取移动浏览器的标识信息；所述标识信息包括所述移动浏览器的包名信息；

提交模块802，用于向系统提交针对所述目标APP的第一调用数据；其中，所述第一调用数据包括用于唤起所述目标APP的自定义参数以及所述移动浏览器的标识信息，以使得所述系统基于所述自定义参数唤醒所述目标APP，并在所述目标APP完成对应的目标业务时响应于所述目标APP提交的携带所述移动浏览器的包名信息的Intent返回所述移动浏览器。

在本例中，所述获取模块801具体用于：

获取所述移动浏览器的User Agent信息；

基于所述移动浏览器的User Agent信息向系统服务器查询所述移动浏览器的包名信息。

在本例中，所述移动浏览器的标识信息还包括所述移动浏览器的User Agent信息；

其中，当所述移动浏览器的标识信息为所述移动浏览器的User Agent信息时，所述移动浏览器的包名信息由所述目标APP基于所述移动浏览器的User Agent信息向系统服务器查询得到。

在本例中，所述第一调用数据包括基于Schema协议定义的url；

所述提交模块802具体用于：

在发起针对目标APP的业务调用时，基于Schema协议定义url；

将用于唤起所述目标APP的目标业务界面的自定义参数，以及所述移动浏览器的标识信息封装至定义的所述url；

调用系统接口，向系统提交所述url。

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

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

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