页面url概述
WeX5/BeX5系统中,UIServer是提供界面展现的服务,一个页面一般对应的是.w文件。一个完整的页面url如“http://x5.justep.com:8080/x5/UI2/takeout/index.w”,其中x5是UIServer的web应用名(在tomcat的server.xml查看,可以根据需要自行修改名字),8080是tomcat的http服务端口号,UI2/takeout/index.w 则为model下面.w资源的路径。
注意:BeX5中的功能是需要授权的,通过上面那样直接输入.w地址不能正常运行(使用到bizData组件的页面不能运行),需要登录通过门户打开,原理上是登录后生成了一个bseesionID,这个做为认证依据,通过cookie和url参数传递给UIServer用于授权相关的认证。
.cache机制
虽然url中显示的是xxx.w,但请求服务器时,服务器并不是直接访问.w,而访问的是.w同级对应的.cache。
.release机制
每个.w对应一个.release,.release是一种中间格式,它的推出主要是为了应用厂商保护自己的源代码。当把一个应用发布给客户的时候,可以仅提供.release,而不用提供.w。.w和.release的使用原则是,如果有.w,则.w有效,否则使用.release。
注意:.release等价于.w,和下面介绍的资源版本号无关
浏览器缓存原理
浏览器在访问网页时,是基于url进行缓存(缓存是指静态资源,例如js、css、png等,.w平台做了特殊处理,也会缓存,这个将极大减少网络流量),如果url相同,那下次访问时直接会从本地缓存中读取。对于js、css和png等静态资源,正常使用不可避免需要有替换的情况,但如果仅仅替换,那浏览器访问是不会自动更新文件,除非自己手工清除浏览器缓存或者把浏览器设置为不缓存模式。为了解决资源更新问题,WeX5/BeX5引入了资源版本机制。
资源版本机制
如果通过网络跟踪工具查看,如果访问“http://x5.justep.com:8080/x5/UI2/takeout/index.w”,实际的url将会是 “http://x5.justep.com:8080/x5 /UI2/$v3747_no_$lzh_CN$s$dm/takeout/index.w”。$v3747_no_$lzh_CN$s$d这段就是平台基于版本维护机制自动加的路径。其中$v3747_no_ 是版本号,由系统版本和应用版本构成,具体看下面部分的资源版本号设置;$s是指皮肤,当前没有设置,所以为空;$d用来标识设备,如果是m表示移动设备,pc表示桌面电脑
资源版本号设置
1.%JUSTEP_HOME%\conf\server.xml中的version,每次WeX5/Bex5版本发布会递增,用于维护平台自身的资源版本
2. 自己应用目录下config\application.xml中的version,应用资源改变了,需要维护这个版本
优先原则:如果应用中没有application.xml文件,将使用justep.xml中的设置。对于WeX5而言,简单起见,可以不用application.xml,直接修改%JUSTEP_HOME%\conf\server.xml,这样所有的缓存都会在页面再次访问时重新生成。
注意:修改%JUSTEP_HOME%\conf\server.xml需要重新启动tomcat
.cache生成
1. studio启动tomcat的化,资源版本号会默认为一个guid,并且每次访问.w,.release和.cache都会重新生成,可以理解为.cache失效,也就是没有缓存机制,因为浏览器每次都会下载资源
2. 在外面启动的应用服务(tomcat等),这个是生产环境实际部署的情况,当访问.w时,如果.w有对应的.cache,将直接访问.cache,否则会先生成.cache,这时读取的资源版本号会以设置的为准
项目实施
由上知道了WeX5/Bex5的缓存机制,那比较容易清楚,生产环境如果改了js、css、png和.w等资源,那需要维护资源版本并让.cache新生成,并且一定要在外面运行tomcat,否则由于缓存失效性能将大幅降低。
App本地资源打包和UIServer的关系
把资源打入到App的主要是有两个好处。一个是可以做不联网的Web应用,另外一个是不用下载资源从而提高第一次运行的速度。但如果需要资源自动更新,那就不建议直接把资源打入到App,否则需要通过本地App更新的机制来替换App。
下面举例来说明:
假设App设置的服务地址和首页指向“http://x5.justep.com:8080/x5/UI2/takeout/index.w”
方式一:没有把资源打入到App。这种模式第一次启动App的时候,会把访问到的页面缓存下来,也就是第一次会有多的请求,速度会慢些。第二次启动App,由于资源已经缓存了,那仅仅会发$.ajax这样的请求。假设takeout下的资源改了,如果没有去修改资源版本号,资源将一直不会得到更新;但如果更新了资源版本号并且重新启动tomcat,则App又会进行资源缓存,整个逻辑和浏览器相同。
方式二:假设把takeout打入进了App。第一次启动App,由于本地已经有资源(App会忽略http://x5.justep.com:8080这个服务地址,也就是不管App打包时设置为谁都忽略,先看App中有没有对应的资源,有就直接访问App的资源,否则发请求到UIServer服务段),仅仅会发$.ajax这样的请求,和方式一第一次启动App相同。假设takeout下的资源改了,并且资源版本号已经修改和重新启动了tomcat,本地App也不会进行更新,因为资源已经打入到了App,如果要更新,只能新打一个包含新资源的App进行替换
本文由WeX5君整理,WeX5一款开源免费的html5开发工具,H5 App开发就用WeX5!