页面加载处理方法及装置与流程

本申请涉及页面加载处理技术领域，特别是涉及页面加载处理方法及装置。

背景技术：

hybridapp(混合模式移动应用)是目前常用的移动互联网应用开发模式，这种模式下，开发人员可以把html5应用程序嵌入到一个细薄的原生容器里面，使得hybridapp可以集原生应用程序和html5应用程序的优点于一体。但是，由于hybridapp中界面渲染需要的html(hypertextmark-uplanguage，超文本标记语言)、css(cascadingstylesheet，级联样式表)和js(javascript)文件通常需要请求服务器获取，因此，可能会存在页面加载时间长的问题，影响用户体验。

为了解决页面加载时间过长的问题，针对ios平台，现有技术中有两种方式。第一种方式是通过自定义nsurlcache实现静态资源的本地加载，具体的，将静态资源文件js/css在本地进行缓存，当访问h5页面时，根据url判断其对应的文件是否在本地缓存，如果在则根据本地文件内容构建nsurlresponse响应并返回。如果本地缓存内不存在，则网络请求远程服务器，获取相应的数据，然后加入到本地缓存中，以便下次访问时从缓存中读取。这种方式该方案可完全实现js、css和图片等静态资源的本地加载，但明显不足是对于本地加载的html请求，应用内置的浏览器控件uiwebview无法获得传入参数。例如，请求访问的h5页面的url(uniformresourelocator，统一资源定位符)为：http://h5.m.taobao.com/trip/holiday/search/search.html？lat＝122&lon＝32，但该方案是根据http://h5.m.taobao.com/trip/holiday/search/search.html找到对应的本地文件内容并构建响应，也即，将lat和lon参数值去掉了，导致lat和lon参数值是无法传递给uiwebview的。但是，如果url中的参数值是与页面渲染相关的，则uiwebview在进行html页面解析渲染时，会因为无法获得参数值 而导致渲染失败。

另一种解决方式是构建虚拟host域方法，首先判断html类型请求对应的文件内容是否在本地磁盘，如果本地可以找到，则将其域名换为一个虚拟host，然后将该域名下的所有静态资源文件(html、js、css和图片)请求重定向到本地加载，而不会访问服务器。也就是说，一旦发现某html请问的文件内容在本地磁盘中有保存，则将与该html具有相同域名的css、js、图片等请求的域名也都修改成虚拟host，使得对css、js、图片等文件的访问也都被重定向到本地磁盘。然后通过在本地构建响应的方式，向uiwebview返回响应。这种方式既能够实现css、js等文件的本地加载，也能够实现html的本地加载，但是缺点在于：一个h5页面通常是由一个html文件、若干css文件、若干js文件和若干图片组成，该方案事先也无法知道html文件究竟包含哪些js/css文件请求，所以无法判断其包含的js、css文件是否在本地磁盘中存在。这样，如果html文件在本地磁盘中，但该html文件请求的js、css不在本地磁盘，则修改每个js、css请求的域名后，会得到一个不存在的虚拟域，因此，无法从本地构建响应，进而页面访问就会出错。

综上，如何进一步优化页面加载流程，在解决页面加载时间过长问题的同时，提高方案的鲁棒性，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了页面加载处理方法及装置，在解决提高页面加载速度的同时，提高方案的鲁棒性。

本申请提供了如下方案：

一种页面加载处理方法，其特征在于，包括：

提供离线数据包，所述离线数据包中包括包内配置信息以及多份数据内容，每份数据内容对应一个待访问的页面文件，所述包内配置信息包括用于访问各页面文件的统一资源定位符url信息与数据内容在包内的相对路径信息之间的对应关系；

对应用中产生的目标页面文件访问请求进行劫持，确定所述目标页面文件访问请求的目标url信息，并利用所述包内配置信息判断所述离线数据包是否存在所述目标url信息对应的目标数据内容；

如果存在所述目标数据内容，则拦截所述目标页面文件访问请求，并利用所述离线数据包中的目标数据内容，通过模拟浏览器响应的方式构建页面文件访问响应数据，并将所述响应数据返回给应用内置的浏览器控件。

一种页面加载处理装置，其特征在于，包括：

离线数据包提供单元，用于提供离线数据包，所述离线数据包中包括包内配置信息以及多份数据内容，每份数据内容对应一个待访问的页面文件，所述包内配置信息包括用于访问各页面文件的统一资源定位符url信息与数据内容在包内的相对路径信息之间的对应关系；

判断单元，用于对应用中产生的目标页面文件访问请求进行劫持，确定所述目标页面文件访问请求的目标url信息，并利用所述包内配置信息判断所述离线数据包是否存在所述目标url信息对应的目标数据内容；

响应数据构建单元，用于如果存在所述目标数据内容，则拦截所述目标页面文件访问请求，并利用所述离线数据包中的目标数据内容，通过模拟浏览器响应的方式构建页面文件访问响应数据，并将所述响应数据返回给应用内置的浏览器控件。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于针对html、css、js、图片等类型的页面文件访问请求，都会判断离线数据包中是否存在对应的目标数据内容，这样，即使html文件在离线数据包中，但同一h5页面下包含的js文件、css文件等不在离线数据包时，也不会出现网页错误的情况。之后，如果离线数据包中存在目标数据内容，则通过完全模拟浏览器响应的方式，利用离线数据包中的目标数据内容构建响应数据，并返回给应用内置的浏览器控件进行解析渲染。期间不需要进行虚拟域的替换等操作，因此，完全支持从离线数据包加载的html请求时，向浏览器控件传递任意参数，js请求、css请求由于不存在 参数传递，因此更能够支持从离线数据包加载。总之，通过本申请实施例，对于各种类型文件的访问请求，都可以实现从离线数据包加载，并且具有高的鲁棒性。

在一种优选的实现方式下，离线数据包可以实现按业务模块进行划分，因此，每次更新的是一个模块的离线包而不是所有app的离线包，更新包体积会变小，更新的成本会降低，灵活性会提高。

在另一种优选的实现方式下，通过提供公用离线数据包以及懒加载离线数据包方案，可以更好地减小离线数据包的体积，并且减少了应用程序安装包的体积。

再一种优选的实现方式下，可以利用缓存机制，将首次访问涉及到的相关数据加入缓存，后续的访问从缓存进行，并将全局配置信息常驻于内存中，从而最大限度地减少了磁盘i/o次数，进一步提升了加载页面的时间。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的数据包概念示意图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的另一方法的流程图；

图4是本申请实施例中与现有技术中的页面加载时间对比示意图；

图5是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，为了进一步优化页面加载流程，在解决页面加载时间过长问题的同时，提高页面加载方案的鲁棒性、健壮性，可以提供离线数据包，应用在运行过程中，可以通过预先注册的协议类对页面文件访问请求进行拦截，在拦截到具体的页面文件访问请求后，无论是html文件访问请求，还是css文件访问请求、js文件访问请求或图片文件访问请求，都首先进行判断，以确定出离线数据包中是否存在该页面文件访问请求对应的数据内容，如果存在，则可以利用离线数据包中的数据内容，以完全模拟浏览器响应的方式，构建页面文件访问响应数据，并返回给应用内置的浏览器控件，进行页面的解析渲染等操作。在该方案中，由于对各种文件类型的访问请求，都会判断离线数据包中是否存在对应的数据内容，如果存在，则根据离线数据包中的数据内容进行加载，否则，按原始的url请求从远程服务器加载。这样，即使html文件在离线数据包中，但同一h5页面下包含的js文件、css文件等不在离线数据包时，也不会出现网页错误的情况。另外，通过完全模拟浏览器响应的方式构建响应数据，不需要进行虚拟域的替换等操作，因此，完全支持从离线数据包加载的html请求时，向浏览器控件传递任意参数。也就是说，本申请实施例提供的页面加载方案，对于各种类型文件的访问请求，都可以实现从离线数据包加载，并且具有高的鲁棒性。

为了便于理解本申请实施例的技术方案，下面首先对涉及到的一些相关的概念以及作用进行介绍。

参见图1，本申请实施例中涉及到的概念包括：

1、关于离线数据包。在本申请实施例中，离线数据包中首先可以包括多分数据内容，其中每份数据内容对应一个待访问的页面文件，所述页面文件包括html文件、css文件、js文件或图片文件，也就是说，各种类型的页面文件的数据内容都可以在离线数据包中进行保存。

2、关于包内配置信息。由于一个离线数据包中保存多份数据内容，每份数据内容对应一个页面文件，为了在拦截到具体的页面文件访问请求时，判断离线数据包内是否存在该请求对应的数据内容，可以提供一包内配置信息。该信息可以以文件等形式存在，其中，包内配置信息中包括：用于访问各页面文件的url信息与数据内容在包内的相对路径信息之间的对应关系。

例如，具体的信息保存结构可以如下所示：“trip/holiday/search/search.html":"search/search.html”,该实例表示页面文件的url是：http://h5.m.taobao.com/trip/holiday/search/search.html，该文件在离线数据包中的相对地址是/search/search.htmll，也即，在search目录下的search.htmll文件，等等。

其中，关于用于访问各页面文件的url信息是可以预先获知的，而数据内容在包内的相对路径信息，可以是在生成离线数据包时进行设置，也即，也是可以预先获知的，因此，在包内配置信息中记录两者之间的映射关系即可。包内配置信息也可以保存在离线数据包中。可以通过文件的扩展名等，与具体的数据内容进行区分，例如，包内配置信息可以以保存为json文件，也即，以json作为扩展名，等等。

3、关于全局配置信息。通常情况下，对于一些功能简单的应用，可以用一个统一的离线数据包对所有页面文件的离线加载提供支持。但是，一些功能比较复杂的应用，包含的页面数量非常多，一个页面下往往又包括一个html文件、若干css文件、若干js文件以及若干图片文件，因此，页面文件的数量会更加庞大，此时，如果将所有的页面文件都保存到同一个离线数据包中，则离线数据包的体积会很大，更新离线数据包时的数据传输量会很大，需要耗费比较长的时间，从服务器下载最新的离线数据包做所花费的时间会比较长，这增加了该功能的不安全性，因为时间越长，发生网络中断或者应用切换到后台运行的概率会越大，更新操作随时可能被终止，尤其是在3g网络状态下，这种情况会更为严重；另外，包体积太大，服务器针对更新包的生成逻辑也会变得非常复杂。

基于上述原因，考虑到一个大型的应用内，通常会按照业务线划分为多个 业务模块，例如，对于阿里旅行app而言，通常按照门票、酒店、度假、打车等业务线区分各个模块，等等。因此，在本申请的优选实施例中，可以按照应用内包括的多个业务模块，提供多个离线数据包，每个离线数据包对应同一业务模块内各页面的页面文件访问请求，并且，每个离线数据包对应各自的包内配置信息。例如，对于阿里旅行app而言，可以分别提供门票模块对应的离线数据包、酒店模块对应的离线业务数据包，等等，其中，门票模块对应的离线数据包，仅包括与门票业务相关的各页面内包括的各类型页面文件，酒店模块对应的离线数据包，仅包括与酒店业务相关的各页面内包括的各类型页面文件，等等。这样，每个离线数据包的体积会大大减小，在对离线数据包进行更新时，可以以每个业务模块对应的离线数据包为单位进行更新，更新数据时传输的数据量大为减小。

当然，在这种方式下，由于每个离线数据包对应各自的包内配置文件，也即，一个包内配置文件只需要记录一个数据包内各个文件url与数据内容在包内相对路径之间的对应关系，因此，为了能够定位到一个目标url实际对应的数据内容，还需要首先获知该url对应的数据内容是保存在具体哪个离线数据包内。

为此，在本申请实施例中，还提供了全局配置信息，该信息也可以以json等类型的文件存在，例如，可以命名为h5packagemap.json等等。在全局配置信息中，可以记录url与对应数据内容所在离线数据包的标识(数据包的标识可以是数据包的名称，简称“包名”，当然也可以是其他标识)之间的对应关系。例如，假设用于访问某页面文件的url为:http://h5.m.taobao.com/trip/holiday/search/search.html，上述链接的相对路径(relativepath)为trip/holiday/search/search.html，该url对应的数据内容位于包名为h5-holiday的离线数据包中，因此，就可以将对应关系记录为：“/trip/holiday/.+”:“h5-holiday”。这样，在具体拦截到页面文件访问请求时，就可以根据请求对应的url以及上述对应关系，确定出对应的离线数据包包名。

需要说明的是，通过前述例子中对包内配置信息以及全局配置信息的示例 可见，在记录url信息与在数据内容在包内相对路径，或者离线数据包包名之间的对应关系时，url信息都是使用的url中的相对应路径部分(relativepath)，也即，将域名部分(host，如http://h5.m.taobao.com/)去掉。这是因为，具体在保存配置信息时，可以采用正则表达式的方式来实现，但是，同一页面文件在测试、预发和线上环境的请求对应的是不同的host，也就是不同的url地址，如果直接用url去匹配，则不同的环境需要不同的正则表达式，这会增大配置信息的数据量。而由于relativepath不随host变化，因此，在本申请实施例中，可以取该url的relativepath作为判断依据，这样，一份正则表达式就可以适配所有环境。

另外，对于全局配置信息，虽然一个离线数据包内包含的页面数量得到了控制(例如，对于阿里旅行app，按照业务线划分为20个左右的离线数据包后，每个离线数据包内包括5到10个h5页面的页面文件)，但是，每个h5页面都包含一个html文件，以及若干css、js、图片等文件。对于这么多的页面文件，很难通过正则表达式将该离线数据包下所有的页面文件的url(包含js和css文件)映射到同一个离线数据包包名。如果不能实现相同业务逻辑的请求从同一个离线数据包加载，那么只能把所有的离线数据包放到同一个本地目录下面，这样按业务模块划分离线数据包的功能也就无从实现。

对此，考虑到webkit内核加载资源的流程是先加载html文件，然后在解析html建立dom树的过程中依次从上到下加载其中的js/css文件，所以对于一个h5页面来说，首先加载的是html资源，后续才是js/css资源。利用这个特点，在本申请优选的实施例中，可以仅在全局配置文件中包括html文件的url与所属离线数据包之间的对应关系，js/css文件的url则不再表达，这样，通过正则表达式进行包名映射的方式得以实现，因为正则表达式只需要保证匹配所有html请求的url和离线数据包包名即可。具体在拦截到页面文件访问请求时，针对html文件访问请求，可以根据全局配置文件，通过正则匹配的方式解析出离线数据包包名，并且可以对该包名进行记录，后续的js/css请求会出现正则匹配失败的情况，此时，可以从前面html请求中解析出的离线数据包获取数据内容。当拦截到新的html请求时，如果解析出的离线数据包包名发生了变化，则可以对记录的离线数据包包 名进行更新，该新的html请求之后的js/css请求，又会从更新后的离线数据包中获取数据内容。

4、关于公用离线数据包。在有些应用中，可能存在一些css、js、图片等页面文件，在不同的业务模块中可能都会用到，对于这部分页面文件，在本申请的优选实施例中，还可以通过单独的公用离线数据包进行保存，而不会在每个业务模块对应的离线数据包中都出现一次，这样可以缩小离线数据包的体积。其中，公用离线数据包中也会包括公用包内配置信息以及多份数据内容，其中，每份数据内容对应一个css文件、js文件或图片文件，公用包内配置信息包括url信息与数据内容在包内相对路径信息之间的对应关系。另外，全局配置信息中也会包括关于该公用离线数据包映射信息，当然，由于公用离线数据包中不包括html文件，并且在实际应用中，真正能够在各个业务模块之间都能公用的文件数量并不多，因此，全局配置信息中可以直接根据各个css/js/图片文件的url生成正则表达式，并映射到公用离线数据包。在拦截到css/js/图片文件访问请求时，可以首先利用请求的url进行正则匹配，如果能够匹配到公用离线数据包，则利用公用离线数据包中的包内配置信息，确定出对应的具体数据内容。如果无法匹配到公用数据包，再判断是否能够匹配到其他各业务模块对应的离线数据包。

在这种情况下，如果全局配置信息中，针对各业务模块对应的离线数据包，仅根据html文件的url生成了正则表达式，则两者也不会冲突，这是因为，css/js/图片文件访问请求会优先匹配公用数据包，并且可以直接利用css/js/图片文件访问请求的url与公用数据包进行匹配。在无法匹配到公用数据包的情况下，再与其他具体业务模块对应的离线数据包进行匹配，此时，再按照前文所述的方式，取最近拦截到的html文件访问请求对应的目标离线数据包，并从中获取css/js/图片文件访问请求对应的数据内容。

5、关于懒加载包。通常情况下，离线数据包可以携带在app的安装中，随着安装包一起被下载到终端设备本地，之后再解压到一个指定的本地磁盘目录下，离线加载的数据从该目录中进行获取。但在实际应用中，有些业务模块中的页面可能存在访问频率较低的情况，对应的离线数据包的使用率也比较低。 对于这种情况，在本申请的优选实施例中，可以将这种访问频率较低的离线数据包称为“懒加载包”，对于这种离线数据包，可以不必放入app安装包内进行发布。但是，可以在全局配置信息中记录关于这种懒加载包的配置信息，也即，能够将具体的页面请求匹配到这种懒加载包上来，另外，全局配置信息中还可以保存懒加载包的下载地址。这样，当用户访问这些页面时，可以先根据全局配置信息确定出存在对应的离线数据包，然后判断本地磁盘中是否存在关于该离线数据包的数据，如果不存在，则证明该业务模块是首次被访问，此时，可以创建一个下载子线程，由该下载子线程按照全局配置信息中记录的数据包下载地址，访问远程服务器，将该页面对应的离线包下载到本地磁盘中指定的目录下，当下次再拦截到与该离线数据包相关的页面文件访问请求时，就直接可以从本地磁盘中获取离线数据包中对应的具体数据内容。

以上对本申请实施例中涉及到的各种概念进行了介绍，下面对本申请实施例提供的具体页面加载处理流程进行详细介绍。

参见图2，本申请实施例提供了一种页面加载处理方法，该方法具体可以包括以下步骤：

s201：提供离线数据包，所述离线数据包中包括包内配置信息以及多份数据内容，每份数据内容对应一个待访问的页面文件，所述页面文件包括超文本标记语言html文件、级联样式表css文件、js文件或图片文件，所述包内配置信息包括用于访问各页面文件的统一资源定位符url信息与数据内容在包内的相对路径信息之间的对应关系；

关于离线数据包，在通常情况下，可以随着app安装包一起进行发布，这样，在用户将app安装到自己的终端设备上时，离线数据包也一起被下载到终端设备本地磁盘。其中，离线数据包在app安装包内可以是以zip包形式存在，且app包不能修改，为了实现离线数据包的动态更新，可以在沙盒下操作离线数据包，所以需要在app安装后且首次打开时，可以将zip包从app安装包中进行拷贝并解压到指定的沙盒目录。其中，如果离线数据包有多个，则全局配置文件(例如，h5packagemap.json)也可以包含在app安装包中，并与zip包一起被解压到指定的沙盒目录。所谓沙盒是指在受限的安全环境中 运行应用程序的一种做法，这种做法是要限制授予应用程序的代码访问权限。关于沙盒的具体实现，并不属于本申请实施例保护的范畴，这里不再详述。

当然，也可以在第一次被访问时，再将离线数据包从服务器下载到终端设备本地磁盘。或者，在存在多个离线数据包的情况下，可以将访问频率高的离线数据包携带在安装包中，将访问频率低的离线数据包保存在服务器上，第一次被访问时，再从服务器上下载到本地沙盒(也就是所谓的懒加载包方式)。

s202：对应用中产生的目标页面文件访问请求进行劫持，确定所述目标页面文件访问请求的目标url信息，并利用所述包内配置信息判断所述离线数据包是否存在所述目标url信息对应的目标数据内容；所述目标页面文件访问请求包括html文件访问请求、css文件访问请求、js文件访问请求或图片文件访问请求；

为了能够对应用中产生的目标页面文件访问请求进行拦截，在具体实现时，可以有多种实现方式。例如，其中一种实现方式下，可以预先通过继承系统提供的预置协议类，并重写其中的关键函数，生成自定义协议类，并在应用被打开时对所述自定义协议类进行注册，这样就可以利用所述自定义协议类对应用中产生的目标页面文件访问请求进行拦截。

具体的，在ios系统下，本申请实施例可以利用nsurlprotocol和nsurlprotocolclient实现hybridapp加载本地页面。通过继承nsurlprotocol并重写关键函数实现自定义fusionurlprotocol，然后通过方法[nsurlprotocolregisterclass:[fusionurlprotocolclass]]注册该自定义protocol，这样，fusionurlprotocol就可控制应用中的页面访问。

其中，nsurlprotocol是cocoatouch框架(软件开发api,用于开发iphone\ipod\ipad上的软件，此库以一系列框架库的形式存在，支持开发人员使用用户界面元素构建图像化的事件驱动的应用程序)提供的抽象类，由一系列的回调函数组成，为加载url数据提供了基础的结构，可劫持全局由nsurlconnection发起的网络请求，通过重写nsurlprotocol方法可以实现定制发起的request请求、返回加工处理后的数据、对已有网络协议做改进和 补充处理、全局缓存支持、user-agent修改和http代理。nsurlprotocolclient提供nsurlprotocol对象控制urlloadingsystem加载url的方法，当nsurlprotocol对象要对url对应的数据内容进行各种操作时就可以调用nsurlprotocolclient的方法。

本申请实施例中，可以使用uiwebview去实现应用内置的浏览器控件功能，而uiwebview的网络资源加载功能正是基于nsurlconnection实现的，因此利用nsurlprotocol可干涉整个uiwebview加载页面的过程。具体的，nsurlconnection的每个请求都会去遍历所有注册过的protocol，当调用回调函数caninitwithrequest时，第一个返回值为yes的protocol会处理该nsurlconnection请求。遍历遵循的原则是后进先出，最晚注册的最先遍历，因此如果还存在其他功能的protocol，则可最后注册本申请实施例中实现页面加载访问控制功能的protocol，以减少额外操作的执行，提高效率。

具体实现时，考虑到具体的页面文件访问请求，按照请求对数据执行的操作类型来划分，可以分为get、post、delete、put等多种类型。其中，post请求的数据必须提交到远程服务器保存，因此不能通过离线包方式进行加载。delete请求需要从服务器删除资源，put请求需要将数据存储到服务器，因此，只有不需要修改服务器内容的get请求才能采用从离线数据包进行加载。因此，在具体实现时，还可以在对应用中产生的目标页面文件访问请求进行拦截之前，还可以确定所述目标页面文件访问请求对数据执行的操作类型，如果属于目标操作类型，例如，get类型，则对目标页面文件访问请求进行拦截，否则不进行拦截，直接由远程服务器进行响应。

具体实现时，在ios系统中，为了实现上述判断，可以重写nsurlprotocol的回调函数+(bool)caninitwithrequest:(nsurlrequest*)request，该方法可根据访问请求中的相关信息来决定是否拦截此访问请求，返回值为yes表示拦截此请求，返回值为no表示不拦截。具体流程可以为:首先，判断访问请求的httpmethod方法是否为get，如果是get则返回yes，如果不是get方式返回值为no。然后，根据访问请求的url，可通过调用预置的功能函数，判断其对应的数据内容是否可在离线数据包中找到。为介绍方便，可以将该功 能函数命名为loadcacheddataforurl，其入参是访问请求的url，返回值是nsdata类型，若返回值data不为空，说明本地离线包存在其对应内容，那么caninitwithrequest函数返回值为yes，拦截该请求，若返回值data为空，说明本地离线包不存在相应内容，caninitwithrequest函数返回值为no，不拦截此请求，通过远程服务器进行加载。

其中，具体在利用所述包内配置信息判断所述离线数据包是否存在所述目标url信息对应的目标数据内容时，也就是判断包内配置信息中，是否存在目标url对应的包内相对路径，如果存在则证明离线数据包中存在目标url信息对应的目标数据内容。如果只有一个离线数据包，并且已经下载到本地磁盘中，则可以根据该数据包所在的目录以及包内相对路径构造出物理路径，通过该物理路径获取到具体的目标数据内容。

如果存在多个业务模块对应的多个离线数据包，则还可以首先进行利用所述全局配置信息判断是否存在与所述目标url对应的目标离线数据包，如果存在，则再利用目标离线数据包的包内配置信息，判断所述目标离线数据包中是否存在所述目标url信息对应的目标数据内容。

其中，如果全局配置信息仅包括html文件访问请求url信息与对应数据内容所在的离线数据包的标识之间的对应关系，则还可以在针对最近拦截到的html文件访问请求确定出对应的目标离线数据包标识后，对所述目标离线数据包标识进行记录，在劫持到其他类型文件访问请求时，可以利用所述记录的目标离线数据包标识，确定所述其他类型文件访问请求对应的目标离线数据包；所述其他类型文件访问请求包括css文件访问请求、js文件访问请求或图片文件访问请求。

如果对于不同业务模块之间公用的css文件、js文件或图片文件，提供单独的公用离线数据包，则在劫持到css文件访问请求、js文件访问请求或图片文件请求时，优先利用所述公用包内配置信息，判断离线数据包内是否存在与所述目标url对应的目标数据内容。

具体的，全局配置信息中，针对公用离线数据包，可以记录css文件、 js文件或图片文件的url信息与对应数据内容在公用离线数据包的标识之间的对应关系。而对于具体业务模块对应的离线数据包，如果仅包括html文件访问请求url信息与对应数据内容所在的离线数据包的标识之间的对应关系，则在劫持到其他类型文件访问请求时，首先利用所述全局配置信息，判断所述公用离线数据包内是否存在所述目标url对应的目标数据内容，如果存在，则利用所述公用包内配置信息，从所述公用离线数据包中获取对应的目标数据内容。如果所述公用离线数据包内不存在与所述目标url对应的目标数据内容，则可以定位到所述记录的最近拦截到的html文件访问请求对应的目标离线数据包标识，并利用该目标离线数据包中的包内配置信息，判断所述目标离线数据包中是否存在所述目标url对应的目标数据内容。

另外，具体实现时，从离线数据包加载文件，涉及到大量的磁盘i/o操作，在实践中发现，对于静态资源文件(html/css/js)的请求，例如，对于同一个html请求，caninitwithrequest函数会执行三次i/o操作，startloading会执行两次i/o操作，这样同一个html文件就会涉及到五次i/o请求。对于同一个js/css资源文件请求，caninitwithrequest函数和startloading函数各执行一次i/o操作，这样同一个js/css文件就会有两次i/o操作。为此，在本申请实施例中，可以使用nscache缓存，也即，在首次i/o读操作后，可以将相关的数据存入缓存,后续对该数据的所有读操作都是从缓存中获取，这样可以优化到只有一次i/o操作，优化了所有重复i/o。

具体的，如果劫持到的目标页面文件访问请求对应新页面创建，也即，是一个html文件访问请求(因为所有的页面访问请求都是从html文件访问开始的)，则可以将该目标url对应的目标数据内容，以及该url所在离线数据包的对应的包内配置信息加入到缓存中。这样，在劫持到该页面内新的页面文件访问请求时，就可以根据url判断缓存中是否存在对应的数据内容，如果存在，则证明该页面正在被访问，可以直接利用缓存中的数据内容进行响应数据构建。如果缓存中不存在对应的数据内容，则可以判断缓存中是否存在该url对应的包内配置信息，如果存在，则可以利用所述缓存中的包内配置信息判断离线包内是否存在与新页面文件访问请求的url对应的数据内容，如果存在，则从磁盘中的离线数据包中获取数据内容，并加入到缓存中。当所 述创建的页面被关闭时，则可以将缓存内与该页面相关的包内配置信息以及目标数据内容释放。当然，由于同一个离线数据包对应多个页面，也就是说，多个页面被访问时，都会用到该离线数据包的包内配置文件，因此，在一个页面被关闭时，缓存内与该页面的包内配置信息也可以暂时不释放。这样，可以实现同一个离线数据包下所有页面访问时，只有在第一次时执行i/o操作，后续操作都可以从缓存中获取数据该离线数据包的包内配置信息。

另外，对于全局配置文件，由于所有页面文件访问请求都需要首先利用该全局配置文件进行判断，因此，还可以保持该全局配置文件常驻在内存中。其中，具体实现时，可以创建单例线程，通过所述单例线程将所述全局配置信息读入到内存中。所述单例线程的特点是，该线程不随页面的关闭而释放，从而可以将所述全局配置信息常驻在内存中，这样，在利用那个所述全局配置信息判断是否存在与所述目标url对应的目标离线数据包时，就可以直接从内存中读取所述全局配置信息，从而使得页面加载时间进一步缩短。

s203：如果存在所述目标数据内容，则拦截所述目标页面文件访问请求，并利用所述离线数据包中的目标数据内容，通过模拟浏览器响应的方式构建页面文件访问响应数据，并将所述响应数据返回给应用内置的浏览器控件。

如果判断出离线数据包中存在当前页面文件访问请求对应的数据内容，则可以获取到该目标数据内容，并利用所述离线数据包中的目标数据内容，通过模拟浏览器响应的方式构建页面文件访问响应数据。

具体在获取到该目标数据内容时，由于访问频率高的高频离线数据包携带在应用的安装包中，并可以在所述应用首次被打开时，从所述安装包内进行解压后保存到本地磁盘的指定目录(沙盒)。因此，具体在从本地磁盘获取目标url对应的目标数据内容时，可以首先判断所述离线数据包是否已解压完毕，如果是，则将离线数据包的物理地址映射到所述指定目录，否则，将离线数据包的物理地址映射到所述安装包内。之后，再结合通过已经确定出的离线数据包名，以及包内相对路径，就可以组装成物理绝对路径，通过该路径获取到具体的数据内容。

其中，如果访问频率低的低频离线数据包保存在远程服务器，但所述全局配置信息中包含url与低频离线数据包之间的对应关系，则在被劫持到的页面文件访问请求的url对应所述低频离线数据包的情况下，可以首先判断本地磁盘中是否存在该低频离线数据包，如果不存在，则可以开启下载子线程，所述下载子线程用于根据所述下载地址信息将所述低频离线数据包进行下载，并保存到本地磁盘的指定目录，然后从所述本地磁盘本地目录中包括的所述低频离线数据包中获取所述被劫持到的页面文件访问请求对应的数据内容，并进行浏览器响应数据的构建。

具体在构建响应数据时，可以通过完全模拟真实的浏览器响应的方式来进行，这样，对于浏览器控件而言，其得到的响应数据，与从远程服务返回的响应数据是相同的，因此，完全可以实现对各种类型页面文件的解析及渲染。其中，具体实现时，如果页面文件访问请求是http请求，则就可以按照http协议构造http响应数据。其中，http响应数据包含两部分，一部分是nshttpurlresponse(响应头)，它用于通知浏览器控件请求资源的类型、数据长度和请求的url，另一部分是数据nsdata，代表响应数据的body(响应体)内容。

这样，具体在构建http响应数据时，就可以首先根据所述目标url中的后缀信息，以及对应目标数据内容的长度信息，生成http响应头部，然后根据所述目标url、http响应头部、http响应状态码(例如，200)以及http协议版本信息(例如，http/1.1)，构建响应头，并根据所述目标数据内容构建响应体，之后再将所述响应头以及响应体返回给应用内置的浏览器控件。这样，浏览器控件就可以利用响应头以及响应体，执行具体的解析渲染操作。

总之，通过本申请实施例，由于针对html、css、js、图片等类型的页面文件访问请求，都会判断离线数据包中是否存在对应的目标数据内容，这样，即使html文件在离线数据包中，但同一h5页面下包含的js文件、css文件等不在离线数据包时，也不会出现网页错误的情况。之后，如果离线数据包中存在目标数据内容，则通过完全模拟浏览器响应的方式，利用离线数据包中 的目标数据内容构建响应数据，并返回给应用内置的浏览器控件进行解析渲染。期间不需要进行虚拟域的替换等操作，因此，完全支持从离线数据包加载的html请求时，向浏览器控件传递任意参数，js请求、css请求由于不存在参数传递，因此更能够支持从离线数据包加载。总之，通过本申请实施例，对于各种类型文件的访问请求，都可以实现从离线数据包加载，并且具有高的鲁棒性。

以上所述提供了多种实现方式，在实际应用中，可以选择其中较为优选的实现方式。例如，在其中一种方式下，可以按照app中的多个业务模块，可以提供多个离线数据包，存在公用离线数据包以及懒加载离线数据包。为了减少i/o次数，还采用缓存模式，离线数据包内的数据(包括包内配置信息以及具体页面文件对应的数据内容)在第一次被读写时可以写入缓存，在页面退出时，相关页面文件的数据内容可以从缓存中释放。关于包内配置信息，可以在与该离线数据包相关的各个页面都退出后再从缓存中释放。另外，关于全局配置信息，可以是在首次使用时读入内存，并常驻在内存中。在这种实现方式下，具体实现时，参见图3，本申请实施例提供的页面加载方法可以包括以下步骤：

s301.劫持应用内的页面文件访问请求；

s302.对请求的文件操作类型进行判断，如果属于get类型，则进入s303，否则将请求放行，从远程服务器进行加载；

s303.判断缓存中是否存在该页面文件请求对应的数据内容，如果存在，则直接从缓存中获取页面文件的数据内容，以用于响应数据的构建，否则，进入s304；

s304.判断缓存中是否存在该页面文件请求对应的包名以及包内配置信息，如果存在，则说明该页面文件对应的离线数据包正在被访问，可以进入s311，否则，说明该页面文件可能没有对应的离线数据包，或者对应的离线数据报没有被访问，相关的数据内容、包内配置信息可以从本地磁盘中获取，因此，可以进入s305；

s305.根据该页面文件请求的url，查询内存中的全局配置信息，判断该 url对应的离线数据包名是否为空，如果为空，则证明该页面文件可能不在离线数据包中，或者，该页面文件访问请求可能是一个css、js或图片请求，而不是html请求，此时，可以进入到s311；否则，如果不为空，则进入s306；

s306.确定离线数据包的本地物理地址；

s307.判断该本地物理地址是否存在对应的离线数据包文件，如果不存在，则进入懒加载模式，且还位于远程服务器，因此，进入s311；如果存在，则进入s308；

s308，获取包内配置信息，根据包内配置信息判断当前页面文件访问请求的url对应的数据内容是否为空，如果为空，证明不存在与该页面文件对应的本地数据内容，因此可以返回空值，进而可以将该请求放行，从远程服务器进行加载；如果不为空，则进入s309；

s309.将记录的最近劫持的请求对应的包名以及包内配置信息进行替换，以用于确定后续劫持到的css、js、图片访问请求对应的离线数据包包名以及包内配置信息；

该步骤是为了解决js/css请求无法命中正则表达式的问题，当通过前述步骤获得新的离线数据包和包内配置信息时，说明接下来可能要访问新的页面，因此可以做替换操作，将新的js/css请求映射到新的离线数据包。

其中，在存在公用离线数据包的情况下，由于公用离线数据包中仅包含各模块公用的js/css的数据内容，因此，在获得新的离线数据包和包内配置信息时，还可以对新的离线数据包的类型进行判断，如果是公用数据包，则不能证明接下来要访问新页面，因此，也不必执行替换操作。

s310.将替换后的包名以及包内配置信息写入到缓存中，并进入s311；

s311.确定数据内容的物理绝对路径；

对于html首次请求，当执行到该步骤，说明已经获得了包名和包内配置信息，对于js/css请求，因先请求html，因此，在步骤s309中上述内容已经得到了保存，总之，当执行到此，包名和包内配置信息是存在的。利用 预置的函数可根据包名获取离线数据包的物理地址，根据包内配置信息(abc.json)映射表可获取其对应文件的相对路径，离线数据包地址+相对路径就是url对应文件的最终绝对路径。

此外，针对映射到公用数据包的url请求可以做特殊处理，因为在步骤s309中没有针对公用数据包做替换操作，也就是在该步骤此时的abc.json内容根本不是公用数据包的配置内容，因此可以再次从公用数据包获取abc.json,进而获得url对应的包内相对路径。

s312.判断物理绝对路径对应的数据内容是否存在，如果不存在，则返回空，进而可以将该请求放行，从远程服务器进行加载，否则，进入s313；

s313.得到离线数据内容，组建响应数据。

通过读取本地离线包获取离线文件的数据内容后，可以将其存入缓存nscache，当后续接收到相同的url请求时，不用执行读磁盘操作或上述步骤，直接从内存中获取数据即可。

可见，进入到s311的途径有三种，分别对应多种不同的情况.第一种情况，包名和包内配置信息可从缓存获取，说明当前url请求的离线数据包正在被访问；第二种情况，无法获取url对应的离线数据包包名，说该url请求可能是js、css或图片请求，无法在步骤5中根据h5cachelist的正则表达式获取包名；第三种情况，既可获得包名，又可获得包配置内容，说明这是一个html请求，并且是首次请求，可以读磁盘获取数据内容。每种情况下具体的确定物理绝对路径的方式可以参见前文中的介绍，另外，关于懒加载模式、公用离线数据包等相关的处理方式，也可以参见前文中的介绍，这里不再赘述。

为了更直观地确定本申请实施例在页面加载时间方面获得的效果，本申请发明人选择了上述优选实现方式，并在淘宝旅行客户端中实施。图4是利用上述优选实现方式进行对比测试的统计数据，其中，纵坐标表示加载时间。在该测试中，针对阿里旅行客户端20个重点页面进行统计，测试结果显示，利用本申请实施例提供的页面加载方案，各个页面的平均加载时间是0.352s(图中仅示出部分重点页面的对比结果，包括国际机票list页，国际机票下单页等等)。 而如果不使用本申请实施例的页面加载方案，则上述统计页面平均加载时间是1.423s，可见，页面加载速度提高了4倍左右。

与本申请实施例提供的页面加载处理方法相对应，本申请实施例还提供了一种页面加载处理装置，其中，参见图5，该装置可以包括：

离线数据包提供单元501，用于提供离线数据包，所述离线数据包中包括包内配置信息以及多份数据内容，每份数据内容对应一个待访问的页面文件，所述页面文件包括超文本标记语言html文件、级联样式表css文件、js文件或图片文件，所述包内配置信息包括用于访问各页面文件的统一资源定位符url信息与数据内容在包内的相对路径信息之间的对应关系；

判断单元502，用于对应用中产生的目标页面文件访问请求进行劫持，确定所述目标页面文件访问请求的目标url信息，并利用所述包内配置信息判断所述离线数据包是否存在所述目标url信息对应的目标数据内容；所述目标页面文件访问请求包括html文件访问请求、css文件访问请求、js文件访问请求或图片文件访问请求；

响应数据构建单元503，用于如果存在所述目标数据内容，则拦截所述目标页面文件访问请求，并利用所述离线数据包中的目标数据内容，通过模拟浏览器响应的方式构建页面文件访问响应数据，并将所述响应数据返回给应用内置的浏览器控件。

其中，所述离线数据包提供单元501具体用于：

按照所述应用内包括的多个业务模块，提供多个离线数据包，其中，每个离线数据包对应同一业务模块内待访问的页面文件，每个离线数据包对应各自的包内配置信息；

此时，所述装置还包括：

全局配置信息提供单元，用于提供全局配置信息，所述全局配置信息包括url信息与对应数据内容所在的离线数据包的标识之间的对应关系；

相应的，所述判断单元包括：

第一判断子单元，用于利用所述全局配置信息判断是否存在与所述目标url对应的目标离线数据包；

第二判断子单元，用于如果存在，则利用所述目标离线数据包的包内配置信息，判断所述目标离线数据包中是否存在所述目标url信息对应的目标数据内容。

其中，所述全局配置信息仅包括html文件访问请求url信息与对应数据内容所在的离线数据包的标识之间的对应关系，所述装置还包括：

记录单元，用于在针对最近拦截到的html文件访问请求确定出对应的目标离线数据包标识后，对所述目标离线数据包标识进行记录；

目标离线数据包确定单元，用于在劫持到其他类型文件访问请求时，利用所述记录的目标离线数据包标识，确定所述其他类型文件访问请求对应的目标离线数据包；所述其他类型文件访问请求包括css文件访问请求、js文件访问请求或图片文件访问请求。

具体实现时，所述离线数据包提供单元具体用于：

对于不同业务模块之间公用的css文件、js文件或图片文件，提供单独的公用离线数据包，所述公用离线数据包中包括公用包内配置信息以及多份数据内容，每份数据内容对应一个css文件、js文件或图片文件，所述公用包内配置信息包括url信息与数据内容在包内相对路径信息之间的对应关系；

所述判断单元具体用于：

在劫持到css文件访问请求、js文件访问请求或图片文件请求时，优先利用所述公用包内配置信息，判断离线数据包内是否存在与所述目标url对应的目标数据内容。

所述全局配置信息中，针对具体业务模块对应的离线数据包，仅包括html文件访问请求url信息与对应数据内容所在的离线数据包的标识之间的对应关系，针对公用离线数据包，包括css文件、js文件或图片文件的url 信息与对应数据内容在公用离线数据包的标识之间的对应关系；

所述判断单元包括：

记录子单元，用于在针对最近拦截到的html文件访问请求确定出对应的目标离线数据包标识后，对所述目标离线数据包标识进行记录；

第三判断子单元，用于在劫持到其他类型文件访问请求时，利用所述全局配置信息，判断所述公用离线数据包内是否存在所述目标url对应的目标数据内容，如果存在，则利用所述公用包内配置信息，从所述公用离线数据包中获取对应的目标数据内容；所述其他类型文件访问请求包括css文件访问请求、js文件访问请求或图片文件访问请求；

定位子单元，用于如果所述公用离线数据包内不存在与所述目标url对应的目标数据内容，则定位到所述记录的最近拦截到的html文件访问请求对应的目标离线数据包标识，并利用该目标离线数据包中的包内配置信息，判断所述目标离线数据包中是否存在所述目标url对应的目标数据内容。

具体实现时，该装置还可以包括：

单例线程创建单元，用于创建单例线程，通过所述单例线程将所述全局配置信息读入到内存中，其中，所述单例线程不随页面的关闭而释放，以便将所述全局配置信息常驻在内存中，在利用那个所述全局配置信息判断是否存在与所述目标url对应的目标离线数据包时，从内存中读取所述全局配置信息。

其中，访问频率低的低频离线数据包保存在远程服务器，但所述全局配置信息中包含url与低频离线数据包之间的对应关系，并保存所述低频离线数据包的下载地址信息；

所述装置还包括：

本地判断单元，用于如果被劫持到的页面文件访问请求的url对应所述低频离线数据包，则判断本地磁盘中是否存在该低频离线数据包；

下载单元，用于如果不存在，则开启下载子线程，所述下载子线程用于根据所述下载地址信息将所述低频离线数据包进行下载，并保存到本地磁盘的指 定目录；

数据内容获取单元，用于从所述本地磁盘本地目录中包括的所述低频离线数据包中获取所述被劫持到的页面文件访问请求对应的数据内容，并进行浏览器响应数据的构建。

访问频率高的高频离线数据包携带在应用的安装包中，并在所述应用首次被打开时，从所述安装包内进行解压后保存到本地磁盘的指定目录；

所述装置还包括：

物理地址映射单元，用于从本地磁盘获取目标url对应的目标数据内容时，判断所述离线数据包是否已解压完毕，如果是，则将离线数据包的物理地址映射到所述指定目录，否则，将离线数据包的物理地址映射到所述安装包内。

所述包内配置信息以及全局配置信息中保存的url信息为用于访问页面文件的url中的相对路径信息；在判断是否存在所述目标url对应的目标数据内容时，利用所述目标url中的相对路径信息，与所述全局配置信息以及包内配置信息进行匹配。

另外，该装置还可以包括：

缓存单元，用于如果所述目标页面文件访问请求对应新页面创建，则将该目标url对应的目标数据内容，以及所在离线数据包的对应的包内配置信息加入到缓存中；

缓存数据判断单元，用于劫持到该页面内新的页面文件访问请求时，根据url判断缓存中是否存在对应的数据内容，如果存在，则利用缓存中的数据内容进行响应数据构建；

缓存配置信息判断单元，用于如果缓存中不存在对应的数据内容，则利用所述缓存中的包内配置信息判断离线包内是否存在与新页面文件访问请求的url对应的数据内容，如果存在，则从磁盘中的离线数据包中获取数据内容，并加入到缓存中；

缓存释放单元，用于当所述创建的页面被关闭时，将缓存内与该页面相关 的内容释放。

具体实现时，可以预先通过继承系统提供的预置协议类，并重写其中的关键函数，生成自定义协议类，并在应用被打开时对所述自定义协议类进行注册，以便利用所述自定义协议类对应用中产生的目标页面文件访问请求进行拦截。

另外，该装置还可以包括：

操作类型确定单元，用于在对应用中产生的目标页面文件访问请求进行拦截之前，确定所述目标页面文件访问请求对数据执行的操作类型；

拦截触发单元，用于如果属于目标操作类型，则触发对目标页面文件访问请求进行拦截。

具体实现时，所述目标页面文件访问请求包括http请求，所述响应数据构造单元，包括：

响应头部生成子单元，用于根据所述目标url中的后缀信息，以及对应目标数据内容的长度信息，生成http响应头部；

响应头构建子单元，用于根据所述目标url、http响应头部、http响应状态码以及http协议版本信息，构建响应头；

响应体构建子单元，用于根据所述目标数据内容构建响应体；

数据返回子单元，用于将所述响应头以及响应体返回给应用内置的浏览器控件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相 似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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