CN103440143A

CN103440143A - 移动web应用升级***及方法

Info

Publication number: CN103440143A
Application number: CN2013103347724A
Authority: CN
Inventors: 黄明登; 郭正欧; 张磊
Original assignee: iFlytek Co Ltd
Current assignee: iFlytek Co Ltd
Priority date: 2013-08-02
Filing date: 2013-08-02
Publication date: 2013-12-11

Abstract

本发明公开了一种移动web应用升级***及方法，该***包括：主浏览器、次浏览器、本地缓存模块；所述本地缓存模块用于存储浏览器缓存数据；所述主浏览器用于加载和运行web页面，并在web应用首次访问时，从程序安装目录中加载数据；在web应用后续启动时，从浏览器缓存数据库中加载数据；所述次浏览器用于对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。利用本发明，可以使用户在每次访问页面时，都能够快速访问，无需等待升级。

Description

移动web应用升级***及方法

技术领域

本发明涉及应用程序升级技术领域，特别是涉及一种移动web应用升级***及方法。

背景技术

移动web（网页）应用是指基于web技术来开发应用程序的主体，外面包裹一层原生浏览器控件webview（浏览器），以第三方应用的方式运行于操作***（如：Android、iOS、Windows Phone等）之上的应用。这种应用混合了web和native两种开发方式，兼具两者的优点，同时使用网页语言与程序语言开发，业界也称之为hybrid应用。

随着移动web应用的不断扩大，对于web应用程序的网络访问和升级问题显得越来越明显。用户不得不不断对应用程序进行升级，在升级的过程中，会出现用户访问页面时，总是提示是否需要更新或是需要等待更新完成，才能访问页面的问题。

发明内容

本发明提供一种移动web应用升级***及方法，以使用户在每次访问页面时，都能够快速访问，无需等待升级。

为此，本发明提供如下技术方案：

一种移动web应用升级***，包括：主浏览器、次浏览器、本地缓存模块；

所述本地缓存模块，用于存储浏览器缓存数据；

所述主浏览器，用于加载和运行web页面，并在web应用首次访问时，从程序安装目录中加载数据；在web应用后续启动时，从浏览器缓存数据库中加载数据；

所述次浏览器，用于对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。

优选地，所述***还包括：

代理服务器，用于监听所述主浏览器和次浏览器发送的访问请求，并且在监听到所述主浏览器发送的访问请求后，从程序安装目录中提取所述web应用的安装文件，并将所述安装文件返回给所述主浏览器；在监听到所述次浏览器发送的访问请求后，将所述访问请求中的URL映射为网络侧所述web应用的真实URL并发起网络请求，从网络侧获取所述web应用的数据，并将所述web应用数据返回给所述次浏览器。

优选地，所述代理服务器通过设定的同一端口监听所述主浏览器和次浏览器发送的访问请求。

优选地，所述主浏览器包括：

接收单元，用于接收用户对web应用的访问请求；

本地访问单元，用于在所述接收单元接收到所述访问请求后，访问本地缓存模块中的浏览器缓存数据库；

服务器访问单元，用于在所述浏览器缓存数据库为空时，向所述代理服务器发送对所述web应用的访问请求，并接收所述代理服务器从程序安装目录中提取的所述web应用的安装文件；

加载单元，用于加载所述web应用的安装文件；

存储单元，用于在所述加载单元加载完成后，将所述安装文件存放到所述浏览器缓存数据库中。

优选地，所述次浏览器包括：

访问请求单元，用于定时向所述代理服务器发送对所述浏览器缓存数据库的访问请求，并接收所述代理服务器从网络侧获取的所述web应用的数据；

检测更新单元，用于根据所述web应用的数据对所述浏览器缓存数据库中的web应用数据进行检测和更新。

优选地，所述次浏览器还包括：

询问单元，用于在所述检测更新单元对所述浏览器缓存数据库中的数据进行检测和更新之前，向用户询问是否对所述web应用数据进行更新；并在接收到用户确认更新的信息后，通知所述检测更新单元执行检测和更新操作。

一种移动web应用升级方法，所述方法包括：

设置主浏览器和次浏览器；

在web应用首次访问时，所述主浏览器从程序安装目录中加载数据；

在web应用后续启动时，所述主浏览器从浏览器缓存数据库中加载数据；

所述次浏览器定时对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。

优选地，所述方法还包括：

设置代理服务器，所述代理服务器监听所述主浏览器和次浏览器发送的访问请求，并且在监听到所述主浏览器发送的访问请求后，从程序安装目录中提取所述web应用的安装文件，并将所述安装文件返回给所述主浏览器；在监听到所述次浏览器发送的访问请求后，将所述访问请求中的URL映射为网络侧所述web应用的真实URL并发起网络请求，从网络侧获取所述web应用的数据，并将所述web应用数据返回给所述次浏览器。

优选地，所述在web应用首次访问时，所述主浏览器从程序安装目录中加载数据包括：

所述主浏览器接收到用户对web应用的访问请求后，访问本地缓存模块中的浏览器缓存数据库；

如果所述浏览器缓存数据库为空，则所述主浏览器向代理服务器发送对所述web应用的访问请求，并接收所述代理服务器从程序安装目录中提取的所述web应用的安装文件；

所述主浏览器加载所述web应用的安装文件，并在加载完成后，将所述安装文件存放到所述浏览器缓存数据库中。

优选地，所述次浏览器定时对所述web应用进行检测更新包括：

所述次浏览器定时向所述代理服务器发送对所述浏览器缓存数据库的访问请求，并接收所述代理服务器从网络侧获取的所述web应用的数据；

根据所述web应用的数据对所述浏览器缓存数据库中的web应用数据进行检测和更新。

本发明实施例提供的移动web应用升级***及方法，通过设置主浏览器和从浏览器，主浏览器用来加载和运行web页面，次浏览器用来在后台检测更新。两个浏览器使用同一份本地缓存，主浏览器负责从缓存中读取数据，次浏览器负责更新缓存数据库。主浏览器在程序首次启动时访问从程序安装目录中加载数据，后续启动都从本地缓存进行读取，因而能做到快速加载。同时，次浏览器使用标准的web机制，从网络侧获取和更新资源，因此能做到实时、差异化升级。

利用本发明实施例提供的移动web应用升级***及方法，可以很好地提升用户体验，使得用户每次访问页面时，都能够快速访问，无需等待升级。在更新时，采取差异性更新的方法，下载速度快，节省流量。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本发明实施例移动web应用升级***的原理框图；

图2是本发明实施例移动web应用升级***的一种具体实现结构示意图；

图3是本发明实施例移动web应用升级***中主浏览器首次访问时的工作示意图；

图4是本发明实施例移动web应用升级***中主浏览器非首次访问时的工作示意图；

图5是本发明实施例移动web应用升级***中从浏览器的工作示意图；

图6是本发明实施例中主浏览器的一种结构示意图；

图7是本发明实施例中次浏览器的一种结构示意图；

图8是本发明实施例移动web应用升级方法的流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

目前移动web应用的升级方式主要有以下三种：

（1）本地更新：web资源打包在程序安装包中，随着安装包一起更新。这种方式优点在于更新逻辑简单，缺点也很明显：升级包体积大，用户等待时间长；一次小的升级或bug修复也必须得整包一起更新，造成用户流量浪费；安装包下载完成后，还需要用户再次执行安装操作后才能使用。

（2）传统的web更新：web资源部署在网络侧，应用程序启动时从网络侧下载web资源。该方式的优点在于能够充分利用标准的web更新机制，做到实时、差异化的更新，无需用户再次安装，缺点在于首次启动时需要从网络侧下载资源，用户等待时间长；没有网络时，无法访问离线资源。

（3）html5方式更新：利用html5中的应用缓存机制，能够解决方式2中无法离线访问的问题。但这种机制的更新方式是将整个离线缓存资源一起更新，不能进行差异化更新。

针对上述现有移动web应用升级中存在的问题，本发明实施例提供一种移动web应用升级***及方法，在客户端的native层设置两个浏览器，即主浏览器和次浏览器，两者相互配合，主浏览器用来加载和运行web页面，次浏览器用来在后台对web应用进行检测更新。两个浏览器使用同一份本地缓存，主浏览器负责从缓存中读取数据，次浏览器负责更新缓存中的数据。主浏览器在web应用首次启动时访问程序安装目录，进行初始的数据加载，后续启动都从本地缓存进行读取，从而做到快速加载。次浏览器使用标准的web机制，从网络端获取和更新资源，实现实时、差异化升级。

进一步，要解决首次下载资源大的问题，最有效的方案就是将web应用所需的web资源打包进程序安装包中。在本发明实施例中，web应用首次启动时，主浏览器直接从程序安装目录进行加载，后续启动则从本地缓存目录进行加载。由于浏览器引擎对于从程序安装目录加载的文件是不会放入本地缓存的，因此，在本发明实施例中，进一步借助代理服务器，将主浏览器从程序安装目录加载的文件变成浏览器的本地缓存。如图1所示，是本发明实施例移动web应用升级***的原理框图。

该***包括：主浏览器11、次浏览器12、本地缓存模块10。其中：

本地缓存模块10，用于存储浏览器缓存数据；

主浏览器11，用于加载和运行web页面，并在web应用首次访问时，从程序安装目录中加载数据；在web应用后续启动时，从浏览器缓存数据库中加载数据；

次浏览器12，用于对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。

要解决首次下载资源大的问题，最有效的方法就是将web资源打包进程序安装包中。web应用首次启动时，主浏览器直接从程序安装目录进行加载，后续启动则从本地缓存目录进行加载。次浏览器负责更新工作，每次更新后将更新的结果放入到本地缓存文件夹中。

由于当浏览器检测到访问的地址为http://127.0.0.1/xxx时，会认为这是一个网络访问，而将其缓存到浏览器数据库中，而实际上这却是一个本地访问。因此，在本发明实施例的***中，利用浏览器的这一特性，在所述***中设置一个代理服务器，在程序中建立一个代理服务，针对浏览器的访问进行监听控制，协调主、次浏览器的工作，使主浏览器从程序安装目录加载的文件放入本地缓存中。

如图2所示，是本发明实施例移动web应用升级***的一种具体实现结构示意图。

在该实施例中，所述***还包括：代理服务器20，用于监听主浏览器11和次浏览器12发送的访问请求，并且在监听到主浏览器11发送的对所述web应用的访问请求后，从程序安装目录中提取所述web应用的安装文件，并将所述安装文件返回给主浏览器11；在监听到次浏览器12发送的对所述浏览器缓存数据库的访问请求后，将所述访问请求中的浏览器缓存数据库的URL映射为网络侧所述web应用的URL并发起网络请求，从网络侧获取所述web应用的数据，并将所述web应用数据返回给次浏览器12。

需要说明的是，在本发明实施例中，代理服务器可以通过设定的同一端口（比如在8089端口）监听所述主浏览器和次浏览器发送的访问请求。而且，所述端口可以自行配置。

而且，在本发明实施例中，可以预先对浏览器的访问进行设置，对同一个地址的访问，主浏览器设置的是先访问浏览器缓存，如果没有，再发消息给代理服务器；次浏览器则直接发消息给代理服务器。

为了进一步清楚了解本发明实施例的***中主、从浏览器的工作及配合过程，下面将分别进行详细说明。

如图3所示，是本发明实施例移动web应用升级***中主浏览器首次访问时的工作示意图。

31.主浏览器在接收用户对web应用的访问请求后，访问本地缓存模块中的浏览器缓存数据库http://127.0.0.1/xxx。

32.如果浏览器缓存数据库为空，则主浏览器向代理服务器发送对所述web应用的访问请求，在该访问请求中携带所述web应用的URL（UniformResource Locator，统一资源定位符）。

33.代理服务器监听到访问请求后，判断是对web应用的首次访问，则确定是主浏览器发送的访问请求，然后从程序安装目录中提取相应的程序安装文件。

具体地，代理服务器可以通过设定的某个端口（比如8089端口）来监听主浏览器和从浏览器发送的请求消息，并且设定一个对应所述web应用的访问变量temp，通过不同的变量值来区分是首次访问还是非首次访问，比如temp=0时，为首次访问；temp=1时，为非首次访问。

这样，代理服务器在监听到请求消息后，读取temp的值为0，则判断是对web应用的首次访问。

34.代理服务器将提取的安装文件返回给主浏览器。

35.主浏览器加载所述程序安装文件，并在安装成功后，向代理服务器返回安装成功消息，以使代理服务器将temp的值设置为1。

36．主浏览器将所述程序安装文件存放到浏览器缓存数据库中。

如图4所示，是本发明实施例移动web应用升级***中主浏览器非首次访问时的工作示意图。

由于设置了主浏览器的加载方式为优先从浏览器缓存数据库加载，因此，在主浏览器接收用户对web应用的访问请求后，直接访问本地缓存模块中的浏览器缓存数据库，不需要再发起http请求。

由此可见，本发明实施例中，主浏览器只在首次对web应用进行访问时，需要向代理服务器发出访问请求，从程序安装目录下加载相应的程序安装文件，其余时刻，都只需从本地缓存模块的浏览器缓存数据库中读取数据，这种访问方式即使在离线的时候也能加载缓存资源。

而且，对于代理服务器来说，对于监听端口只有一次接收的消息是来自主浏览器，其余接收到的消息都是来自次浏览器的。代理服务器每次只需检测访问变量temp的值，就可判断是主浏览器还是次浏览器发送的消息并做相应的应答。

如图5所示，是本发明实施例移动web应用升级***中从浏览器的工作示意图。

51.次浏览器定时发送访问请求，访问URL前缀为http://127.0.0.1/xxx的文件。

52.代理服务器监听到上述访问请求后，判断是次浏览器发送的访问请求（比如检测到访问变量temp的值为1），则将访问请求中的URL映射为实际的网络侧web应用的地址，并使用该地址发起http请求。

53.代理服务器从网络侧获取相应的数据。

在上述过程中，代理服务器起到的作用是IP地址转换和消息转发的作用。当代理服务器监听到次浏览器要访问http://127.0.0.1/xxx时，将http://127.0.0.1/xxx转换成实际的网络地址，从网络侧获取所述web应用的数据。

所述网络地址可以预先在客户端配置，并在客户端启动时传送给代理器。

54.代理服务器将从网络侧获取的数据返回给次浏览器。

55.次浏览器收到代理服务器返回的数据后，次浏览器中的浏览器引擎将依据标准的web缓存机制，进行缓存的检测和更新。

需要说明的是，在实际应用中，次浏览器可以根据用户的需要和应用程序的特点进行相应的设置。例如，根据更新文件的大小、更新内容、更新需要的流量等条件，决定是否直接进行更新，还是先向用户询问，得到用户确认后再进行更新。

另外，根据http缓存机制，浏览器向web服务器发送http请求时，会在请求中携带本地缓存文件的最近一次更新时间，web服务器在收到请求后，会比较服务器端对应的该文件的更新时间。根据比较结果，web服务器决定是否下发新文件还是告知浏览器直接使用本地缓存文件。这样web端有更新的文件才会重新下载，没有更新的则使用本地缓存文件，以此达到差异更新的目的。因此，次浏览器对web应用进行更新时，可以采取差异性更新，节省流量，进一步提高更新速度。

次浏览器可以每隔一段时间发送一次对浏览器缓存数据库的访问请求。

由此可见，本发明实施例中，次浏览器也使用代理服务器进行访问，与主浏览器访问文件的URL保持一致，因此两个浏览器共享的是同一份缓存。次浏览器对缓存进行更新之后，主浏览器读取的就是更新后的资源了。

本发明实施例提供的移动web应用升级***，采用访问和更新分离的方式，分别由主浏览器完成web页面的加载和运行，由次浏览器在后台定时对web应用进行检测更新。两个浏览器相互配合，使用同一份本地缓存，主浏览器负责从缓存中读取数据，次浏览器负责更新缓存中的数据。主浏览器在web应用首次启动时访问程序安装目录，进行初始的数据加载，后续启动都从本地缓存进行读取，从而做到快速加载。次浏览器使用标准的web机制，从网络端获取和更新资源，实现实时、差异化升级。从而使得用户每次访问页面时，都能够快速访问，无需等待相关web应用的升级，很好地提升了用户体验。进一步地，在更新时，采用差异性更新的方式，下载速度快，节省流量。

利用本发明实施例提供的移动web应用升级***，可以很好地提升用户体验，使得用户每次访问页面时，都能够快速访问，无需等待升级。在更新时，采取差异性更新的方法，下载速度快，节省流量。

如图6所示，是本发明实施例中主浏览器的一种结构示意图。

在该实施例中，所述主浏览器包括：

接收单元61，用于接收用户对web应用的访问请求；

本地访问单元62，用于在所述接收单元61接收到所述访问请求后，访问本地缓存模块中的浏览器缓存数据库；

服务器访问单元63，用于在所述浏览器缓存数据库为空时，向代理服务器发送对所述web应用的访问请求，并接收所述代理服务器从程序安装目录中提取的所述web应用的安装文件；

加载单元64，用于加载所述web应用的安装文件。

存储单元65，用于在加载单元64加载完成后，将所述安装文件存放到所述浏览器缓存数据库中。

该主浏览器主要用于加载和运行web页面，并在web应用首次访问时，从程序安装目录中加载数据；在web应用后续启动时，从所述浏览器缓存数据库中加载数据。其工作过程可参照前面图3和图4所示流程，在此不再赘述。

如图7所示，是本发明实施例中次浏览器的一种结构示意图。

在该实施例中，所述次浏览器包括：

访问请求单元71，用于定时向代理服务器发送对所述浏览器缓存数据库的访问请求，并接收所述代理服务器从网络侧获取的所述web应用的数据；

检测更新单元72，用于根据所述web应用的数据对所述浏览器缓存数据库中的web应用数据进行检测和更新。

进一步地，所述次浏览器还可包括：询问单元（未图示），用于在所述检测更新单元72对所述浏览器缓存数据库中的数据进行检测和更新之前，向用户询问是否对所述web应用数据进行更新；并在接收到用户确认更新的信息后，通知所述检测更新单元72执行检测和更新操作。

该次浏览器主要用于对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。其工作过程可参照前面图5所示流程，在此不再赘述。

相应地，本发明实施例还提供一种移动web应用升级方法，如图8所示，是该方法的流程图，包括以下步骤：

步骤801，设置主浏览器和次浏览器；

步骤802，在web应用首次访问时，所述主浏览器从程序安装目录中加载数据；

步骤803，在web应用后续启动时，所述主浏览器从浏览器缓存数据库中加载数据；

步骤804，所述次浏览器定时对所述web应用进行检测更新，并在每次更新后将更新的数据存储到所述浏览器缓存数据库中。

需要说明的是，在实际应用中，可以通过设置代理服务器使主浏览器和次浏览器完成分工协作，实现移动web应用的智能升级。

为此，在本发明实施例中，还可进一步包括以下步骤：

相应地，所述主浏览器从程序安装目录中加载数据包括以下步骤：

相应地，所述次浏览器定时对所述web应用进行检测更新包括：

本发明实施例提供的移动web应用升级方法，采用访问和更新分离的方式，使得用户每次访问页面时，都能够快速访问，无需等待升级，很好地提升了用户体验。进一步地，在更新时，采用差异性更新的方式，下载速度快，节省流量。

需要说明的是，在实际应用中，可以将本发明实施例的方法及***作为移动web应用的一个组件，采用软件或者软件硬件相结合的方式实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

以上所描述的***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式对本发明进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及设备；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种移动web应用升级***，其特征在于，包括：主浏览器、次浏览器、本地缓存模块；

所述本地缓存模块，用于存储浏览器缓存数据；

2.根据权利要求1所述的***，其特征在于，所述***还包括：

3.根据权利要求2所述的***，其特征在于，所述代理服务器通过设定的同一端口监听所述主浏览器和次浏览器发送的访问请求。

4.根据权利要求2所述的***，其特征在于，所述主浏览器包括：

接收单元，用于接收用户对web应用的访问请求；

加载单元，用于加载所述web应用的安装文件；

5.根据权利要求2所述的***，其特征在于，所述次浏览器包括：

6.根据权利要求5所述的***，其特征在于，所述次浏览器还包括：

7.一种移动web应用升级方法，其特征在于，包括：

设置主浏览器和次浏览器；

8.根据权利要求7所述的方法，其特征在于，还包括：

9.根据权利要求8所述的方法，其特征在于，所述在web应用首次访问时，所述主浏览器从程序安装目录中加载数据包括：

10.根据权利要求8所述的方法，其特征在于，所述次浏览器定时对所述web应用进行检测更新包括：