Android開發之性能優化

      随着技術的發展，智能手機硬體配置越來越高，可是它和現在的PC相比，其運算能力，續航能力，存儲空間等都還是受到很大的限制，同時使用者對手機的體驗要求遠遠高于PC的桌面應用程式。以上理由，足以需要開發人員更加專心去實作和優化你的代碼了。選擇合适的算法和資料結構永遠是開發人員最先應該考慮的事情。同時，我們應該時刻牢記，寫出高效代碼的兩條基本的原則：（1）不要做不必要的事；（2）不要配置設定不必要的記憶體。

我從去年開始接觸Android開發，以下結合自己的一點項目經驗，同時參考了Google的優化文檔和網上的諸多技術大牛給出的意見，整理出這份文檔。

2)避免建立不必要的對象

就像世界上沒有免費的午餐，世界上也沒有免費的對象。雖然gc為每個線程都建立了臨時對象池，可以使建立對象的代價變得小一些，但是配置設定記憶體永遠都比不配置設定記憶體的代價大。如果你在使用者界面循環中配置設定對象記憶體，就會引發周期性的垃圾回收，使用者就會覺得界面像打嗝一樣一頓一頓的。是以，除非必要，應盡量避免盡力對象的執行個體。下面的例子将幫助你了解這條原則：

當你從使用者輸入的資料中截取一段字元串時，盡量使用substring函數取得原始資料的一個子串，而不是為子串另外建立一份拷貝。這樣你就有一個新的String對象，它與原始資料共享一個char數組。 如果你有一個函數傳回一個String對象，而你确切的知道這個字元串會被附加到一個StringBuffer，那麼，請改變這個函數的參數和實作方式，直接把結果附加到StringBuffer中，而不要再建立一個短命的臨時對象。

一個更極端的例子是，把多元數組分成多個一維數組：

int數組比Integer數組好，這也概括了一個基本事實，兩個平行的int數組比 (int,int)對象數組性能要好很多。同理，這試用于所有基本類型的組合。如果你想用一種容器存儲(Foo,Bar)元組，嘗試使用兩個單獨的Foo[]數組和Bar[]數組，一定比(Foo,Bar)數組效率更高。（也有例外的情況，就是當你建立一個API，讓别人調用它的時候。這時候你要注重對API接口的設計而犧牲一點兒速度。當然在API的内部，你仍要盡可能的提高代碼的效率）

總體來說，就是避免建立短命的臨時對象。減少對象的建立就能減少垃圾收集，進而減少對使用者體驗的影響。

3)靜态方法代替虛拟方法

如果不需要通路某對象的字段，将方法設定為靜态，調用會加速15%到20%。這也是一種好的做法，因為你可以從方法聲明中看出調用該方法不需要更新此對象的狀态。

4)避免内部Getters/Setters

在源生語言像C++中，通常做法是用Getters(i=getCount())代替直接字段通路(i=mCount)。這是C++中一個好的習慣，因為編譯器會内聯這些通路，并且如果需要限制或者調試這些域的通路，你可以在任何時間添加代碼。

而在Android中，這不是一個好的做法。虛方法調用的代價比直接字段通路高昂許多。通常根據面向對象語言的實踐，在公共接口中使用Getters和Setters是有道理的，但在一個字段經常被通路的類中宜采用直接通路。

無JIT時，直接字段通路大約比調用getter通路快3倍。有JIT時(直接通路字段開銷等同于局部變量通路)，要快7倍。

5)将成員緩存到本地通路成員變量比通路本地變量慢得多，下面一段代碼：

 for(int i =0; i <this.mCount; i++)  {

 dumpItem(this.mItems);

 }

最好改成這樣：

 int count = this.mCount;

 Item[] items = this.mItems;

 for(int i =0; i < count; i++)  {

        dumpItems(items);

 }

另一個相似的原則是：永遠不要在for的第二個條件中調用任何方法。如下面方法所示，在每次循環的時候都會調用getCount()方法，這樣做比你在一個int先把結果儲存起來開銷大很多。

 for(int i =0; i < this.getCount(); i++) {

 dumpItems(this.getItem(i));

 }

同樣如果你要多次通路一個變量，也最好先為它建立一個本地變量，例如：

 protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {

 if(isHorizontalScrollBarEnabled()) {

 intsize = mScrollBar.getSize(false);

 if(size <=0) {

        size = mScrollBarSize;

 }

 mScrollBar.setBounds(0, height - size, width, height);

 mScrollBar.setParams(computeHorizontalScrollRange(), computeHorizontalScrollOffset(), computeHorizontalScrollExtent(),false);

 mScrollBar.draw(canvas);

 }

 }

這裡有4次通路成員變量mScrollBar，如果将它緩存到本地，4次成員變量通路就會變成4次效率更高的棧變量通路。

另外就是方法的參數與本地變量的效率相同。

1)對常量使用static final修飾符

讓我們來看看這兩段在類前面的聲明：

 static int intVal = 42;

 static String strVal = "Hello, world!";

必以其會生成一個叫做clinit的初始化類的方法，當類第一次被使用的時候這個方法會被執行。方法會将42賦給intVal，然後把一個指向類中常量表的引用賦給strVal。當以後要用到這些值的時候，會在成員變量表中查找到他們。 下面我們做些改進，使用“final”關鍵字：

 static final int intVal = 42;

 static final String strVal = "Hello, world!";

現在，類不再需要clinit方法，因為在成員變量初始化的時候，會将常量直接儲存到類檔案中。用到intVal的代碼被直接替換成42，而使用strVal的會指向一個字元串常量，而不是使用成員變量。

将一個方法或類聲明為final不會帶來性能的提升，但是會幫助編譯器優化代碼。舉例說，如果編譯器知道一個getter方法不會被重載，那麼編譯器會對其采用内聯調用。

你也可以将本地變量聲明為final，同樣，這也不會帶來性能的提升。使用“final”隻能使本地變量看起來更清晰些（但是也有些時候這是必須的，比如在使用匿名内部類的時候）。

2)使用改進的For循環文法

改進for循環(有時被稱為for-each循環)能夠用于實作了iterable接口的集合類及數組中。在集合類中，疊代器讓接口調用hasNext()和next()方法。在ArrayList中，手寫的計數循環疊代要快3倍(無論有沒有JIT)，但其他集合類中，改進的for循環文法和疊代器具有相同的效率。下面展示集中通路數組的方法：

 static class Foo {

         int mSplat;

     }

     Foo[] mArray = ...

     public void zero() {

         int sum = 0;

         for (int i = 0; i < mArray.length; ++i) {

             sum += mArray.mSplat;

         }

     }

     public void one() {

         int sum = 0;

         Foo[] localArray = mArray;

         int len = localArray.length;

         for (int i = 0; i < len; ++i) {

             sum += localArray.mSplat;

         }

     }

     public void two() {

         int sum = 0;

         for (Foo a : mArray) {

             sum += a.mSplat;

         }

 }

 }

在zero()中，每次循環都會通路兩次靜态成員變量，取得一次數組的長度。

在one()中，将所有成員變量存儲到本地變量。

two()使用了在java1.5中引入的foreach文法。編譯器會将對數組的引用和數組的長度儲存到本地變量中，這對通路數組元素非常好。但是編譯器還會在每次循環中産生一個額外的對本地變量的存儲操作（對變量a的存取）這樣會比one()多出4個位元組，速度要稍微慢一些。

3)避免使用浮點數

通常的經驗是，在Android裝置中，浮點數會比整型慢兩倍，在缺少FPU和JIT的G1上對比有FPU和JIT的Nexus One中确實如此(兩種裝置間算術運算的絕對速度差大約是10倍)

從速度方面說，在現代硬體上，float和double之間沒有任何不同。更廣泛的講，double大2倍。在桌上型電腦上，由于不存在空間問題，double的優先級高于float。

但即使是整型，有的晶片擁有硬體乘法，卻缺少除法。這種情況下，整型除法和求模運算是通過軟體實作的，就像當你設計Hash表，或是做大量的算術那樣，例如a/2可以換成a*0.5。

4)了解并使用類庫

選擇Library中的代碼而非自己重寫，除了通常的那些原因外，考慮到系統空閑時會用彙編代碼調用來替代library方法，這可能比JIT中生成的等價的最好的Java代碼還要好。

i.當你在處理字串的時候，不要吝惜使用String.indexOf()，String.lastIndexOf()等特殊實作的方法。這些方法都是使用C/C++實作的，比起Java循環快10到100倍。

ii.System.arraycopy方法在有JIT的Nexus One上，自行編碼的循環快9倍。

iii.android.text.format包下的Formatter類，提供了IP位址轉換、檔案大小轉換等方法；DateFormat類，提供了各種時間轉換，都是非常高效的方法。

詳細請參考http://developer.android.com/ref ... ackage-summary.html

iv.TextUtils類

對于字元串處理Android為我們提供了一個簡單實用的TextUtils類，如果處理比較簡單的内容不用去思考正規表達式不妨試試這個在android.text.TextUtils的類，詳細請參考http://developer.android.com/ref ... text/TextUtils.html

v.高性能MemoryFile類。

很多人抱怨Android處理底層I/O性能不是很理想，如果不想使用NDK則可以通過MemoryFile類實作高性能的檔案讀寫操作。

MemoryFile适用于哪些地方呢？對于I/O需要頻繁操作的，主要是和外部存儲相關的I/O操作，MemoryFile通過将 NAND或SD卡上的檔案，分段映射到記憶體中進行修改處理，這樣就用高速的RAM代替了ROM或SD卡，性能自然提高不少，對于Android手機而言同時還減少了電量消耗。該類實作的功能不是很多，直接從Object上繼承，通過JNI的方式直接在C底層執行。

詳細請參考http://developer.android.com/reference/android/os/MemoryFile.html

在此，隻簡單列舉幾個常用的類和方法，更多的是要靠平時的積累和發現。多閱讀Google給的幫助文檔時很有益的。

6)複雜算法盡量用C完成

複雜算法盡量用C或者C++完成，然後用JNI調用。但是如果是算法比較單間，不必這麼麻煩，畢竟JNI調用也會花一定的時間。請權衡。

7)減少不必要的全局變量

盡量避免static成員變量引用資源耗費過多的執行個體,比如Context。Android提供了很健全的消息傳遞機制(Intent)和任務模型(Handler),可以通過傳遞或事件的方式，防止一些不必要的全局變量。

9)了解Java四種引用方式

JDK 1.2版本開始，把對象的引用分為4種級别，進而使程式能更加靈活地控制對象的生命周期。這4種級别由高到低依次為：強引用、軟引用、弱引用和虛引用。

i.強引用（StrongReference）

強引用是使用最普遍的引用。如果一個對象具有強引用，那垃圾回收器絕不會回收它。當記憶體空間不足，Java虛拟機甯願抛出OutOfMemoryError錯誤，使程式異常終止，也不會靠随意回收具有強引用的對象來解決記憶體不足的問題。

ii.軟引用（SoftReference）

如果一個對象隻具有軟引用，則記憶體空間足夠，垃圾回收器就不會回收它；如果記憶體空間不足了，就會回收這些對象的記憶體。隻要垃圾回收器沒有回收它，該對象就可以被程式使用。軟引用可用來實作記憶體敏感的高速緩存。

iii.弱引用（WeakReference）

在垃圾回收器線程掃描它所管轄的記憶體區域的過程中，一旦發現了隻具有弱引用的對象，不管目前記憶體空間足夠與否，都會回收它的記憶體。不過，由于垃圾回收器是一個優先級很低的線程，是以不一定會很快發現那些隻具有弱引用的對象。

iv.虛引用（PhantomReference）

顧名思義，就是形同虛設。與其他幾種引用都不同，虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收器回收。

了解并熟練掌握這4中引用方式，選擇合适的對象應用方式，對記憶體的回收是很有幫助的。

詳細請參考http://blog.csdn.net/feng88724/article/details/6590064

10)使用實體類比接口好

假設你有一個HashMap對象，你可以将它聲明為HashMap或者Map：

 Map map1 = new HashMap();

 HashMap map2 = new HashMap();

哪個更好呢？

按照傳統的觀點Map會更好些，因為這樣你可以改變他的具體實作類，隻要這個類繼承自Map接口。傳統的觀點對于傳統的程式是正确的，但是它并不适合嵌入式系統。調用一個接口的引用會比調用實體類的引用多花費一倍的時間。如果HashMap完全适合你的程式，那麼使用Map就沒有什麼價值。如果有些地方你不能确定，先避免使用 Map，剩下的交給IDE提供的重構功能好了。(當然公共API是一個例外：一個好的API常常會犧牲一些性能）

11)避免使用枚舉

枚舉變量非常友善，但不幸的是它會犧牲執行的速度和并大幅增加檔案體積。例如：

 public class Foo {

        public enum Shrubbery { GROUND, CRAWLING, HANGING }

 }

會産生一個900位元組的.class檔案(Foo$Shubbery.class)。在它被首次調用時，這個類會調用初始化方法來準備每個枚舉變量。每個枚舉項都會被聲明成一個靜态變量，并被指派。然後将這些靜态變量放在一個名為”$VALUES”的靜态數組變量中。而這麼一大堆代碼，僅僅是為了使用三個整數。

這樣：Shrubbery shrub =Shrubbery.GROUND；會引起一個對靜态變量的引用，如果這個靜态變量是final int，那麼編譯器會直接内聯這個常數。

一方面說，使用枚舉變量可以讓你的API更出色，并能提供編譯時的檢查。是以在通常的時候你毫無疑問應該為公共API選擇枚舉變量。但是當性能方面有所限制的時候，你就應該避免這種做法了。

有些情況下，使用ordinal()方法擷取枚舉變量的整數值會更好一些，舉例來說：

 for(int n =0; n < list.size(); n++) {

        if(list.items[n].e == MyEnum.VAL_X) {

               // do something

        } else if(list.items[n].e == MyEnum.VAL_Y) {

               // do something

        }

 }

替換為：

 int valX = MyEnum.VAL_X.ordinal();

 int valY = MyEnum.VAL_Y.ordinal();

 int count = list.size();

 MyItem items = list.items();

 for(int n =0; n < count; n++) {

        intvalItem = items[n].e.ordinal();

        if(valItem == valX) {

               // do something

        } else if(valItem == valY) {

               // do something

        }

 }

會使性能得到一些改善，但這并不是最終的解決之道。

12)在私有内部内中，考慮用包通路權限替代私有通路權限

 public class Foo {

            public class Inner {

                 public void stuff() {

                        Foo.this.doStuff(Foo.this.mValue);

                 }

            }

            private int mValue;

            public void run() {

                 Inner in = new Inner();

                 mValue = 27;

                 in.stuff();

            }

            private void doStuff(int value) {

                  System.out.println("value:"+value);

            }

 }

需要注意的關鍵是：我們定義的一個私有内部類（Foo$Inner），直接通路外部類中的一個私有方法和私有變量。這是合法的，代碼也會列印出預期的“Value is 27”。

但問題是，虛拟機認為從Foo$Inner中直接通路Foo的私有成員是非法的，因為他們是兩個不同的類，盡管Java語言允許内部類通路外部類的私有成員，但是通過編譯器生成幾個綜合方法來橋接這些間隙的。

 static int Foo.access$100(Foo foo) {

 return foo.mValue;

 }

 static void Foo.access%200(Foo foo,int value) {

        foo.duStuff(value);

 }

内部類會在外部類中任何需要通路mValue字段或調用doStuff方法的地方調用這些靜态方法。這意味着這些代碼将直接存取成員變量表現為通過存取器方法通路。之前提到過存取器通路如何比直接通路慢，這例子說明，某些語言約會定導緻不可見的性能問題。

如果你在高性能的Hotspot中使用這些代碼，可以通過聲明被内部類通路的字段和成員為包通路權限，而非私有。但這也意味着這些字段會被其他處于同一個包中的類通路，是以在公共API中不宜采用。

13)将與内部類一同使用的變量聲明在包範圍内

請看下面的類定義：

 public class Foo {

        private class Inner {

            void stuff() {

                Foo.this.doStuff(Foo.this.mValue);

            }

        }

        private int mValue;

        public void run() {

            Inner in = new Inner();

            mValue = 27;

            in.stuff();

        }

        private void doStuff(int value) {

            System.out.println("Value is " + value);

        }

 }

這其中的關鍵是，我們定義了一個内部類(Foo$Inner)，它需要通路外部類的私有域變量和函數。這是合法的，并且會列印出我們希望的結果Value is 27。

問題是在技術上來講（在幕後）Foo$Inner是一個完全獨立的類，它要直接通路Foo的私有成員是非法的。要跨越這個鴻溝，編譯器需要生成一組方法：

  static int Foo.access$100(Foo foo) {

     return foo.mValue;

 }

  static void Foo.access$200(Foo foo, int value) {

     foo.doStuff(value);

 }

内部類在每次通路mValueg和gdoStuffg方法時，都會調用這些靜态方法。就是說，上面的代碼說明了一個問題，你是在通過接口方法通路這些成員變量和函數而不是直接調用它們。在前面我們已經說過，使用接口方法（getter、setter）比直接通路速度要慢。是以這個例子就是在特定文法下面産生的一個“隐性的”性能障礙。

通過将内部類通路的變量和函數聲明由私有範圍改為包範圍，我們可以避免這個問題。這樣做可以讓代碼運作更快，并且避免産生額外的靜态方法。（遺憾的是，這些域和方法可以被同一個包内的其他類直接通路，這與經典的OO原則相違背。是以當你設計公共API的時候應該謹慎使用這條優化原則）。

14)緩存

适量使用緩存，不要過量使用，因為記憶體有限，能儲存路徑位址的就不要存放圖檔資料，不經常使用的盡量不要緩存，不用時就清空。

15)關閉資源對象

對SQLiteOpenHelper，SQLiteDatabase，Cursor，檔案，I/O操作等都應該記得顯示關閉。

2.視圖優化

1)View優化

i.減少不必要的View以及View的嵌套層次。

比如實作一個listview中常用的layout，可以使用RelativeLayout減少嵌套，要知道每個View的對象會耗費1~2k記憶體，嵌套層次過多會引起頻繁的gc，造成ANR。

ii.通過HierarchyViewer檢視布局結構

利用HierarchyViewer來檢視View的結構：~/tools/hierarchyviewer，能很清楚地看到RelativeLayout下面的扁平結構，這樣能加快dom的渲染速度。

詳細請參考http://developer.android.com/gui ... erarchy-viewer.html

iii.通過Layoutopt優化布局

通過Android sdk中tools目錄下的layoutopt 指令檢視你的布局是否需要優化。詳細請參考http://apps.hi.baidu.com/share/detail/34247942

4)對大型圖檔進行縮放

圖檔讀取是OOM(Out of Memory)的常客，當在Android手機上直接讀取4M的圖檔時，死神一般都會降臨，是以導緻往往自己手機拍攝的照片都不能直接讀取。對大型圖檔進行縮放有，處理圖檔時我們經常會用到BitmapFactory類，android系統中讀取位圖Bitmap時分給虛拟機中圖檔的堆棧大小隻有8M。用BitmapFactory解碼一張圖檔時，有時也會遇到該錯誤。這往往是由于圖檔過大造成的。這時我們需要配置設定更少的記憶體空間來存儲。BitmapFactory.Options.inSampleSize設定恰當的inSampleSize可以使BitmapFactory配置設定更少的空間以消除該錯誤。Android提供了一種動态計算的，如下：

讀取圖檔之前先檢視其大小：

 BitmapFactory.Options opts = new BitmapFactory.Options();

 opts.inJustDecodeBounds = true;

 Bitmap bitmap = BitmapFactory.decodeFile(imageFile, opts);

使用得到的圖檔原始寬高計算适合自己的smaplesize

 BitmapFactory.Options opts = new BitmapFactory.Options();

 opts.inSampleSize = 4 ;// 4就代表容量變為以前容量的1/4

 Bitmap bitmap = BitmapFactory.decodeFile(imageFile, opts);

對于過時的Bitmap對象一定要及時recycle，并且把此對象指派為null。

 <span style="line-height: 1.5;">bitmap.recycle(); </span>

 bitmap = null;

6)針對ListView的性能優化

i.複用convertView。

ii.在getItemView中，判斷convertView是否為空，如果不為空，可複用。如果couvertview中的view需要添加listerner，代碼一定要在if(convertView==null){}之外。

iii.異步加載圖檔，item中如果包含有web image，那麼最好異步加載。

iv.快速滑動時不顯示圖檔

當快速滑動清單時（SCROLL_STATE_FLING），item中的圖檔或擷取需要消耗資源的view，可以不顯示出來；而處于其他兩種狀态（SCROLL_STATE_IDLE 和SCROLL_STATE_TOUCH_SCROLL），則将那些view顯示出來。

v.item盡可能的減少使用的控件和布局的層次；背景色與cacheColorHint設定相同顔色；ListView中item的布局至關重要，必須盡可能的減少使用的控件，布局。RelativeLayout是絕對的利器，通過它可以減少布局的層次。同時要盡可能的複用控件，這樣可以減少ListView的記憶體使用，減少滑動時gc次數。ListView的背景色與cacheColorHint設定相同顔色，可以提高滑動時的渲染性能。

vi.getView優化

ListView中getView是性能是關鍵，這裡要盡可能的優化。getView方法中要重用view；getView方法中不能做複雜的邏輯計算，特别是資料庫和網絡通路操作，否則會嚴重影響滑動時的性能。優化如下所示：

 @Override

 public View getView(int position, View convertView, ViewGroup parent) {

        Log.d("MyAdapter", "Position:" + position + "---" + String.valueOf(System.currentTimeMillis()));

        final LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

        View v = inflater.inflate(R.layout.list_item_icon_text, null);

        ((ImageView) v.findViewById(R.id.icon)).setImageResource(R.drawable.icon);

        ((TextView) v.findViewById(R.id.text)).setText(mData[position]);

        return v;

 }

建議改為：

 @Override

 public View getView(int position, View convertView, ViewGroup parent) {

        Log.d("Adapter", "Position:" + position + " : " + String.valueOf(System.currentTimeMillis()));

        ViewHolder holder;

        if (convertView == null) {

               final LayoutInflater inflater = (LayoutInflater) mContext.getSystemService(Context.LAYOUT_INFLATER_SERVICE);

               convertView = inflater.inflate(R.layout.list_item_icon_text, null);

               holder = new ViewHolder();

              holder.icon = (ImageView) convertView.findViewById(R.id.icon);

              holder.text = (TextView) convertView.findViewById(R.id.text);

              convertView.setTag(holder);

        } else {

              holder = (ViewHolder) convertView.getTag();

        }

               holder.icon.setImageResource(R.drawable.icon);

               holder.text.setText(mData[position]);

               return convertView;

        }

        static class ViewHolder {

                ImageView icon;

                TextView text;

        }

 }

以上是Google IO大會上給出的優化建議，經過嘗試ListView确實流暢了許多。使用1000條記錄，經測試第一種方式耗時：25211ms，第二種方式耗時：16528ms。

4.結束語

本文給出了一些Android 移動開發中常見的優化方法，多數情況下利用這些優化方法優化後的代碼，執行效率有明顯的提高，記憶體溢出情況也有所改善。在實際應用中對程式的優化一定要權衡是否是必須的，因為優化可能會帶來諸如增加BUG，降低代碼的可讀性，降低代碼的移植性等不良效果。

希望不要盲目優化，請先确定存在問題，再進行優化。并且你知道目前系統的性能，否則無法衡量你進行嘗試所得到的性能提升。

希望本文能給大家切實帶來幫助。歡迎就上述問題進一步交流。如有發現錯誤或不足，請斧正。