由服务器端实现网页渲染的方法、 设备和系统 【技术领域】
本发明涉及计算机技术领域， 特别涉及由服务器端实现网页渲染的方法、 设备和系统。 背景技术 随着 3G 技术的推广、 以及移动电话价格和入网费用的降低， 人们对于手机上网的 需求， 逐渐的从访问简单以文本为主的 Wap 网页， 转向了直接访问互联网网站， 以获取更加 丰富的内容。目前， 在手机直接访问互联网时， 互联网都是返回网页标签给手机浏览器， 由 手机浏览器对网页标签进行解析渲染， 最后完成绘制显示。
但是， 由于手机和 PC 相比， 最重要区别是手机的内存容量小、 cpu 主频低、 网络传 输速度慢、 费用高。如果由手机浏览器对网页标签进行解析渲染， 这会存在以下问题 ：
1) 占用内存太大
手机浏览器为了实现对网页标签进行解析渲染， 需要在内存中存储一整套的解析 渲染引擎代码， 并且， 手机浏览器在对网页标签进行渲染时， 需要保存对象变量等至内存 中， 这会导致手机内存空存被大量占用。
2) 执行速度慢
由于网页的渲染是涉及到大量的计算， 而手机的 cpu 主频相对于 PC 来说是非常低 的， 这大大减慢了网页渲染的执行速度。
3) 网络速度太慢
由于手机相对于 PC， 无线网络的传输速率较低， 而互联网上的网页数据往往尺寸 较大， 需要花费很长的时间才能传输到手机。
发明内容
本发明提供了由服务器端实现网页渲染的方法、 设备和系统， 以避免由手机浏览 器对网页标签进行解析渲染所带来的技术问题。
本发明提供的技术方案包括 ：
一种由服务器端实现网页渲染的方法， 所述服务器端包含内核 webcore ； 关键在 于， 预先在服务器端设置渲染服务器 RenderServer ； 该方法包括 ：
所述渲染服务器将接收的页面解析成 DOM 树， 并将接收的页面发送至所述内核， 由所述内核对所述页面进行渲染， 形成渲染树 ；
所述渲染服务器依据所述 DOM 树将所述渲染树上渲染对象对应的数据信息转换 为二进制流， 并下发给移动终端， 由所述移动终端依据接收的二进制流执行绘制操作， 以实 现网页浏览。
一种由服务器端实现网页渲染的设备， 所述设备设置在服务器端， 所述服务器端 包含内核 ； 所述设备包括 ：
处理单元， 用于接收页面， 将所述页面解析成 DOM 树， 并发送所述页面至所述内核， 由所述内核对所述页面进行渲染， 形成渲染树 ；
转换单元， 用于依据所述 DOM 树将所述渲染树上渲染对象对应的数据信息转换为 二进制流， 并下发给移动终端， 由所述移动终端依据接收的二进制流执行绘制操作， 以实现 网页浏览。
一种由服务器端实现网页渲染的系统， 该系统包括内核、 移动终端和如上所述的 设备。
由以上技术方案可以看出， 本发明中， 通过在服务器端增加渲染服务器， 由该渲染 服务器完成网页的渲染， 并将渲染的结果返回给手机浏览器， 由手机浏览器根据渲染结果 执行绘制操作。这显然能够避免由手机浏览器对网页标签进行解析渲染所带来的技术问 题， 降低手机浏览器的 CPU、 内存和网络流量的压力。 附图说明
图 1 为本发明实施例提供的基本流程图 ；
图 2 为本发明实施例提供的详细流程图 ；
图 3 为本发明实施例提供的步骤 210 的流程图 ；
图 4 为 TLV 编码格式示意图 ； 图 5 为本发明实施例提供的设备基本结构图 ； 图 6 为本发明实施例提供的设备详细结构图。具体实施方式
本发明实施例主要是由服务器端完成网页的渲染， 并将渲染的结果返回给手机浏 览器， 由手机浏览器根据渲染结果执行绘制操作。 这相比于现有技术， 能够降低手机浏览器 的 CPU、 内存和网络流量的压力。
为了使本发明的目的、 技术方案和优点更加清楚， 下面结合附图和具体实施例对 本发明进行详细描述。
参见图 1， 图 1 为本发明实施例提供的基本流程图。在执行该流程之前， 需要预先 在服务器端设置渲染服务器， 其中， 服务器端包含内核。基于此， 如图 1 所示， 该流程可包括 以下步骤 ：
步骤 101， 渲染服务器将接收的页面解析成 DOM 树， 并将接收的页面发送至所述内 核， 由所述内核对所述页面进行渲染， 形成渲染 (Render) 树。
本步骤 101 中， 渲染服务器可按照现有解析方法将接收的页面解析成 DOM 树。内 核可按照现有渲染方法将渲染服务器接收的页面进行渲染， 形成渲染树。
步骤 102， 渲染服务器依据所述 DOM 树将所述渲染树上渲染对象对应的数据信息 转换为二进制流， 并下发给移动终端， 由所述移动终端依据接收的二进制流执行绘制操作， 以实现网页浏览。
也就是说， 服务器端代替移动终端比如手机执行网页渲染功能， 并将渲染执行结 果发送给移动终端， 移动终端即可直接根据接收的二进制流进行绘制操作 ( 具体可与现有 绘制操作类似 )， 如此， 即可流畅的浏览网页。
至此， 完成图 1 所示的流程。下面对本发明实施例进行详细描述。
该实施例主要是由移动终端比如手机和服务器端之间的通信协议来完成的， 具体 可参见图 2 所示的流程。
参见图 2， 图 2 为本发明实施例提供的详细流程图。如图 2 所示， 该流程可包括以 下步骤 ：
步骤 201， 手机发送 URL 请求给转发服务器 (BrokerServer)。
步骤 202， BrokerServer 通过页面转换服务器 (SkeetServer) 将所述 URL 请求发 送给内核引擎服务器 (ChromeServer)。
可以看出， 在步骤 202 中， BrokerServer 和 SkeetServer 实质上是将 URL 请求透 传给 ChromeServer。
步骤 203， ChromeServer 抓取所述 URL 请求对应的原始网页， 通过解析所述原始网 页获取并存储所述原始网页中图片标签对应的图片信息至数据库 (DCache)， 以及执行所述 原始网页包含的 JS。
步骤 204， ChromeServer 发送解析后的网页至 SkeetServer。
步骤 205， SkeetServer 判断发送所述 URL 请求的手机是否支持所述解析后的网 页， 如果是， 执行步骤 206 ； 否则， 执行步骤 207。
步骤 206， 将所述解析后的网页发送至 BrokerServer。之后执行步骤 208。
步 骤 207， 将 所 述 解 析 后 的 网 页 转 换 为 所 述 手 机 支 持 的 网 页， 并发送至 BrokerServer。
之所以执行步骤 205 至步骤 207， 主要是因为目前大多数手机仅支持 wap2.0 网页， 并不支持互联网站上的 www 网页， 基于此， 如果本实施例中发送了 URL 请求的手机不支持 www 网页， 则在 SkeetServer 接收到 www 网页时， 就需要将该 www 网页转换为 wap2.0 网页， 之后发送至 BrokerServer。 当然， 如果本实施例中发送了 URL 请求的手机具有强大的功能， 即可支持 wap2.0 网页， 又支持 www 网页， 则在 SkeetServer 接收到 www 网页时， 就不需要执 行转换操作， 直接将该 www 网页发送至 BrokerServer 即可。可以看出， 步骤 205 至步骤 207 的执行主要是依赖于手机的功能。
步骤 208， BrokerServer 接收 SkeetServer 发送的网页， 从 DCache 中读取图片信 息， 插入至该网页上对应该图片信息的图片标签处， 得到插入后的网页 ( 记为网页 1)， 之后 将该网页 1 发送至 RenderServer。
步骤 209， RenderServer 将接收的网页 1 解析成 DOM 树， 并将接收的网页 1 发送至 内核 (webcore)， 由 webcore 对网页 1 进行渲染， 形成渲染树。
步骤 210， RenderServer 依据 DOM 树将所述渲染树上渲染对象对应的数据信息转 换为二进制流。
本步骤 210 中的具体操作可参见图 3 所示的流程 ：
参见图 3， 图 3 为本发明实施例提供的步骤 210 的流程图。如图 3 所示， 该流程可 包括以下步骤 ：
步骤 301， 从渲染树上获取发送了 URL 请求的手机所需要的 Render 对象。
本实施例中， 移动终端需要的渲染对象为 ： RenderText 对象、 RenderImage 对象、 控件 Render 对象、 以及与发送了 URL 请求的手机逻辑相关的 Render 对象 ； 或者， 为所述渲染树上所有的 Render 对象。
其中， 与手机逻辑相关的 Render 对象具体可为 RenderView 对象 ( 用于存放文档 页面大小、 HTML Head 标签元素等 )， RenderBlock 对象 (Form 表单元素 ) 等。
通过获取手机所需要的 Render 对象， 能够过滤掉其他一些不必要的 Render 对象， 这可在后续发送 Render 对象时节省流量。
步骤 302， 针对获取的每一 Render 对象， 获取该 Render 对象的渲染信息， 以及在所 述 DOM 树上获取该 Render 对象对应的 DOM 元素和该 DOM 元素的属性。
通常， Render 对象至少对应一个 DOM 元素。
其中， Render 对象的渲染信息主要为手机在步骤 213 执行绘制操作时用到的样式 信息， 具体可包括 ： Render 对象在屏幕上的坐标值和宽高， 颜色等。
DOM 元素和该 DOM 元素的属性具体定义可与现有技术中的定义类似， 这里不再赘 述。
本实施例中， 获取 Render 对象的渲染信息， 以及在所述 DOM 树上获取该 Render 对 象对应的 DOM 元素和该 DOM 元素的属性， 主要目的是为了步骤 213 的绘制操作。以 Render 对象的渲染信息包含 Render 对象在屏幕上的坐标值、 宽高和颜色， DOM 元素的标签是 标 签， 属性为 href ＝ http://www.qq.com 为例， 则当手机在步骤 213 得到该渲染信息、 DOM 元 素和该 DOM 元素的属性时， 由于有位置， 颜色和文本等信息就知道该怎么进行绘制， 而且也 知道点击该元素时进行的响应操作， 因为有其标签属性为 ， 同时也知道该跳转到什么网 页， 因为有属性 href ＝” http://www.qq.com” 。 步骤 303， 将获取的渲染信息、 DOM 元素和该 DOM 元素的属性分别进行二进制编码， 得到二进制流。
本步骤 303 可按照图 4 所示的 Tag-Length-Value(TLV) 编码格式分别对渲染信 息、 DOM 元素和该 DOM 元素的属性进行二进制编码。在图 4 中， Tag 是指标志位使用可变长 度变量， 本身占用 1 到 2 个字节。如果待编码的信息 ( 比如渲染信息、 DOM 元素或者该 DOM 元素的属性 ) 的值是从 0 到 254 的， 则使用单个字节 ； 如果值为 255 或者以上的， 则第一个 字节为 0xFF， 第二个字节为 ( 该待编码的信息的值 -255)。Length 是指 Value 字段中承载 的二进制流的长度。 Value 承载了二进制流， 长度由 Length 字段决定， 该二进制流本身可以 为数字或者字符串。 通过二进制编码， 能够大大减少服务器端和手机之间的流量传输压力。
至此， 完成了图 3 所示的流程。
步骤 211， 在该得到的二进制流的前部或者后部增加对应该二进制流的文件标识 和版本号， 以供识别该二进制流， 并通过 SkeetServer 发送至 BrokerServer。
其中， 文件标识和版本号各占一个字段。
步骤 212， BrokerServer 将接收的二进制流进行 WUP 协议组包和压缩， 下发给发送 了 URL 请求的手机。
步骤 213， 所述发送了 URL 请求的手机通过解析 WUP 协议组包得到二进制流， 依据 该二进制流执行绘制操作， 以实现网页浏览。
本步骤 213 的绘制操作可与现有技术类似， 这里不再赘述。
至此， 完成了图 2 所示的流程。
以上对本发明实施例提供的方法进行了描述， 下面对本发明实施例提供的设备和
系统进行描述。
参见图 5， 图 5 为本发明实施例提供的设备基本结构图。设备设置在服务器端， 其 中， 所述服务器端包含 webcore。如图 5 所示， 该设备包括 ：
处理单元 501， 用于接收页面， 将所述页面解析成 DOM 树， 并发送所述页面至所述 内核， 由所述内核对所述页面进行渲染， 形成渲染树 ；
转换单元 502， 用于依据所述 DOM 树将所述渲染树上渲染对象对应的数据信息转 换为二进制流， 并下发给移动终端， 由所述移动终端依据接收的二进制流执行绘制操作， 以 实现网页浏览。
以上对本发明实施例提供的设备进行了简单描述， 下面对该设备进行详细描述。
参见图 6， 图 6 为本发明实施例提供的设备详细结构图。如图 6 所示， 该设备可包 括： 处理单元 601 和转换单元 602， 其中， 处理单元 601 和转换单元 602 具有的功能分别与 处理单元 501 和转换单元 502 具有的功能类似， 这里不再详述。
优选地， 如图 6 所示， 转换单元 602 可包括 ：
第 一 获 取 子 单 元 6021， 用于从所述渲染树上获取所述移动终端需要的渲 染 Render 对 象 ； 本 实 施 例 中， 所述移动终端需要的渲染对象为 ： RenderText 对 象、 RenderImage 对象、 至少一个控件 Render 对象、 以及与所述移动终端逻辑相关的 Render 对 象； 或者， 为所述渲染树上所有的 Render 对象。 第二获取子单元 6022， 用于针对获取的每一 Render 对象， 获取该 Render 对象的渲 染信息， 以及在所述 DOM 树上获取该 Render 对象对应的 DOM 元素和该 DOM 元素的属性 ；
编码子单元 6023， 用于将获取的渲染信息、 DOM 元素和该 DOM 元素的属性进行二进 制编码， 得到二进制流 ；
转发子单元 6024， 用于将所述二进制流进行 WUP 协议组包和压缩， 下发给移动终 端， 以供移动终端通过解析 WUP 协议组包得到二进制流， 依据该二进制流执行绘制操作。
本发明实施例还提供了由服务器端实现网页渲染的系统， 其中， 该系统可包括 webcore、 移动终端比如手机和如图 5 或图 6 所述的设备。
本实施例中， 所述系统还包括 ： ChromeServer、 DCache 和 BrokerServer ；
其中， 所述 ChromeServer， 用于抓取所述移动终端发送的 URL 请求对应的原始网 页， 通过解析所述原始网页获取并存储所述原始网页中图片标签对应的图片信息至所述数 据库， 以及执行所述原始网页包含的 JS， 并向 BrokerServer 发送解析后的网页 ；
所述 BrokerServer， 用于接接收到网页后， 从所述数据库读取图片信息， 并插入至 该网页中对应该图片信息的图片标签处， 得到所述页面， 之后将所述页面发送至所述设备 中的处理单元。
优选地， 所述服务器端还包括连接在所述 ChromeServer 和所述 BrokerServer 之 间的 SkeetServer ；
所述 SkeetServer 接收所述 ChromeServer 发送的解析后的网页， 并判断所述移动 终端是否支持所述网页， 如果否， 则将所述解析后的网页转换为所述移动终端支持的网页， 并转发至所述 BrokerServer， 如果是， 将所述解析后的网页转发至所述 BrokerServer。
由以上技术方案可以看出， 本发明中， 通过在服务器端增加渲染服务器， 由该渲染 服务器完成网页的渲染， 并将渲染的结果返回给移动终端比如手机上的浏览器， 由手机浏
览器根据渲染结果执行绘制操作。 这显然能够避免由手机浏览器对网页标签进行解析渲染 所带来的技术问题， 降低手机浏览器的 CPU、 内存和网络流量的压力。
以上所述仅为本发明的较佳实施例而已， 并不用以限制本发明， 凡在本发明的精 神和原则之内， 所做的任何修改、 等同替换、 改进等， 均应包含在本发明保护的范围之内。