手机百度前端工程化之路

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 的渲染方式上，这得减少了多少工作量啊:)

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