如何理解Android屬性動畫

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

動畫是什麼？

這或許是個簡單的問題，很多人都會回答說“動畫就是一幀幀靜態畫面的連續播放”。這樣的回答表明，動畫的組成元素是每一幀畫面。我們看到的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內完成的，因而我們感覺到動畫效果是順滑。