终端设备的处理类Handler的处理方法及电子设备与流程

本申请涉及软件开发技术领域，具体而言，本申请涉及一种终端设备的处理类handler的处理方法及电子设备。

背景技术：

随着互联网技术及移动通信技术的发展，用户不仅可以通过在智能手机、ipad等移动终端中的网页视图webview来查看、处理各种信息，而且可以通过在移动终端上安装与该webview相对应的客户端(例如各种各样的应用程序)，来访问、获取各种信息，或者对各种信息进行对应的处理操作。其中，当用户通过webview进行了某一处理操作(例如关注用户a)时，需要将用户的这一处理操作同步传递到与webview对应的客户端中，即在客户端中也同样进行“关注用户a”这一处理操作。同样的，当用户通过客户端进行了某一处理操作(例如对某一评论x点赞)时，需要将用户的这一处理操作同步传递到与客户端对应的webview中，即在webview中也同样进行“对某一评论x点赞”的处理操作。

本申请的发明人在具体实施过程中发现：目前都是通过jsbridge注册的处理类handler，来实现webview与对应客户端之间的事件传递，然而，目前通过jsbridge注册的处理类handler，都是通过相同接口的不同类型来进行分离的，这些不同类型可能归到了一个簇中，导致实际应用中存在解析层数较多、权限不易分离等问题。

技术实现要素：

本申请的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：

第一方面，提供了一种终端设备的处理类handler的处理方法，终端设备包括网页视图webview端与客户端，包括：

当检测到对webview端的第一处理操作时，确定第一处理操作对应的第一数据信息，并通过jsbridge调用第一预设方法将第一数据信息传递到对应客户端，第一预设方法是客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法；

客户端根据第一预设方法确定第一目标handler，并通过第一目标handler根据第一数据信息执行与webview端相对应的处理操作。

在一种实现方式中，在约定第一预设方法之前，还包括：

确定客户端的第一版本信息以及第一版本信息支持的与待约定方法相对应的handler的注册模式。

在另一种实现方式中，若第一版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第一预设方法是客户端基于第一注册模式的handler与webview端预先约定的方法；

若第一版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第一预设方法是客户端基于第二注册模式的handler与webview端预先约定的方法。

在另一种实现方式中，第一注册模式的handler是通过相同接口的不同类型进行分离的，且第一注册模式的handler根据权限归属于相应的权限簇；

第二注册模式的handler是根据各个类型各自对应的接口注册的，且不同第二注册模式的handler的权限是独立配置的。

在另一种实现方式中，还包括：

当检测到客户端的第一版本信息的更新时，移除更新版本后的客户端中的第一注册模式的handler。

第二方面，提供了一种终端设备的处理类handler的处理方法，终端设备包括网页视图webview端与客户端，包括：

当检测到对客户端的第二处理操作时，确定第二处理操作对应的第二数据信息，并通过jsbridge调用第二预设方法将第二数据信息传递到对应webview端，第二预设方法是webview端基于当前的第二版本信息支持的handler的注册模式与客户端预先约定的方法；

webview根据第二预设方法确定第二目标handler，并通过第二目标handler根据第二数据信息执行与客户端相对应的处理操作。

在一种实现方式中，若第二版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第二预设方法是webview端基于第一注册模式的handler与客户端预先约定的方法；

若第二版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第二预设方法是webview端基于第二注册模式的handler与客户端端预先约定的方法。

第三方面，提供了一种终端设备的处理类handler的处理装置，终端设备包括网页视图webview端与客户端，包括：

第一处理模块，用于当检测到对webview端的第一处理操作时，确定第一处理操作对应的第一数据信息，并通过jsbridge调用第一预设方法将第一数据信息传递到对应客户端，第一预设方法是客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法；

第二处理模块，用于客户端根据第一预设方法确定第一目标handler，并通过第一目标handler根据第一数据信息执行与webview端相对应的处理操作。

在另一种实现方式中，还包括确定模块；

确定模块，用于确定客户端的第一版本信息以及第一版本信息支持的与待约定方法相对应的handler的注册模式。

在另一种实现方式中，若第一版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第一预设方法是客户端基于第一注册模式的handler与webview端预先约定的方法；

若第一版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第一预设方法是客户端基于第二注册模式的handler与webview端预先约定的方法。

在另一种实现方式中，第一注册模式的handler是通过相同接口的不同类型进行分离的，且第一注册模式的handler根据权限归属于相应的权限簇；

第二注册模式的handler是根据各个类型各自对应的接口注册的，且不同第二注册模式的handler的权限是独立配置的。

在另一种实现方式中，还包括移除模块；

移除模块，用于当检测到客户端的第一版本信息的更新时，移除更新版本后的客户端中的第一注册模式的handler。

第四方面，提供了一种终端设备的处理类handler的处理装置，终端设备包括网页视图webview端与客户端，包括：

第三处理模块，用于当检测到对客户端的第二处理操作时，确定第二处理操作对应的第二数据信息，并通过jsbridge调用第二预设方法将第二数据信息传递到对应webview端，第二预设方法是webview端基于当前的第二版本信息支持的handler的注册模式与客户端预先约定的方法；

第四处理模块，用于webview根据第二预设方法确定第二目标handler，并通过第二目标handler根据第二数据信息执行与客户端相对应的处理操作。

在一种实现方式中，若第二版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第二预设方法是webview端基于第一注册模式的handler与客户端预先约定的方法；

若第二版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第二预设方法是webview端基于第二注册模式的handler与客户端端预先约定的方法。

第五方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的终端设备的处理类handler的处理方法。

第六方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的终端设备的处理类handler的处理方法。

本申请实施例提供的终端设备的处理类handler的处理方法，通过jsbridge调用客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法，将第一数据信息传递到对应客户端，使得可以根据客户端的版本信息定义相应的handler的注册模式，从而在将事件从webview端传递到客户端时，可以根据客户端的版本信息支持的handler的注册模式，来约定将webview端的处理操作对应的数据信息传递到对应客户端的方法，实现了handler的注册模式的多样化，不仅在一定程度上避免了通过相同接口的不同类型来进行分离的handler的注册模式的局限性，而且能够根据客户端的版本信息支持不同的handler的注册模式，实现了多种handler的注册模式的兼容及新老handler的注册模式的过渡。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例一的终端设备的处理类handler的处理方法的流程示意图；

图2为本申请实施例二的终端设备的处理类handler的处理方法的流程示意图；

图3为本申请实施例三的终端设备的处理类handler的处理装置的基本结构示意图；

图4为本申请实施例三的终端设备的处理类handler的处理装置的详细结构示意图；

图5为本申请实施例四的终端设备的处理类handler的处理装置的基本结构示意图；

图6为本申请实施例五的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

实施例一

本申请实施例提供了一种终端设备的处理类handler的处理方法，如图1所示，包括：

步骤s110，当检测到对webview端的第一处理操作时，确定第一处理操作对应的第一数据信息，并通过jsbridge调用第一预设方法将第一数据信息传递到对应客户端，第一预设方法是客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法。

具体地，当终端设备检测到用户在webview端对某个事件(例如点赞事件、关注事件等)的处理操作(即上述的第一处理操作)时，确定出与该处理操作相对应的数据信息，即确定出该处理操作所产生的数据信息，接着，通过jsbridge调用客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法(即上述的第一预设方法)，并通过该预先约定的方法将该处理操作所产生的数据信息，传递到该webview端对应的客户端，以使得客户端根据该数据信息同样进行某个事件(例如点赞事件、关注事件等)的处理操作。

步骤s120，客户端根据第一预设方法确定第一目标handler，并通过第一目标handler根据第一数据信息执行与webview端相对应的处理操作。

具体地，客户端接收到用户在webview端的处理操作所产生的数据信息后，根据与webview端预先约定的方法(即上述的第一预设方法)，确定该预先约定的方法所对应的handler(即上述的第一目标handler)，并通过该确定出的handler根据接收到的数据信息，执行与webview端相对应的处理操作，例如点赞事件的处理操作、关注事件的处理操作等，从而将事件从webview端传递到客户端。

本申请实施例提供的终端设备的处理类handler的处理方法，与现有技术相比，通过jsbridge调用客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法，将第一数据信息传递到对应客户端，使得可以根据客户端的版本信息定义相应的handler的注册模式，从而在将事件从webview端传递到客户端时，可以根据客户端的版本信息支持的handler的注册模式，来约定将webview端的处理操作对应的数据信息传递到对应客户端的方法，实现了handler的注册模式的多样化，不仅在一定程度上避免了通过相同接口的不同类型来进行分离的handler的注册模式的局限性，而且能够根据客户端的版本信息支持不同的handler的注册模式，实现了多种handler的注册模式的兼容及新老handler的注册模式的过渡。

本申请实施例提供了另一种可能的实现方式，其中，在步骤s110之前还包括步骤s100(图中未标注)：确定客户端的第一版本信息以及第一版本信息支持的与待约定方法相对应的handler的注册模式。

具体地，(1)若第一版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第一预设方法是客户端基于第一注册模式的handler与webview端预先约定的方法；(2)若第一版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第一预设方法是客户端基于第二注册模式的handler与webview端预先约定的方法。

其中，第一注册模式的handler是通过相同接口的不同类型进行分离的，且第一注册模式的handler根据权限归属于相应的权限簇，即第一注册模式的handler的权限是归于同一个权限簇的，由于权限归属于相应的权限簇，因此无法对单个handler的权限进行配置，而且当类型较多时，权限的分离将会比较复杂、解析层数较多。

第二注册模式的handler是根据各个类型各自对应的接口注册的，且不同第二注册模式的handler的权限是独立配置的，从而实现了将每个类型单独抽出来，各自对应一个handler，从而使得可以对各个handler的权限单独进行配置，进而降低解析层数。

下面对本实现方式涉及的内容进行如下详细介绍：

假如从5.0版本的客户端开始出现了第二注册模式的handler，且5.0版本的客户端中关于点赞事件支持的仍是原始的第一注册模式的handler、5.0版本的客户端中关于关注事件支持的是改进后的第二注册模式的handler，则：

1、当终端设备检测到用户在webview端进行了点赞事件的处理操作时，首先确定终端设备当前安装的客户端的版本信息(例如5.0版本)以及该版本信息所支持的传递点赞事件的方法的handler为第一注册模式的handler，接着确定出点赞事件的处理操作对应的数据信息，并通过jsbridge调用客户端基于当前的版本信息支持的handler的注册模式与webview端预先约定的方法，接着通过该预先约定的方法将该点赞事件的处理操作所产生的数据信息，传递到该webview端对应的客户端，以使得客户端根据该数据信息同样进行点赞事件的处理操作。

2、当终端设备检测到用户在webview端进行了关注事件的处理操作时，首先确定终端设备当前安装的客户端的版本信息(例如5.0版本)以及该版本信息所支持的传递关注事件的方法的handler为第二注册模式的handler，接着确定出关注事件的处理操作对应的数据信息，并通过jsbridge调用客户端基于当前的版本信息支持的handler的注册模式与webview端预先约定的方法，接着通过该预先约定的方法将该关注事件的处理操作所产生的数据信息，传递到该webview端对应的客户端，以使得客户端根据该数据信息同样进行关注事件的处理操作。

其中，由于5.0版本的客户端中关于关注事件支持的是改进后的第二注册模式的handler，故可以在5.0版本的客户端中移除关于关注事件支持的原始的第一注册模式的handler，从而在5.0版本的客户端中只支持关于关注事件的第二注册模式的handler即可。随着客户端版本的不断升级，假如客户端版本升级到了5.1版本，且5.1版本的客户端中关于点赞事件支持的是改进后的第二注册模式的handler，故可以在5.1版本的客户端中移除关于点赞事件支持的原始的第一注册模式的handler，从而在5.1版本的客户端中只支持关于点赞事件的第二注册模式的handler即可。另外，由于5.0版本的客户端已经支持关于关注事件的第二注册模式的handler，因此在没有更好注册模式的handler的情况下，5.1版本的客户端可以延续使用5.0版本的客户端中关于关注事件的第二注册模式的handler。

随着客户端版本的不断更新及第二注册模式的handler的使用面的逐渐普及，可以在更新后的客户端中逐渐移除更新版本前的第一注册模式的handler，即随着版本的升级，逐渐移除原始的第一注册模式的handler，并且当版本升级到一定程度时，例如目前客户端已经升级到了7.0版本，此时7.0版本的客户端可能已经全面支持第二注册模式的handler，于是可以将刚开始区分第一注册模式的handler与第二注册模式的handler的5.0版本的客户端彻底关闭，不再投入人力、物力、财力等对其进行维护。

通过上述方法，实现了在客户端升级过程中逐渐由第一注册模式的handler过渡到第二注册模式的handler，提供了一种从仅支持单注册模式(第一注册模式的handler)的客户端，到支持多注册模式(第一注册模式的handler与第二注册模式的handler)的客户端的迁移方案。

实施例二

本申请实施例提供了一种终端设备的处理类handler的处理方法，如图2所示，包括：

步骤s210，当检测到对客户端的第二处理操作时，确定第二处理操作对应的第二数据信息，并通过jsbridge调用第二预设方法将第二数据信息传递到对应webview端，第二预设方法是webview端基于当前的第二版本信息支持的handler的注册模式与客户端预先约定的方法。

具体地，当终端设备检测到用户在客户端对某个事件(例如点赞事件、关注事件等)的处理操作(即上述的第二处理操作)时，确定出与该处理操作相对应的数据信息，即确定出该处理操作所产生的数据信息，接着，通过jsbridge调用客户端基于当前的第二版本信息支持的handler的注册模式与webview端预先约定的方法(即上述的第二预设方法)，并通过该预先约定的方法将该处理操作所产生的数据信息，传递到该客户端对应的webview端，以使得webview端根据该数据信息同样进行某个事件(例如点赞事件、关注事件等)的处理操作。

步骤s220，webview根据第二预设方法确定第二目标handler，并通过第二目标handler根据第二数据信息执行与客户端相对应的处理操作。

具体地，webview端接收到用户在客户端的处理操作所产生的数据信息后，根据与客户端预先约定的方法(即上述的第二预设方法)，确定该预先约定的方法所对应的handler(即上述的第二目标handler)，并通过该确定出的handler根据接收到的数据信息，执行与客户端相对应的处理操作，例如点赞事件的处理操作、关注事件的处理操作等，从而将事件从客户端传递到webview端。

本申请实施例提供的终端设备的处理类handler的处理方法，与现有技术相比，通过jsbridge调用webview端基于当前的版本信息支持的handler的注册模式与客户端预先约定的方法，将第二数据信息传递到对应webview端，使得客户端可以根据当前的版本信息定义相应的handler的注册模式，从而在将事件从客户端传递到webview端时，可以根据客户端的版本信息支持的handler的注册模式，来约定将客户端的处理操作对应的数据信息传递到对应webview端的方法，实现了handler的注册模式的多样化，不仅在一定程度上避免了通过相同接口的不同类型来进行分离的handler的注册模式的局限性，而且能够根据客户端的版本信息支持不同的handler的注册模式，实现了多种handler的注册模式的兼容及新老handler的注册模式的过渡。

在另一种可能的实现方式中，(1)若第二版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第二预设方法是webview端基于第一注册模式的handler与客户端预先约定的方法；(2)若第二版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第二预设方法是所述webview端基于第二注册模式的handler与客户端端预先约定的方法。

本申请实施例所实现的方法，与上述实施例一所实现的方法类似，两者的区别仅在于：

上述实施例一中实现的是：将检测到的用户在webview端对某个事件的处理操作，传递到与该webview端相对应的客户端，在客户端也同步进行该某个事件的处理操作。

本申请实施例实现的是：将检测到的用户在客户端对某个事件的处理操作，传递到与该客户端相对应的webview端，在webview端也同步进行该某个事件的处理操作。

除此之外，本申请实施例中涉及到的内容与原理与上述实施例一中涉及的内容与原理相同，换言之，上述实施例一中涉及的内容、实现原理等同样适应于本申请实施例，在此不再赘述。

实施例三

图3为本申请实施例提供的一种终端设备的处理类handler的处理装置的基本结构示意图，如图3所示，该装置30可以包括第一处理模块31与第二处理模块32，其中，

第一处理模块31用于当检测到对webview端的第一处理操作时，确定第一处理操作对应的第一数据信息，并通过jsbridge调用第一预设方法将第一数据信息传递到对应客户端，第一预设方法是客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法；

第二处理模块32用于客户端根据第一预设方法确定第一目标handler，并通过第一目标handler根据第一数据信息执行与webview端相对应的处理操作。

此外，图4提供了一种终端设备的处理类handler的处理装置的详细结构示意图，其中，装置40中包括第一处理模块41、第二处理模块42、确定模块43及移除模块44。其中，第一处理模块41与图3中的第一处理模块31所实现的功能相同，第二处理模块42与图3中的第二处理模块32所实现的功能相同，在此不再赘述。

其中，确定模块43用于确定客户端的第一版本信息以及第一版本信息支持的与待约定方法相对应的handler的注册模式。

在一种实现方式中，若第一版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第一预设方法是客户端基于第一注册模式的handler与webview端预先约定的方法。

若第一版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第一预设方法是客户端基于第二注册模式的handler与webview端预先约定的方法。

在另一种实现方式中，第一注册模式的handler是通过相同接口的不同类型进行分离的，且第一注册模式的handler根据权限归属于相应的权限簇；

第二注册模式的handler是根据各个类型各自对应的接口注册的，且不同第二注册模式的handler的权限是独立配置的。

在另一种实现方式中，还包括移除模块44，其中，移除模块44用于当检测到客户端的第一版本信息的更新时，移除更新版本后的客户端中的第一注册模式的handler。

本申请实施例提供的装置，与现有技术相比，通过jsbridge调用客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法，将第一数据信息传递到对应客户端，使得可以根据客户端的版本信息定义相应的handler的注册模式，从而在将事件从webview端传递到客户端时，可以根据客户端的版本信息支持的handler的注册模式，来约定将webview端的处理操作对应的数据信息传递到对应客户端的方法，实现了handler的注册模式的多样化，不仅在一定程度上避免了通过相同接口的不同类型来进行分离的handler的注册模式的局限性，而且能够根据客户端的版本信息支持不同的handler的注册模式，实现了多种handler的注册模式的兼容及新老handler的注册模式的过渡。

实施例四

图5为本申请实施例提供的一种终端设备的处理类handler的处理装置的基本结构示意图，如图5所示，该装置50可以包括第三处理模块51与第四处理模块52，其中，

第三处理模块51用于当检测到对客户端的第二处理操作时，确定第二处理操作对应的第二数据信息，并通过jsbridge调用第二预设方法将第二数据信息传递到对应webview端，第二预设方法是webview端基于当前的第二版本信息支持的handler的注册模式与客户端预先约定的方法；

第四处理模块52用于webview根据第二预设方法确定第二目标handler，并通过第二目标handler根据第二数据信息执行与客户端相对应的处理操作。

在一种实现方式中，若第二版本信息支持的与待约定方法相对应的handler的注册模式为第一注册模式，则第二预设方法是webview端基于第一注册模式的handler与客户端预先约定的方法；

若第二版本信息支持的与待约定方法相对应的handler的注册模式为第二注册模式，则第二预设方法是webview端基于第二注册模式的handler与客户端端预先约定的方法。

本申请实施例提供的装置，与现有技术相比，通过jsbridge调用webview端基于当前的版本信息支持的handler的注册模式与客户端预先约定的方法，将第二数据信息传递到对应webview端，使得客户端可以根据当前的版本信息定义相应的handler的注册模式，从而在将事件从客户端传递到webview端时，可以根据客户端的版本信息支持的handler的注册模式，来约定将客户端的处理操作对应的数据信息传递到对应webview端的方法，实现了handler的注册模式的多样化，不仅在一定程度上避免了通过相同接口的不同类型来进行分离的handler的注册模式的局限性，而且能够根据客户端的版本信息支持不同的handler的注册模式，实现了多种handler的注册模式的兼容及新老handler的注册模式的过渡。

实施例五

下面参考图6，其示出了适于用来实现本申请实施例的电子设备600的结构示意图。本申请实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、pda(个人数字助理)、pad(平板电脑)、pmp(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字tv、台式计算机等等的固定终端。图6示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(rom)602中的程序或者从存储装置608加载到随机访问存储器(ram)603中的程序而执行各种适当的动作和处理。在ram603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、rom602以及ram603通过总线604彼此相连。输入/输出(i/o)接口605也连接至总线604。

通常，以下装置可以连接至i/o接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(lcd)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从rom602被安装。在该计算机程序被处理装置601执行时，执行本申请实施例的方法中限定的上述功能。

需要说明的是，本申请上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、rf(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：当检测到对webview端的第一处理操作时，确定第一处理操作对应的第一数据信息，并通过jsbridge调用第一预设方法将第一数据信息传递到对应客户端，第一预设方法是客户端基于当前的第一版本信息支持的handler的注册模式与webview端预先约定的方法；客户端根据第一预设方法确定第一目标handler，并通过第一目标handler根据第一数据信息执行与webview端相对应的处理操作。

或者使得该电子设备：当检测到对客户端的第二处理操作时，确定第二处理操作对应的第二数据信息，并通过jsbridge调用第二预设方法将第二数据信息传递到对应webview端，第二预设方法是webview端基于当前的第二版本信息支持的handler的注册模式与客户端预先约定的方法；webview根据第二预设方法确定第二目标handler，并通过第二目标handler根据第二数据信息执行与客户端相对应的处理操作。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)——连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。