silverlight線程與基于事件驅動javascript引擎（實現軌跡回放功能）
2019-11-20 23:43:20
供稿：網友
案例背景：
整個功能其實就是從數據庫取出數據，然后在界面上播放，簡單地說就是類似網上在線看視頻，聽音樂，只不過我取的是字符串數據，而他們取的是流文件數據。把整體數據分成十份，十個線程同時向數據庫取數據（并發提高速度）放在十個隊列中，另外一個線程從隊列中取數據拿出來到界面上播放，可以拖動播放進度，停止，暫停，重新播放，控制播放速度。恩，功能聽起來似乎很簡單，做起來也不是很難。但是后面發現的一些問題，以及順著這些問題往下挖掘，挖掘了一些我認為值得記住的東西。
關鍵東西：
1. siliverlight 后臺線程 BackgroundWorker m_GetReplayData= new BackgroundWorker();
2. 跨線程訪問界面控件 ,this.Dispatcher.BeginInvoke( /訪問界面UI）;
3. javascript 式的函數指針： var ShowSIngleLog = function(){} ;（在父頁面上）
4 .子頁面注冊父頁面的事件： var fatharWindow = window.opener; ;
fatharWindow .ShowSIngleLog =function(){//播放數據 showTrace()};
5.javascript引擎線程,界面渲染線程,瀏覽器事件觸發線程；
6.瀏覽器引擎是單線程，也就是所有東西都是同步的，不存在兩個線程同時跑
問題所在：
通過silverlight線程的循環來調用JS方法達到播放界面數據的效果，因為silverlight只能調用本頁面的JS方法，可是軌跡回放的頁面是主頁面彈出的一個子頁面，于是我利用主頁面的一個空的函數指針，子頁面注冊父頁面的事件來達到Silverlight調用子頁面方法目（上面提到的第3點）。經過我仔細的推敲和論證我確定沒問題，做完后的也沒什么問題。本地測試的都是用上百條，上千條數據，問題不大，停止，暫停，拖動進度，問題都不大，就是父頁面界面有點卡，一開始我并沒有重視這個問題。到了測試那邊是2萬多條數據播放，播放5分鐘后主界面卡死了，軌跡回放頁面上的，停止，拖動進度，暫停，播放按鈕全部失效了。現象非常地詭異，我一度認為是測試的機器問題，最后發現是大數據量的問題。this.Dispatcher.BeginInvoke( /訪問界面UI）這個調用看似很簡單，很普通，但是有兩 個特點:
1.它是異步的，也就是調一下不一定馬上執行，先調不一定先執行，需要做同步控制；
2.這個方法要搶占瀏覽器界面渲染線程，而該線程與javascript引擎線程是互斥的.
2萬多數據，一開始我控制了播放速度，所以剛開始沒什么問題，到后面很多數據都卡在這個方法上，導致不斷地搶占瀏覽器界面渲染線程，導致主頁面非常卡，直到卡死為止。點擊主頁面，瀏覽器事件觸發線程要運行，但是這個時候界面渲染線程在跑，所以非常卡。
解決方案：
this.Dispatcher.BeginInvoke( /訪問界面UI），很明是這個東西造成，那就找替代方法。原來數據隊列是放在silverlight上，我改成放在javascript 隊列上。播放數據不依賴銀光線程，利用setimeout （該方法在IE6下會內存泄露，所以一開始被我排斥）來定時播放數據。結果很漂亮，頁面很順暢，沒有了異步的問題，不用去控制讓數據同步播放，也比較簡單。
分析原因：
為什么用silerlight來播放會很卡，但是setimeout來播不會卡，兩個都是連續播放的，而且setimeout在播放的時候，點擊頁面，頁面也能響應事件，這個問題我們要從事件驅動javascript引擎。頁面卡的原因上面已經說了，主要是想解釋一下setimeout播放為什么不卡。瀏覽器中的JavaScript引擎是基于事件驅動的,這里的事件可看作是瀏覽器派給它的各種任務,這些任務可以源自 JavaScript引擎當前執行的代碼塊,如調用setTimeout添加一個任務,也可來自瀏覽器內核的其它線程,如界面元素鼠標點擊事件,定時觸發器時間到達通知,異步請求狀態變更通知等.從代碼角度看來任務實體就是各種回調函數,JavaScript引擎一直等待著任務隊列中任務的到來.由于單線程關系,這些任務得進行排隊,一個接著一個被引擎處理。所以在播放數據的時候，操作界面的是會被加到任務隊列中，會得到執行，自然用戶角度感受到整個頁面也不卡了。
