關於Android開發的40條優化建議

以下是開始Android程式設計的好方法：

1、找一些與你想開發的功能類似的程式碼；

2、調整它，嘗試讓它變成你想要的；

3、回顧開發中遇到的問題

4、使用StackOverflow來解決遇到的問題

對每個你想實現的東西重複上述過程。採用這種方法能夠激勵你，因為你在保持不斷迭代更新，在這個過程裡面你會學到很多。當然，當你釋出應用的時候你還要去做一些更深入的東西。

從一些能夠正常編譯的程式碼到成為一個應用程式，這是一個質的飛躍，比起iOS，Android則表現的更加明顯。當iOS應用釋出的時候，實際上只是在一種裝置之間跳躍，對iOS很多機型而言都很相似，同樣大小的螢幕，並且都有良好的硬體支撐，95%上機型執行相同版本的iOS作業系統。然而在Android應用中，並不會遇到這種情況。

我們的程式必須能夠應對一切：包括不同的螢幕、處理器、定製作業系統、API以及其他任何帶Android作業系統的裝置。

以下是我認為對Android比較好的一些建議。

目標螢幕尺寸及解決辦法

在Android的大世界裡有超過100種不同的螢幕尺寸，當然，解決螢幕適配的方法也很多。為了進行Android的螢幕適配，你需要確定以下兩件事情：

1、對不同的螢幕解析度和尺寸有一個良好的佈局和結構來適應它

2、UI影像能夠適應不同解析度的手機

這些都是獨立的任務，也許你有一個超級的tablet佈局，但佈局上的圖片看起來很糟。接下來我會依次討論它們。

為不同的螢幕尺寸設計佈局

1、一般用ScrollView+ListView輕鬆搞定它

當我們有一系列不同螢幕尺寸的手機時，它們之間最大的不同就是螢幕的高度。因此ScrollView和ListView通常顯示良好，雖然有時侯它們並不能完全覆蓋整個螢幕。在OpenSignal中的Dashboard標籤下我們可以看到所有東西，他們不需要滑動，然而對於許多高階控制元件來說，滑動展示並非一件壞事。如果你能夠讓你的應用適配各種不同尺寸的手機，那就很完美了，否則這兩個控制元件會讓你用最小的代價來保證你的應用適配大多數不同的螢幕尺寸。

Dashboard風格的就不需要滾動

2、使用資料夾結構

Android 的res資料夾結構非常強大, 它允許開發者更改圖片、文字、佈局檔案、尺寸規格、顏色等資源。下面的例子展示了在res資料夾的用處:

在values-small資料夾中有一個 bools.xml 檔案, 檔案中有以下幾行程式碼：

<resources>
    <bool name="small_screen">true</bool>
</resources>

在程式碼中可以進行呼叫：

if(getResources().getBoolean(R.bool.small_screen)){
    getSupportActionBar().hide();
}

在小螢幕裝置中把boolean值設為true，因而將ActionBar隱藏以節省空間。這段程式碼正是牛逼的ActionBarSherlock 擴充套件庫中的一部分，稍後會談到他。在values-sw360dp資料夾中，存放螢幕寬度為360dp的res檔案。相應程式碼如下：

<resources>
    <bool name="small_screen">false</bool>
</resources>

在大螢幕裝置上ActionBar就置為可見狀態。

我們並不一定需要將 bools.xml 檔案放入 values-sw400dp 資料夾中, 因為Android作業系統會自動按相應路徑搜尋. 例如一個裝置寬 600dp (600/160=3.75 英寸) 作業系統會在values-sw600dp 和其對應資料夾中搜尋 bools.xml 檔案, 若沒有找到則搜尋 values-sw400dp 資料夾，再沒找到就搜尋 values-sw360dp 資料夾，以此類推。

3、160dp = 1英寸。320 dp = 2英寸。dp = dip。

4、你可以用這些目錄結構技巧來應付所有資源型別。

比如xml佈局用指定的大小來解決，例如layout-sw360dp目錄可以適配目標寬是360dp的機型，如果還需要支援橫豎屏的話可以採用以下目錄：

layout-sw360dp-land
layout-sw360dp-port

等等，如果你有一半的使用者是阿拉伯的，那就將佈局檔案改為下面這樣：

layout-sw360dp-land
layout-sw360dp-port
layout-sw360dp-land-ar
layout-sw360dp-port-ar

前兩個資料夾的佈局可以適用於所有語言，後兩個的-ar表示阿拉伯語。

5、res資源命名規則：

XXX                        // 沒有字尾，預設適用於Nexus One，Droid 2,S2 
XXX-sw360dp                // 比較大的手機 – Galaxy Nexus, S3, S4 
XXX-sw600dp                // 7"  平板 
XXX-sw720dp                // 10" 平板

在Kindle裝置有點不同的地方，如下所示：

XXX-large-mdpi             // kindle fire 7"
XXX-large-hdpi             // kindle fire 7" HD

6、如果你不想這樣佈局的話，可以採用 dimens.xml 檔案。

如果你剛才用心看了，你就會發現剛才我的values目錄裡有很多dimens.xml，因為我更喜歡在佈局檔案裡設定值，在每一個xml佈局檔案裡我通常喜歡這麼做：

<ImageView
    android:layout_centerHorizontal="true"
    android:layout_marginTop="@dimen/small_margin"
    android:layout_width="@dimen/dashBoardWidth"
    android:layout_height="@dimen/dashBoardHeight"
    android:id="@+id/dashboard"/>

small_margin的值是在dimen.xml檔案裡面定義的：

<resources>
    <dimen name="small_margin">4dp</dimen>
</resources>

這個4dp變數寫在所有dimen檔案裡。我有一個Excel檔案，裡面建立了所有不同尺寸的定義。也許你會有個疑問：為什麼不讓Android作業系統來處理這些螢幕適配的問題？為什麼不用一個values目錄和一個layout目錄來代替所有寫死的值呢？那當然是可以的，如果設定得當，都會得到所有的尺寸，但是對於有些元素並沒有那麼容易就能得到尺寸。

7、讓空白大小大於影像大小，讓影像大小大於按鈕大小。

如果將按鈕，多選框，切換控制元件放大後是很醜的。一個100dip(0.63″)大小的按鈕是不想在平板上顯示為原來兩倍寬度200dip(1.25″)的，原因是螢幕變大了，但是這不代表平板是給巨人用的。我們可以這麼做，在按鈕和圖片擴充套件的位置新增空白。

8、用GraphicalLayout工具快速預覽。

GraphicalLayout是一種WYSIWG XML編輯器。不過我喜歡直接寫程式碼，而不是拖放控制元件而丟棄的程式設計，但在新增一些元素之後，可以在GraphicalLayout的下拉選擇選單裡選擇不同螢幕尺寸進行測試。

9、不要對所有的圖片進行縮放。

用佈局檔案來適應不同螢幕尺寸的方法只是成功的一半，佈局裡的控制元件(如：圖片)也要能在高解析度螢幕下良好展示。比較簡單的方式就是建立一套完整的圖片目錄讓它們與各種drawable目錄進行匹配。

drawable-sw600dp-ldpi

drawable-sw600dp-mdpi

drawable-sw600dp-hdpi

drawable-sw600dp-xhdpi

drawable-sw600dp-xxhdpi等等…

然而其實並不需要這樣做，一般來說有drawble-ldpi, drawable-hdpi等目錄就足夠了，並不需要將所有的都加上。

10、儘量避免使用點陣圖(bitmap)(jpg、png)。

對於一些圖示來說，點陣圖是個不錯的選擇，因為它們使用簡單。但是如果可以避免使用點陣圖，你可以節省很多空間，採用不同的方法也可以達到很好的結果。

11、用XML進行繪圖。

點陣圖都可以用XML繪圖來代替的，雖然XML繪圖不是萬能的，但是它的方便性還是使我感到震驚，在Android開發文件中有詳細的介紹，下面舉個簡單例子：

    <shape
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:shape="rectangle" >

        <corners
            android:bottomRightRadius="14dp"
            android:bottomLeftRadius="14dp"
            android:topLeftRadius="14dp"
            android:topRightRadius="14dp"/>

        <gradient
            android:startColor="@color/off_white"
            android:endColor="@color/pale_yellow"
            android:angle="270"
            android:type="linear"/>

        <stroke
            android:width="4dp"
            android:color="@color/osm_darkerblue"/>

    </shape>

上面程式碼定義了一個圓角矩形，一個有漸變的邊(深藍)。你可以在佈局檔案引用他，並且它適應任何螢幕。用它可以做出理想的按鈕背景。

12、採用更多XML繪圖。

再來個用XML繪圖製作出能更加讓你興奮的例子，下面的雷達效果看起來是不是更加的複雜呢：

不使用點陣圖對於UI是沒有壞處的(icon圖示例外)。

13、還是XML繪圖(如果有必要，那就用點陣圖)。

那我們怎樣畫一個酷炫的天氣圖示-讓燈泡動態的根據光的強度來調節其亮度，以及如何在點選後讓它旋轉呢？這裡我們用點陣圖和XML結合起來做個例子：

燈泡我們用PNG圖：icon_magnitude_min(一個空的燈泡)和icon_magnitude_max(最高亮度的燈泡)，然後我們動態的裁剪後者。為了實現這個目標我是這樣做的：

    <layer-list xmlns:android="http://schemas.android.com/apk/res/android">
        <item
            android:drawable="@drawable/icon_magnitude_min" />
        <item >
            <clip
                android:clipOrientation="vertical"
                android:drawable="@drawable/icon_magnitude_max"
                android:gravity="top" />
        </item>
    </layer-list>

在java程式中進行引用，用於控制光的強度。

14、為什麼要用9-patch(當你可以用xml、drawables的時候)?

Android具有使用.9檔案來定義drawables的選擇，有些教程闡述了怎樣用它們來做一個按鈕，這樣可以在拉伸的時候保持幾個邊角的大小不變 (並且避免了畫素處理)。如果你已經知道怎樣使用.9，可能是從Web設計中學會的，那麼它們或許值得一用。如果你對9-patches並不熟悉，建議你保持原樣。如果你想適應一些諸如圓角或者顏色，這就像回到了影像編輯器的時代。許多用.9實現的效果也可以通過XML實現。

15、通過重寫onDraw()方法實現自定義控制元件。

有些事情XML並不能完全實現，我們在OpenSignal和WeatherSignal中畫過許多影像，為此有許多的庫，但是我們要為自定義影像自己編寫程式碼。這很有趣，或許你永遠也不需要做這個，但為了使影像高度動態並實現自定義，這經常是唯一可行的辦法。

16、在不能使用XML的地方使用SVG。

有時候覆蓋onDraw()並勤勤懇懇的為自定義view編寫程式碼畫出需要的線條與弧線是過於技術化了。畢竟有一種向量影像語言Scalable Vector Graphics（可擴充套件向量圖形）。它也是史上最酷的Android應用之一——Androidify的動力來源。事實上他們建立這個庫就是為了那款應用，他們將它釋出在這裡：SVG for Android 。這也就是我們在OpenSignal中畫儀表盤所用到的。

17、對SVG檔案GZip壓縮，將它們變得更小它們就會處理的更快。

18、SVG庫也並非支援一切.

在一些特定的alpha通道中似乎不能正常工作，你甚至不得不在程式碼中將它們移除。

達到在Android所有版本里展示一致的目標

19、在一些android系統裡（如TouchWhizz/HTC Sense/MotoBlur等等），預設的Button和其他UI元件會跟谷歌原生系統裡的看起來差別很大。我希望這不是真的，但事實卻是如此。

20、自定義UI控制元件。

為了保證你的app在所有的裝置裡看起來是一樣的效果，你將需要自定義所有的東西。這其實沒有你想象中那麼難，只要你做到了，你將能更加好地把握你的app的展示外觀。

21、Selectors是建立Button的利器。

我們在上面提到了如何在XML裡定義button的背景，但是你將如何建立一個當按下去會改變的button呢？很簡單，像下面那樣在xml檔案裡定義背景。該xml檔案能夠改變Button的點選狀態與正常狀態。

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_pressed="true" android:drawable="@drawable/btn_bg_selected" />
    <item android:state_focused="true" android:drawable="@drawable/btn_bg" />
    <item android:drawable="@drawable/btn_bg" /> <!-- default -->
</selector>

22、在Honeycomb之前的版本里並沒有ActionBar及很多animation樣式的，所以可以使用ActionBarSherlock以及NineOldAndroids來代替。

Jake Wharton寫的Android開源元件都是API向下相容的精心傑作。更讓人欣慰的是，ABS 擁有強大的功能用來定義ActionBar。

把響應速度作為目標

23、在執行慢的手機上測試。

你將在執行慢的手機上發現很多問題，即使它讓你抓狂，因為沒人會喜歡執行慢的程式。

24、儘量減少XML佈局層次。

更多的層次意味著系統將為解析你的程式碼付出更多的工作，這將會讓影像渲染的更慢。

25、用Android Lint檢查程式。

在工程目錄上右鍵選擇Eclipse>Android Tools>Run Lint。它將會得到應用的一些相關資訊，並能提高程式的執行速度，或者它能讓你得程式碼更加清爽。

26、Android Lint可以得到錯誤資訊。

它可以給你的程式碼提供很詳細的資訊，並在你出錯之前就可以給做出提示。

27、用<merge>可以幫助你減少檢視層次結構。

這是一種簡單的方式來去除多餘的層次。好的文章都對此有所解釋，而且在 Android Developer中它也顯得與眾不同。

28、用HierarchyViewer可以直觀的看到你佈局的層次。

這個智慧的工具可以顯示佈局中有多少層次，而且可以提示出那些可以讓程式變慢。

29、如果可以儘量用RelativeLayout。

AbsoluteLayout已經過期了，就不要用了。你經常會遇到在RelativeLayout和LinearLayout中做出選擇的情況，那就直接用RelativeLayouot吧，因為它可以讓你減少檢視層次。比如，你想實現一個如下檢視：

A Box 在螢幕左半邊 | B Box在螢幕右半邊

你首先會想到這麼做：

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal">

        <TextView
            android:layout_width="0dip"
            android:layout_height="wrap_content"
            android:layout_weight="1"
            android:text="Box A takes up left half of the screen" />

        <TextView
            android:layout_width="0dip"
            android:layout_height="wrap_content"
            android:layout_weight="1"
            android:text="Box B takes up left half of the screen" />
    </LinearLayout>

程式碼沒問題，其實你也可以這麼做：

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal">

        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_toLeftOf="@+id/dummy_center"
            android:text="Box A takes up left half of the screen" />

        <View
            android:id="@+id/dummy_center"
            android:layout_width="0dip"
            android:layout_height="0dip"
            android:layout_gravity="center" />

        <TextView
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_toRightOf="@+id/dummy_center"
            android:text="Box B takes up left half of the screen" />
    </RelativeLayout>

第二個表單比第一個難看的多，事實上是相當的糟糕：我們已經介紹過一個完整的新元素了。但是假如我們要給每個Box里加入一個圖片，一般的我們將這樣做：

A Box在螢幕左半邊 圖片 | B Box在螢幕右半邊 圖片

用第一中方法，你得建立一個有兩個層次的LinearLayout，如果用第二種方法，你可以直接在同一個RelativeLayout中加入圖片，比如要指定第一個圖片必須在“dummy_center”的左邊，而且一個TextView A必須也在其左側。那麼你就得用7個元素3個檢視層次了(LinearLayout 方式)，而(RelativeLayout方式)只用6個元素2個層次，這樣所有的工作新增完成。

30、用一些擴充套件工具如DDMS。

這可以幫助你發現一些不必要的網路呼叫、檢視電池使用量、垃圾回收資訊，狀態變化(例子：當回撥onStop和onDestroy時)等。LittleEye是我目前比較喜歡的工具。

31、用AsyncTasks。

Anroid工程團隊受夠了人們經常在UI執行緒裡面實現網路呼叫(注：耗時操作，容易阻塞UI重新整理)，所以他們實現了一些可產生編譯級錯誤資訊的API。但是仍然在很多app中的一些工作會拖垮UI執行緒，我們要考慮到UI佈局要快以及提高UI的響應性。

目標機器空間小

32、一些Aandroid裝置有100mb空間大小的限制。

現在情況已有變化了，但是仍然有很多使用者還會擔心5Mb大小的app會浪費空間。如果你可以選擇將app裝入SD卡的話，這就不是問題了，但如果你的app需要在onBoot裡啟動的話你就不能裝入SD卡了(例子：如一些窗體小部件).甚至對於一些新的裝置，如果能很快的下載一個小的APK的話，使用者還是很高興的。

33、用XML資源（我發誓上次我已經說過了），這將比PNG資源節省很多空間。

當你僅僅需要一個可以滿足很多螢幕大小的配置時，一個XML檔案會比能實現同樣功能的PNG省空間。

34、如果要用PNG，最好優化一下(用PNGCrush或ImageOptim)

目標Bug

35、在Android控制檯裡檢查所有被自動檢測出來的bug。

36、ProGuard現在是預設啟動著的。

Proguard太好用了 (提高你app的速度和降低檔案大小)，但這也讓StackTraces 非常難以處理。你將需要重新追蹤你的StackTraces，因此你將需要繼續保留在每次構建中建立的Proguard的對映檔案。我把它們都放到以程式碼版本號命名的資料夾裡。

37、為了顯示StackTraces裡的行數，你需要修改ProGuard的配置。

確認你的proguard.cfg擁有下面這句話：

-keepattributes SourceFile,LineNumberTable

38、使用staged rollouts。測試5%的基礎使用者，並且觀察bug報告。

39、使用真實裝置測試平臺。

Device Anywhere and Perfecto Mobile提供了虛擬測試平臺，在那裡，你可以使用真正的移動裝置。我發現他們有一些不好的地方，假如連續不斷地進行測試的話，會導致有一些不好的情況發生。如果你在辦公的環境裡工作，或者有一些Android開發的好友，那麼去啟動一個“裝置池”吧。

40、多寫程式碼少寫部落格。

其實不是的, 分享就是關愛, 我只是想不出第40條寫什麼罷了。

英文原文：http://opensignal.com/blog/2013/07/30/40-developer-tips-for-android-optimization/