前一段时间一直在重构工作站轨迹回放功能，一开始我觉得很简单，但是后面引发了一系列奇怪的问题，让我很蛋疼，所以不得不写个总结加深记忆。
案例背景：
整个功能其实就是从数据库取出数据，然后在界面上播放，简单地说就是类似网上在线看视频，听音乐，只不过我取的是字符串数据，而他们取的是流文件数据。把整体数据分成十份，十个线程同时向数据库取数据（并发提高速度）放在十个队列中，另外一个线程从队列中取数据拿出来到界面上播放，可以拖动播放进度，停止，暂停，重新播放，控制播放速度。恩，功能听起来似乎很简单，做起来也不是很难。但是后面发现的一些问题，以及顺着这些问题往下挖掘，挖掘了一些我认为值得记住的东西。
关键东西：
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引擎一直等待着任务队列中任务的到来.由于单线程关系,这些任务得进行排队,一个接着一个被引擎处理。所以在播放数据的时候，操作界面的是会被加到任务队列中，会得到执行，自然用户角度感受到整个页面也不卡了。