WeX5/BeX5 UIServer的缓存机制
页面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进行替换