最近在做一個項目，原來在手機運行非常流暢的代碼移植到平板電腦中，運行就感覺明顯很卡, 原因是平板電腦的分辨率是手機的兩倍，而CPU還遠達不到手機的兩倍。原來採用ViewGroup的形式，就不得采用繪製到Bitmap的做法， 繪製到Bitmap這種做法，已經成Android繪製各種特效的常規做法了。 但是繪製到Bitmap，相對ViewGroup有很多不足的地方： 1. 不靈活, 不像ViewGroup的形式，可以採用XML佈局的形式。ViewGroup做法的移植性相對來說更好些。 2.. 按鍵響應控制， 每個View都有自己的事件響應方法，而採用Bitamp繪製，不得不根據區域來判斷響應事件。但是基於效率考慮，不得不採用在SurfaceView中用繪製Bitmap的方法，來達到無限制數量的左右滑動容器(類似gallery)的效果。 其實，目前android很多的應用都是採用這種方式來做的，比如所有流行的電子書閱讀界面。
SurfaceView繪製效率高，就是Android 提供一個讓我們直接可以繪製的Buffer。
控制SurfaceView的生命週期有三個函數 surfaceCreate,sufaceChange, surfaceDestroy. surfaceChange一般用於處理橫豎屏幕切換。
我的做法是:
1. 創建一個繪製線程,
ThreaddrawThread = new Thread {
public void run () {
do {
// Canvas 繪製
// wait() 線程等待 .
} while(true);
}
}
2. 和手姿結合起來
3. 數據源綁定
我是在onScroll 結束的時候和更新數據，而這些數據就是在繪製時候需要的bitmap. 一定不要再繪製線程做一些數據處理和數據獲得的耗時操作。
數據的獲取是開另一個數據處理線程來做，目的是準備需要繪製的bitmaps.
數據獲取採用的是環形Buffer這樣的數據結構(之前我的博客已經介紹過這個數據結構)。
基本的思路已經提供了，這個框架我在開發Android應用是屢試不爽了。但我要強調的是不是這個框架，而是這個框架中包含的計算，這裏面涉及到很多圖形圖像算法，數學算法。