应用消息推送方法和装置与流程

本发明涉及通信技术领域，特别是涉及一种应用消息推送方法和装置。

背景技术：

随着移动应用的迅速普及，为了保证用户对移动应用的使用，对移动应用进行通知推送成为提升用户活跃度的有效手段。目前，为了保证通知推送的实时性，需要维护客户端与服务端之间的长连接，所谓长连接是指在一个连接上连续发送多个数据包，在客户端与服务端之间创建和保持稳定可靠的连接。在长连接中，客户端通常采用长轮询的方式，即服务端循环监测数据，当监测到数据更新时，立即输出给客户端并断开连接，客户端收到数据后再次发送请求，以使服务器进入下一个周期。在长连接中，服务端与每个客户端都保持持久的连接。

因此，为了对移动应用进行实时通知推送，需要开启大量的常驻服务器，但是通常对移动应用的通知推送最多也就一天一次，这样将造成大量的服务器资源闲置，降低了服务器的利用率。

技术实现要素：

基于此，有必要针对上述问题，提供一种能够降低服务端的资源需求，提高服务器的利用率的应用消息推送方法和装置。

一种应用消息推送方法，包括：

接收终端定时轮询上传的消息推送请求，消息推送请求携带用户标识；

根据消息推送请求检测预设的消息数据库中是否存在用户标识对应的推送消息；

若是，则获取推送消息并将推送消息发送至终端，以使终端对推送消息进行展示。

在其中一个实施例中，应用消息推送方法还包括：

根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户；

根据预设筛选条件对活跃用户进行筛选，将满足预设条件的活跃用户作为消息推送的目标用户；

将目标用户的用户标识与推送消息相互关联并存储在消息数据库中。

在其中一个实施例中，根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户，包括：

获取预设时间内系统日志中记录的访问频次以及访问时长；

根据访问频次以及访问时长获取用户活跃度；

筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

在其中一个实施例中，根据预设筛选条件对活跃用户进行筛选，将满足预设筛选条件的活跃用户作为消息推送的目标用户，包括：

获取活跃用户对应的用户标识及应用信息，应用信息包括应用的版本号、地区代码、语言编号及活跃时间版本号、地区代码、语言编号及活跃时间中的至少一种；

根据预设筛选条件对应用信息进行筛选，将满足预设筛选条件的应用信息对应的活跃用户作为消息推送的目标用户。

在其中一个实施例中，应用消息推送方法还包括：

根据接收到的终端返回的推送成功的信息清除消息数据库中的推送消息。

一种应用消息推送装置，包括：

接收模块，用于接收终端定时轮询上传的消息推送请求，消息推送请求携带用户标识；

检测模块，用于根据消息推送请求检测预设的消息数据库中是否存在用户标识对应的推送消息；

发送模块，用于若检测预设的消息数据库中存在用户标识对应的推送消息，则获取推送消息并将推送消息发送至终端，以使终端对推送消息进行展示。

在其中一个实施例中，应用消息推送装置还包括：

活跃用户筛选模块，用于根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户；

目标用户确定模块，用于根据预设筛选条件对活跃用户进行筛选，将满足预设条件的活跃用户作为消息推送的目标用户；

消息存储模块，用于将目标用户的用户标识与推送消息相互关联并存储在消息数据库中。

在其中一个实施例中，活跃用户筛选模块用于获取预设时间内系统日志中记录的访问频次以及访问时长；根据访问频次以及访问时长获取用户活跃度；筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

在其中一个实施例中，目标用户确定模块用于获取活跃用户对应的用户标识及应用信息，应用信息包括应用的版本号、地区代码、语言编号及活跃时间版本号、地区代码、语言编号及活跃时间中的至少一种；根据预设筛选条件对应用信息进行筛选，将满足预设筛选条件的应用信息对应的活跃用户作为消息推送的目标用户。

在其中一个实施例中，应用消息推送装置还包括：

清除模块，用于根据接收到的终端返回的推送成功的信息清除消息数据库中的推送消息。

上述应用消息推送方法和装置，根据终端定时轮询上传的消息推送请求以及携带的用户标识在消息数据库中检测用户标识对应的推送消息，获取推送消息发送至终端以使终端进行展示，完成应用消息推送的过程。通过终端定时轮询发送消息推送请求，服务器不需要一直与终端建立持久的连接，只需要在终端发送消息推送请求时进行响应，降低对服务端的资源要求，通过设置终端轮询发送消息推送请求的时间间隔，能够达到只使用少量服务器即可满足用户访问的需求，提高了服务器的利用率。

附图说明

图1为一个实施例中应用消息推送方法流程图；

图2为一个实施例中服务端生成应用推送消息的步骤的流程图；

图3为一个实施例中获取活跃用户的步骤流程图；

图4为另一个实施例中应用消息推送方法流程图；

图5为一个实施例中应用消息推送装置的结构框图；

图6为一个实施例中应用消息推送装置的结构框图；

图7为另一个实施例中应用消息推送装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，在一个实施例中，提供一种应用消息推送方法，包括以下步骤：

步骤110，接收终端定时轮询上传的消息推送请求，消息推送请求携带用户标识。

本实施例中，预先在应用中设置定时轮询机制，定时轮询是指每隔预设时间发出一次请求。当终端中某个应用在运行时，启动定时轮询机制，终端每隔预设时间向正在运行的应用对应的服务器的消息推送接口发送一次消息推送请求。

通过消息推送接口接收终端发送的消息推送请求，消息推送请求携带用户标识，这里所说的用户标识可以是根据终端系统信息生成的唯一标识符如udid，也可以是登录应用的账号信息对应的id。这里的终端可以但不仅限于是手机、平板电脑、可穿戴设备等移动终端或者其他可运行应用的设备。

步骤120，根据消息推送请求检测预设的消息数据库中是否存在用户标识对应的推送消息，若是，则执行步骤130。

本实施例中，服务端在特定的时间对推送消息进行更新，并且将更新的推送消息与用户标识相互关联存储在消息数据库中。当接收到终端的消息推送请求后，服务端查询消息数据库，即将推送消息携带的用户标识与消息数据库中的用户标识相互匹配，若匹配不成功，则说明用户标识对应的应用没有相关联的推送消息，服务器断开与终端的连接关系，若匹配成功，则说明用户标识对应的应用存在相关联的推送消息，执行步骤130。

步骤130，获取推送消息并将推送消息发送至终端，以使终端对推送消息进行展示。

本实施例中，当在消息数据库中匹配到与终端发送的消息推送请求携带的用户标识一致的用户标识时，获取该用户标识相关联的推送消息并发送至用户标识对应的终端，以使终端对推送消息进行展示。这里所说的推送消息可以为应用的优化更新信息、版本变更信息、活动推送信息等各种通知信息，或其他推广信息如公益宣传广告信息等。该推送消息可以在服务端预先编辑定义，因此能够避免不良信息或者大量广告信息的推送。终端对推送消息的展示方式可以是但不仅限于是通知栏展示、弹窗展示、锁屏展示。

上述应用消息推送方法，服务器只需要对终端定时发送的消息推送请求进行响应，获取对应的推送消息传输至终端即可完成对推送消息的推送过程，不需要服务器一直与终端保持连接，不断监测数据更新发送至终端，因此，降低了对服务器资源的需求，使少量的服务器就能满足基本的用户需求，提高了服务器的使用率。

在一个实施例中，应用消息推送方法还包括终端生成推送消息的步骤，如图2所示，包括以下步骤：

步骤210，根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

本实施例中，为了提高推送的效率，仅对近期的活跃用户进行消息推送，活跃用户指近期经常使用应用的用户，可以利用用户活跃度来确定活跃用户。在使用应用时，终端应用对服务器的数据请求被记录在系统日志中，系统日志是指记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。通过获取预设时间内的系统日志，获取预设时间内的用户活跃度，预先根据数据分析或产品需求设置预设活跃度，获取的预设时间内的用户活跃度大于该预设活跃度的应用对应的用户标识即为活跃用户对应的用户标识。

步骤220，根据预设筛选条件对活跃用户进行筛选，将满足预设筛选条件的活跃用户作为消息推送的目标用户。

本实施例中，为了进一步提升推送的效率，设置筛选条件对获取的活跃用户再次进行筛选，将满足预设筛选条件的活跃用户为消息推送的目标用户。

具体的，对于相同的应用，不同的用户的需求可能不同，因此为了进一步提高推送的效率，设置筛选条件针对不同的用户推送不同的消息。如一款提供新闻阅读的应用，对于不同的用户对新闻种类的需求不同，如一部分用户比较关注金融类信息，另外一部分用户比较关注娱乐消息，如果现在有一则金融类相关的消息需要推送，则首先设置筛选条件为预设时间内访问过金融类相关信息，对获取的活跃用户进行筛选，符合该筛选条件的活跃用户即为该金融类相关信息推送的目标用户。

步骤230，将目标用户的用户标识与推送消息相互关联并存储在消息数据库中。

本实施例中，为了能够为对应的终端提供对应的推送消息，在获取目标用户后，获取目标用户对应的用户标识，将推送消息与目标用户的用户标识相互关联并存储在消息数据库中。当接收到终端发送的消息推送请求时，即可根据该关联关系在消息数据库中查询用户标识对应的推送消息。

本实施例中，通过系统日志获取预设时间内的活跃用户，并根据不同的推送消息设置不同的筛选条件，在活跃用户中进一步获取推送消息的目标用户，最后将推送消息与目标用户的用户标识建立关联存储在消息数据库中，能够针对不同的用户需求推送不同的消息，有效的提高了推送的效率。

如图3所示，在一个实施例中，根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户，包括：

步骤310，获取预设时间内系统日志中记录的访问频次以及访问时长。

本实施例中，访问频次是指预定时间内用户使用应用的频率和次数，访问时长是指用户每次使用应用的时长。由于用户每次使用应用均会在服务端产生访问记录，记录在系统日志中，因此对系统日志进行分析，能够获取对应用户预设时间内使用应用的频次和时长。

步骤320，根据访问频次以及访问时长获取用户活跃度。

本实施例中，用户活跃度可以用访问频次和访问时长进行衡量，预先根据数据分析或者产品需求设置一个活跃度，将预设的活跃度作为衡量是否为活跃用户的标准。每天定时对前一日系统日志进行分析，获取前一日系统日志中的访问频次及访问时长，从而获取每日用户活跃度，同时获取预设时间内的系统日志获取预设时间内的用户活跃度，根据每日用户活跃度与预设时间内的用户活跃度获取对应的用户活跃度。

步骤330，筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

本实施例中，将获取的用户活跃度与预设的活跃度进行比较，筛选出用户活跃度大于预设的活跃度的用户标识，则筛选出的用户标识对应的用户即为活跃用户。具体的，可以通过设置活跃度使在预设时间内使用了应用的用户就判断为活跃用户，此时只需要对预设时间内的系统日志进行遍历，获取系统日志中记录的用户标识，对获取的用户标识进行去重操作即可获取活跃用户对应的用户标识列表。

在一个实施例中，根据预设筛选条件对活跃用户进行筛选，将满足预设筛选条件的活跃用户作为消息推送的目标用户，包括：

获取活跃用户对应的用户标识及应用信息，应用信息包括应用的版本号、地区代码、语言编号及活跃时间中的至少一种；

根据预设筛选条件对应用信息进行筛选，将满足预设筛选条件的应用信息对应的活跃用户作为消息推送的目标用户。

本实施例中，为了提高推送效率，对活跃用户进行进一步筛选获取推送的目标用户。具体的，系统日志中记载了用户使用应用对服务端进行访问时的应用信息以及对应的用户标识，应用信息包括应用的版本号、地区代码、语言编号及活跃时间中的至少一种。当编写推送消息时，根据推送消息的具体内容，通过应用信息的任意组合设置合适的筛选条件，获取对应的目标用户标识。比如检测到一个应用版本号5之前的版本存在重大的漏洞，此时需要编写一个通知推送给对应的用户，此时以版本号为筛选条件，版本号为5或者以下的应用对应的用户标识为该推送消息的目标用户标识；再如若版本号5之前的英文版本存在问题而中文版本不存在问题，则筛选条件即为英文和版本号为5或以下的应用对应的用户标识为该筛选条件对应的目标用户标识。

在一个实施例中，应用消息推送方法还包括：根据接收到的终端返回的推送成功的信息清除消息数据库中的推送消息。

本实施例中，当服务器将获取的用户标识对应的推送消息发送至终端时，终端对接收到的推送消息进行展示，展示完成后返回推送成功的消息至服务器，该消息同样携带用户标识，服务器接收到该推送成功的消息后，根据携带的用户标识在消息数据库中查找到该用户标识对应的推送消息，并将该推送消息清除。

本实施例中，当终端接收到推送消息并成功展示后，服务器接收终端返回的推送成功的信息，对用户标识对应的推送消息进行清除，有效的避免了消息重复推送，提高了推送的效率。

如图4所示，在一个实施例中，提供一种应用消息推送方法，包括以下步骤：

步骤410，获取预设时间内系统日志中记录的访问频次以及访问时长，根据访问频次以及访问时长获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

本实施例中，为了提高推送消息的效率，仅针对近期的活跃用户进行消息推送，为了筛选出活跃用户可以预先设置活跃度作为评价用户是否为活跃用户的标准。系统日志是指记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。获取预设时间内系统日志中监视应用访问的记录，即获取系统日志中应用的访问频次和访问时长，从而根据访问频次和访问时长获取用户活跃度，将根据系统日志获取的用户活跃度与预设活跃度相比较，用户活跃度大于预设活跃度的应用对应的用户标识即为活跃用户对应的用户标识。

具体的，为了方便对活跃用户进行筛选，设置活跃度的衡量标准为前一日对应用进行了使用，即服务器每天定时对前一日的系统日志进行分析，只要满足在服务器分析的系统日志中有使用应用的记录，就认为该应用对应的用户标识为活跃用户标识。当用户主动使用应用的某个功能时，服务端触发该功能对应的服务器端的api(applicationprogramminginterface，应用程序编程接口)调用，此时只需要遍历系统日志中的api请求日志就可以获得活跃用户对应的用户标识。例如，用户标识为系统信息生成的udid值，此时首先使用linuxgrep命令，定时对前一日的系统日志进行筛选，筛选出用户使用应用产生的api请求日志，该请求日志中包含udid参数，然后使用linux命令awk，将udid参数抽取出来保存到一个文件中，每一行对应一个udid。由于用户可能一天多以使用应用或者使用了应用的不同功能，因此此时抽取出的udid参数存在重复，对该保存udid参数的文件使用linuxsort命令，然后使用linuxuniq命令，就得到去除重复之后的活跃用户的udid列表。

步骤420，获取活跃用户对应的用户标识及应用信息，并将用户标识与应用信息存储在数据库中。

本实施例中，获取活跃用户的用户标识后，在系统日志中获取对应的应用信息，应用信息包括应用的版本号、地区代码、语言编号及活跃时间等至少一种。将应用信息与用户标识相关联并存储在数据库中，以便后续操作。

具体的，以mysql(关系型数据库管理系统)为例，mysql是一种关联数据库管理系统，关联数据库将数据保存在不同的表中。这里的用户标识可以用终端系统信息生成的udid值表示，不同的udid值对应不同的终端及不同的应用信息。经过筛选、去重操作之后获取udid列表，获取该udid列表中的udid对应的应用信息，并将udid列表及对应的应用信息存储到mysql数据库的user表中。

在其他实施例中，如果每日的用户访问量较多，还可以使用数据仓库对用户标识和对应的应用信息进行存储，更加适合批量增加和条件查询的场景。这里所说的数据仓库是指一个面向主题的(subjectoriented)、集成的(integrated)、相对稳定的(non-volatile)、反映历史变化(timevariant)的数据集合，用于支持管理决策(decisionmakingsupport)。

步骤430，根据预设筛选条件对应用信息进行筛选，将满足预设筛选条件的应用信息对应的活跃用户作为消息推送的目标用户。

本实施例中，为了进一步提高推送效率，预先在数据库中根据应用信息设置筛选条件，对存储的活跃用户对应的应用信息进行筛选，将满足预设的筛选条件的应用信息对应的用户标识作为消息推送的目标用户标识。

具体的，应用信息包括应用的版本号、地区代码、语言编号及活跃时间中的至少一种。对于不同版本号的应用需要不同的升级信息；推送的消息根据地区的不同内容有所不同，如一款预报天气的应用，对于不同的地区需要针对当地的情况进行信息推送；针对应用活跃时间推送不同的消息，如一款音乐服务的应用，针对用户的活跃时间推荐不同类型的音乐等，因此针对不同的推送消息的具体内容，预先根据应用的版本号、地区代码、语言编号及活跃时间中的至少一种设置筛选条件，在活跃用户对应的用户标识中获取对应的目标用户的用户标识。如以mysql为例，当根据系统日志获取对应的活跃用户的用户标识以及对应的应用信息，并存储在mysql数据库的user表中后，通过sql设置筛选条件对user表进行筛选，得到目标用户对应的用户标识的集合。

步骤440，将目标用户的用户标识与推送消息相互关联并存储在消息数据库中。

本实施例中，确定推送消息的目标用户之后，将推送消息的具体消息与目标用户对应的用户标识相互关联，并存储在消息数据库中，便于根据终端的请求信息携带的用户标识对相应的推送消息进行查询。

具体的，以redis数据库为例，redis是一个开源的使用ansic语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api。当获取到目标用户对应的用户标识的集合后，用户标识用udid值表示，获取目标用户对应的udid列表中的每一个udid值，并将每一个udid值分别与编写的推送消息相互关联，保存在以udid为key的redis数据库列表中。redis数据库的数据模型为key-value模式，当以udid为key保存时，支持udid的存取，并且推送消息以udid为标识。

以nosql(notonlysql，泛指非关系型的数据库)为例，nosql是通过主键对数据进行查询。获取目标用户对应的udid列表之后，获取udid列表中的每一个udid值，并将udid值分别与推送消息相互关联，保存在一个列表中，将udid为表的主键。

步骤450，接收终端定时轮询上传的消息推送请求，消息推送请求携带用户标识，根据消息推送请求携带的用户标识检测预设的消息数据库中是否存在用户标识对应的推送消息。

本实施例中，预先在应用中设置定时轮询机制，当终端运行该应用时，触发定时轮询机制，定时轮询服务器的消息推送接口并发送消息推送请求，消息推送请求携带用户标识，服务器接收终端发送的消息推送请求后，通过在消息数据库中检测是否存在相同的用户标识，检测是否存在用户标识对应的推送消息。

具体的，如以终端系统信息生成的udid值为用户标识，服务器接收到终端上传的消息推送请求时，获取消息推送请求携带的udid，查询redis数据库中以udid为key的列表，此时udid作为调用服务器api的参数，是推送消息的标识，查找到对应的udid即说明redis数据库中有与该udid相关联的推送消息。

同样的，若推送消息存储在nosql数据库中，则udid作为主键查询nosql中的以udid为主键的表格，若有相同的udid则说明nosql数据库中对应的推送的消息需要推送至该udid对应的应用终端。

步骤460，当检测到存在用户标识对应的推送消息时，获取推送消息并将推送消息发送至终端，以使终端对推送消息进行展示。

本实施例中，由于在消息数据库中用户标识与推送消息相关联，若在消息数据库中检测到了消息推送请求携带的用户标识相同的用户标识，则说明存在与推送请求携带的用户标识对应的推送消息，获取与该用户标识相关联的推送消息并发送至终端，以使终端对推送消息进行展示。

具体的，如以终端系统信息生成的udid值为用户标识，以udid为key在redis数据库中查找到了相同的udid，则获取与该udid相关联的推送消息，则该推送消息推送至终端，使终端对该推送消息进行展示，如在通知栏展示、弹窗展示、锁屏展示等，以使用户看到该推送消息进行相应操作。

步骤470，根据接收到的终端返回的推送成功的信息清除消息数据库中的推送消息。

本实施例中，本实施例中，当服务器将获取的用户标识对应的推送消息发送至终端时，终端对接收到的推送消息进行展示，展示完成后返回推送成功的消息至服务器，该消息同样携带用户标识，服务器接收到该推送成功的消息后，根据携带的用户标识在消息数据库中查找到该用户标识对应的推送消息，并将该推送消息清除。

具体的，当服务端对终端以udid为标识向服务端消息推送接口发送的消息推送请求进行相应，并在redis或者nosql数据库中查找到对应的推送消息发送至终端后，终端对该推送消息进行展示，并返回携带该udid的推送成功信息至服务端，服务端根据该udid在redis或者nosql数据库中查找到对应的推送消息，将该推送消息清除，避免重复推送。

本实施例中，服务端定时分析系统日志以确定目标用户，并将目标用户的用户标识与推送消息的具体信息关联存储在消息数据库中，为消息推送做准备。当接收到终端发送的消息推送的请求时，根据推送请求携带的用户标识在消息数据库中查找对应的用户标识，从而获取对应的推送消息进行推送，推送成功后根据终端的返回信息，清除已经推送成功的推送消息。通过终端定时轮询发送请求获取服务端的推送消息，不需要服务端一直与终端保持联系，通过设置定时轮询的时间间隔，能够合理的利用服务端资源，并且建立反馈机制，避免重复推送进一步降低了对服务端的资源需求，提高服务器的使用率。

如图5所示，在一个实施例中，提供一种应用消息推送装置，包括：

接收模块510，用于接收终端定时轮询上传的消息推送请求，消息推送请求携带用户标识；

检测模块520，用于根据消息推送请求检测预设的消息数据库中是否存在用户标识对应的推送消息；

发送模块530，用于若检测预设的消息数据库中存在用户标识对应的推送消息，则获取推送消息并将推送消息发送至终端，以使终端对推送消息进行展示。

上述应用消息推送装置，通过接收终端定时轮询上传的消息推送请求，根据消息推送请求携带的用户标识在消息数据库中查询对应的推送消息，并将推送消息发送至用户标识对应的终端以对推送消息进行展示。服务器只需要接收终端定时上传的推送消息请求并进行响应，不需要一直与终端建立持久的连接，降低了对服务资源的要求，达到使用少量服务器就能够满足用户需求，提高了服务器的利用率。

如图6所示，在一个实施例中，提供一种应用消息推送装置，包括：

活跃用户筛选模块610，用于根据预设时间内的系统日志获取用户活跃度，筛选出用户活跃度大于预设活跃度的用户作为活跃用户；

目标用户确定模块620，用于根据预设筛选条件对活跃用户进行筛选，将满足预设条件的活跃用户作为消息推送的目标用户；

消息存储模块630，用于将目标用户的用户标识与推送消息相互关联并存储在消息数据库中。

在一个实施例中，活跃用户筛选模块610用于获取预设时间内系统日志中记录的访问频次以及访问时长；根据访问频次以及访问时长获取用户活跃度；筛选出用户活跃度大于预设活跃度的用户作为活跃用户。

在一个实施例中，目标用户确定模块620用于获取活跃用户对应的用户标识及应用信息，应用信息包括应用的版本号、地区代码、语言编号及活跃时间中的至少一种；根据预设筛选条件对应用信息进行筛选，将满足预设筛选条件的应用信息对应的活跃用户作为消息推送的目标用户。

如图7所示，在一个实施例中，应用消息推送装置还包括：

清除模块540，用于根据接收到的终端返回的推送成功的信息清除消息数据库中的推送消息。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。