Android高效編程的實踐

看過《 編寫高效的Android代碼》見http://www.linuxidc.com/Linux/2011-09/43807.htm 這篇文章，覺得挺有道理的，於是按照其說法從以下幾個角度修改了自己的app代碼。

1，避免建立對象。 這一點是沒有問題的，java編程時都需要盡量控制new 對象的次數，每次在heap中生成新的對象是很費時的。

2，不涉及成員變量和成員方法的方法都定義為static。這一點也沒有問題，姑且不論效率問題，這也是OO思想的一個體現。

3，成員變量緩存到本地。 理論上講，成員變量的訪問，是存儲在heap中的，heap的訪問沒有stack中訪問高效。而且經過java測試，我發現，對比兩次使用成員變量 和 一次申請局部變量緩存後再兩次使用局部變量，後者要效率高。代碼如下：

1. public class test {    
2.     public long a ;    
3.     public long b ;    
4.     test(long x , long y){    
5.         a = x;    
6.         b = y;    
7.     }    
8.     void reset(long x , long y){    
9.         a = x ;    
10.         b = y ;    
11.     }    
12.         
13.     public static void main(String args[]){     
14.         test mt = new test(-1,-1);    
15.         System.out.print("成員變量訪問 與 局部變量 訪問對比 1:\n");    
16.         long time = System.currentTimeMillis();    
17.         for (long i = 0 ; i != 1000000 ; i ++){  //下面是兩次對成員變量的使用   
18.             if ( mt.a == i ){    
19.                 i ++ ;    
20.             }     
21.             if ( mt.a == i ){    
22.                 i ++ ;    
23.             }     
24.         }    
25.         System.out.print("成員變量 : "+(System.currentTimeMillis() - time) + "ms\n");    
26.             
27.         time = System.currentTimeMillis();    
28.             
29.         for (long i = 0 ; i != 1000000 ; i ++){  //下面先緩存為局部變量，再兩次使用局部變量   
30.             long x = mt.a ;    
31.             if ( x == i ){    
32.                 i ++ ;    
33.             }  
34.             if ( x == i ){    
35.                 i ++ ;    
36.             }     
37.         }    
38.         System.out.print("局部變量: "+(System.currentTimeMillis() - time) + "ms\n\n");    
39.             
40.             
41.          
42.     }  
43.    }    

用於測試的app為一個surfaceview為主體的重力感應游戲。

為了體現效率方面的變化，我在surfaceview中設定一個變量記錄了每60秒游戲中，真正執行代碼的時間總和（游戲中使用了50ms為周期的while循環，一周期中不到50秒的會調用sleep()補全時間。這個測試時間就是累加了每個周期中執行游戲邏輯的時間）。

對修改前和修改後的程序，我分別做了二十次測試，取平均值。

意外的是，在我作出如上修改之前，平均值為23.690ms，調整代碼後，測試時間平均值均為23.873ms，如此看來，反而修改後的代碼有了略微的劣勢。

總結：

個人認為，第一、第二條中所講都是常規編程需要注意的內容，可以確信。

而第三條，作為應對CPU、內存能力有限的移動終端，理論上似乎不錯，但實際結果運行卻並不如意。

個人猜想，是否是Dalvik虛擬機本身已經對成員變量的訪問方面做過了優化？ 在網上搜了下，大多都說道，Dalvik是基於寄存器的虛擬機，而常規的JVM是基於棧的虛擬機。對於Dalvik , 在經過SUN JDK編譯器生成字節碼.class後，還會用DX工具再次優化生成.dex文件。 或許兩者本身優化策略的不同，導致了這一試驗結果。

沒有找到更多關於Dalvik的介紹，附一覺得不錯的鏈接：Dalvik虛擬機淺識1 。

歡迎大家探討。