一种智能交互通信方法及通信系统

摘要

本发明实施例涉及通信技术领域，公开了一种智能交互通信方法及通信系统，该方法包括：在获取到二维码上的URL地址信息之后，解析URL地址信息以获取请求对应的URL地址路径；与服务端建立通信连接以发送HTTP报文数据；根据请求对应的URL地址路径，控制服务端通过Web路由向业务处理器分发业务数据；其中，业务数据为服务端对HTTP报文数据进行解析之后所获得的；获取业务处理器的业务处理结果。实施本发明实施例，能够高效处理网络请求，且不占用太多系统资源。

权利要求

1.一种智能交互通信方法，其特征在于，包括：

在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径；

与服务端建立通信连接以发送HTTP报文数据；

根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据；其中，所述业务数据为所述服务端对所述HTTP报文数据进行解析之后所获得的；

获取所述业务处理器的业务处理结果；

所述根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据，包括：将所述请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配；若匹配成功，控制所述服务端向所述拦截器分发所述业务数据；

若所述请求对应的URL地址路径与所述拦截器路由表上的映射路径匹配不成功，将所述请求对应的URL地址路径与控制器路由表上的映射路径进行匹配；若匹配成功，控制所述服务端向所述控制器分发所述业务数据。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：若所述请求对应的URL地址路径与所述控制器路由表上的映射路径匹配不成功，将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配；

若匹配成功，获取所述文件路径中的数据信息作为所述业务处理结果。

3.根据权利要求2所述的方法，其特征在于，所述在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径之前，所述方法还包括：采用注解加反射的方式将扫描包中带有的拦截器及控制器注解的类分别映射到哈希路由表；其中，所述哈希路由表内至少含有拦截器路由表与控制器路由表；

启动HTTP服务，以监听所述二维码发送的请求。

4.根据权利要求1～3任一项所述的方法，其特征在于，所述方法还包括：若接收到所述业务处理结果的响应信号低于指定次数，确定出当前连接并非长连接状态；

断开与所述服务端之间的连接。

5.一种通信系统，其特征在于，所述通信系统包括：

解析单元，用于在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径；

连接单元，用于与服务端建立通信连接以发送HTTP报文数据；

控制单元，用于根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据；其中，所述业务数据为所述服务端对所述HTTP报文数据进行解析之后所获得的；

获取单元，用于获取所述业务处理器的业务处理结果；

所述控制单元包括：

第一匹配子单元，用于将所述请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配；

第一控制子单元，用于在所述第一匹配子单元将所述请求对应的URL地址路径与拦截器路由表上的映射路径成功匹配时，控制所述服务端向所述拦截器分发所述业务数据；

第二匹配子单元，用于在所述第一匹配子单元将所述请求对应的URL地址路径与所述拦截器路由表上的映射路径不成功匹配时，将所述请求对应的URL地址路径与控制器路由表上的映射路径进行匹配；

第二控制子单元，用于在所述第二匹配子单元将所述请求对应的URL地址路径与控制器路由表上的映射路径成功匹配时，控制所述服务端向所述控制器分发所述业务数据。

6.根据权利要求5所述的通信系统，其特征在于，所述控制单元还包括：第三匹配子单元，用于在所述第二匹配子单元将所述请求对应的URL地址路径与控制器路由表上的映射路径不成功匹配时，将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配；

获取子单元，用于在所述第三匹配子单元将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径成功匹配时，获取所述文件路径中的数据信息。

说明书

一种智能交互通信方法及通信系统

技术领域

[0001] 本发明涉及通信技术领域，尤其涉及一种智能交互通信方法及通信系统。

背景技术

[0002] 目前，市面上常见的通信系统应用大多都是基于互联网进行数据交互通信的，即都需要与服务器进行交互通信。但在实践中发现，传统的Web服务程序大多都是需要安装于通信系统中依附于通信系统的系统以运行的，而由于通信系统的RAM存储容量有限(一般在1到3G之间，去除系统核心服务和系统程序，剩余的可用内存会比较小)，进而容易对通信系统的运行速度造成一定的影响。

发明内容

[0003] 本发明实施例公开一种智能交互通信方法及通信系统，能够高效处理网络请求，且不占用太多系统资源。

[0004] 本发明实施例第一方面公开一种智能交互通信方法，所述方法包括：在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径；

[0005] 与服务端建立通信连接以发送HTTP报文数据；

[0006] 根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据；其中，所述业务数据为所述服务端对所述HTTP报文数据进行解析之后所获得的；

[0007] 获取所述业务处理器的业务处理结果。

[0008] 作为另一种可选的实施方式，在本发明实施例第一方面中，所述根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据，包括：

[0009] 将所述请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配；若匹配成功，控制所述服务端向所述拦截器分发所述业务数据；

[0010] 若所述请求对应的URL地址路径与所述拦截器路由表上的映射路径匹配不成功，将所述请求对应的URL地址路径与控制器路由表上的映射路径进行匹配；若匹配成功，控制所述服务端向所述控制器分发所述业务数据。

[0011] 作为另一种可选的实施方式，在本发明实施例第一方面中，所述方法还包括：

[0012] 若所述请求对应的URL地址路径与所述控制器路由表上的映射路径匹配不成功，将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配；

[0013] 若匹配成功，获取所述文件路径中的数据信息作为所述业务处理结果。

[0014] 作为另一种可选的实施方式，在本发明实施例第一方面中，所述在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径之前，所述方法还包括：

[0015] 采用注解加反射的方式将扫描包中带有的拦截器及控制器注解的类分别映射到哈希路由表；其中，所述哈希路由表内至少含有拦截器路由表与控制器路由表；

[0016] 启动HTTP服务，以监听所述二维码发送的请求。

[0017] 作为另一种可选的实施方式，在本发明实施例第一方面中，所述方法还包括：

[0018] 若接收到所述业务处理结果的响应信号低于指定次数，确定出当前连接并非长连接状态；

[0019] 断开与所述服务端之间的连接。

[0020] 本发明实施例第二方面公开一种通信系统，所述通信系统包括：

[0021] 解析单元，用于在获取到二维码上的URL地址信息之后，解析所述URL地址信息以获取请求对应的URL地址路径；

[0022] 连接单元，用于与服务端建立通信连接以发送HTTP报文数据；

[0023] 控制单元，用于根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据；其中，所述业务数据为所述服务端对所述HTTP报文数据进行解析之后所获得的；

[0024] 获取单元，用于获取所述文件路径中的数据信息作为所述业务处理结果。

[0025] 作为一种可选的实施方式，在本发明实施例第二方面中，所述控制单元包括：

[0026] 第一匹配子单元，用于将所述请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配；

[0027] 第一控制子单元，用于在所述第一匹配子单元将所述请求对应的URL地址路径与拦截器路由表上的映射路径成功匹配时，控制所述服务端向所述拦截器分发所述业务数据；

[0028] 第二匹配子单元，用于在所述第一匹配子单元将所述请求对应的URL地址路径与所述拦截器路由表上的映射路径不成功匹配时，将所述请求对应的URL地址路径与控制器路由表上的映射路径进行匹配；

[0029] 第二控制子单元，用于在所述第二匹配子单元将所述请求对应的URL地址路径与控制器路由表上的映射路径成功匹配时，控制所述服务端向所述控制器分发所述业务数据。

[0030] 作为一种可选的实施方式，在本发明实施例第二方面中，所述控制单元还包括：

[0031] 第三匹配子单元，用于在所述第二匹配子单元将所述请求对应的URL地址路径与控制器路由表上的映射路径不成功匹配时，将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配；

[0032] 获取子单元，用于在所述第三匹配子单元将所述请求对应的URL地址路径与指定的本地磁盘目录中的文件路径成功匹配时，获取所述文件路径中的数据信息。

[0033] 本发明实施例第三方面公开一种通信系统，所述通信系统包括：

[0034] 存储有可执行程序代码的存储器；

[0035] 与所述存储器耦合的处理器；

[0036] 所述处理器调用所述存储器中存储的所述可执行程序代码，执行本发明实施例第一方面公开的一种智能交互通信方法。

[0037] 本发明实施例第四方面公开一种计算机可读存储介质，其存储计算机程序，其中，所述计算机程序使得计算机执行本发明实施例第一方面公开的一种智能交互通信方法。

[0038] 本发明实施例第五方面公开一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行第一方面的任意一种智能交互通信方法的部分或全部步骤。

[0039] 本发明实施例第六方面公开一种应用发布平台，所述应用发布平台用于发布计算机程序产品，其中，当所述计算机程序产品在计算机上运行时，使得所述计算机执行第一方面的任意一种智能交互通信方法的部分或全部步骤。

[0040] 与现有技术相比，本发明实施例具有以下有益效果：

[0041] 本发明实施例中，在获取到二维码上的URL地址信息之后，通信系统可解析所述URL地址信息以获取请求对应的URL地址路径，并与服务端建立通信连接以发送HTTP报文数据，随后可根据所述请求对应的URL地址路径，控制所述服务端通过Web路由向业务处理器分发业务数据；其中，所述业务数据为所述服务端对所述HTTP报文数据进行解析之后所获得的，最后，获取所述业务处理器的业务处理结果。可见，本发明实施例，能够高效处理网络请求，且不占用太多系统资源。

附图说明

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

[0043] 图1是本发明实施例公开的一种智能交互通信方法的流程示意图；

[0044] 图2是本发明实施例公开的另一种智能交互通信方法的流程示意图；

[0045] 图3是本发明实施例公开的一种通信系统的结构示意图；

[0046] 图4是本发明实施例公开的另一种通信系统的结构示意图；

[0047] 图5是本发明实施例公开的另一种通信系统的结构示意图。

具体实施方式

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

[0049] 需要说明的是，本发明的说明书和权利要求书中的术语“第一”、“第二”、“第三”“第四”等是用于区别不同的对象，而不是用于描述特定顺序。本发明实施例的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、通信系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

[0050] 本发明实施例公开了一种智能交互通信方法及通信系统，。

[0051] 实施例一

[0052] 请参阅图1，图1是本发明实施例公开的一种智能交互通信方法的流程示意图。如图1所示，该智能交互通信方法可以包括以下步骤。

[0053] 101、通信系统在获取到二维码上的URL地址信息之后，解析URL地址信息以获取请求对应的URL地址路径。

[0054] 作为一种可选的实施方式，在本发明实施例中，请求的URL地址信息可代表网站的地址，后面可以没有参数，也可以通过？和&添加键值对，一般情况下，URL的长度不能超过2048个字符，即2KB，超过此限制的话服务器可能就不识别。

[0055] 102、通信系统与服务端建立通信连接以发送HTTP报文数据。

[0056] 作为一种可选的实施方式，在本发明实施例中，移动终端可通过二维码发送URL地址信息以发出请求，在通信系统接收到URL地址信息之后，可解析服务端地址的域名对应的IP地址，并向该服务端地址发起“TCP三次握手”以建立通信连接；

[0057] 以及，在与服务端建立TCP通信连接之后，通信系统可通过该TCPTCP通信连接向服务器发送Http请求报文。

[0058] 作为一种可选的实施方式，在本发明实施例中，本申请的HTTP协议是基于TCP协议之上的，通过TCP协议进行传输，且这些协议都是有一定规范标准的，只要都符合这些标准即可实现服务端与浏览器互相通信。

[0059] 作为一种可选的实施方式，在本发明实施例中，本申请中通过“TCP三次握手”以与服务端建立通信连接，能够防止过期的链接再次传给被连接的主机。

[0060] 举例来说，第一次握手：客户端发送syn到服务器，等待服务器确认。(syn＝x)；第二次握手：服务器收到syn包，必须确认客户端的syn(ack＝x+1),同时发送一个自己的syn包syn＝y；第三次握手：客户端收到syn+ack后，再次向服务器发送确认包ack(y+1)，发送后三次握手完成，建立连接。

[0061] 103、通信系统根据请求对应的URL地址路径，控制服务端通过Web路由向业务处理器分发业务数据；其中，业务数据为服务端对HTTP报文数据进行解析之后所获得的。

[0062] 作为一种可选的实施方式，在本发明实施例中，通信系统可能会有负载均衡设备来平均分配所有用户的请求，即对工作任务进行平衡分摊到多个业务处理器上执行，如图片服务器，应用服务器等。

[0063] 104、通信系统获取业务处理器的业务处理结果。

[0064] 作为一种可选的实施方式，在本发明实施例中，服务端收到Http报文后可对其内容进行解析，并做相关的业务处理，最后，服务端可将处理结果也封装成Http报文同样通过当前的TCP连接发回给通信系统；

[0065] 以及，通信系统收到服务端的Http报文之后，可对其进行解析并根据具体报文内容做进一步的渲染呈现。

[0066] 作为一种可选的实施方式，在本发明实施例中，本申请可采用Netty框架进行建立Http协议的通信，而Netty是一个由JBOSS提供的一个java开源框架，基于NIO提供异步、事件驱动的高性能网络编程框架，本申请可借助它来建立Http协议的通信，并进一步去开发处理Http报文的相关功能。

[0067] 作为一种可选的实施方式，在本发明实施例中，在本申请中HttpHandler(处理中心)处理器主要处理的是Http报文，而每次收到的报文并不是完整的往往只是整个报文的一部分，一般先是Response或Request的header再是其body(body也可能分为多份)；

[0068] 以及，以解码Raw数据(这里一般指Text、JavaScript、Json、HTML、XML等数据类型)为例，需要将chunk数据逐个接收缓存在内存中(当然也可以选择缓存再磁盘中)，当接收到最后一块chunk时代表当前Http报文已经完全接收成功，将进入路由等待被相关的控制器去做进一步处理。

[0069] 作为一种可选的实施方式，在本发明实施例中，至于表单处理方式比较复杂，但主要原理也是一样，逐块接收处理，最后合成数据交给路由分发。

[0070] 作为一种可选的实施方式，在本发明实施例中，本申请可以高效处理网络请求，且不占用太多系统资源，而对比传统的web服务需要各种环境(如：PHP、Tomcat、Apache、Nginx、Mysql)不同，本申请可以将服务集成到Android应用程序中且不需要在系统中安装、配置运行所需环境，也可根据需要通过路由映射的方式映射至外网从而搭建微型的web服务器，也能在没外网的环境下在局域网中使用。

[0071] 作为一种可选的实施方式，在本发明实施例中，本申请能以SDK的方式集成在Android应用程序中进行二次开发。

[0072] 作为一种可选的实施方式，在本发明实施例中，本申请目的是实现将云服务器上的web服务放置在AndroidTV板卡上运行，从而实现本地扫码分享这一特定的业务。

[0073] 可见，实施图1所描述的智能交互通信方法，能够高效处理网络请求，且不占用太多系统资源。

[0074] 此外，实施图1所描述的智能交互通信方法，能够实现在Android上搭建web服务又不其他程序运行。

[0075] 此外，实施图1所描述的智能交互通信方法，能够实现本地扫码分享这一特定的业务。

[0076] 实施例二

[0077] 请参阅图2，图2是本发明实施例公开的另一种智能交互通信方法的流程示意图。如图2所示，该智能交互通信方法可以包括以下步骤：

[0078] 201、通信系统采用注解加反射的方式将扫描包中带有的拦截器及控制器注解的类分别映射到哈希路由表；其中，哈希路由表内至少含有拦截器路由表与控制器路由表。

[0079] 作为一种可选的实施方式，在本发明实施例中，由于用户的请求千变万化，传统只接收Http报文是不够的，而请求上传文件、请求访问静态资源、请求api获取动态数据等，以及同时请求的方法也不一样，而请求的方法可包括Get、Post、Put、DELETE等；

[0080] 以及，本申请需要区分这些请求并且分发给相应的控制器就需要用到路由，而为了方便后续开发，本申请可使用注解加反射的方式去扫描包中相关的类，并映射到哈希路由表中。

[0081] 202、通信系统启动HTTP服务，以监听二维码发送的请求。

[0082] 作为一种可选的实施方式，在本发明实施例中，控制器的逻辑较为复杂一些，需要扫描控制器下的所有方法，并且读取每个方法上的注解，映射时需要将控制器和控制器方法中的RequestMapping参数进行合并处理，当映射完成之后就会启动Http服务，监听客户发送的请求。

[0083] 203、通信系统在获取到二维码上的URL地址信息之后，解析URL地址信息以获取请求对应的URL地址路径。

[0084] 204、通信系统与服务端建立通信连接以发送HTTP报文数据。

[0085] 205、通信系统将请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配，若匹配成功，执行步骤206，若匹配不成功，执行步骤207。

[0086] 206、通信系统控制服务端向拦截器分发业务数据，执行步骤211～步骤213。

[0087] 207、通信系统将请求对应的URL地址路径与控制器路由表上的映射路径进行匹配，若匹配成功，执行步骤208，若匹配不成功，执行步骤209。

[0088] 208、通信系统控制服务端向控制器分发业务数据，执行步骤211～步骤213。

[0089] 209、通信系统将请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配，若匹配成功，执行步骤210，若匹配不成功，结束本次流程。

[0090] 210、通信系统获取文件路径中的数据信息作为业务处理结果，执行步骤212～步骤213。

[0091] 作为一种可选的实施方式，在本发明实施例中，当收到请求后通信系统可先将请求的路径与拦截器路由表进行匹配，如果匹配上可先将请求交由拦截器处理；

[0092] 以及，如果请求没有被拦截则会去匹配控制器路由表(包括正则路由表)，如果匹配上了则将请求交给对应的控制器方法去处理，从而实现了动态请求的处理。

[0093] 作为一种可选的实施方式，在本发明实施例中，如果什么都没匹配上会尝试匹配指定的本地磁盘目录中的文件，如果找到则返回该文件的数据实现了静态请求的处理。

[0094] 作为一种可选的实施方式，在本发明实施例中，这样的做法会比if‑else更耗性能，但更解耦，对于后续开发非常有利。

[0095] 211、通信系统获取业务处理器的业务处理结果。

[0096] 212、若接收到业务处理结果的响应信号低于指定次数，通信系统确定出当前连接并非长连接状态。

[0097] 213、通信系统断开与服务端之间的连接。

[0098] 作为一种可选的实施方式，在本发明实施例中，如果当前连接并非“长连接”则服务端会将连接关闭(发起“TCP4次挥手”)，反之则保持TCP的连接。

[0099] 作为一种可选的实施方式，在本发明实施例中，二维码分享Web端和后端API是前后端分离的设计，Web端对接后端接口API实现业务逻辑交互，Web端网页以静态文件保存，而API则用上面所介绍的方法实现控制器即可，至于数据库部分则使用了Android自带的SQLite数据库实现，数据的存储。

[0100] 可见，实施图2所描述的智能交互通信方法，能够高效处理网络请求，且不占用太多系统资源。

[0101] 此外，实施图2所描述的智能交互通信方法，能够比if‑else更耗性能，但更解耦，对于后续开发非常有利。

[0102] 实施例三

[0103] 请参阅图3，图3是本发明实施例公开的一种通信系统的结构示意图。如图3所示，该通信系统300可以包括解析单元301、连接单元302、控制单元303与获取单元304，其中：

[0104] 解析单元301，用于在获取到二维码上的URL地址信息之后，解析URL地址信息以获取请求对应的URL地址路径。

[0105] 连接单元302，用于与服务端建立通信连接以发送HTTP报文数据。

[0106] 控制单元303，用于根据请求对应的URL地址路径，控制服务端通过Web路由向业务处理器分发业务数据；其中，业务数据为服务端对HTTP报文数据进行解析之后所获得的。

[0107] 获取单元304，用于获取业务处理器的业务处理结果。

[0108] 作为一种可选的实施方式，在本发明实施例中，请求的URL地址信息可代表网站的地址，后面可以没有参数，也可以通过？和&添加键值对，一般情况下，URL的长度不能超过2048个字符，即2KB，超过此限制的话服务器可能就不识别。

[0109] 作为一种可选的实施方式，在本发明实施例中，移动终端可通过二维码发送URL地址信息以发出请求，在解析单元301接收到URL地址信息之后，可解析服务端地址的域名对应的IP地址，随后连接单元302可向该服务端地址发起“TCP三次握手”以建立通信连接；

[0110] 以及，在与服务端建立TCP通信连接之后，连接单元302可通过该TCPTCP通信连接向服务器发送Http请求报文。

[0111] 作为一种可选的实施方式，在本发明实施例中，本申请的HTTP协议是基于TCP协议之上的，通过TCP协议进行传输，且这些协议都是有一定规范标准的，只要都符合这些标准即可实现服务端与浏览器互相通信。

[0112] 作为一种可选的实施方式，在本发明实施例中，连接单元302通过“TCP三次握手”以与服务端建立通信连接，能够防止过期的链接再次传给被连接的主机。

[0113] 举例来说，第一次握手：客户端发送syn到服务器，等待服务器确认。(syn＝x)；第二次握手：服务器收到syn包，必须确认客户端的syn(ack＝x+1),同时发送一个自己的syn包syn＝y；第三次握手：客户端收到syn+ack后，再次向服务器发送确认包ack(y+1)，发送后三次握手完成，建立连接。

[0114] 作为一种可选的实施方式，在本发明实施例中，通信系统可能会有负载均衡设备来平均分配所有用户的请求，即对工作任务进行平衡分摊到多个业务处理器上执行，如图片服务器，应用服务器等。

[0115] 作为一种可选的实施方式，在本发明实施例中，服务端收到Http报文后可对其内容进行解析，并做相关的业务处理，最后，服务端可将处理结果也封装成Http报文同样通过当前的TCP连接发回给通信系统；

[0116] 以及，获取单元304收到服务端的Http报文之后，解析单元301还可对其进行解析并根据具体报文内容做进一步的渲染呈现。

[0117] 作为一种可选的实施方式，在本发明实施例中，本申请可采用Netty框架进行建立Http协议的通信，而Netty是一个由JBOSS提供的一个java开源框架，基于NIO提供异步、事件驱动的高性能网络编程框架，本申请可借助它来建立Http协议的通信，并进一步去开发处理Http报文的相关功能。

[0118] 作为一种可选的实施方式，在本发明实施例中，在本申请中HttpHandler(处理中心)处理器主要处理的是Http报文，而每次收到的报文并不是完整的往往只是整个报文的一部分，一般先是Response或Request的header再是其body(body也可能分为多份)；

[0119] 以及，以解码Raw数据(这里一般指Text、JavaScript、Json、HTML、XML等数据类型)为例，需要将chunk数据逐个接收缓存在内存中(当然也可以选择缓存再磁盘中)，当接收到最后一块chunk时代表当前Http报文已经完全接收成功，将进入路由等待被相关的控制器去做进一步处理。

[0120] 作为一种可选的实施方式，在本发明实施例中，至于表单处理方式比较复杂，但主要原理也是一样，逐块接收处理，最后合成数据交给路由分发。

[0121] 作为一种可选的实施方式，在本发明实施例中，本申请可以高效处理网络请求，且不占用太多系统资源，而对比传统的web服务需要各种环境(如：PHP、Tomcat、Apache、Nginx、Mysql)不同，本申请可以将服务集成到Android应用程序中且不需要在系统中安装、配置运行所需环境，也可根据需要通过路由映射的方式映射至外网从而搭建微型的web服务器，也能在没外网的环境下在局域网中使用。

[0122] 作为一种可选的实施方式，在本发明实施例中，本申请能以SDK的方式集成在Android应用程序中进行二次开发。

[0123] 作为一种可选的实施方式，在本发明实施例中，本申请目的是实现将云服务器上的web服务放置在AndroidTV板卡上运行，从而实现本地扫码分享这一特定的业务。

[0124] 可见，实施图3所描述的通信系统，能够高效处理网络请求，且不占用太多系统资源。

[0125] 此外，实施图3所描述的通信系统，能够实现在Android上搭建web服务又不其他程序运行。

[0126] 此外，实施图3所描述的通信系统，能够实现本地扫码分享这一特定的业务。

[0127] 实施例四

[0128] 请参阅图4，图4是本发明实施例公开的另一种通信系统的结构示意图。其中，图4所示的通信系统是由图3所示的通信系统进行优化得到的。与图3所示的通信系统相比较，图4所示的控制单元303可以包括：

[0129] 第一匹配子单元3031，用于将请求对应的URL地址路径与拦截器路由表上的映射路径进行匹配；

[0130] 第一控制子单元3032，用于在第一匹配子单元3031将请求对应的URL地址路径与拦截器路由表上的映射路径成功匹配时，控制服务端向拦截器分发业务数据；

[0131] 第二匹配子单元3033，用于在第一匹配子单元3031将请求对应的URL地址路径与拦截器路由表上的映射路径不成功匹配时，将请求对应的URL地址路径与控制器路由表上的映射路径进行匹配；

[0132] 第二控制子单元3034，用于在第二匹配子单元3033将请求对应的URL地址路径与控制器路由表上的映射路径成功匹配时，控制服务端向控制器分发业务数据。

[0133] 作为一种可选的实施方式，在本发明实施例中，当收到请求后第一匹配子单元3031可先将请求的路径与拦截器路由表进行匹配，如果匹配上第一控制子单元3032可先将请求交由拦截器处理；

[0134] 以及，如果请求没有被拦截，第二匹配子单元3033可将请求的路径与控制器路由表(包括正则路由表)匹配，如果匹配上了第二控制子单元3034可将请求交给对应的控制器方法去处理，从而实现了动态请求的处理。

[0135] 与图3所示的通信系统相比较，图4所示的控制单元303还可以包括：

[0136] 第三匹配子单元3035，用于在第二匹配子单元3033将请求对应的URL地址路径与控制器路由表上的映射路径不成功匹配时，将请求对应的URL地址路径与指定的本地磁盘目录中的文件路径进行匹配；

[0137] 获取子单元3036，用于在第三匹配子单元3035将请求对应的URL地址路径与指定的本地磁盘目录中的文件路径成功匹配时，获取文件路径中的数据信息。

[0138] 作为一种可选的实施方式，在本发明实施例中，如果第二匹配子单元3033什么都没匹配上，第三匹配子单元3035可尝试将请求的路径与指定的本地磁盘目录中的文件匹配，如果找到则返回该文件的数据实现了静态请求的处理。

[0139] 作为一种可选的实施方式，在本发明实施例中，这样的做法会比if‑else更耗性能，但更解耦，对于后续开发非常有利。

[0140] 与图3所示的通信系统相比较，图4所示的通信系统还可以包括：

[0141] 映射单元305，用于在解析单元301解析URL地址信息以获取请求对应的URL地址路径之前，采用注解加反射的方式将扫描包中带有的拦截器及控制器注解的类分别映射到哈希路由表；其中，哈希路由表内至少含有拦截器路由表与控制器路由表。

[0142] 作为一种可选的实施方式，在本发明实施例中，由于用户的请求千变万化，传统只接收Http报文是不够的，而请求上传文件、请求访问静态资源、请求api获取动态数据等，以及同时请求的方法也不一样，而请求的方法可包括Get、Post、Put、DELETE等；

[0143] 以及，本申请需要区分这些请求并且分发给相应的控制器就需要用到路由，而为了方便后续开发，本申请可使用注解加反射的方式去扫描包中相关的类，并映射到哈希路由表中。

[0144] 启动单元306，用于启动HTTP服务，以监听二维码发送的请求。

[0145] 作为一种可选的实施方式，在本发明实施例中，控制器的逻辑较为复杂一些，需要扫描控制器下的所有方法，并且读取每个方法上的注解，映射时需要将控制器和控制器方法中的RequestMapping参数进行合并处理，当映射完成之后就会启动Http服务，监听客户发送的请求。

[0146] 与图3所示的通信系统相比较，图4所示的通信系统还可以包括：

[0147] 确定单元307，用于若接收到业务处理结果的响应信号低于指定次数，确定出当前连接并非长连接状态；

[0148] 断开单元308，用于断开与服务端之间的连接。

[0149] 作为一种可选的实施方式，在本发明实施例中，如果当前连接并非“长连接”则断开单元308会将连接关闭(发起“TCP4次挥手”)，反之则保持TCP的连接。

[0150] 作为一种可选的实施方式，在本发明实施例中，二维码分享Web端和后端API是前后端分离的设计，Web端对接后端接口API实现业务逻辑交互，Web端网页以静态文件保存，而API则用上面所介绍的方法实现控制器即可，至于数据库部分则使用了Android自带的SQLite数据库实现，数据的存储。

[0151] 可见，实施图4所描述的通信系统，能够高效处理网络请求，且不占用太多系统资源。

[0152] 此外，实施图4所描述的通信系统，能够比if‑else更耗性能，但更解耦，对于后续开发非常有利。

[0153] 实施例五

[0154] 请参阅图5，图5是本发明实施例公开的另一种通信系统的结构示意图。如图5所示，该通信系统可以包括：

[0155] 存储有可执行程序代码的存储器501；

[0156] 与存储器501耦合的处理器502；

[0157] 其中，处理器502调用存储器501中存储的可执行程序代码，执行图1～图4任意一种智能交互通信方法。

[0158] 本发明实施例公开一种计算机可读存储介质，其存储计算机程序，其中，该计算机程序使得计算机执行图1～图2任意一种智能交互通信方法。

[0159] 本发明实施例还公开一种计算机程序产品，其中，当计算机程序产品在计算机上运行时，使得计算机执行如以上各方法实施例中的方法的部分或全部步骤。

[0160] 本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一种计算机可读存储介质中，存储介质包括只读存储器(Read‑Only Memory，ROM)、随机存储器(Random Access Memory，RAM)、可编程只读存储器(Programmable Read‑only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、一次可编程只读存储器(One‑time Programmable Read‑Only Memory，OTPROM)、电子抹除式可复写只读存储器(Electrically‑Erasable Programmable Read‑Only Memory，EEPROM)、只读光盘(Compact Disc Read‑Only Memory，CD‑ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

[0161] 以上对本发明实施例公开的一种智能交互通信方法及通信系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。