詳解JavaScript之分解任務(wù)
下面來看，JavaScript中分解任務(wù)，供參考。
我們通常將一個任務(wù)分解成一系列子任務(wù)。如果一個函數(shù)運行時間太長，那么查看它是否可以分解成一系列能夠短時間完成的較小的函數(shù)?？蓪⒁恍写a簡單地看作一個原子任務(wù)，多行代碼組合在一起構(gòu)成一個獨立任務(wù)。某些函數(shù)可基于函數(shù)調(diào)用進行拆分。例如：
- function saveDocument(id){
- openDocument(id)
- writeText(id);
- closeDocument(id);
- updateUI(id);
- }
如果函數(shù)運行時間太長，它可以拆分成一系列更小的步驟，把獨立方法放在定時器中調(diào)用。你可以將每個函數(shù)都放入一個數(shù)組，然后使用前一節(jié)中提到的數(shù)組處理模式：
- function saveDocument(id){
- var tasks = [openDocument, writeText, closeDocument, updateUI];
- setTimeout(function(){
- var task = tasks.shift();
- task(id);
- if (tasks.length > 0){
- setTimeout(arguments.callee, 25);
- }
- }, 25);
- }
這個版本將每個方法放入任務(wù)數(shù)組，然后在每個定時器中調(diào)用一個方法。從根本上說，現(xiàn)在它成為數(shù)組處理模式，只有一點不同：處理函數(shù)就包含在數(shù)組項中。正如前面一節(jié)所討論的，此模式也可封裝重用：
- function multistep(steps, args, callback){
- var tasks = steps.concat();
- setTimeout(function(){
- var task = tasks.shift();
- task.apply(null, args || []);
- if (tasks.length > 0){
- setTimeout(arguments.callee, 25);
- } else {
- callback();
- }
- }, 25);
- }
multistep()函數(shù)接收三個參數(shù)：用于執(zhí)行的函數(shù)數(shù)組，為每個函數(shù)提供參數(shù)的參數(shù)數(shù)組，當(dāng)處理結(jié)束時調(diào)用的回調(diào)函數(shù)。函數(shù)用法如下：
- function saveDocument(id){
- var tasks = [openDocument, writeText, closeDocument, updateUI];
- multistep(tasks, [id], function(){
- alert("Save completed!");
- });
- }
注意傳給multistep()的第二個參數(shù)必須是數(shù)組，它創(chuàng)建時只包含一個id。正如數(shù)組處理那樣，使用此函數(shù)的前提條件是：任務(wù)可以異步處理而不影響用戶體驗或?qū)е乱蕾嚧a出錯。
（一）限時運行代碼
有時每次只執(zhí)行一個任務(wù)效率不高?？紤]這樣一種情況：處理一個擁有1'000個項的數(shù)組，每處理一個項需要1毫秒。如果每個定時器中處理一個項，在兩次處理之間間隔25毫秒，那么處理此數(shù)組的總時間是(25 + 1) × 1'000 = 26'000 秒，也就是26 秒。如果每批處理50個，每批之間間隔25毫秒會怎么樣呢？整個處理過程變成(1'000 / 50) × 25 + 1'000 = 1'500毫秒，也就是1.5秒，而且用戶也不會察覺界面阻塞，因為最長的腳本運行只持續(xù)了50毫秒。通常批量處理比每次處理一個更快。
如果你記住JavaScript可連續(xù)運行的最大時間是100毫秒，那么你可以優(yōu)化先前的模式。我的建議是將這個數(shù)字削減一半，不要讓任何JavaScript代碼持續(xù)運行超過50毫秒，只是為了確保代碼永遠不會影響用戶體驗。
可通過原生的Date 對象跟蹤代碼的運行時間。這是大多數(shù)JavaScript分析工具所采用的工作方式：
- var start = +new Date(),
- stop;
- someLongProcess();
- stop = +new Date();
- if(stop-start < 50){
- alert("Just about right.");
- } else {
- alert("Taking too long.");
- }
由于每個新創(chuàng)建的Data 對象以當(dāng)前系統(tǒng)時間初始化，你可以周期性地創(chuàng)建新Data對象并比較它們的值，以獲取代碼運行時間。加號（+）將Data 對象轉(zhuǎn)換為一個數(shù)字，在后續(xù)的數(shù)學(xué)運算中就不必再轉(zhuǎn)換了。這一技術(shù)也可用于優(yōu)化以前的定時器模板。
processArray()方法通過一個時間檢測機制，可在每個定時器中執(zhí)行多次處理：
- function timedProcessArray(items, process, callback){
- var todo = items.concat();
- setTimeout(function(){
- var start = +new Date();
- do {
- process(todo.shift());
- } while (todo.length > 0 && (+new Date() – start < 50));
- if (todo.length > 0){
- setTimeout(arguments.callee, 25);
- } else {
- callback(items);
- }
- }, 25);
- }
此函數(shù)中添加了一個do-while循環(huán)，它在每個數(shù)組項處理之后檢測時間。定時器函數(shù)運行時數(shù)組中存放了至少一個項，所以后測試循環(huán)比前測試更合理。在Firefox 3中，如果process()是一個空函數(shù)，處理一個1'000個項的數(shù)組需要38 – 34毫秒；原始的processArray()函數(shù)處理同一個數(shù)組需要超過25'000毫秒。這就是定時任務(wù)的作用，避免將任務(wù)分解成過于碎小的片斷。
（二）定時器與性能
定時器使你的JavaScript代碼整體性能表現(xiàn)出巨大差異，但過度使用它們會對性能產(chǎn)生負面影響。使用定時器序列，同一時間只有一個定時器存在，只有當(dāng)這個定時器結(jié)束時才創(chuàng)建一個新的定時器。以這種方式使用定時器不會帶來性能問題。
當(dāng)多個重復(fù)的定時器被同時創(chuàng)建會產(chǎn)生性能問題。因為只有一個UI線程，所有定時器競爭運行時間。Google Mobile的Neil Thomas 將此問題作為測量性能的方法進行研究，針對iPhone和Android上運行的移動Gmail程序。
Thomas發(fā)現(xiàn)低頻率的重復(fù)定時器——間隔在1 秒或1 秒以上——幾乎不影響整個網(wǎng)頁應(yīng)用的響應(yīng)。這種情況下定時器延遲遠超過使UI 線程產(chǎn)生瓶頸的值，因此可安全地重復(fù)使用。當(dāng)多個重復(fù)定時器使用更高的頻率（間隔在100到200毫秒之間），Thomas發(fā)現(xiàn)移動Gmail程序明顯變慢，反應(yīng)較差。
Thomas研究的言外之意是，要在你的網(wǎng)頁應(yīng)用中限制高頻率重復(fù)定時器的數(shù)量。同時，Thomas建議創(chuàng)建一個單獨的重復(fù)定時器，每次執(zhí)行多個操作。
原文地址： http://www.yiiyaa.net/1223
【編輯推薦】
