系统静态资源加载方法及装置与流程
本发明涉及到计算机技术领域，特别涉及到系统静态资源加载方法及装置。
背景技术：
随着互联网开发和迭代速度越来越快，互联网网站也变的越来越庞大，存在大量的静态资源，静态资源之间的关系变得错综复杂，给开发工程师带来了很多麻烦。目前，静态的资源的处理主要包括：
1、SeaJS：SeaJS遵循CMD规范，是一个专注于Web浏览器的模块加载器，采用懒执行的方式实现。其缺点在于：1>打包spm非常难，新手需要不少的学习成本；2>无法对静态资源进行更新控制；3>无法快速实现版本迭代发布与回滚。
2、RequireJS：RequireJS遵循AMD规范，是一个支持浏览器与Node等环境的模块加载器，采用预执行的方式加载模块。其缺点在于：1>打乱了用户的文件加载顺序，可能产生一些异常情况；2>无法对静态资源进行更新控制；3>无法快速实现版本迭代发布与回滚。
综上，现有的静态资源处理方式可以对web静态资源加载起到一定的优化，但是静态资源的优化程度低。
技术实现要素：
本发明实施例提供一种系统静态资源加载方法及装置，旨在解决现有的静态资源处理方式可以对web静态资源加载起到一定的优化，但是静态资源的优化程度低的问题。
为实现上述目的，本发明实施例提出一种系统静态资源加载方法，包括：
在接收到页面访问请求时，获取提前编译后的静态资源数据；
从所获取的静态资源数据中提取所述访问数据对应的静态资源；
加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。
为了实现上述目的，本发明实施例还进一步提出一种系统静态资源加载装置，包括：
获取模块，用于在接收到页面访问请求时，获取提前编译后的静态资源数据；
提取模块，用于从所获取的静态资源数据中提取所述访问数据对应的静态资源；
加载模块，用于加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。
本发明通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
附图说明
图1为本发明实施例系统静态资源加载装置所涉及的硬件架构示意图；
图2为本发明系统静态资源加载方法的第一实施例的流程示意图；
图3为本发明提前对静态资源进行编译处理一实施例的细化流程示意图；
图4为本发明从所获取的静态资源数据中提取所述访问数据对应的静态资源一实施例的细化流程示意图；
图5为本发明系统静态资源加载方法的第二实施例的流程示意图；
图6为本发明系统静态资源加载方法的第三实施例的流程示意图；
图7为本发明系统静态资源加载方法的第四实施例的流程示意图；
图8为本发明系统静态资源加载装置的第一实施例的功能模块示意图；
图9为本发明系统静态资源加载装置的第二实施例的功能模块示意图；
图10为图8中提取模块一实施例的细化功能模块示意图；
图11为本发明系统静态资源加载装置的第三实施例的功能模块示意图；
图12为本发明系统静态资源加载装置的第四实施例的功能模块示意图；
图13为本发明系统静态资源加载装置的第五实施例的功能模块示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例的主要解决方案是：在接收到页面访问请求时，获取提前编译后的静态资源数据；根据所确定的静态资源数据得到静态资源的部署路径和依赖关系；根据所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取所述访问数据对应的静态资源；加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
由于现有的静态资源处理方式可以对web静态资源加载起到一定的优化，但是静态资源的优化程度低的问题。
本发明实施例架构一系统静态资源加载装置，该系统静态资源加载装置通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
其中，本实施例系统静态资源加载装置可以承载于PC端，也可以承载于手机、平板电脑等可以使用浏览器等网络应用的电子终端。该系统静态资源加载装置所涉及的硬件架构可以如图1所示。
图1示出了本发明实施例系统静态资源加载装置所涉及的硬件架构。如图1所示，所述系统静态资源加载装置所涉及的硬件包括：处理器301，例如CPU，网络接口304，用户接口303，存储器305，通信总线302。其中，通信总线302用于实现该信息推送平台中各组成部件之间的连接通信。用户接口303可以包括显示屏(Display)、键盘(Keyboard)、鼠标等组件，用于接收用户输入的信息，并将接收的信息发送至处理器305进行处理。显示屏可以为LCD显示屏、LED显示屏，也可以为触摸屏，用于显示系统静态资源加载装置需要显示的 数据，例如网页访问数据、系统静态资源加载等操作界面。可选用户接口303还可以包括标准的有线接口、无线接口。网络接口304可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器305可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器305可选的还可以是独立于前述处理器301的存储装置。如图1所示，作为一种计算机存储介质的存储器305中可以包括操作系统、网络通信模块、用户接口模块以及系统静态资源加载程序。
在图1所示的系统静态资源加载装置所涉及的硬件中，网络接口304主要用于连接应用平台，与应用平台进行数据通信；用户接口303主要用于连接客户端，与客户端进行数据通信，接收客户端输入的信息和指令；而处理器301可以用于调用存储器305中存储的系统静态资源加载程序，并执行以下操作：
在接收到页面访问请求时，获取提前编译后的静态资源数据；
从所获取的静态资源数据中提取所述访问数据对应的静态资源；
加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统静态资源加载程序可以执行以下操作：
对静态资源进行编译处理；
在编译过程中，建立一张静态资源关系表，记录每个静态资源的部署路径及依赖关系；
在编译完成后，生成编译后的静态资源数据。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统静态资源加载程序可以执行以下操作：
判断所述访问请求对应的页面访问是否在后端运行；
在后端运行时，确定所述页面访问对应组件的使用信息；
根据所述组件的使用信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中调度对应的静态资源，为前端返回页面渲染所需要的静态资源。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统 静态资源加载程序可以执行以下操作：
在前端运行时，确定所述访问请求对应的交互行为信息；
根据所述交互行为信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取对应的静态资源，以完成前端页面的访问。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统静态资源加载程序可以执行以下操作：
获取静态资源的使用信息；
根据所述静态资源的使用信息提取相关联的静态资源；
自动合并相关联的静态资源。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统静态资源加载程序可以执行以下操作：
获取静态资源对应文件内容的hash值；
根据所述hash值控制静态资源的版本更新。
进一步地，在一个实施例中，处理器301调用存储器305中存储的系统静态资源加载程序可以执行以下操作：
在静态资源运行过程中，确定运行过程静态资源对应的配置信息；
接收所述配置信息的更改指令，根据所述更改指令更改所述配置信息以更改静态资源的访问权控制。
本实施例根据上述方案，通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
基于上述硬件架构，提出本发明系统静态资源加载方法实施例。
如图2所示，提出本发明一种系统静态资源加载方法的第一实施例，所述系统静态资源加载方法包括：
步骤S10，在接收到页面访问请求时，获取提前编译后的静态资源数据；
在本实施例中，提前对静态资源进行编译处理。参考图3，所述提前对静态资源进行编译处理的过程包括：
步骤S01，对静态资源进行编译处理；
步骤S02，在编译过程中，建立一张静态资源关系表，记录每个静态资源的部署路径及依赖关系；
步骤S03，在编译完成后，生成编译后的静态资源数据。
对静态资源进行编译处理，包括多静态资源进行预处理，url处理(例如，添加md5戳)、添加CDN前缀，优化(压缩、合并等)，生成Sourcemap等。在编译过程中，系统会扫描静态资源，建立一张静态资源关系表，记录每个静态资源的部署路径及依赖关系等信息，通过对静态资源进行编译处理，得到编译后的静态资源数据。
具体的，本发明实施例为网站工程师提供了声明依赖关系的语法和规则，在编译阶段会扫描静态资源，建立一张静态资源关系表，记录每个静态资源的部署路径以及依赖关系等信息。依赖关系声明过程包括如下几个实例：
1、在html中声明依赖：在项目的index.html里使用注释声明依赖关系：
<--
@require demo.js
Qrequire”demo.css”
-->
在SourceMap中则可以看到；
{
”demo.css”:{
”uri”:”/static/css/demo_7defa41.css”，
”type”:”css”
}，
”demo.js”:{
”uri”:”/static/css/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”]
}，
”index.html”:{
”uri”:”/index.html”，
”type”:”html”，
”deps”:[”demo.js”，”demo.css”]
}
}，
”pkg”:{}
}
2、在js中声明依赖：支持js文件中的require函数，或者主时钟的@require字段标记的依赖关系，这些分析处理对html的script标签内容同样有效。
//demo.js
/**
*@require demo.css
*@require list.js
*/
var$＝require(’jquery’)；
在SourceMap中则可以看到：
{
”res”:{
…
”demo.js”:{
”uti”:”/static/js/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”，”list.js”，”jquery”]
}，
…
}
”pkg”:{}
}
3、在css中声明依赖：支持css文件，注释中的@require字段标记的依赖关系，这些分析处理对html的style标签内容同样有效。
//demo.js
/**
*@require demo.css
*@require list.js
*/
var$＝require(’jquery’)；
在SourceMap中则可以看到：
{
”res”:{
…
”demo.js”:{
”uti”:”/static/js/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”，”list.js”，”jquery”]
}，
…
}
”pkg”:{}
}
接收页面访问请求，在接收到页面访问请求时，获取提前编译后的静态资源数据。所述页面访问请求优选为web页面访问请求，在本发明其他实施例中也还可以是其他类型的页面访问请求，在此不再一一赘述。
步骤S20，从所获取的静态资源数据中提取所述访问数据对应的静态资源；
从所述提前编译后的静态资源所数据中，提取到静态资源的部署路径和依赖关系，即得到静态资源的调度逻辑。在提取到静态资源的部署路径和依赖关系后，根据所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取所述访问数据对应的静态资源。
优选地，参考图4，所述从所获取的静态资源数据中提取所述访问数据对应的静态资源的过程可以包括：
步骤S21，根据所确定的静态资源数据得到静态的部署路径和依赖关系；
步骤S22，根据所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取所述访问数据对应的静态资源。
具体的，判断所述访问请求对应的页面访问是否在后端运行，在后端运 行时，确定所述页面访问对应组件的使用信息，根据所述组件的使用信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中调度对应的静态资源，为前端返回页面渲染所需要的静态资源；在前端运行时，确定所述访问请求对应的交互行为信息；根据所述交互行为信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取对应的静态资源，以完成前端页面的访问。
步骤S30，加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。
在本实施例中，在提取到所述访问请求对应的静态资源后，加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。例如，页面访问在后端运行时，根据组件使用情况来调度静态资源，为前端返回页面渲染需要的资源，通过调度静态资源来实现页面数据的访问。通过对网页的JS、CSS等静态资源进行整合，可以帮助工程师快速的开发高性能的网站，加快开发效率，提高系统稳定性。
在系统接管了项目中的静态资源后，可以知道静态资源的运行情况以及依赖关系，然后可以做到自动为页面按需加载静态资源，如：
Sidebar.tpl中的内容如下：
<！—
@require”common:ui/dialog/dialog/css”
-->
<a id＝”btn-navbar”class＝”btn-navbar>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
</a>
{script}
var sidebar＝require(”common:ui/dialog/dialog/js”)；
sidebar.run()；
{/script}
{script}
$(’a.btn-navbar’).click(function(){
Require/async(’common:ui/dialog/dialog.async.js’，function(dialog){dialog.run()；
})；
})；
{/script}
对项目编译后，自动化工具会分析依赖关系，并生成SourceMap，如下：
”common:widget/sidebar/sidebar.tpl”{
”uri”:”common/widget/sidebar/sidebar.tpl”，
”type”:”tpl”，
”extras”:{
”async”:[
”common:ui/dialog.async.js”
]
}，
”deps”:[
”common:ui/dialog/dialog.js”，
”common:ui/dialog/dialog.css”
]
}
在sidebar被调用后，系统通过查询SourceMap可以得知，当前sidebar同步依赖sidebar.js、sidebar.css，异步依赖sdebar.async.js，在要输出的html前面，生成静态资源外链，我们得到最终的html如下：
<link rel＝”stylesheet”href＝”/static/ui/dialog/dialog_7defa41.css”>
<a id＝”btn-navbar＝”btn-navbar”>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
</a>
<script type＝”text/javascript”
Src＝”/static/common/ui/dialog/$12cd4.js”></script>
<script type＝”text/javascript”>
require.resourceMap({
”res”:{
”common:ui/dialog/dialog.asyunc.js”:{
”url”:/satic/common/ui/dialog/dialog.async_449e169.js”
}
}
})；
</script>
<script rype＝”text/javascript”>
var sidebar＝require(”common:ui/dialog/dialog.js”)；
sidebar.run()；
$(’a.btn-navbar’).click(funcition(){
Require.async(’common:ui/dialog/dialog/async.js’，
function(dialog){dialog.run()；
})；
})；
</script>
如上可见，后端模块化框架将同步的script url统一生成到页面底部，将css url统一生成在head中，对于异步注册reSourceMap代码，框架会通过{script}标签收集到页面所有script，统一管理并按顺序输出script到相应位置。
本实施例通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
进一步地，基于上述系统静态资源加载方法的第一实施例，提出本发明的第二实施例。如图5所示，所述方法还可以包括：
步骤S40，获取静态资源的使用信息；
步骤S50，根据所述静态资源的使用信息提取相关联的静态资源；
步骤S60，自动合并相关联的静态资源。
在本实施例中，获取静态资源的使用信息；根据所述静态资源的使用信息提取相关联的静态资源；自动合并相关联的静态资源。具体的过程为：根据产品线上静态资源使用的数据，自动完成静态资源合并工作，对工程师完全透明，解决了手工维护的未及时排除废弃资源、不可持续、成本高等问题。在本发明其他实施例中也还可以是：根据静态资源的使用信息，自动排除一些废弃的静态资源数据，例如，排除已经过期的静态资源或许久(1年或半年等)未使用的静态资源数据。
本实施例通过获取静态资源的使用信息，将相关联的静态资源自动合并，提高静态资源管理的合理性和有效性。
进一步地，基于上述系统静态资源加载方法的第一实施例，提出本发明的第三实施例。如图6所示，所述方法还可以包括：
步骤S70，获取静态资源对应文件内容的hash值；
步骤S80，根据所述hash值控制静态资源的版本更新。
在本实施例中，系统采用基于文件内容的hash值来控制静态资源的版本更新，例如如下所示：
<script type＝”text/javascript”src＝”a_8244e91.js”></script>
其中_8244e91这串字符是根据a.js的文件内容进行hash运算得到的，只有文件内容发生变化了才会有更改，这样做的好处有：
线上的a.js不是同名文件覆盖，而是文件名+hash的冗余，所以可以先线上静态资源，在上线html页面，不存在间隙的问题；遇到问题回滚版本的时候，无需回滚a.js，只需回滚页面即可。由于静态资源版本号是文件内容的hash，因此所有静态资源可以开启永久强缓存，只有更新了内容的文件才会缓存失效，缓存利用率大增。修改静态资源后会在线上产生新的文件，一个文件对应一个版本，因此不会受到构造CDN缓存形式的攻击。系统会在编译compile过程中识别文件中的定位标记(url)，计算对应文件的hash，并自动替换为’文件名+hash’，无需工程师手动修改。
进一步地，基于上述系统静态资源加载方法的第一实施例，提出本发明 的第四实施例。如图7所示，所述方法还可以包括：
步骤S90，在静态资源运行过程中，确定运行过程静态资源对应的配置信息；
步骤S100，接收所述配置信息的更改指令，根据所述更改指令更改所述配置信息以更改静态资源的访问权控制。
在本实施例中，系统可以对静态资源做进一步控制以达到分级发布的效果，主要包括以下两块核心功能，feature flags，用来控制feature对应的静态资源是否加载；feature flippers，可以灵活控制feature，不仅仅是on或off，可以做到类似’3％用户可以访问此功能、对内部所有员工开放类似的效果。通过以上的控制我们可以轻松做到通过网站发布一个新功能让这个功能只对部分用户可访问，当功能完善后对所有用户开放，如果功能出现问题直接一键回滚即可，在项目中的类似代码如下：
{if$config.some eq’Fred’}
Do something new and amazing here.
{elseif$config.some eq’Wilma’}
Do the current boring stuff.
{else}
Whatever you are.
系统会根据配置在运行时对$config.some进行干预，实现对静态资源的访问控制权的控制，通过运行时的配置(feature flag)来控制静态资源，还可以支持主干开发的方式，来达到更快的迭代速度。以上各个实施例中涉及的代码仅仅是一个实施例的举例，在其他实施例中，其他代码或者实现方式不在此一一举例，但也包括在本发明实施方式内。
对应地，提出本发明系统静态资源加载装置的第一实施例。参考图8，所述系统静态资源加载装置包括获取模块10、提取模块20及加载模块30。
所述获取模块10，用于在接收到页面访问请求时，获取提前编译后的静态资源数据；
在本实施例中，提前对静态资源进行编译处理。参考图9，所述装置还包括：
编译模块40，用于对静态资源进行编译处理；
处理模块50，用于在编译过程中，建立一张静态资源关系表，记录每个静态资源的部署路径及依赖关系；
生成模块60，用于在编译完成后，生成编译后的静态资源数据。
对静态资源进行编译处理，包括多静态资源进行预处理，url处理(例如，添加md5戳)、添加CDN前缀，优化(压缩、合并等)，生成Sourcemap等。在编译过程中，系统会扫描静态资源，建立一张静态资源关系表，记录每个静态资源的部署路径及依赖关系等信息，通过对静态资源进行编译处理，得到编译后的静态资源数据。
具体的，本发明实施例为网站工程师提供了声明依赖关系的语法和规则，在编译阶段会扫描静态资源，建立一张静态资源关系表，记录每个静态资源的部署路径以及依赖关系等信息。依赖关系声明过程包括如下几个实例：
1、在html中声明依赖：在项目的index.html里使用注释声明依赖关系：
<--
@require demo.js
Qrequire”demo.css”
-->
在SourceMap中则可以看到；
{
”demo.css”:{
”uri”:”/static/css/demo_7defa41.css”，
”type”:”css”
}，
”demo.js”:{
”uri”:”/static/css/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”]
}，
”index.html”:{
”uri”:”/index.html”，
”type”:”html”，
”deps”:[”demo.js”，”demo.css”]
}
}，
”pkg”:{}
}
2、在js中声明依赖：支持js文件中的require函数，或者主时钟的@require字段标记的依赖关系，这些分析处理对html的script标签内容同样有效。
//demo.js
/**
*@require demo.css
*@require list.js
*/
var$＝require(’jquery’)；
在SourceMap中则可以看到：
{
”res”:{
…
”demo.js”:{
”uti”:”/static/js/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”，”list.js”，”jquery”]
}，
…
}
”pkg”:{}
}
3、在css中声明依赖：支持css文件，注释中的@require字段标记的依赖关系，这些分析处理对html的style标签内容同样有效。
//demo.js
/**
*@require demo.css
*@require list.js
*/
var$＝require(’jquery’)；
在SourceMap中则可以看到：
{
”res”:{
…
”demo.js”:{
”uti”:”/static/js/demo_33c5143.js”，
”type”:”js”，
”deps”:[”demo.css”，”list.js”，”jquery”]
}，
…
}
”pkg”:{}
}
接收页面访问请求，在接收到页面访问请求时，获取提前编译后的静态资源数据。所述页面访问请求优选为web页面访问请求，在本发明其他实施例中也还可以是其他类型的页面访问请求，在此不再一一赘述。
所述提取模块20，用于从所获取的静态资源数据中提取所述访问数据对应的静态资源；
从所述提前编译后的静态资源所数据中，提取到静态资源的部署路径和依赖关系，即得到静态资源的调度逻辑。在提取到静态资源的部署路径和依赖关系后，根据所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取所述访问数据对应的静态资源。优选地，根据所确定的静态资源数据得到静态的部署路径和依赖关系；根据所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取所述访问数据对应的静态资源。
具体的，参考图10，所述提取模块20包括：判断单元21，用于判断所 述访问请求对应的页面访问是否在后端运行；确定单元22，用于在后端运行时，确定所述页面访问对应组件的使用信息；提取单元23，用于根据所述组件的使用信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中调度对应的静态资源，为前端返回页面渲染所需要的静态资源；在前端运行时，确定所述访问请求对应的交互行为信息；根据所述交互行为信息及所述静态资源的部署路径和依赖关系从所获取的静态资源数据中提取对应的静态资源，以完成前端页面的访问。
所述加载模块30，用于加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。
在本实施例中，在提取到所述访问请求对应的静态资源后，加载所提取的静态资源，以通过所提取的静态资源完成所述访问请求对应页面数据的访问。例如，页面访问在后端运行时，根据组件使用情况来调度静态资源，为前端返回页面渲染需要的资源，通过调度静态资源来实现页面数据的访问。通过对网页的JS、CSS等静态资源进行整合，可以帮助工程师快速的开发高性能的网站，加快开发效率，提高系统稳定性。
在系统接管了项目中的静态资源后，可以知道静态资源的运行情况以及依赖关系，然后可以做到自动为页面按需加载静态资源，如：
Sidebar.tpl中的内容如下：
<！—
@require”common:ui/dialog/dialog/css”
-->
<a id＝”btn-navbar”class＝”btn-navbar>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
</a>
{script}
var sidebar＝require(”common:ui/dialog/dialog/js”)；
sidebar.run()；
{/script}
{script}
$(’a.btn-navbar’).click(function(){
Require/async(’common:ui/dialog/dialog.async.js’，function(dialog){dialog.run()；
})；
})；
{/script}
对项目编译后，自动化工具会分析依赖关系，并生成SourceMap，如下：
”common:widget/sidebar/sidebar.tpl”{
”uri”:”common/widget/sidebar/sidebar.tpl”，
”type”:”tpl”，
”extras”:{
”async”:[
”common:ui/dialog.async.js”
]
}，
”deps”:[
”common:ui/dialog/dialog.js”，
”common:ui/dialog/dialog.css”
]
}
在sidebar被调用后，系统通过查询SourceMap可以得知，当前sidebar同步依赖sidebar.js、sidebar.css，异步依赖sdebar.async.js，在要输出的html前面，生成静态资源外链，我们得到最终的html如下：
<link rel＝”stylesheet”href＝”/static/ui/dialog/dialog_7defa41.css”>
<a id＝”btn-navbar＝”btn-navbar”>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
<span class＝”icon-bar”></span>
</a>
<script type＝”text/javascript”
Src＝”/static/common/ui/dialog/$12cd4.js”></script>
<script type＝”text/javascript”>
require.resourceMap({
”res”:{
”common:ui/dialog/dialog.asyunc.js”:{
”url”:/satic/common/ui/dialog/dialog.async_449e169.js”
}
}
})；
</script>
<script rype＝”text/javascript”>
var sidebar＝require(”common:ui/dialog/dialog.js”)；
sidebar.run()；
$(’a.btn-navbar’).click(funcition(){
Require.async(’common:ui/dialog/dialog/async.js’，
function(dialog){dialog.run()；
})；
})；
</script>
如上可见，后端模块化框架将同步的script url统一生成到页面底部，将css url统一生成在head中，对于异步注册reSourceMap代码，框架会通过{script}标签收集到页面所有script，统一管理并按顺序输出script到相应位置。
本实施例通过提前预编译整个静态资源的依赖关系，避免现有的静态资源处理方式优化程度低的问题。提高静态资源的优化程度。
进一步地，基于上述系统静态资源加载装置的第二实施例，提出本发明装置的第三实施例。如图11所示，所述装置还可以包括合并模块70，
所述获取模块10，还用于获取静态资源的使用信息；
所述提取单元23，还用于根据所述静态资源的使用信息提取相关联的静态资源；
所述合并模块70，用于自动合并相关联的静态资源。
在本实施例中，获取静态资源的使用信息；根据所述静态资源的使用信息提取相关联的静态资源；自动合并相关联的静态资源。具体的过程为：根据产品线上静态资源使用的数据，自动完成静态资源合并工作，对工程师完全透明，解决了手工维护的未及时排除废弃资源、不可持续、成本高等问题。在本发明其他实施例中也还可以是：根据静态资源的使用信息，自动排除一些废弃的静态资源数据，例如，排除已经过期的静态资源或许久(1年或半年等)未使用的静态资源数据。
本实施例通过获取静态资源的使用信息，将相关联的静态资源自动合并，提高静态资源管理的合理性和有效性。
进一步地，基于上述系统静态资源加载装置的第三实施例，提出本发明装置的第四实施例。如图12所示，所述装置还可以包括：控制模块80，
所述获取模块10，还用于获取静态资源对应文件内容的hash值；
所述控制80，用于根据所述hash值控制静态资源的版本更新。
在本实施例中，系统采用基于文件内容的hash值来控制静态资源的版本更新，例如如下所示：
<script type＝”text/javascript”src＝”a_8244e91.js”></script>
其中_8244e91这串字符是根据a.js的文件内容进行hash运算得到的，只有文件内容发生变化了才会有更改，这样做的好处有：
线上的a.js不是同名文件覆盖，而是文件名+hash的冗余，所以可以先线上静态资源，在上线html页面，不存在间隙的问题；遇到问题回滚版本的时候，无需回滚a.js，只需回滚页面即可。由于静态资源版本号是文件内容的hash，因此所有静态资源可以开启永久强缓存，只有更新了内容的文件才会缓存失效，缓存利用率大增。修改静态资源后会在线上产生新的文件，一个文件对应一个版本，因此不会受到构造CDN缓存形式的攻击。系统会在编译compile过程中识别文件中的定位标记(url)，计算对应文件的hash，并自动替换为’文件名+hash’，无需工程师手动修改。
进一步地，基于上述系统静态资源加载装置的第四实施例，提出本发明装置的第五实施例。如图13所示，所述装置还可以包括：接收模块90和更改模块100，
所述确定单元22，还用于在静态资源运行过程中，确定运行过程静态资源对应的配置信息；
所述接收模块90，用于接收所述配置信息的更改指令；
所述更改模块100，用于根据所述更改指令更改所述配置信息以更改静态资源的访问权控制。
在本实施例中，系统可以对静态资源做进一步控制以达到分级发布的效果，主要包括以下两块核心功能，feature flags，用来控制feature对应的静态资源是否加载；feature flippers，可以灵活控制feature，不仅仅是on或off，可以做到类似’3％用户可以访问此功能、对内部所有员工开放类似的效果。通过以上的控制我们可以轻松做到通过网站发布一个新功能让这个功能只对部分用户可访问，当功能完善后对所有用户开放，如果功能出现问题直接一键回滚即可，在项目中的类似代码如下：
{if$config.some eq’Fred’}
Do something new and amazing here.
{elseif$config.some eq’Wilma’}
Do the current boring stuff.
{else}
Whatever you are.
系统会根据配置在运行时对$config.some进行干预，实现对静态资源的访问控制权的控制，通过运行时的配置(feature flag)来控制静态资源，还可以支持主干开发的方式，来达到更快的迭代速度。以上各个实施例中涉及的代码仅仅是一个实施例的举例，在其他实施例中，其他代码或者实现方式不在此一一举例，但也包括在本发明实施方式内。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或 者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
- 还没有人留言评论。精彩留言会获得点赞！