手机百度前端工程化之路

   日期:2023-08-13     来源:网络整理    作者:佚名     移动:http://mapp.b2b-1.com/news/486954.html
核心提示:手机百度前端工程化之路梳理可以缓存的静态资源,将文件分为:基础层、通用层和业务逻辑层,缓存的主要是基础层和通用层的代码关于FIS的模块化和静态资源管理,厂子FIS开发团队同学有一篇文章《如何高效地管理网站静态资源》这样模块化的代码经常成了网页的瓶颈,因为模块化存在,造成了更多的外链!

手机百度前端工程化之路

PS:年前参与一个速度优化项目,其中一个优化方式就是减少cookie,减少请求头中的cookie,在慢速网络的速度提升有明显提高!

ok百度代码规范,继续探索……

细粒度缓存

上面的版本号解决方案,是将md5值存在一个cookie,一个md5值32位,即使使用一半也16位,加上cookie的key,怎么也要20个字节以上,我们能不能利用20~100个字节,尽量缓存更多的缓存文件版本号信息呢?

于是我们开始了版本号细化的工作。

梳理可以缓存的静态资源,将文件分为:基础层、通用层和业务逻辑层,缓存的主要是基础层和通用层的代码

指定cookie的value值格式,为了缓存更多的版本号信息,我们不再使用md5做版本号信息,而是规定了下面的格式:jA-V_cB-V,即jA和cB代表缓存的文件名,保持两位(j代表js,c代表css,t代表前端js模板文件,);V代表版本号,保持一位,版本号是36进制的手机百度前端工程化之路,当版本号要超过一位时,从0开始重新记录;按照每周上线一次的情况,cookie时间是一周,36个版本号可以够我们用的

将需要缓存的文件统一放在一个路径下管理

这样做了之后,就是用脚本做缓存文件自动更新版本号了,开始想到的是通过svn hook的方式,当有新的ci时,计算md5值,写入一个版本号config文件。上线时比较线上config和svn中的config,如果不一样就升版本号。但是每次ci都做一次的方式又多此一举、略显蛋疼,最终的方案是在上线脚本中做了一些工作,没有使用svn hook:

对缓存文件路径下的文件做md5hao123,生成一张map

去线上拉取最新的版本号config文件,跟第一步生成的map做比较,不一样则版本升高

多维度缓存

上面的解决方案还是不够完美,总感觉存的东西还是少,所以又做了一个 多维度cookie版本方案 。

我们把cookie看成可以两个维度来存储: 域名 和 路径 。

举例

域名下百度代码规范,有三个产品:新闻、视频和小说,分别放在三个path:

那么新闻、视频和小说,各自有各自的通用代码,比如:通用样式,通用js组件。这样我们在设置cookie的时候指定相应的path,则可以实现多维度缓存

开启缓存

为了实现的缓存,我们增加了类来处理cookie,下发缓存代码,将FIS扩展smarty的 标签进行了修改,增加了属性,即下面代码就可以将页面开启缓存:

1
2
3

<%html localstorage="true"%>
//something~
<%/html%>

模块化

为了解决重复代码的问题,我们开始结合FIS来做模块化,像seajs、这些CMD、AMD框架,是后加载的,即用什么就拉取什么,属于异步模块。js为了实现异步模块,而大量的代码在处理模块依赖关系。在移动上,我们不希望这样,我们希望在后端维护模块的依赖关系,当我require一个模块的时候,会按照依赖关系,依次输出。

我写了一个Bdbox的AMD规范的模块化基础库,然后在FIS编译时,包裹AMD的define外层,并且可以生成一张加载资源表,当使用、和标签内使用require这些smarty扩展标签时,会通过php来动态维护模块依赖。

关于FIS的模块化和静态资源管理,厂子FIS开发团队同学有一篇文章《如何高效地管理网站静态资源》

模块化举例

现在页面要引入 moduleA 模块,而 moduleA 依赖于 moduleB 和 moduleC ,moduleB 和 moduleC 又有自己的依赖模块,如果不先输出 moduleB 和 moduleC 的依赖模块,直接执行 moduleA 的 define 函数会报错的,因为 moduleA 模块依赖的moduleB 和 moduleC 还没有达到 ready 的状态。

有时候甚至更加复杂的依赖关系:

这时候通过《如何高效地管理网站静态资源》文章提到的,FIS编译后会得到的模块依赖关系表:map.json,来做动态模块依赖管理。

通过修改fis编译脚本,将模块依赖文件内容放到map.json中,当使用smarty扩展语法标签的时,php会自动读取map.json,然后将依赖解析出来,提前将moduleA依赖的模块都在其 code>define 之前引入,所以下面的两种代码写法:

1
2
3
4
5

<%require name="common:bdbox/moduleA"%>`
<%*或者*%>
<%script%>
    var moduleA = require('common:bdbox/moduleA');
<%/script%>

实际输出的html代码是:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<script>
    define('common:bdbox/moduleB', function(){
        //A依赖模块B
    });
    define('common:bdbox/moduleC', function(){
        //A依赖模块C
    });
    define('common:bdbox/moduleA', function(){
        //模块A
        var C = require('common:bdbox/moduleC');
        var B = require('common:bdbox/moduleA');
    });
    var moduleA = require('common:bdbox/moduleA');
script>

对于不是模块的js或者css文件,如果使用了,则主动使用来读取内容。

Q & A为啥不用FIS自己的modjs,而自己重复造轮子?为什么命名不是标准的AMD规范?静态资源引入模式

上面所有的关于静态资源管理的解决方案,都是围绕 一刀切 的方案在做优化,而没有利用http本身的cache,实际上:在3G、wifi甚至4G的环境中,http cache的方案,在易用性和兼容性上面要比+inline内嵌静态资源的方式要好。

而且从手机百度真实的用户网络类型统计来说,3G+wifi已经达到75%以上,如果能结合wise团队提供的ip测速库和公司的CDN服务,会有一种更好的解决方案,进一步来说,如果可以根据网络类型和用户真实网络速度,自由选择在+inline和CDN方案之间切换就更好了。于是我们做到了!一种新的渲染方式出现了:CDN+combo。

再说这种渲染方式之前,先梳理下上面提到的一些名词:

好,继续那模块化说的moduleA模块依赖moduleB和moduleC来说,经过 tag模式 ,会输出下面的html:

1
2
3
4
5
6

<script src="http://xxx/bdbox/moduleC.js">script>
<script src="http://xxx/bdbox/moduleB.js">script>
<script src="http://xxx/bdbox/moduleA.js">script>
<script>
    var moduleA = require('common:bdbox/moduleA');
script>

这样模块化的代码经常成了网页的瓶颈,因为模块化存在,造成了更多的外链!下面我们需要一个CDN+combo服务,来合并http请求。

因为smarty的扩展语法,结合之前生成的map.json,我们实现了模块化依赖关系后端自动处理依赖,然后选择最合理的输出顺序。这时候我们不是直接输出对应的tag或者inline内容,而是将它合并到一个combo服务对应的URL,统一输出!

1

<script src="cdn-combo-server?file=bdbox/moduleC,bdbox/moduleB,bdbox/moduleA">script>

渲染模式智能切换

如何根据用户网络环境智能切换渲染方式呢?我继续改造了smarty的标签,添加属性,通过wise测速库和手机百度客户端传给我们的网络类型,选择不同的方式:

1
2
3
4
5
6
7
8
9

<%if ($slow_network || $nettype=='2G') && $support_localstorage %>
    <%html rendermode="inline" localstorage="true"%>
<%elseif $fast_network%>
    <%html rendermode="combo"%>
<%else%>
    <%html rendermode="inline"%>
<%/if%>
//……
<%/html%>

拆分父子模板

上面的方案,我们如果逐个页面去写代码,改方案,想想就蛋疼,所以我们拆分了父子模板,从框架本身来分,一个module对应一个父模板,其他子模板使用smarty的extends标签实现继承关系。

经过模板拆分后,子模板专注于做业务,父模板专注于做解决方案,而且也方便了抽样和统计。

其他总结

试想一下,如果2015年,用户都用上了4G,那么我们需要将父模板的改成 ="combo" 就可以全部切到 CDN+combo 的渲染方式上,这得减少了多少工作量啊:)

【本文来源于互联网转载,如侵犯您的权益或不适传播,请邮件通知我们删除】

免责声明:手机百度前端工程化之路来源于互联网,如有侵权请通知我们删除! (留言)
 
标签: 百度代码规范
 
更多>同类行业资讯
0相关评论

图文信息
最新发布
行业资讯
最受欢迎
网站首页  |  网站地图  |  RSS订阅  |  违规举报  |  B2B-1.COM