FrameAnimation
如果有播放超多幀動畫的需求，直接點擊 FrameAnimation 在github查看，基本能滿足你的所有需求，就不用往下看了，基本能滿足99.99%人的需求。
PS. 此文年久失修，上述代碼的具體實現本文已有較大差距，不過整體思路還是可以參考下的。
關于Android幀動畫
???????當在應用中需要使用幀動畫的時候，最先想到的就是Android提供的AnimationDrawable了，但是如果幀動畫中如果包含上百幀圖片，此時再用AnimationDrawable就不是那么理想了。AnimationDrawable使用一個Drawable數組來存儲每一幀的圖像，會直接把全部圖片加載進內存。隨著幀數量的增多，就算性能再強勁的機器也會卡頓、OOM。
使用SurfaceView來實現幀動畫的效果
????最近的項目中需要用到大量的幀動畫（各種閃瞎24K鈦合金狗眼的禮物效果，多的高達200幀），既然AnimationDrawable不行，就想到了兩種解決方法。
第一個想到的解決辦法就是用openGL來繪制了。
???因為是直播的項目，包含人臉貼圖等都是用opengl繪制的，如果用OpenGL繪制一層Texture直接推流還省事。只在主播端處理就行了，但是IOS那邊都弄得差不多了，直接原生的不用處理也不會有什么異常什么的。。很尷尬。
第二個就是使用Android自帶的surfaceView了
????好吧，第一個不行那就想到Android自帶的surfaceView啦。我首先用不同的手機測試了下應用從本地decode一個bitmap的時間（png格式，414*736，大小在30-100k之間），因為幀動畫的每幀不會太大，在性能好點的設備上基本保持在10-30ms之間（不推流基本上推流狀態下10ms左右，推流狀態下20左右），在性能稍差的設備中基本上也不會超過50ms，所以說是沒什么大問題的。
在移動設備播放的幀動畫一定要盡最大可能的壓縮，推薦一個網站，會把圖片顏色深度壓縮成8位的。TinyPNG
實現思路
整個思路大概如圖。
既然不能完全加載到內存，想到的就是類似視頻播放或者視頻直播類似的思路。首先定義一個Bitmap的緩沖區，邊繪制邊加載。首先加載一定數量的幀到Bitmap緩沖區，加載完成后通知SurfaceView開始繪制。SurfaceView繪制一幀完成后通知Bitmap緩沖區加載下一幀，同時將繪制過的一幀的從Bitmap緩沖區移除。一幀繪制完成后，繪制線程根據設置的幀間隔休眠一段時間，休眠完成后開始從Bitmap緩沖區獲取下一幀，依此類推，一直循環，直到播放完成或者手動停止。按照這種方式實現起來，發現oom卡頓什么的果然不存在了，內存的使用情況如圖。
但是看著這個垃圾桶一個挨一個，這個內存回收情況完全不正常！GC太頻繁了。想著應該是這里出現了問題。[圖片上傳失敗...(image-96f387-1512626035688)]
頻繁的添加移除bitmap，導致了不算太嚴重的內存抖動。之所以稱之為不算太嚴重，因為大概400ms一次，一次gc花費2ms左右。不看內存，只看運行效果。真的感覺不出來。但是呢，這樣顯然也是不行滴。
內存抖動的解決
最常見的解決方法就是對象的復用，創建各種pool。Android也提供了Bitmap的復用方式，在加載bitmap的時候傳入一個inBitmap，那么加載的bitmap就會復用原bitmap的內存空間，所以理論上將要復用的bitmap和新加載的bitmap在顏色深度一樣的情況下，復用的bitmap寬高要大于新加載的bitmap。50L的桶畢竟最多只能裝50L的水。關于inBitmap更多資料可以參考這里，還有這里。（請自備梯子）。 使用起來很簡單，大概就是這樣
Bitmap mInBitmap;
BitmapFactory.Options mOptions = new BitmapFactory.Options();
mOptions.inMutable = true;
mOptions.inSampleSize = 1;
//mInBitmap不能為null，此處省去賦值
mOptions.inBitmap = mInBitmap;
Bitmap bitmap = BitmapFactory.decodeStream(mAssetManager.open(path), null, mOptions);
然后實現思路就是在這里修改了，把將要刪除的哪一幀留下來作為inBitmap。
