有時候技術人員之間的差異微乎其微，但就是這微乎其微的差異積少成多，讓我們與大牛之間的距離越來越遠，當你開始在意這些細節而不是只關注成長的速度的時候，時間會告訴你當前版本的答案，技術的積累會產生難以想象的質變。大鵬一日同風起，然后一直起！起！起！（扯遠了...回歸主題）。

      會用和看懂是兩個概念，假如你不趕時間的話，我愿用我蹩腳的解釋，帶你去看看作者的匠心獨具。先上第一段熱乎的代碼：

      語言的盡頭并不是C語言，機器無法執行一段C代碼，她需要經編譯，匯編等等操作最終形成可執行的機器碼，當然我們是看不懂的，所以我們要理解，C語言首先要變成匯編代碼，那么一條語句就可能編程好幾句。

      當你從裸機編程切換到OS調度機制的時候，本質上來講比單純的裸機，CPU需要執行的代碼更多更復雜了，機器的性能相對是降低了，為了盡量降低這種額外的開銷，于是就出現了開局default的操作，這完全是站在機器的角度上選擇結果，軟件少一次的case判斷，變成匯編語言就是可以少執行好幾條語句，節省掉多個機器周期。

      接下來：讓我們看一下兩種運行任務的方式：

//運行任務
#define RunTask(TaskName,TaskID)  
do 
{ 
	if (timers[TaskID]==0) 
	{ 
		TASK d=TaskName(); 
		while(timers[TaskID]!=d) 
		timers[TaskID]=d;
	} 
} while(0);
//運行任務，前面的任務優先保證執行
#define RunTaskA(TaskName,TaskID)
do 
{ 
	if (timers[TaskID]==0) 
	{ 
		TASK d=TaskName(); 
		while(timers[TaskID]!=d) 
		timers[TaskID]=d;
		continue;
	} 
} while(0);

    先看下任務是如何運行的，先判斷該任務對應的阻塞時間是否到達：

    1. 沒到達的情況下，不運行任務，結束執行。

     2.時間到，timers倒計時為0，執行任務，并返回阻塞時間，第一個細節操作來了，先判斷timers是否等于返回的阻塞時間，如果不等于則進行賦值，這里是不是多此一舉，不用判斷直接賦值多好，去掉while判斷。你能這么想是因為你站在程序員的角度上，換一個角度，你站在機器的角度上來考慮問題，while判斷和賦值操作的運行時間，假定賦值操作需要更多的執行時間開銷，那么加一條while判斷，再相等的情況下，是否就不需要執行賦值操作了，可以節省更多的操作時間，二當需要賦值的情況下，可能也就加一條簡單的判斷操作，我是這樣的理解的，當然也可能不對，只是給你提供一條思路。

      對比任務和函數的區別：函數的返回值一般給到的是變量，作為函數執行的輸出（當然是純軟的情況下，有硬件參與的情況下，更多的是硬件對應的執行動作），任務的返回值的意義是：阻塞時間，將值記錄到任務對應的timers數組中，提供給任務框架進行計時操作。

      RunTask和RunTaskA的最大區別，就是continue的操作，執行完任務后，理論上任務返回的阻塞時間可以是任意值，當返回值為0時，代表著任務并未阻塞，這個是帶有continue操作的任務將會重新運行該任務，也就是TaskA優先保證執行。