终端及其基于二维码的信息交互方法、存储装置与流程

本发明涉及信息交互技术领域，具体涉及一种终端及其基于二维码的信息交互方法、存储装置。

背景技术：

交际社会，联系人信息的交互是一种自我宣传及结识他人的一种重要方式，当前利用手机等电子终端进行联系人信息的交互已逐渐代替纸质名片，成为社交圈内的一股潮流。现有手机一般以文本形式和二维码方式进行联系人信息的交互。但是，文本形式无法支持联系人信息的快捷分享，而二维码方式不仅需要对方手动操作终端对二维码进行扫描和联系人信息的添加，而且受到地理位置的限制。

技术实现要素：

有鉴于此，本发明提供一种终端及其基于二维码的信息交互方法、存储装置，能够实现联系人信息的快捷分享，减少用户操作，且不受地理位置限制。

本发明一实施例的基于二维码的信息交互方法，包括：

第一终端调取联系人信息，并生成与联系人信息对应的二维码；

第一终端筛选出能够传输位图文件的应用程序，并通过应用程序将所述二维码发送给第二终端；

第二终端接收二维码，并将二维码保存于系统图片库；

所述第二终端监测系统图片库是否有新增的图片；

当监测到系统图片库有新增的图片时，第二终端检测新增的图片是否包含二维码；

若是，则第二终端扫描二维码以获取相应的联系人信息。

本发明一实施例的基于二维码进行信息交互的终端，所述终端包括处理器以及与处理器连接的存储器和收发器，其中，

收发器用于接收二维码，并将所述二维码保存于系统图片库；

处理器用于监测系统图片库是否有新增的图片，并在监测到系统图片库有新增的图片时检测新增的图片是否包含二维码；若是，则处理器用于扫描二维码以获取相应的联系人信息；

存储器用于存储联系人信息。

本发明一实施例的存储装置，存储有程序数据，所述程序数据能够被执行以实现上述基于二维码的信息交互方法。

有益效果：本发明通过二维码进行联系人信息的发送与接收，能够实现联系人信息的快捷分享，通过传输位图文件的应用程序发送二维码的方式，使得对方无需当面或近距离扫描二维码，因此能够减少用户操作，且不受地理位置限制。

附图说明

图1是本发明第一实施例的基于二维码的信息交互方法的流程示意图；

图2是本发明一实施例的通过应用程序分享二维码的方法的流程示意图；

图3是本发明一实施例的监测系统图片库是否有新增的图片的方法的流程示意图；

图4是本发明一实施例的检测新增的图片是否包含二维码的方法的流程示意图；

图5是本发明第二实施例的基于二维码的信息交互方法的流程示意图；

图6是本发明另一实施例的检测新增的图片是否包含二维码的方法的流程示意图；

图7是本发明第三实施例的基于二维码的信息交互方法的流程示意图；

图8是本发明一实施例的终端的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明所提供的各个示例性的实施例的技术方案进行清楚、完整地描述。在不冲突的情况下，下述各个实施例以及实施例中的特征可以相互组合。

请参阅图1，为本发明一实施例的基于二维码的信息交互方法。所述信息交互方法可以包括步骤s11～s16。

s11：第一终端调取联系人信息，并生成与联系人信息对应的二维码。

第一终端可以采用vcard(personaldatainterchange,个人数据交换)格式调取联系人信息，所述联系人信息包括但不限于通讯录中联系人的手机号码、地址、头像等信息。vcard格式字段通过标识符记录联系人信息，即不同取值的标识符与不同的联系人信息具有映射关系。由于vcard格式字段的标识符的取值有限，为了实现更多联系人信息的添加，本实施例可以使用枚举类型来记录vcard格式字段的标识符与联系人信息的映射关系，即，本实施例将vcard格式字段的标识符所有可能的取值一一列举出来，并与联系人信息建立映射关系。

第一终端可以根据用户指令选择某一指定联系人的部分信息并生成二维码。具体地，在接收到用户指令后，第一终端的系统可以通过contentprovider(内容提供)组件获取vcard格式字段中的指定字段。当然，本发明的其他实施例也可以在未接收到用户指令时默认调取某一指定联系人的全部信息并生成对应的二维码。

本实施例可以使用zxing(开源项目)源码来对vcard格式字段进行编码，且在编码后返回一个bitmatrix(位矩阵)对象，最后利用这个bitmatrix对象绘制二维码。所绘制的二维码包括寻像图形、定位图形、数据编码内容和纠错信息码。寻像图形和定位图形表现为二维码的三个“回”字形区域，用于确定二维码的位置，并提供坐标参考。数据编码内容即vcard格式字段按照某种预定编码算法转换成的条码。纠错信息码用于指定二维码的容错率，以保证数据的容错性，纠错信息码可以为rs码(reedsolomon,里所码)。二维码的容错率越高，其包含的纠错信息码越多，二维码的可修复能力越高。

进一步，本实施例可以采用addlogo(加贴标识)方法在二维码中间添加联系人头像。具体地，第一终端的系统采用canvas(覆盖)算法将二维码和联系人头像这两张图片按照一定比例进行合成绘制。在合成绘制过程中，由于原二维码(合成绘制之前的二维码)的中间部分的数据被覆盖而丢失，因此需要原二维码的容错率较高。

s12：第一终端筛选出能够传输位图文件的应用程序，并通过应用程序将所述二维码发送给第二终端。

二维码实质上就是位图文件(bitmap)，因此分享一张二维码与分享一张图片的方式相同。基于此，请参阅图2，首先，第一终端的系统设置intent(需求)组件的action(动作)为发送，即intent.action_send，并且intent组件的type(类型)为“image/jpeg”或“image/*”。然后，通过packagemanager(程序包管理)组件的getpackageinfo(获取程序包信息)函数即可获取第一终端安装的所有具有“image/jpeg”或“image/*”的应用程序的信息。如果intent组件指定需要使用特定应用程序进行二维码的分享，则第一终端可以通过packagemanager组件获取resultinfo(结果信息)的list(列表)，通过比较resultinfo的packagename(软件包名)与目标应用程序的packagename来确定目标应用程序。最后，系统将目标应用程序的component(组件)作为的intent组件的component，并调用startactivity(执行动作)函数将二维码发送出去，以此实现通过该目标应用程序分享二维码。

s13：第二终端接收二维码，并将二维码保存于系统图片库。

在第二终端成功获取到第一终端传输过来的二维码后，第二终端的系统图片库便发生变化，新的二维码添加入系统图片库。

s14：第二终端监测系统图片库是否有新增的图片。

以android系统为例，第二终端的系统可使用contentobserver(内容观察)组件监控系统图片库中的数据变化。当系统图片库中的数据变化时，contentobserver组件可以通过onchange()函数(待改变函数)返回变化前和变化后的数据，以此获取到新增的图片。

为了增加对系统图片库的监控时长，即尽可能在宏观上一直保持监测状态，本实施例可以采用图3所示三种方式中的一种执行监测。

一是，提高监测系统图片库的后台进程的优先级，使得后台进程变为服务进程(intentservice)，并通过服务进程监测系统图片库是否有新增的图片。具体地，在androidmanifest(名单)中设置后台进程的优先级数值，例如为最高值1000。然后，调用onstartcommand(待启动命令)函数返回start_stickt(连续)命令。基于此，服务进程在系统资源紧张时可能会被结束运行，但当系统资源恢复时，该服务进程就会重新启动，从而继续监测系统图片库是否有新增的图片。

二是，提高监测系统图片库的后台进程在前台运行的优先级，而后通过后台进程监测系统图片库是否有新增的图片。具体地，第二终端的系统设置receiver_boot_completed组件为permission(许可)，以将activity进程和service进程分开。service进程通过br(broadcastreceiver,广播接收机)接收开机信号，并启动service进程。然后，service进程调用startforeground(开启前台)函数。activity进程启动后与service进程绑定，两者之间通过ipc(inter-processcommunication,进程间通信)方式进行通信，从而能够在第二终端的菜单通知栏显示是否有新增的图片的通知项。activity进程退出时与service进程解绑。

三是，使用服务进程和守护进程交替监测系统图片库是否有新增的图片。服务进程和守护进程保持父子关系，若子进程结束，则父进程重新创建子进程；若父进程结束，则子进程使用am(activitymanager,活动管理)命令重启父进程。即，服务进程监听守护进程的运行状态，若守护进程结束，则服务进程重新唤起守护进程；守护进程监听服务进程的运行状态，若服务进程结束，则守护进程重新唤起服务进程。

当然，本发明其他实施例可以通过监测系统图片库中图片的标识符以判断是否有新增的图片。具体地，将监听服务依附于某些具体的软件，当软件被用户打开运行时，后台服务进程可以对系统图片库中图片的标识符进行遍历查找，以此筛选出新增的图片。其中，标识符可以使用bit(字节)类型，如果图片被监测过，则其标识符修改为1，否则为null。通过这种方式，当系统图片库具有大量图片时，即使对系统图片库进行一遍遍历，也能减少时间和资源上的损耗。

如果监测到系统图片库有新增的图片，则执行步骤s15～s16。如果未监测到系统图片库有新增的图片，则继续执行步骤s14，直至监测到系统图片库有新增的图片时才执行步骤s15～s16。

s15：第二终端检测新增的图片是否包含二维码。

结合图4所示，本实施例可以在zxing(开源项目)源码中通过getframingrect()函数(矩形框架函数)修改二维码扫描的聚焦框的尺寸，即并不限定聚焦框的尺寸为图片(屏幕)尺寸的5/8，而后通过getframingrectinpreview()函数(矩形框架预览函数)完成第二终端的屏幕分辨率到相机分辨率的转换，从而能够在聚焦框中显示图片的全部尺寸。而后，通过聚焦框扫描图片，并判断该图片是否存在三个“回”字形标识，若存在，则判定新增的图片包含二维码，执行步骤s16；若不存在，则判定新增的图片不包含二维码，不对该图片执行后续扫描处理，可以继续执行步骤s14。本实施例通过扫描检测图片是否含有三个“回”字形标识即可，而不需要全盘扫描图片并解析出二维码的全部内容。

s16：第二终端扫描二维码以获取相应的联系人信息。

本实施例可以调用zxing源码中qrcodereader(二维码读取)组件的decode()函数(解码函数)自动扫描二维码。

基于上述，本实施例采用当前通用的二维码进行联系人信息的分享与交互，解决了传统使用文本或附件形式分享需要用户手动进行信息添加处理的弊端，同时具有一定的数据保密性。并且，相比较于现有技术仅能够对通讯录中的联系人信息生成二维码，本实施例能够允许二维码携带更多的联系人信息。

另外，通过能够传输位图文件的应用程序发送联系人信息的二维码，本实施例能够多渠道分享联系人信息，例如用户可以通过彩信、微信、邮件等应用程序传输联系人信息，使得对方无需当面或近距离扫描二维码，因此能够减少用户操作，且不受地理位置限制。

并且，通过后台服务进程自动检测新增的图片是否包含二维码并识别其中的信息，改变了“打开扫描器—打开系统图片库—选择系统图片库中的图片—进行二维码扫描”这一传统的扫描系统图片库二维码方式，能够大大简化用户操作。

请参阅图5，为本发明另一实施例的基于二维码的信息交互方法。所述信息交互方法可以包括步骤s51～s56。

s51：第一终端调取联系人信息，并生成与联系人信息对应的二维码。

s52：第一终端筛选出能够传输位图文件的应用程序，并通过应用程序将所述二维码发送给第二终端。

s53：第二终端接收二维码，并将二维码保存于系统图片库。

s54：第二终端件监测系统图片库在预定时间内是否有多张新增的图片。

在监测到所述系统图片库预定时间内有多张新增的图片时，本实施例执行步骤s55和s56。在监测到所述系统图片库预定时间内仅有一张新增的图片时，本实施例直接执行步骤s56。

s55：第二终端获取所述多张新增的图片中含有二维码的图片并显示给用户，并根据用户指令扫描二维码。

s56：第二终端扫描二维码以获取相应的联系人信息。

在前述实施例的描述基础上，但与其不同的是，本实施例第二终端的系统会进行一个预定时间(例如2秒)的延时操作，用以区分用户操作的目的性。当这段预定时间内只有一张新增的图片导入时，表示该图片是用户有意加入，有较大概率需要扫描，此时系统在延时结束后会检测该新增的图片是否含有二维码，如果有，则直接扫描并获取相应的联系人信息并保存。如果这段预定时间内有多张新增的图片导入，表示用户需要自动扫描二维码的目的性不强，因此只需要在延时结束后对新增的图片进行是否包含二维码的检测即可。

其中，在这段预定时间内有多张新增的图片导入时，本实施例可以将多张新增的图片的uri(uniformresourceidentifier,统一资源标识符)加入待处理队列，而不需要将新增的图片缓存。只有当用户下达对待处理队列中的图片进行操作时，本实施例才根据uri缓存新增的图片，并将其中包含二维码的图片显示给用户，交由用户选择是否扫描。

对于cpu和内存资源都极其有限的终端来说，图片的加载和处理过程容易大量被占用系统资源，导致系统卡顿并影响整个系统的性能，严重时会出现oom(outofmemory,内存不足)现象。基于此，在监测到系统图片库预定时间内有多张新增的图片时，本实施例可以将多张新增的图片依序加入阻塞队列，并建立线程池，利用线程池建立的多个工作线程检测阻塞队列中的多张新增的图片是否包含二维码。

结合图6所示，利用线程池设定本次任务最大可开启的工作线程数例如为n，线程池在创建时其本身没有工作线程。线程池管理器将预定时间内获取的多张新增的图片依序加入阻塞队列中，阻塞队列能保证处理过程有序进行。阻塞队列会对当前的工作线程产生阻塞，如果阻塞队列为空，则当前的工作线程会被阻塞直到阻塞队列中有了新增的图片，然后被阻塞的工作线程会被唤醒。唤醒的工作线程判断新增的图片是否包含二维码，并将判断结果加入结果队列。线程池管理器从结果队列中获取多张新增的图片中含有二维码的图片。通过阻塞队列+线程池的方式，本实施例能够有效的管理、调度工作线程去识别多张新增的图片是否包含二维码，避免过多的系统资源消耗。

请参阅图7，为本发明的基于二维码的信息交互方法一具体应用例。该实施例实现本发明前述实施例的整个过程，在此不作赘述。

应该理解到，上述各个实施例之间可以相互结合，并且上述功能如果以软件功能的形式实现并作为独立产品销售或使用时，可存储在一个电子设备可读取存储介质中，即，本发明还提供一种存储有程序数据的存储装置，所述程序数据能够被执行以实现上述实施例的方法，该存储装置可以为如u盘、光盘、服务器等。也就是说，本发明的各个实施例可以以软件产品的形式体现出来，其包括若干指令用以使得一台智能终端执行各个实施例所述方法的全部或部分步骤。

请参阅图8，为本发明一实施例的基于二维码进行信息交互的终端。所述终端80可以包括处理器81、存储器82、收发器83、显示器84和通信总线85，处理器81通过通信总线85与存储器82、收发器83和显示器84连接。

收发器83用于接收二维码，并将二维码保存于系统图片库。

处理器81用于监测系统图片库是否有新增的图片，并在监测到系统图片库有新增的图片时检测新增的图片是否包含二维码。若有，则处理器81用于扫描二维码以获取相应的联系人信息。

存储器82用于存储联系人信息。

为了增加对系统图片库的监控时长，即尽可能在宏观上一直保持监测状态，处理器81可以提高监测系统图片库的后台进程的优先级，使得所述后台进程变为服务进程，并通过服务进程监测系统图片库是否有新增的图片，或者，提高监测系统图片库的后台进程在前台运行的优先级，而后通过后台进程监测系统图片库是否有新增的图片；又或者，使用服务进程和守护进程交替监测系统图片库是否有新增的图片。

在处理器81监测到系统图片库预定时间内有多张新增的图片时，所述终端80的显示器84用于将多张新增的图片中含有二维码的图片显示给用户，收发器83用于接收用户指令，处理器81用于根据收发器83接收到的用户指令扫描二维码。

在监测到系统图片库预定时间内有多张新增的图片时，处理器81用于将多张新增的图片依序加入阻塞队列，以及建立线程池，并利用线程池建立的多个工作线程检测阻塞队列中的多张新增的图片是否包含二维码。

本实施例的终端80的上述结构元件对应执行上述各个实施例的基于二维码的信息交互方法，具有与其相同的技术效果。

本发明全文所述终端(包括第一终端和第二终端)可以为智能手机、pda(personaldigitalassistant，个人数字助理或平板电脑)等移动终端，也可以是佩戴于肢体或者嵌入于衣物、首饰、配件中的具有联系人信息交互显示功能的可穿戴设备。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，例如各实施例之间技术特征的相互结合，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。