CN112187993B - 跨应用的关系链扩展方法、装置、设备以及存储介质 - Google Patents

Abstract

本申请实施例公开了一种跨应用的关系链扩展方法、装置、设备以及存储介质，涉及计算机技术领域以及云技术领域。该方法包括：响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；响应于针对第二联系人目录中目标联系人的确定操作，向目标联系人对应的第二应用客户端发送联系人添加请求；以在目标联系人对应的第二应用客户端发送同意添加指令后，将目标联系人添加在第一应用的第一联系人目录。采用本申请实施例，可提高跨应用的关系链扩展的便捷性，提升用户体验，适用性高。

Description

跨应用的关系链扩展方法、装置、设备以及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种跨应用的关系链扩展方法、装置、设备以及存储介质。

背景技术

随着计算机技术和应用的不断发展，多样化的应用已经成为用户休闲娱乐和工作必不可少的一部分，用户会选择不同的应用来进行工作、休闲以及娱乐等等。

由于应用的多样性，尤其对于通讯类的应用来说，不同的用户所选择的常用应用往往不同，由此可能会导致用户间沟通不畅。例如，在当前的应用中，用户通过某应用客户端只能向该应用的联系人发送消息，用户需要添加其他人作为其在该应用中的联系人时，往往需要通过其他方式告知被添加人，使得被添加人注册并登录该应用以完成添加联系人的过程。

因此，目标的应用的添加联系人的方法操作繁琐，用户体验差。

发明内容

本申请实施例提供一种跨应用的关系链扩展方法、装置、设备以及存储介质，可提高跨应用的关系链扩展的便捷性，提升用户体验。

第一方面，本申请实施例提供一种跨应用的关系链扩展方法，该方法包括：

响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；

响应于针对上述第二联系人目录中目标联系人的确定操作，向上述目标联系人对应的第二应用客户端发送联系人添加请求；以在上述目标联系人对应的第二应用客户端发送同意添加指令后，将上述目标联系人添加在上述第一应用的第一联系人目录。

在一种可能的实施方式中，上述响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示第二应用的第二联系人目录，包括：

响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示联系人添加提示信息；

响应于针对上述联系人添加提示信息的确认操作，在上述联系人添加界面中显示第二应用的第二联系人目录。

在一种可能的实施方式中，上述方法还包括：

在上述第一应用的添加详情界面中显示以下至少一项：

已发送联系人添加请求的联系人的相关信息；

未发送过联系人添加请求的联系人的相关信息。

第二方面，本申请实施例提供了一种跨应用的关系链扩展方法，上述方法包括：

获取输入的联系人添加指令；

响应于上述联系人添加指令，获取第二应用的第二联系人目录并发送至第一应用客户端，以在第一应用的联系人添加界面中显示上述第二联系人目录；

获取上述第一应用客户端发送的联系人添加请求，上述联系人添加请求是由上述第一应用客户端基于针对上述第二联系人目录中目标联系人的确定操作确定的；

向上述目标联系人对应的第二应用客户端发送上述联系人添加请求。

在一种可能的实施方式中，上述向上述目标联系人对应的第二应用客户端发送上述联系人添加请求之后，上述方法还包括：

若在预设时长内未获取到上述目标联系人对于上述联系人添加请求的响应、且已向上述目标联系人对应的第二应用客户端发送联系人添加请求的次数小于上述预设次数，则向上述目标联系人对应的第二应用客户端再次发送上述联系人添加请求；

若在上述预设时长内未获取到上述目标联系人对于上述联系人添加请求的响应、且已向上述目标联系人对应的第二应用客户端发送联系人添加请求的次数等于上述预设次数，则确定上述目标联系人拒绝添加在上述第一应用的第一联系人目录。

第三方面，本申请实施例提供了一种跨应用的关系链扩展方法，上述方法由用户的第二应用客户端执行，上述方法包括：

接收联系人添加请求并显示上述联系人添加请求对应的请求内容，其中，上述联系人添加请求为上述用户在上述第二应用中的联系人通过该联系人在第一应用客户端发起的。

第四方面，本申请实施例提供了一种跨应用的关系链扩展装置，该装置包括：

第一显示模块，用于响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；

第一添加模块，用于响应于针对上述第二联系人目录中目标联系人的确定操作，向上述目标联系人对应的第二应用客户端发送联系人添加请求；以在上述目标联系人对应的第二应用客户端发送同意添加指令后，将上述目标联系人添加在上述第一应用的第一联系人目录。

第五方面，本申请实施例提供了一种跨应用的关系链扩展装置，该装置包括：

添加指令获取模块，用于获取输入的联系人添加指令；

联系人信息获取及发送模块，用于响应于上述联系人添加指令，获取第二应用的第二联系人目录并发送至第一应用客户端，以在第一应用的联系人添加界面中显示上述第二联系人目录；

第二添加模块，用于获取上述第一应用客户端发送的联系人添加请求，上述联系人添加请求是由上述第一应用客户端基于针对上述第二联系人目录中目标联系人的确定操作确定的；

添加请求发送模块，用于向上述目标联系人对应的第二应用客户端发送上述联系人添加请求。

第六方面，本申请实施例提供了一种跨应用的关系链扩展装置，该装置包括：

接收模块，用于接收联系人添加请求，上述联系人添加请求由第一应用客户端响应于针对第二应用的第二联系人目录中目标联系人的确定操作确定的；

第二显示模块，用于在上述第二应用的请求内容显示界面中显示上述联系人添加请求对应的请求内容。

第七方面，本申请实施例提供了一种电子设备，包括处理器和存储器，该处理器和存储器相互连接；

上述存储器用于存储计算机程序；

上述处理器被配置用于在调用上述计算机程序时，执行上述第一方面、第二方面和/或第三方面任一种可能的实施方式所提供的方法。

第八方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行以实现上述第一方面、第二方面和/或第三方面任一种可能的实施方式所提供的方法。

第九方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述第一方面、第二方面和/或第三方面任一种可能的实施方式所提供的方法。

在本申请实施例中，第一应用客户端响应与联系人添加指令，可在联系人添加界面中显示第二应用的联系人目录，从而通过联系人添加界面使得用户直接选择其需要添加的目标联系人，可优化用户体验。与此同时，第一应用的服务器可将联系人添加指令发送至第二应用客户端，从而使得用户可直接基于第一应用客户端添加第二应用中的联系人，简化用户添加联系人的操作，提升添加联系人的便捷性，适用性高。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种网络架构示意图；

图2是本申请实施例提供的跨应用的关系链扩展方法的一时序示意图；

图3a是本申请实施例提供的触发联系人添加指令的一场景示意图；

图3b是本申请实施例提供的触发联系人添加指令的另一场景示意图；

图4a是本申请实施例提供的引导界面的一示意图；

图4b是本申请实施例提供的引导界面的另一示意图；

图5a是本申请实施例提供的联系人添加界面的一示意图

图5b是本申请实施例提供的联系人添加界面的另一示意图；

图5c是本申请实施例提供的联系人添加界面的又一示意图；

图6是本申请实施例提供的添加详情界面的示意图；

图7a是本申请实施例提供的消息通知界面的一示意图；

图7b是本申请实施例提供的消息通知界面的另一示意图；

图8是本申请实施例提供的通知详情界面的一示意图；

图9是本申请实施例提供的跨应用的关系链扩展方法的另一时序示意图；

图10是本申请实施例提供的请求内容编辑界面的示意图；

图11a是本申请实施例提供的添加进度界面的一示意图；

图11b是本申请实施例提供的添加进度界面的另一示意图；

图12是本申请实施例提供的一跨应用的关系链扩展装置的结构示意图；

图13是本申请实施例提供的另一跨应用的关系链扩展装置的结构示意图；

图14是本申请实施例提供的又一跨应用的关系链扩展装置的结构示意图；

图15是本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参见图1，图1是本发明实施例提供的一种网络架构示意图。如图1所示，本申请实施例提供的网络架构示意图可以包括终端200、服务器300、终端500以及服务器400。其中，终端200安装有第一应用客户端，服务器300为第一应用服务器，终端200安装的第一应用客户端所对应的用户100，可通过第一应用服务器300与第一应用的其他用户进行通信。其中，终端500安装有第二应用客户端，服务器400为第二应用服务器，终端500安装的第二应用客户端所对应的用户600，可通过第二应用服务器400与第二应用的其他用户进行通信。

并且，第一应用客户端和第一应用服务器300可基于终端200与服务器300之间的通信连接进行通信，第二应用客户端和第二应用服务器400可基于终端500与服务器400之间的通信连接进行通信，终端200与服务器300之间的通信连接，以及终端500与服务器400之间的通信连接可通过有线或无线通信方式进行直接或间接地连接，但并不局限于此。

其中，第一应用和第二应用可为即时通信应用，终端200和终端500包括但不限于手机、平板电脑、笔记本电脑、掌上电脑、智能手表以及移动互联网设备(mobile internetdevice，MID)等，服务器300和服务器400可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content DeliveryNetwork，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器或服务器集群等，具体可基于实际应用场景需求确定，在此不做限制。

在本申请实施例中，终端200内的第一应用客户端，可响应于用户100输入的联系人添加指令，该联系人添加指令为用户100在添加第二应用的联系人目录中的联系人时所输入的。终端200内的第一应用客户端响应于联系人添加指令，并在第一应用的联系人添加界面中显示用户100在第二应用中的第二联系人目录。第一应用客户端可进一步响应于用户针对联系人添加界面所显示的第二联系人目录中目标联系人(用户600)的确定操作，向服务器300发送联系人添加请求。

服务器300向第二应用的服务器400发送联系人添加请求，以使服务器400将联系人添加请求发送至终端500内的第二应用客户端。终端500可通过第二应用客户端向用户600显示联系人添加请求对应的请求内容，从而用户600在同意添加时，即用户600对应的第二应用客户端发送同意添加指令后，基于上述通信交互方式可将用户同意添加指令的相关信息发送至第一应用服务器300，从而使得第一应用客户端基于同意添加指令的相关信息，将用户600添加在用户100在第一应用的第一联系人目录。基于上述实现方式，用户100可通过第一应用客户端，将其在第二应用第二联系人目录中的目标联系人(用户600)添加为其在第一应用的第一联系人目录中的联系人。

其中，服务器300和服务器400之间的通信还可基于云技术(Cloud technology)实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术，即服务器300和服务器400可根据云技术的网络统一性实现互相通信。

其中，本申请实施例中涉及的到数据存储，如第一应用的第一联系人目录以及第二应用的第二联系人目录的存储，可通过云存储(cloud storage)以及数据库等方式进行存储。其中，云存储是在云计算概念上延伸和发展出来的一个新的概念，云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

参见图2，图2是本申请实施例提供的跨应用的关系链扩展方法的一时序示意图。其中，为方便描述，图2中将第一应用客户端称为第一客户端，将第一应用服务器称为第一服务器，将第二应用客户端称为第二客户端。图2所示的跨应用的关系链扩展方法可包括如下步骤：

步骤S21、响应于输入的联系人添加指令。

在一些可行的实施方式中，联系人添加指令为第一应用的用户开始添加其在第二应用中的联系人时所输入至第一客户端的。其中，用户可通过点击第一客户端中用于指示添加第二应用中的联系人的添加按钮(功能区域)，来触发针对第二应用的联系人添加指令。

例如，如图3a所示，图3a是本申请实施例提供的触发联系人添加指令的一场景示意图。图3a所示了第一客户端中添加联系人对应的功能界面，用户需要添加其在第二应用的第二联系人目录中的联系人时，可进入该功能界面并通过添加操作，如点击用于指示添加联系人的添加按钮、以及相关的功能区域，来触发针对第二联系人目录中联系人的联系人添加指令。其中，图3a中的用于指示添加第二联系人目录中的联系人的添加按钮以及功能区域，可以为任意标识、文字、符号中的一种或多种组合，如图3a中该功能界面中“第二应用联系人”对应的区域，具体可基于实际应用场景确定，在此不做限制。

可选的，当第一客户端对用户的各种手势操作配置有相对应的操作指令时，用户可基于相对应的手势操作输入联系人添加指令，从而第一客户端在检测到该手势操作后，响应用户输入的联系人添加指令。

可选的，用户可在第一客户端相应的联系人搜索位置，通过输入其在第二应用的第二联系人目录中联系人的账号进行搜索时，触发联系人添加指令。例如，如图3b所示，图3b是本申请实施例提供的触发联系人添加指令的另一场景示意图。图3b所示了第一客户端中添加第二应用中的联系人对应的功能界面，用户需要添加其在第二应用中的联系人时，可进入该功能界面，并在界面提示下输入联系人的账号，并确认搜索该账号时触发联系人添加指令。其中，上述联系人账号还可为联系人手机号、邮箱以及姓名等，具体可基于实际应用场景确定，在此不做限制。

可选的，第一客户端的用户还可通过语音指令向第一客户端输入语音指令，第一客户端接收到用户的语音指令后，通过语音识别来确定用户所输入的语音指令为联系人添加指令。需要说明的是，上述用户触发或者输入联系人添加指令的具体实现方式仅为示例，具体可与实际应用场景需求和第一客户端的实际设置确定，在此不做限制。

对于第一客户端而言，第一客户端可响应于用户输入的联系人添加指令，并将该联系人添加指令发送至第一服务器。从而第一应用服务器接收到用户输入的联系人添加指令之后，才可获取用户在第二应用的第二联系人目录，以进行下一步的联系人添加操作。

步骤S22、响应于联系人添加指令，获取第二应用的第二联系人目录。

在一些可行的实施方式中，第一服务器在接收到第一客户端发送的，用户输入的联系人添加指令之后，可响应于该联系人添加指令，以获取用户在第二应用的第二联系人目录。

具体的，第一服务器可通过向第二应用服务器(为方便描述，以下简称第二服务器)发送联系人获取请求的方式，从第二服务器获取用户第二应用的第二联系人目录。

在一些可行的实施方式中，第一客户端响应于用户输入的联系人添加指令，可确定用户是否可通过第一应用获取其在第二应用的第二联系人目录。具体的，第一客户端可通过第一服务器确定用户对应于第一应用的账号与第二应用是否绑定。当用户的对应于第一应用的账号与第二应用绑定时，说明第一服务器可通过用户的账号从第二服务器获取该用户在第二应用的第二联系人目录。若该用户的账号未与第二应用绑定，第一服务器则无法从第二服务器获取该用户在第二服务器中的相关信息。

进一步的，由于信息安全的因素影响，第一客户端需要获取到用户对于获取第二应用的第二联系人目录的授权，以在用户允许之下通过第一服务器从第二服务器获取用户在第二应用的第二联系人目录。

因此，若用户的账号与第二应用未绑定，或者第一客户端未获取到用户对于获取该用户在第二应用的第二联系人目录的授权时，第一客户端无法通过第一服务器获取第二联系人目录。在此情况在，第一客户端可向用户显示引导界面，以通过引导界面引导用户将账号与第二应用绑定，和/或，授权第一客户端获取用户对于获取第二应用的第二联系人目录的授权。

在用户的账号与第二应用绑定，且第一客户端获取到用户对于获取第二应用的第二联系人目录的授权的情况下，通过第一服务器从第二服务器获取用户在第二应用的第二联系人目录。

其中，用户对于第一应用的账号与第二应用绑定，可以表现为将用户对应于第一应用的账号与用户对应于第二应用的账号之间建立关联关系，如授权用户通过第一应用的账号登录第二应用，或者使用户对应于第一应用的账号和用户对应于第二应用的账号同时对应于同一验证信息等，具体可基于实际应用场景确定，在此不做限制。其中，上述验证信息包括但不限于用户的手机号、邮箱、身份证号以及其他用于表示用户身份的唯一表示信息，具体也可基于实际应用场景确定，在此不做限制。

参见图4a，图4a是本申请实施例提供的引导界面的一示意图。当用户的账号与第二应用未绑定时，第一客户端可显示引导界面，通过引导信息如“是否绑定第二应用”来引导用户将其账号与第二应用绑定。其中，当用户确定绑定时，第一客户端可响应于用户针对绑定第二应用的确定操作，并触发第一客户端所在的终端启动第二应用，进而通过第二应用的绑定界面完成用户账号与第二应用的绑定。可选的，当第一客户端所在的终端未安装有第二应用时，第一客户端可响应于用户针对绑定第二应用的确定操作之后，显示下载提示页面以提示用户下载第二应用的第二客户端，进而通过第二客户端的绑定界面完成用户账号与第二应用的绑定。

参见图4b，图4b是本申请实施例提供的引导界面的另一示意图。当第一客户端未获取到用户对于获取其在第二应用的联系人的授权时，第一客户端可同样显示引导界面，通过引导信息图“是否获取第二应用的联系人”授权获取第二应用的第二联系人目录的授权。其中，第一客户端可通过第一服务器向第二客户端的第二服务器发送联系人获取请求，以使第二服务器在同意联系人获取请求后，完成对第一客户端获取用户对于获取第二应用的第二联系人目录的授权。

其中，当用户的账号与第二应用未绑定，并且第一客户端未获取用户对于获取第二应用的第二联系人目录的授权时，第一客户端可通过引导界面先引导用户将其账号与第二应用绑定。在用户完成账号与第二应用的绑定之后，再次通过引导界面授权获取第二应用的第二联系人目录的授权。

需要特别说明的是，上述基于引导界面引导用户将账号与第二应用绑定，和/或授权获取第二应用的第二联系人目录的授权的具体实现方式仅为示例，具体可基于实际应用场景确定，在此不做限制。

步骤S23、在联系人添加界面中显示第二应用的第二联系人目录。

在一些可行的实施方式中，第一客户端通过第一服务器在获取到用户在第二应用的第二联系人目录之后，可在联系人添加界面中显示用户在第二应用的第二联系人目录。其中，第一客户端在联系人添加界面中显示第二应用的第二联系人目录时，可通过用户头像、用户名、用户账号以及其他联系人信息中的一种或者多种组合的方式，显示第二应用的第二联系人目录，具体可基于实际应用场景确定，在此不做限制。

如图5a所示，图5a是本申请实施例提供的联系人添加界面的一示意图。在图5a中，第一客户端在联系人添加界面可显示第二联系人目录中各联系人的用户头像和用户名。并且，第一客户端在联系人添加界面以列表的形式，向用户显示第二联系人目录中的联系人。

在一些可行的实施方式中，第一客户端在通过联系人添加界面显示第二联系人目录之前，即在响应于用户输入的联系人添加指令之后，在联系人添加界面中显示联系人添加提示信息。通过联系人添加提示信息提示用户如何添加第二联系人目录中的联系人，以及添加第二联系人目录中的联系人时向第二客户端发送联系人添加请求的发送机制，包括但不限于如何时发送、发送次数、每两次发送之间的时间间隔以及每个联系人对联系人添加请求的接收机制(如每个联系人每天最多收到用户的1条联系人添加请求，累计不超过3条)等等，具体可基于实际应用场景确定，在此不做限制。

进一步的，响应于用户针对联系人添加提示信息的确认操作，即用户在已知联系人添加提示信息的具体提示内容并确认之后，第一客户端可在联系人添加界面中显示用户在第二应用的第二联系人目录。

如图5b所示，图5b是本申请实施例提供的联系人添加界面的另一示意图。在图5b中，第一客户端通过联系人添加界面所显示的联系人添加提示信息，一部分为“选择第二应用上的联系人，自动发送联系人添加请求”，该部分用于提示用户其选择邀请联系人之后，将自动向该联系人发送添加请求。另一部分为“每个联系人每天最多收到用户的1条联系人添加请求，累计不超过3条”，用于提示用户每个联系人每天最多只能收到1条联系人添加请求，并且每个联系人累计只能接收到3条该用户对应的联系人添加请求，从而提示用户合理安排联系人添加策略，提升用户体验。

步骤S24、响应于针对第二联系人目录中目标联系人的确定操作，发送联系人添加请求。

在一些可行的实施方式中，第一客户端响应于用户针对联系人添加界面所显示的联系人中目标联系人的确定操作，即当用户在联系人添加界面选择其需要添加的目标联系人并确定添加之后，即第一客户端可向第一服务器发送联系人添加请求，第一服务器进而通过第二服务器向目标联系人对应的第二应用客户端发送联系人添加请求。

可选的，在联系人添加界面中显示的第二应用的第二联系目录中，可显示第二联系人目录中所有联系人，并对于其中已添加在第一联系人目录中的联系人，以及已拒绝添加在第一联系人目录的联系人进行标记，以提示用户选择其可以添加的联系人。

可选的，在联系人添加界面中显示的第二联系人目录的联系人，可包括除以添加在第一联系人目录的联系人，以及已拒绝添加在第一联系人目录的联系人外的其他联系人，以使用户可选择联系人添加界面中所显示的任一联系人。

参见图5c，图5c是本申请实施例提供的联系人添加界面的又一示意图。在图5c中，联系人添加界面中显示的第二联系人目录中的联系人分别为“小红”、“小明”、“老王”以及“老李”。用户从第二联系人目录中所选择的目标联系人为“小红”和“小明”，并且用户在选择目标联系人时联系人添加界面可向用户显示其一共选择的目标联系人的数量以及总的联系人的数量。即用户此时从4位第二联系人目录的联系人中，选择两位联系人作为目标联系人。当用户点击“确认”按钮时，表示用户确认添加“小红”和“小明”作为其在第一应用的第一联系人目录的联系人，此时第一客户端可向“小红”和“小明”对应的第二应用的第二客户端发送联系人添加请求，以在“小红”和“小明”对应的第二客户端发送同意添加指令后，将“小红”和“小明”添加在第一应用的第一联系人目录。

在一些可行的实施方式中，第一客户端响应于用户针对第二联系人目录中目标联系人的确定操作，并发送联系人添加请求之后，第一客户端可向用户显示添加详情信息，以告知用户其添加第二联系人目录的目标联系人的详细信息。或者，第一客户端可在用户查看添加进度时向用户显示详情添加界面。其中，第一客户端在添加详情界面中显示已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息以及已添加和未添加在第一联系热目录中的联系人的相关信息等，具体可基于实际应用场景确定，在此不做限制。

其中，已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息，以及已添加和未添加在第一联系人目录的联系人的相关信息，包括但不限于用户名、用户头像以及数量等，具体可基于实际应用场景确定，在此不做限制。

如图6所示，图6是本申请实施例提供的添加详情界面的示意图。在图6中，第一客户端在向目标联系人对应的第二客户端发送联系人添加请求之后，第一客户端在显示添加详情界面中显示有“2已选择”，表示用户此前通过第一客户端向两位目标联系人发送联系人添加请求；还显示有“1位已添加”，表示在此之前用户已将1位目标联系人添加在第一应用的第一联系人目录；还显示有“0位已拒绝添加”，表示在此之前有0位目标联系人拒绝添加在第一应用的第一联系人目录。

步骤S25、接收联系人添加请求，在请求内容显示界面中显示联系人添加请求对应的请求内容。

在一些可行的实施方式中，当第二客户端接收到联系人添加请求后，第二客户端通过消息通知界面向目标联系人显示添加请求通知，以提醒目标联系人此时接收到联系人添加请求。其中，上述添加请求通知为系统消息提示通知，即第二客户端通过系统消息提示目标联系人接收到联系人添加请求。或者，由于用户的账号与第二应用绑定，因此第二服务器可通过用户对应于第二应用的账号，向目标联系人发送联系人添加请求。即第二客户端可通过用户在第二应用中对应的消息通知提示目标联系人接收到联系人添加请求。

例如，参见图7a，图7a是本申请实施例提供的消息通知界面的一示意图。如图7a所示，第一客户端发送的联系人添加请求可以系统通知的形式提醒目标联系人此时接收到联系人添加请求。或者可参见图7b，图7b是本申请实施例提供的消息通知界面的另一示意图。如图7b所示，第一客户端发送的联系人添加请求可以第二应用中的用户(大伟)的联系人消息通知的形式提醒目标联系人此时接收到联系人添加请求。

目标联系人可通过查看消息通知界面上的相应通知，即第二客户端响应于目标联系人的查看操作，在通知详情界面显示联系人添加请求对应的请求内容。其中，联系人添加请求对应的请求内容包括但不限于请求人(用户)信息，联系人添加请求的发送时间、以及具体添加文案等，具体可基于实际应用场景确定，在此不做限制。

参见图8，图8是本申请实施例提供的通知详情界面的一示意图。如图8所示，第二客户端可响应于目标联系人针对于添加请求通知的确定操作，即目标联系人通过图7a或者图7b中消息通知界面查看添加请求通知，第二客户端在通知详情界面显示联系人添加请求对应的请求内容。其中，图8中的通知详情界面显示有联系人添加请求的发送时间“11月29日”和添加文案“大伟邀请您成为其在第一应用的联系人，请点击确认同意，或点击取消拒绝入。”，其中添加文案中表明了添加人(大伟)和添加目的。

在一些可行的实施方式中，当目标联系人同意添加时，即第二客户端响应于目标联系人针对于请求内容的同意或者拒绝操作时，通过第二应用的第二服务器，向第一应用的第一服务器发送同意添加指令。

步骤S26、将目标联系人添加在第一应用的第一联系人目录。

在一些可行的实施方式中，第一客户端在接收到第二应用客户端发送的同意添加指令后，可将目标联系人添加在第一应用的第一联系人目录。即此时目标联系人可作为用户在第一应用中的联系人，用户可通过第一客户端向目标联系人发送消息，目标联系人可通过第二客户端接收并查看用户通过第一客户端发送的消息。

在本申请实施例中，第一应用客户端响应与联系人添加指令，可在联系人添加界面中显示第二应用的联系人目录，从而通过联系人添加界面使得用户直接选择其需要添加的目标联系人，可优化用户体验。与此同时，第一应用的服务器可通过第二应用的服务器，将联系人添加指令发送至第二应用客户端，从而使得用户可直接基于第一应用客户端添加第二应用中的联系人，简化用户添加联系人的操作，提升添加联系人的便捷性，适用性高。进一步的，用户在添加第二应用中的联系人时，可第一应用可通过详情添加界面向用户显示已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息，以及已添加和未添加为用户在第一应用中的联系人的相关信息等，进一步提升用户体验。

参见图9，图9是本申请实施例提供的跨应用的关系链扩展方法的另一时序示意图。同样的，为方便描述，图9中将第一应用客户端称为第一客户端，将第一应用服务器称为第一服务器，将第二应用客户端称为第二客户端，将第二应用服务器称为第二服务器。本申请实施例提供的跨应用的关系链扩展方法包括如下步骤：

步骤S31、获取用户针对第二应用的联系人添加指令。

步骤S32、响应于联系人添加指令，获取用户在第二应用中的联系人。

步骤S33、在联系人添加界面显示用户在第二应用中的联系人。

在一些可行的实施方式中，步骤S31至步骤S33的具体实现方式，可参见图2中步骤S21至步骤23所示的实现方式，在此不再赘述。

步骤S34、响应于针对第二联系人目录中目标联系人的确定操作，显示请求内容编辑界面。

在一些可行的实施方式中，第一客户端响应于针对第二联系人目录中目标联系人的确定操作的具体实施方式，可参见图2中步骤S24中的实现方式，在此不再赘述。

在一些可行的实施方式中，第一客户端响应于针对第二联系人目录中目标联系人的确定操作，可向用户显示请求内容编辑界面，通过请求内容编辑界面确定用户的请求内容。其中，上述请求内容为目标联系人在基于第二客户端接收到联系人添加请求之后，第二客户端向第二用户展示的内容。换句话说，上述请求内容为用户在目标联系人在接收到联系人连接请求后，希望目标联系人所看到的内容。

具体的，第一客户端可通过请求内容编辑界面获取用户的编辑操作，基于编辑操作生成联系人添加请求。其中，第一客户端在显示内容编辑界面中显示有请求内容模板，该请求内容模板为用户设置或者第二客户端预设的请求内容。当第一客户端通过请求内容编辑界面获取到的用户的编辑操作为内容确认操作，即第一客户端确定用户决定使用请求内容模板的请求内容，第一客户端可根据请求内容模板的请求内容生成联系人添加请求。

可选的，当第一客户端通过请求内容编辑界面获取到的用户的编辑操作为内容修改操作，则根据用户的内容修改操作对上述请求内容模板进行修改，得到修改后的请求内容。响应于用户针对修改后的请求内容的确认操作，即当用户对修改后的请求内容确认无误时，根据修改后的请求内容生成联系人添加请求。

其中，上述请求内容模板对应的请求内容，以及修改后的请求内容包括但不限于用户的邀请文案、用户名片、用户姓名、用户账号、添加联系人时间、字体以及显示请求内容对应的背景图片等，具体可基于实际应用场景确定，在此不做限制。

可选的，第一客户端可预设有多个请求内容模板，响应于用户针对显示的联系人中目标联系人的确定操作，可先在模板选择界面中显示当前所有的请求内容模板。进一步地，第一客户端可响应于用户针对请求内容模板的模板确认操作，并通过请求内容编辑界面向用户展示用户所选择的请求模板内容模板。从而第一客户端可通过内容编辑界面获取到的用户的编辑操作，生成联系人添加请求。

进一步的，第一客户端每基于用户的内容修改操作对请求内容模板进行修改之后，可将修改后的请求内容模板作为新的请求内容模板，并将新的请求内容模板存储至预设存储空间，以在用户下一次添加第二应用的联系人时，通过模板选择界面向用户显示以使用户选择，或者通过请求内容编辑界面向用户显示新的请求内容模板，具体实现方式可基于实际应用场景确定，在此不做限制。

其中，上述预设存储空间包括但不限于第一客户端所在终端的终端存储空间、第一客户端对应的服务器、数据库或者第一客户端对应的云存储空间等，具体可基于实际应用场景需求确定，在此不做限制。

例如，参见图10，图10是本申请实施例提供的请求内容编辑界面的示意图。在图10所示的请求内容编辑界面中显示的请求内容模板包括用户的用户名片和添加文案，其中，用户名片包括用户名称(大伟)以及用户的用户头像，添加文案为“您好，欢迎添加我在第一应用的账号，以后我将在第一应用为您提供服务。”基于上述请求内容编辑界面所显示的请求内容模板，可生成联系人添加请求，并当第二客户端接收到联系人添加请求后，可向目标联系人显示上述请求内容模板中的请求内容。即第二客户端可向目标联系人展示上述用户名片和添加文案。

步骤S35、发送联系人添加请求。

在一些可行的实施方式中，第一客户端在基于请求内容模板或者修改后的请求内容生成联系人添加请求后，将联系人添加请求发送至第一服务器，以使第一服务器将联系人添加请求通过第二服务器发送至目标联系人对应的第二客户端。

步骤S36、确定是否发送联系人添加请求。

在一些可行的实施方式中，为避免频繁向目标联系人发送联系人添加指令，导致目标联系人多次接收联系人添加指令所造成的用户体验度较低的问题，第一服务器在接收到第一客户端发送的联系人添加请求之后，可确定在此之前向目标联系人发送联系人添加请求的次数。

进一步的，当第一服务器已向目标联系人发送联系人添加请求的次数小于预设次数时，第一服务器则向第二服务器发送联系人添加请求，以通过第二服务器将联系人添加请求发送至目标联系人对应的第二客户端。否则，第一服务器则拒绝向第二服务器发送联系人添加请求，并向第一客户端发送添加异常信息，以通过第一客户端向用户显示添加异常信息，提醒用户此时无法添加目标联系人。

可选的，第一服务器在接收到第一客户端发送的联系人添加请求之后，还可确定距离上一次向目标联系人发送用户对应的联系人添加请求的时间间隔，若时间间隔小于预设时间间隔时，第一服务器则向第二服务器发送联系人添加请求，以通过第二服务器将联系人添加请求发送至目标联系人对应的第二客户端。否则，第一服务器则拒绝向第二服务器发送联系人添加请求，并向第一客户端发送添加异常信息，以通过第一客户端向用户显示添加异常信息，提醒用户此时无法添加目标联系人。

其中，上述预设次数和预设时间间隔可基于实际应用场景确定，在此不做限制。如预设次数为3次，说明用户通过第一客户端累计只能向目标联系人对应的第二客户端发送3次联系人添加请求。如预设时间间隔为1天，说明用户通过第一客户端每天只能向目标联系人对应的第二客户端发送1次联系人添加请求。

步骤S37、接收联系人添加请求，在第二应用的请求内容显示界面中显示联系人添加请求对应的请求内容。

在一些可行的实施方式中，第二服务器可将第一服务器发送的联系人添加请求发送至目标联系人对应的第二客户端，第二客户端可接收联系人添加请求，并在第二应用的请求内容显示界面中显示联系人添加请求对应的请求内容。其中，第二客户端所显示的请求内容与用户基于请求内容编辑界面确定的请求内容模板或者修改后的请求内容一致，具体实现方式可参见图2中步骤S25所示的实施方式，在此不做限制。

步骤S38、发送添加事件信息。

在一些可行的实施方式中，当目标联系人同意添加或者拒绝添加时，即第二客户端响应于目标联系人针对于请求内容的同意添加指令或者拒绝添加指令时，第二客户端可通过第二服务器，向第一服务器发送添加事件信息。其中，添加事件信息用于说明目标联系人同意添加在第一应用的第一联系人目录，或者拒绝添加在第一应用的第一联系人目录。

步骤S39、更新目标联系人状态。

在一些可行的实施方式中，第一服务器在接收到第二服务器发送的添加事件信息之后，第一服务器可向第一客户端发送状态更新信息，以使第一客户端更新目标联系人的添加状态。

具体的，当第一服务器基于添加事件信息确定目标联系人同意添加之后，可向第一客户端发送用于说明目标联系人同意添加在第一应用的第一联系人目录的第一状态更新信息，以使第一客户端将目标联系人的状态信息更新为已添加状态。

进一步的，当第一服务器基于添加事件信息确定目标联系人拒绝添加之后，可向第一客户端发送用户说明目标联系人拒绝添加在第一应用的第一联系人目录的第二状态更新信息，以使第一客户端将目标联系人的更新状态信息更新为已拒绝状态。

可选的，为在一定程度上使得用户可多次添加目标联系人的同时，减少用户基于第一客户端发起联系人添加请求的次数，第一服务器在基于添加事件信息确定目标联系人拒绝添加在第一应用的第一联系人目录之后，可确定已向目标联系人对应的第二客户端发送联系人添加请求的次数。若已向目标联系人对应的第二客户端发送联系人添加请求的次数小于预设次数时，第一服务器可基于预设发送规则再次向目标联系人对应的第二客户端发送联系人添加请求。若已向目标联系人对应的第二客户端发送联系人添加请求的次数不小于预设次数时，向第一客户端发送用户说明目标联系人拒绝添加在第一应用的第一联系人目录的第二状态更新信息，以使第一客户端将目标联系人的更新状态信息更新为已拒绝状态。

或者，第一服务器可确定距离上次向目标联系人发送联系人添加请求的时间间隔，若时间间隔小于预设时间间隔，第一服务器可基于预设发送规则再次向目标联系人对应的第二客户端发送联系人添加请求。若时间间隔不小于预设时间间隔，则向第一客户端发送用户说明目标联系人拒绝添加在第一应用的第一联系人目录的第二状态更新信息，以使第一客户端将目标联系人的更新状态信息更新为已拒绝状态。

其中，上述预设发送规则可基于实际应用场景确定，在此不做限制。如在第二天的相同时间发送联系人添加请求，每隔预设时间段发送联系人添加请求等。

在一些可行的实施方式中，若目标联系人在一定时间内未对联系人添加请求作出响应，即第一服务器在一定时间内未接收到第二服务器发送的添加事件信息，第一服务器可向第一客户端发送第二状态更新信息，以使第一客户端将目标联系人的添加状态更改为已拒绝。

可选的，第一服务器可确定已向目标联系人对应的第二客户端发送联系人添加请求的次数，或者距离上次向目标联系人发送联系人添加请求的时间间隔，基于上述次数或者时间间隔确定向第一客户端发送第二状态更新信息或者再次向第二服务器发送联系人添加请求，具体可基于实际应用场景以及第一客户端设置确定，在此不做限制。

进一步的，在一些可行的实施方式中，当用户需要查询其在第二应用的联系人的添加进度时，第一客户端可响应于用户针对添加进度的查询操作，并向用户显示添加进度界面。通过添加进度界面，第一客户端可向用户显示已发送联系人添加请求的联系人的添加进度。其中，添加进度包括已添加、已拒绝等，具体可基于实际应用场景确定，在此不做限制。

参见图11a，图11a是本申请实施例提供的添加进度界面的一示意图。如图11a所示的添加进度界面，第一客户端响应于用户针对添加进度的查询操作之后，通过添加进度界面可向用户展示各联系人的添加进度。如“小红”的添加进度为已添加，即说明“小红”已同意用户的联系人添加请求，“小红”此时为用户在第一应用中的联系人。如“老王”和“老李”的添加进度为已拒绝，即说明“老王”和“老李”已拒绝用户的联系人添加请求，“老王”和“老李”不是用户在第一应用中的联系人。添加进度界面未显示“小明”的添加进度，说明用户已向“小明”发送联系人添加请求，但是“小明”还未做出响应，或者用户未通过第一客户端向“小明”对应的第二客户端发送联系人添加请求。

在一些可行的实施方式中，用户还可基于第一客户端对指定添加进度的联系人进行查询，即第一客户端可响应于用户针对指定添加进度的联系人的查询操作，通过添加进度界面显示已发送联系人添加请求的联系人中，指定添加进度的联系人的相关信息。

其中，上述指定添加进度包括但不限于正在添加的联系人、已添加的联系人、已拒绝的联系人等，具体可基于实际应用场景确定，在此不做限制。其中，上述指定添加进度的联系人的相关信息同样包括但不限于该联系人的添加进度、用户名、账号以及用户头像等，具体也可基于实际应用场景确定，在此不做限制。

参加图11b，图11b是本申请实施例提供的添加进度界面的另一示意图。在图11b所示的添加进度界面中，第一客户端通过响应于用户的进度筛选操作，通过添加进度界面向用户展示不同的筛选方式。进而第一客户端可响应于用户针对指定添加进度的联系人的查询操作，即响应于用户选择不同筛选方式的选择操作，按照相对应的筛选方式为通过添加进度界面向用户展示筛选后的，符合指定添加进度的联系人的相关信息。如第一客户端响应于用户针对已添加的联系人的查询操作，通过添加进度界面向用户展示“小红”的相关信息，如用户名“小红”、用户头像以及添加进度(已添加)。

在本申请实施例中，第一应用客户端响应与联系人添加指令，可在联系人添加界面中显示第二应用的联系人目录，从而通过联系人添加界面使得用户直接选择其需要添加的目标联系人，可优化用户体验。与此同时，第一应用的服务器可通过第二应用的服务器，将联系人添加指令发送至第二应用客户端，从而使得用户可直接基于第一应用客户端添加第二应用中的联系人，简化用户添加联系人的操作，提升添加联系人的便捷性，适用性高。进一步的，用户在添加第二应用中的联系人时，可第一应用可通过详情添加界面向用户显示已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息，以及已添加和未添加为用户在第一应用中的联系人的相关信息等，进一步提升用户体验。此外，第一应用还可通过请求内容编辑界面可使用户选择、编辑对应的请求内容，可迎合用户喜好，为用户提供个性化的联系人添加服务，适用性高。

参见图12，图12是本申请实施例提供的一跨应用的关系链扩展装置的结构示意图。本申请实施例提供的训练装置1包括：

第一显示模块11，用于响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；

第一添加模块12，用于响应于针对上述第二联系人目录中目标联系人的确定操作，向上述目标联系人对应的第二应用客户端发送联系人添加请求；以在上述目标联系人对应的第二应用客户端发送同意添加指令后，将上述目标联系人添加在上述第一应用的第一联系人目录。

在一些可行的实施方式中，上述第一添加模块12，用于：

响应于针对上述第二联系人目录中目标联系人的确定操作，显示请求内容编辑界面；

通过上述请求内容编辑界面获取用户的编辑操作；

基于上述编辑操作对应的请求内容，向上述目标联系人对应的第二应用客户端发送联系人添加请求。

在一些可行的实施方式中，上述请求内容编辑界面显示有请求内容模板，上述编辑操作包括内容确认操作或内容修改操作；

若上述编辑操作为内容确认操作，上述第一添加模块12，用于：

基于上述请求内容模板，向上述目标联系人对应的第二应用客户端发送联系人添加请求；

若上述编辑操作为内容修改操作，上述第一添加模块12，用于：

根据上述内容修改操作，对上述请求内容模板进行修改，显示修改后的请求内容；

响应于针对上述修改后的请求内容的确认操作，根据上述修改后的请求内容，向上述目标联系人对应的第二应用客户端发送联系人添加请求。

在一些可行的实施方式中，上述第一显示模块11，用于：

响应于输入的联系人添加指令，在第一应用的联系人添加界面中显示联系人添加提示信息；

响应于针对上述联系人添加提示信息的确认操作，在上述联系人添加界面中显示第二应用的第二联系人目录。

在一些可行的实施方式中，上述第一显示模块11，用于：

若用户的账号与上述第二应用未绑定，或者未获取到上述用户对于获取上述第二应用的第二联系人目录的授权，则显示引导界面，以通过上述引导界面引导上述用户将上述账号与上述第二应用绑定，和/或，授权获取上述第二应用的第二联系人目录的授权；

在上述账号与上述第二应用绑定，且获取到上述用户对于获取上述第二应用的第二联系人目录的授权时，在联系人添加界面中显示上述第二应用的第二联系人目录。

在一些可行的实施方式中，在第一应用的联系人添加界面中显示的第二应用的第二联系人目录，包括除以下联系人之外的联系人：

已添加在上述第一联系人目录的联系人；

已拒绝添加在上述第一联系人目录的联系人。

在一些可行的实施方式中，上述第一显示模块11，还用于：

在上述第一应用的添加详情界面中显示以下至少一项：

已发送联系人添加请求的联系人的相关信息；

未发送过联系人添加请求的联系人的相关信息。

在一些可行的实施方式中，上述第一显示模块11，还用于：

响应于针对添加进度的查询操作；

在上述第一应用的添加进度界面中显示已发送联系人添加请求的联系人的添加进度。

在一些可行的实施方式中，上述第一显示模块11，还用于：

响应于针对指定添加进度的联系人的查询操作；

在上述第一应用的添加进度界面中显示已发送联系人添加请求的联系人中上述指定添加进度的联系人的相关信息。

参见图13，图13是本申请实施例提供的另一跨应用的关系链扩展装置的结构示意图。本申请实施例提供的训练装置2包括：

添加指令获取模块21，用于获取输入的联系人添加指令；

联系人信息获取及发送模块22，用于响应于上述联系人添加指令，获取第二应用的第二联系人目录并发送至第一应用客户端，以在第一应用的联系人添加界面中显示上述第二联系人目录；

第二添加模块23，用于获取上述第一应用客户端发送的联系人添加请求，上述联系人添加请求是由上述第一应用客户端基于针对上述第二联系人目录中目标联系人的确定操作确定的；

添加请求发送模块24，用于向上述目标联系人对应的第二应用客户端发送上述联系人添加请求。

在一些可行的实施方式中，上述添加请求发送模块24，用于：

确定已向上述目标联系人对应的第二应用客户端发送联系人添加请求的次数；

若上述次数小于预设次数，则向上述目标联系人对应的第二应用客户端发送上述联系人添加请求。

在一些可行的实施方式中，上述添加请求发送模块24，还用于：

若在预设时长内未获取到上述目标联系人对于上述联系人添加请求的响应、且已向上述目标联系人对应的第二应用客户端发送联系人添加请求的次数小于上述预设次数，则向上述目标联系人对应的第二应用客户端再次发送上述联系人添加请求；

若在上述预设时长内未获取到上述目标联系人对于上述联系人添加请求的响应、且已向上述目标联系人对应的第二应用客户端发送联系人添加请求的次数等于上述预设次数，则确定上述目标联系人拒绝添加在上述第一应用的第一联系人目录。

参见图14，图14是本申请实施例提供的又一跨应用的关系链扩展装置的结构示意图。本申请实施例提供的训练装置3包括：

接收模块31，用于接收联系人添加请求，上述联系人添加请求由第一应用客户端响应于针对第二应用的第二联系人目录中目标联系人的确定操作确定的；

第二显示模块32，用于在上述第二应用的请求内容显示界面中显示上述联系人添加请求对应的请求内容。

在本申请实施例中，第一应用客户端响应与联系人添加指令，可在联系人添加界面中显示第二应用的联系人目录，从而通过联系人添加界面使得用户直接选择其需要添加的目标联系人，可优化用户体验。与此同时，第一应用的服务器可通过第二应用的服务器，将联系人添加指令发送至第二应用客户端，从而使得用户可直接基于第一应用客户端添加第二应用中的联系人，简化用户添加联系人的操作，提升添加联系人的便捷性，适用性高。进一步的，用户在添加第二应用中的联系人时，可第一应用可通过详情添加界面向用户显示已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息，以及已添加和未添加为用户在第一应用中的联系人的相关信息等，进一步提升用户体验。此外，第一应用还可通过请求内容编辑界面可使用户选择、编辑对应的请求内容，可迎合用户喜好，为用户提供个性化的联系人添加服务，适用性高。

参见图15，图15是本申请实施例提供的电子设备的结构示意图。如图15所示，本实施例中的电子设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述电子设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1004可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图15所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用。

在图15所示的电子设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用，以实现本申请实施例任一可选实施例中所提供的方法，如可以实现本申请实施例所提供的第一应用的客户端所执行的方法，或者第二应用的客户端所执行的方法，或者第一应用的客户端的服务器所执行的方法，或者第二应用的服务器所执行的方法。

应当理解，在一些可行的实施方式中，上述处理器1001可以是中央处理单元(central processing unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integratedcircuit，ASIC)、现成可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。该存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。存储器的一部分还可以包括非易失性随机存取存储器。例如，存储器还可以存储设备类型的信息。

在本申请实施例中，第一应用客户端响应与联系人添加指令，可在联系人添加界面中显示第二应用的联系人目录，从而通过联系人添加界面使得用户直接选择其需要添加的目标联系人，可优化用户体验。与此同时，第一应用的服务器可通过第二应用的服务器，将联系人添加指令发送至第二应用客户端，从而使得用户可直接基于第一应用客户端添加第二应用中的联系人，简化用户添加联系人的操作，提升添加联系人的便捷性，适用性高。进一步的，用户在添加第二应用中的联系人时，可第一应用可通过详情添加界面向用户显示已发送联系人添加请求的联系人的相关信息、未发送过联系人添加请求的联系人的相关信息，以及已添加和未添加为用户在第一应用中的联系人的相关信息等，进一步提升用户体验。此外，第一应用还可通过请求内容编辑界面可使用户选择、编辑对应的请求内容，可迎合用户喜好，为用户提供个性化的联系人添加服务，适用性高。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，被处理器执行以实现图2和/或图9中各个步骤所提供的方法，具体可参见上述各个步骤所提供的实现方式，在此不再赘述。

上述计算机可读存储介质可以是前述任一实施例提供的任务处理装置的内部存储单元，例如电子设备的硬盘或内存。该计算机可读存储介质也可以是该电子设备的外部存储设备，例如该电子设备上配备的插接式硬盘，智能存储卡(smart media card,SMC)，安全数字(secure digital,SD)卡，闪存卡(flash card)等。上述计算机可读存储介质还可以包括磁碟、光盘、只读存储记忆体(read-only memory，ROM)或随机存储记忆体(randomaccess memory，RAM)等。进一步地，该计算机可读存储介质还可以既包括该电子设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该电子设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行图2和/或图9中各个步骤所提供的方法。

本申请的权利要求书和说明书及附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或电子设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或电子设备固有的其它步骤或单元。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置展示该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

以上所揭露的仅为本申请较佳实施例而已，不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (10)

1.一种跨应用的关系链扩展方法，其特征在于，所述方法包括：

响应于通过第一应用客户端输入的联系人添加指令，在第一应用的联系人添加界面中显示联系人添加提示信息，所述联系人添加提示信息包括添加第二联系人目录中的联系人时向第二客户端发送联系人添加请求的发送机制；响应于用户针对联系人添加提示信息的确认操作，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；所述发送机制包括发送时间、发送次数、每两次发送之间的时间间隔；

响应于针对所述第二联系人目录中至少一个目标联系人的确定操作，显示请求内容编辑界面，通过所述请求内容编辑界面获取用户的编辑操作，基于所述编辑操作生成联系人添加请求并发送至第一服务器，所述联系人添加请求包括所述编辑操作对应的请求内容，所述第一服务器根据所述发送机制向所述目标联系人对应的第二应用客户端发送至少一次联系人添加请求，以在所述目标联系人对应的第二应用客户端未发送同意添加指令时，根据所述发送次数和每两次发送之间的时间间隔再次向目标联系人对应的第二应用客户端发送联系人添加请求，以及所述目标联系人对应的第二应用客户端发送同意添加指令后，将所述目标联系人添加在所述第一应用的第一联系人目录；

响应于通过第一应用客户端输入的添加进度查询操作，显示添加进度界面，通过所述添加进度界面显示已发送联系人添加请求的联系人的添加进度；

响应于通过第一应用客户端输入的针对指定添加进度的查询操作，显示已发送联系人添加请求的联系人中，与所述指定添加进度对应的联系人的相关信息。

2.根据权利要求1所述的方法，其特征在于，所述请求内容编辑界面显示有请求内容模板，所述编辑操作包括内容确认操作或内容修改操作；

若所述编辑操作为内容确认操作，所述基于所述编辑操作对应的请求内容，向所述目标联系人对应的第二应用客户端发送联系人添加请求，包括：

基于所述请求内容模板，向所述目标联系人对应的第二应用客户端发送联系人添加请求；

若所述编辑操作为内容修改操作，所述基于所述编辑操作对应的请求内容，向所述目标联系人对应的第二应用客户端发送联系人添加请求，包括：

根据所述内容修改操作，对所述请求内容模板进行修改，显示修改后的请求内容；

响应于针对所述修改后的请求内容的确认操作，根据所述修改后的请求内容，向所述目标联系人对应的第二应用客户端发送联系人添加请求。

3.根据权利要求1所述的方法，其特征在于，所述在第一应用的联系人添加界面中显示第二应用的第二联系人目录，包括：

若用户的账号与所述第二应用未绑定，或者未获取到所述用户对于获取所述第二应用的第二联系人目录的授权，则显示引导界面，以通过所述引导界面引导所述用户将所述账号与所述第二应用绑定，和/或，授权获取所述第二应用的第二联系人目录的授权；

在所述账号与所述第二应用绑定，且获取到所述用户对于获取所述第二应用的第二联系人目录的授权时，在联系人添加界面中显示所述第二应用的第二联系人目录。

4.根据权利要求1至3中任一项所述的方法，其特征在于，在第一应用的联系人添加界面中显示的第二应用的第二联系人目录，包括除以下联系人之外的联系人：

已添加在所述第一联系人目录的联系人；

已拒绝添加在所述第一联系人目录的联系人。

5.一种跨应用的关系链扩展方法，其特征在于，所述方法包括：

获取第一应用客户端发送的联系人添加指令；

响应于所述联系人添加指令，获取第二应用的第二联系人目录并发送至所述第一应用客户端，以在第一应用的联系人添加界面中显示联系人添加提示信息，所述联系人添加提示信息包括添加所述第二联系人目录中的联系人时向第二客户端发送联系人添加请求的发送机制，并且响应于用户针对联系人添加提示信息的确认操作，在第一应用的联系人添加界面中显示所述第二联系人目录；所述发送机制包括发送时间、发送次数、每两次发送之间的时间间隔；

获取所述第一应用客户端发送的联系人添加请求，所述联系人添加请求是由所述第一应用客户端基于针对所述第二联系人目录中目标联系人的确定操作确定的；

根据所述发送机制向所述目标联系人对应的第二应用客户端发送至少一次所述联系人添加请求，以在所述目标联系人对应的第二应用客户端未发送同意添加指令时，根据所述发送次数和每两次发送之间的时间间隔再次向目标联系人对应的第二应用客户端发送联系人添加请求。

6.根据权利要求5所述的方法，其特征在于，其中，所述向所述目标联系人对应的第二应用客户端发送至少一次所述联系人添加请求，包括：

确定已向所述目标联系人对应的第二应用客户端发送联系人添加请求的次数；

若所述次数小于预设次数，则向所述目标联系人对应的第二应用客户端发送所述联系人添加请求。

7.一种跨应用的关系链扩展装置，其特征在于，所述装置包括：

第一显示模块，用于响应于通过第一应用客户端输入的联系人添加指令，在第一应用的联系人添加界面中显示联系人添加提示信息，所述联系人添加提示信息包括添加第二联系人目录中的联系人时向第二客户端发送联系人添加请求的发送机制；响应于用户针对联系人添加提示信息的确认操作，在第一应用的联系人添加界面中显示第二应用的第二联系人目录；所述发送机制包括发送时间、发送次数、每两次发送之间的时间间隔；

第一添加模块，用于响应于针对所述第二联系人目录中至少一个目标联系人的确定操作，显示请求内容编辑界面，通过所述请求内容编辑界面获取用户的编辑操作，基于所述编辑操作生成联系人添加请求并发送至第一服务器，所述联系人添加请求包括所述编辑操作对应的请求内容，所述第一服务器根据所述发送机制向所述目标联系人对应的第二应用客户端发送联系人添加请求；以在所述目标联系人对应的第二应用客户端未发送同意添加指令时，根据所述发送次数和每两次发送之间的时间间隔再次向目标联系人对应的第二应用客户端发送联系人添加请求，以及所述目标联系人对应的第二应用客户端发送同意添加指令后，将所述目标联系人添加在所述第一应用的第一联系人目录；

其中，所述第一添加模块还用于：

响应于通过第一应用客户端输入的添加进度查询操作，显示添加进度界面，通过所述添加进度界面显示已发送联系人添加请求的联系人的添加进度；

响应于通过第一应用客户端输入的针对指定添加进度的查询操作，显示已发送联系人添加请求的联系人中，与所述指定添加进度对应的联系人的相关信息。

8.一种跨应用的关系链扩展装置，其特征在于，所述装置包括：

添加指令获取模块，用于获取第一应用客户端发送的联系人添加指令；

联系人信息获取及发送模块，用于响应于所述联系人添加指令，获取第二应用的第二联系人目录并发送至所述第一应用客户端，以在第一应用的联系人添加界面中显示联系人添加提示信息，所述联系人添加提示信息包括添加所述第二联系人目录中的联系人时向第二客户端发送联系人添加请求的发送机制，并且响应于用户针对联系人添加提示信息的确认操作，在第一应用的联系人添加界面中显示所述第二联系人目录；所述发送机制包括发送时间、发送次数、每两次发送之间的时间间隔；

第二添加模块，用于获取所述第一应用客户端发送的联系人添加请求，所述联系人添加请求是由所述第一应用客户端基于针对所述第二联系人目录中目标联系人的确定操作确定的；

添加请求发送模块，用于根据所述发送机制向所述目标联系人对应的上述第二应用客户端发送至少一次联系人添加请求，以在所述目标联系人对应的第二应用客户端未发送同意添加指令时，根据所述发送次数和每两次发送之间的时间间隔再次向目标联系人对应的第二应用客户端发送联系人添加请求。

9.一种电子设备，其特征在于，包括处理器和存储器，所述处理器和存储器相互连接；

所述存储器用于存储计算机程序；

所述处理器被配置用于在调用所述计算机程序时，执行如权利要求1至4任一项所述的方法，或者执行权利要求5至6任意一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行以实现权利要求1至6任一项所述的方法。

Images