和之前的文章一樣，沒有使用代碼進行講解，所以讀者閱讀起來可能有點吃力。我建議閱讀的時候，結合源碼，效果更佳。文章必定會有疏漏的地方，讀者在閱讀過程如發現，請務必指正，不甚感激！

動畫是什么？

這或許是個簡單的問題，很多人都會回答說“動畫就是一幀幀靜態畫面的連續播放”。這樣的回答表明，動畫的組成元素是每一幀畫面。我們看到的2D動畫就是這樣。然而我們發現在電影院，2D動畫幾乎已經絕跡，普遍都是畫質更為逼真，人物表情更為豐富的CG動畫。制作CG動畫有一個重要的步驟就是--建模，比如人物，花草，建筑物等等都是被獨立看待的一個個模型。我們以CG動畫的角度看，動畫的組成元素是一個個獨立的模型。每個模型都有本身的屬性，比如頭發的弧度，手臂的位置，瞳孔的顏色等等。當我們把動畫以幀的方式進行分割，實際上就割裂了屬性變化的連續性。而CG動畫則是以事物屬性為關注點，并且注重屬性變化的連續性，所以效果就更加逼真靈動。

從2D動畫到CG動畫，是技術的進步，也是認知的提升。Android動畫框架也經歷了這樣的轉變。

Android早期提供的動畫框架被稱為幀動畫，就像2D動畫一樣，所以也有著2D動畫的缺點--動畫效果卡頓。這使得Android在3.0推出了全新的動畫框架--屬性動畫。屬性動畫與CG動畫的核心理念是一樣的--所動畫的是屬性，而不是幀。Androd官方把屬性動畫框架的開發稱之為--黃油計劃，原因顯而易見，就是讓動畫像黃油一樣順滑。

我在此談的就是屬性動畫。

動畫回調何時執行？

在回答這個問題之前先談談主線程。主線程又稱UI線程，主要作用是處理交互事件，執行界面繪制等功能。每個人都能拿這個回答去搪塞別人，回答問題的人未必在頭腦中建立了主線程運轉機制的模型。線程交互的基本模型就是生產者-消費者模型。在這個模型中工作線程將生產的Runnable，不斷發送到主線程供其消費。主線程的Run方法存在一個死循環，在這個死循環中，它不斷處理別人生成的Runnable.。投遞給主線程的Runnable一般分為兩類。一類是系統產生的事件，如交互事件，四大組件的生命周期回調；另一類事件是程序自身產生的--那些post系列方法發送的Runnable，動畫事件回調，界面繪制事件。四大組件的生命周期回調我們不談及，他是由系統操控的。這些Runnable就是胡亂的塞到主線程的消息隊列中的嗎？顯然不是，絕對不是！

問題來了，這些Runnable如何在主線程中進行組織？

所謂組織就是給這些Runnable排個序，排序標準有兩個：一是這些Runnale之間固有的先后順序，比如交互事件的處理就應該在繪制事件前面，因為我們只有計算了手移動了多少距離，才能決定屏幕中的控件移動多少距離；二是以時間排序，比如postDelayed方法就會延遲Runnable的執行。這些事件在主線程的處理順序是：交互事件回調--動畫事件回調--界面繪制。Android系統每隔16ms發出VSYNC信號，接收到VSYNC信號，主線程會依次執行交互事件回調，動畫事件回調，最后觸發UI繪制。在Android中實現Runnable調度組織功能的是Choreographer，它為以上三類事件的分別維護了一個列表。

屬性動畫如何將動畫回調事件交給Choreographer？

我能想到最簡陋的動畫效果實現就是，一個放映員不斷切換幻燈片，只要放映員切換速度足夠快，也能達到"動畫"的效果。這里有個重要的角色就是切換幻燈片的放映員。Android的屬性動畫也需要這樣一個放映員，我們稱這個放映員為動畫引擎。

Android屬性動畫的引擎只有一個，所有的動畫都由這個引擎調度。這樣做的好處是所有動畫分享相同的時間，那么動畫之間就能同步。在Android中動畫引擎的實現類是AnimationHandler--組織編排所有動畫的執行（每個動畫的啟動時間不一樣，另外有的動畫會延遲執行），根據動畫時間計算動畫值。AnimationHandler會拿到Choreographer的一個實例，并將自己放置到Choreographer所維護的動畫事件列表中，隨著每一次VSYNC信號的到來，而得到執行。

為什么屬性動畫會順滑？

之前提到了Android系統會每隔16ms發出VSYNC信號。為什么是16ms?因為人類視覺能接受到畫面變化的時間就是16ms,當大于16ms,人就會感覺到畫面不連續，我們稱為卡頓，所以Android會每隔16ms刷新一次畫面。一般的，我們在動畫回調中修改了View的某些屬性，然后緊接著在View的繪制中應用了了這些屬性，這一切都是在這16ms內完成的，因而我們感覺到動畫效果是順滑。