手機騰訊網js模塊管理框架，MT2.0發布
關于 MT
什么是MT
MT是手機騰訊網前端團隊開發維護的一個專注于移動端的js模塊管理框架。
github:https://github.com/mtjs/mt
為了方便大家我們還在http://git.oschina.net上放了一個鏡像：
http://git.oschina.net/luyongfugx/mt
為什么使用MT
- 無更新不下載
- 簡單友好的模塊定義規范
- 簡單易用的打包管理工具
- 強大的js增量更新代理服務
MT2.0新增特性
- 本地存儲異常回調
- 統計回調
- combo支持
- 新增LCS增量算法
本地存儲異常，統計回調
設置回調
通過設施g_config的storeInc對象的statFunc,storeExFunc兩個函數，可以設置統計和本地存儲異常回調 , statFunc在請求每個js的時候觸發,便于統計每個js的請求情況，storeExFunc在寫本地存儲異常回調， 將腳本內容寫入本地存儲出現異常的時候調用，用來提供給業務清理本地存儲。
storeInc:{
//統計回調，統計腳本請求情況,jsUrl是js地址，
//mode是請求模式，full:表示全量請求，
//inc表示增量請求，local表示從本地存儲讀取
'statFunc':function(jsUrl,mode){
console.log('get '+jsUrl+' from '+mode);
},
//寫本地存儲異常回調，將腳本內容寫入本地存儲
//出現異常的時候調用，用來提供給業務清理本地存儲
//，storekey表示寫如的key
'storeExFunc':function(storeKey){
console.log('set store item '+storeKey+' exception');
},
'store': true,
'inc': true,
'proxy':true,
'debug': false
},
combo支持
冷combo
冷combo就是在打包混淆的時候把多個不同的模塊打包進同一個js,前臺下載的時候直接下載這個js 這個MT1.0已經支持，打包配置如下：
{
'./release/{pv}/base-{fv}.js': {
files: ['./js/init.js','./js/util.js']
},
'./release/{pv}/page/p1-{fv}.js': {
files: ['./js/page/p1.js']
},
'./release/{pv}/page/p2-{fv}.js': {
files: ['./js/page/p2.js']
},
'./release/{pv}/page/p3-{fv}.js': {
files: ['./js/page/p3.js']
}
}
可以看到我們的init,util模塊被打到base.js里，達到冷combo的目的
熱combo，半熱combo
半熱combo是相對冷combo來說的，除了走打包實現冷combo以外，我們還支持通過前臺配置來實現半熱combo或熱combo
combo:{
//是否啟用combo cb:true,
//哪些模塊的js走半熱combo一塊下載 //，這里數組的每個項是要一起下載的模塊 conf:['init,util','p1,p2,p3']
}
上面的代碼，我們設置了combo的cb為true,說明走combo. conf的配置則設置了哪些模塊是要走combo一起下載的， 即使打包腳本沒有把他們打在一起。 為了看效果，我們先把cb設為false，conf設置為空數組,表示不走combo：
combo:{
//是否啟用combo cb:flase,
//哪些模塊的js走半熱combo一塊下載 //，這里數組的每個項是要一起下載的模塊 conf:[]
}
我們看下網絡請求:
可以看到base.js,p1.js,p2.js,p3.js是分開下載的，說明沒有走combo
然后設置了combo的cb為true,說明走combo. 我們看下網絡請求：
可以看到base.js,p1.js是分開下載的，而p2.js,p3.js是一起下載的，這是因為mt2.0自己分析了依賴，把某個模塊共同依賴一起下載了，這個例子里面p1依賴了p2,p3兩個模塊 所以p2,p3被一起下載了，這就是熱combo!
這時候我們想,我想讓p1,p2,p3一次就下載了，怎么弄？很簡單，我們只要設置combo.conf為如下
combo:{
//是否啟用combo cb:true,
//哪些模塊的js走半熱combo一塊下載 //，這里數組的每個項是要一起下載的模塊 conf:['init,util','p1,p2,p3']
}
我們看下網絡請求：
ok，p1,p2,p3一次就下載了！！，這就是半熱combo,需要配置一下conf.
新增基于lcs算法的增量更新
MT1.0的增量更新是基于chunk算法來實現的，精確度是到塊級別的。后來很多朋友給我意見，說其實可以做得更加精確一些，精確到字符級別。 于是我用lcs算法實現了精確到字符級別的設計，最后這個demo也可以看作是整個MT2.0的使用方法
首先到我們的github:https://github.com/mtjs/mt下載代碼，然后看mt2.0文件夾下的demo目錄，里面有個test.html，可以看到總配置代碼
var g_config = {
jsmap:{
'init': 'base.js',
'util': 'base.js',
'p1': 'page/p1.js',
'p2': 'page/p2.js',
'p3': 'page/p3.js'
},
storeInc:{
//統計回調，統計腳本請求情況,jsUrl是js地址，mode是請求模式，full:表示全量請求，inc表示增量請求，local表示從本地存儲讀取
'statFunc':function(jsUrl,mode){
console.log('get '+jsUrl+' from '+mode);
},
//寫本地存儲異常回調，將腳本內容寫入本地存儲出現異常的時候調用，用來提供給業務清理本地存儲，storekey表示寫如的key
'storeExFunc':function(storeKey){
console.log('set store item '+storeKey+' exception') ;
},
'store': true,
'inc': true,
'proxy':true,
'debug': false
},
//是否走combo,同時支持conf指定哪幾個js是合并下載的
combo:{cb:true,conf:["init,util","p1,p2,p3"]},
testEnv: false,
staticPath: '/release',
serverDomain: 'http://localhost:6600',
buildType: 'project',
ver: '2014053000002'
};
在2014053000002版本，我們的p2代碼如下：
define('p2', [], function () {
console.log('p2 ok!');
document.write('p2 ok!<br>');
});
}
本地打包
我們運行demo目錄下的build.sh ,其實是執行命令
node ../js/mtbuild.js test.html build.conf lcs第三個參數說明走lcs增量更新算法，你也可以設置成chunk走老算法
啟動增量服務
到js目錄下執行命令
node storeincServer.js lcs ../demo第2個參數說明走lcs增量更新算法，你也可以設置成chunk走老算法，第三個參數是根目錄，這里設置成../demo
效果演示
打開chrome(必須支持localstorage),輸入地址:http://localhost:6600/test.html,可以看到請求的是全量的js
本地存儲里的內容是2014053000002版本的：
接著我們修改p2.js代碼，加上"lcs"這3個字 ：
define('p2', [], function () {
console.log('p2 ok!');
document.write('p2 ok lcs!<br>');
});
然后重新運行命令
node ../js/mtbuild.js test.html build.conf lcs這時候生成2014053000003版本代碼，打開chrome(必須支持localstorage), 輸入地址:http://localhost:6600/test.html,這時候可以看到請求的內容是增量的,并且精確到了字符級別:
我們來看下同樣是這個修改，如果我們走chunk算法，會是什么樣子。 我們需要重新走一遍上邊的流程，但是把build.sh命令的lcs參數改成chunk,啟動storeincServer時的lcs也改成chunk, 這里就不羅嗦步驟了，我們直接看看走chunk是的網絡請求：
發現相對lcs算法，chunk的精確度是比較差的，所以推薦使用lcs算法
mt1.0介紹文檔
mt1.0的同學請看mt1.0