Android代碼優(yōu)化小技巧總結(jié)
前言
這篇文章主要是介紹了一些小細節(jié)的優(yōu)化技巧，當這些小技巧綜合使用起來的時候，對于整個Android App的性能提升還是有作用的，只是不能較大幅度的提升性能而已。選擇合適的算法與數(shù)據(jù)結(jié)構(gòu)才應(yīng)該是你首要考慮的因素，在這篇文章中不會涉及這方面。你應(yīng)該使用這篇文章中的小技巧作為平時寫代碼的習慣，這樣能夠提升代碼的效率。
代碼性能優(yōu)化建議
通常來說，高效的代碼需要滿足下面兩個規(guī)則：
- 不要做冗余的動作
- 如果能避免，盡量不要分配內(nèi)存
代碼的執(zhí)行效果會受到設(shè)備CPU,設(shè)備內(nèi)存,系統(tǒng)版本等諸多因素的影響。為了確保代碼能夠在不同設(shè)備上都運行良好，需要***化代碼的效率。
避免創(chuàng)建不必要的對象
雖然GC可以回收不用的對象，可是為這些對象分配內(nèi)存，并回收它們同樣是需要耗費資源的。 因此請盡量避免創(chuàng)建不必要的對象，有下面一些例子來說明這個問題：
- 如果你需要返回一個String對象，并且你知道它最終會需要連接到一個StringBuffer，請修改你的實現(xiàn)方式，避免直接進行連接操作，應(yīng)該采用創(chuàng)建一個臨時對象來做這個操作.
- 當從輸入的數(shù)據(jù)集中抽取出Strings的時候，嘗試返回原數(shù)據(jù)的substring對象，而不是創(chuàng)建一個重復的對象。
- 一個稍微激進點的做法是把所有多維的數(shù)據(jù)分解成1維的數(shù)組:
- 一組int數(shù)據(jù)要比一組Integer對象要好很多。可以得知，兩組1維數(shù)組要比一個2維數(shù)組更加的有效率。同樣的，這個道理可以推廣至其他原始數(shù)據(jù)類型。
- 如果你需要實現(xiàn)一個數(shù)組用來存放(Foo,Bar)的對象，嘗試分解為Foo[]與Bar[]要比(Foo,Bar)好很多。(當然，為了某些好的API的設(shè)計，可以適當做一些妥協(xié)。但是在自己的代碼內(nèi)部，你應(yīng)該多多使用分解后的容易。
- 通常來說，需要避免創(chuàng)建更多的對象。更少的對象意味者更少的GC動作，GC會對用戶體驗有比較直接的影響。
選擇Static而不是Virtual
如果你不需要訪問一個對象的值域,請保證這個方法是static類型的,這樣方法調(diào)用將快15%-20%。這是一個好的習慣，因為你可以從方法聲明中得知調(diào)用無法改變這個對象的狀態(tài)。
常量聲明為Static Final
先看下面這種聲明的方式
- static int intVal = 42;
- static String strVal = "Hello, world!";
編譯器會在類***被使用到的時候，使用初始化方法來初始化上面的值，之后訪問的時候會需要先到它那里查找，然后才返回數(shù)據(jù)。我們可以使用static final來提升性能：
- static final int intVal = 42;
- static final String strVal = "Hello, world!";
這時再也不需要上面的那個方法來做多余的查找動作了。 所以，請盡可能的為常量聲明為static final類型的。
避免內(nèi)部的Getters/Setters
像C++等native language,通常使用getters(i = getCount())而不是直接訪問變量(i = mCount).這是編寫C++的一種優(yōu)秀習慣，而且通常也被其他面向?qū)ο蟮恼Z言所采用，例如C#與Java，因為編譯器通常會做inline訪問，而且你需要限制或者調(diào)試變量，你可以在任何時候在getter/setter里面添加代碼。 然而，在Android上，這是一個糟糕的寫法。Virtual method的調(diào)用比起直接訪問變量要耗費更多。那么合理的做法是：在面向?qū)ο蟮脑O(shè)計當中應(yīng)該使用getter/setter，但是在類的內(nèi)部你應(yīng)該直接訪問變量。 沒有JIT(Just In Time Compiler)時，直接訪問變量的速度是調(diào)用getter的3倍。有JIT時,直接訪問變量的速度是通過getter訪問的7倍。 請注意，如果你使用ProGuard, 你可以獲得同樣的效果，因為ProGuard可以為你inline accessors.
使用增強的For循環(huán)寫法
請比較下面三種循環(huán)的方法：
- static class Foo {
- int mSplat;
- }
- Foo[] mArray = ...
- public void zero() {
- int sum = 0;
- for (int i = 0; i < mArray.length; ++i) {
- sum += mArray[i].mSplat;
- }
- }
- public void one() {
- int sum = 0;
- Foo[] localArray = mArray;
- int len = localArray.length;
- for (int i = 0; i < len; ++i) {
- sum += localArray[i].mSplat;
- }
- }
- public void two() {
- int sum = 0;
- for (Foo a : mArray) {
- sum += a.mSplat;
- }
- }
zero()是最慢的，因為JIT沒有辦法對它進行優(yōu)化。
one()稍微快些。
two() 在沒有做JIT時是最快的，可是如果經(jīng)過JIT之后，與方法one()是差不多一樣快的。它使用了增強的循環(huán)方法for-each。
所以請盡量使用for-each的方法，但是對于ArrayList，請使用方法one()。
使用包級訪問而不是內(nèi)部類的私有訪問
參考下面一段代碼
- 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);
- }
- }
我們定義了一個私有的內(nèi)部類（Foo$Inner），它直接訪問了外部類中的私有方法以及私有成員對象。這是合法的，這段代碼也會如同預期一樣打印出”Value is 27”。
問題是，VM因為Foo和（Foo.Inner）是不同的類，會認為在 (Foo.Inner）中直接訪問Foo類的私有成員是不合法的。即使Java語言允許內(nèi)部類訪問外部類的私有成員。為了去除這種差異，編譯器會產(chǎn)生一些仿造函數(shù)：
- /*package*/ static int Foo.access$100(Foo foo) {
- return foo.mValue;
- }
- /*package*/ static void Foo.access$200(Foo foo, int value) {
- foo.doStuff(value);
- }
每當內(nèi)部類需要訪問外部類中的mValue成員或需要調(diào)用doStuff()函數(shù)時，它都會調(diào)用這些靜態(tài)方法。這意味著，上面的代碼可以歸結(jié)為，通過accessor函數(shù)來訪問成員變量。早些時候我們說過，通過accessor會比直接訪問域要慢。所以，這是一個特定語言用法造成性能降低的例子。
如果你正在性能熱區(qū)（hotspot:高頻率、重復執(zhí)行的代碼段）使用像這樣的代碼，你可以把內(nèi)部類需要訪問的域和方法聲明為包級訪問，而不是私有訪問權(quán)限。不幸的是，這意味著在相同包中的其他類也可以直接訪問這些域，所以在公開的API中你不能這樣做。
避免使用float類型
Android系統(tǒng)中float類型的數(shù)據(jù)存取速度是int類型的一半，盡量優(yōu)先采用int類型。
使用庫函數(shù)
盡量使用System.arraycopy()等一些封裝好的庫函數(shù)，它的效率是手動編寫copy實現(xiàn)的9倍多。
Tip: Also see Josh Bloch’s Effective Java, item 47.
謹慎使用native函數(shù)
當你需要把已經(jīng)存在的native code遷移到Android，請謹慎使用JNI。如果你要使用JNI,請學習JNI Tips
關(guān)于性能的誤區(qū)
在沒有做JIT之前，使用一種確切的數(shù)據(jù)類型確實要比抽象的數(shù)據(jù)類型速度要更有效率。(例如，使用HashMap要比Map效率更高。) 有誤傳效率要高一倍，實際上只是6%左右。而且，在JIT之后，他們直接并沒有大多差異。
關(guān)于測量
上面文檔中出現(xiàn)的數(shù)據(jù)是Android的實際運行效果。我們可以用Traceview 來測量，但是測量的數(shù)據(jù)是沒有經(jīng)過JIT優(yōu)化的，所以實際的效果應(yīng)該是要比測量的數(shù)據(jù)稍微好些。
