我的Android進階之旅------>對Android開發人員有益的40條最佳化建議

　　2: 使用檔案夾. Android 的資源檔夾結構非常強大, 它允許開發人員將不同的圖片、字串、布局檔案、外形、顏色這些資源，在api、代碼、螢幕尺寸等部分. 下面是一個例子，展示了在資源檔夾下你可以怎樣做:

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

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

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

　　建議3:160dp = 1英寸。320 dp = 2英寸。dp = dip

　　建議4:你可以用這些目錄結構技巧來應付所有資源類型，比如你的XML布局用指定的系統目錄名稱

　　建議5：資源規則簡介：

　　XXX //例子：沒有添加目錄名：預設-適用於Nexus One，Droid 2,S2

建議6：如果你不想裁剪所有的布局檔案，你可以用dimens.xml檔案。你要是留心我上面的文章，你就會注意到在我的values目錄裡有很多dimens.xml，這樣是因為我更喜歡在一個layout.xml裡設定值，在每一個布局檔案裡我喜歡這樣做：

<ImageViewandroid: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> <dimenname="small_margin">4dp</dimen></resources>

　　建議7:讓空白空間大於映像空間。讓映像空間大於按鈕的大小。如果將按鈕，多選框，切換控制項放大後是很醜陋的。一個100dip(0.63")大小的按鈕是不想在平板上顯示為原來兩倍寬度200dip(1.25")的.原因是螢幕變大了，這不是說平板是給巨人用的。我們可以這樣做，在按鈕增加的空間和圖片擴充的空間裡添加空白。

　　建議8:用GraphicalLayout工具快速預覽。GraphicalLayout是WYSIWG XML編輯器。我喜歡直接編寫元素-而不是拖，丟棄的可見編程方式，但在添加一些元素之後，可以在GraphicalLayout的下拉選擇菜單裡選擇不同螢幕尺寸進行測試。

                               

　　建議9:不要把所有的圖片都縮放了。用布局檔案來適應不同螢幕尺寸的方法只是成功的一半，布局裡的元素(如：圖片)也要能在高解析度的螢幕下良好工作。在概念上比較簡單的方式就是建立一套完整的圖片目錄並將它們與很多drawable目錄匹配起來。

　　drawable-sw600dp-mdpi
　　drawable-sw600dp-hdpi
　　drawable-sw600dp-xhdpi
　　drawable-sw600dp-xxhdpi
　　...其它的類似。

　　建議10:避免使用位元影像(jpg,png)。對於一些表徵圖來說，用位元影像是個不錯的選擇，因為它們使用簡單。但是如果可以避免使用位元影像，你可以節省很多空間。但用不同的方法也可以達到很好的結果。

　　建議11:用XML繪圖。位元影像都可以用XML繪圖來代替的。XML繪圖不是萬能的，但是它的方便性還是使我感到驚訝。Android開發文檔中有詳細的介紹，這裡有個簡單的例子：

<shapexmlns:android="http://schemas.android.com/apk/res/android"android:shape="rectangle"><cornersandroid:bottomRightRadius="14dp"android:bottomLeftRadius="14dp"android:topLeftRadius="14dp"android:topRightRadius="14dp"/><gradientandroid:startColor="@color/off_white"android:endColor="@color/pale_yellow"android:angle="270"android:type="linear"/><strokeandroid:width="4dp"android:color="@color/osm_darkerblue"/></shape>

　　建議12:用更多的XML繪圖。再來介紹一個用XML繪圖製作出能更加讓你興奮的例子，下面的雷達背景看起來是不是更加的複雜：

　　建議13:仍然用更多的XML繪圖(如果必須，就用位元影像)。那我們怎樣為天氣訊號構建一個超酷的表徵圖-讓燈泡動態依據光的強度來進行自動填滿，以及怎麼點擊指標後讓其旋轉呢？這裡我們用位元影像和XML結合起來做個例子：

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

　　建議14: 為什麼要用9-patch (當你可以用XML drawables的時候)? Android具有使用9-patches 來定義drawables的選擇，有些教程闡述了怎樣用它們來做一個按鈕，這樣可以在伸展的時候保持幾個角不變 (並且避免了像素處理)。如果你已經知道怎樣使用9-patches，可能是從web設計中學會的，那麼它們或許值得一用。如果你對9-patches並不熟悉，我建議你維持原樣。如果你想適應什麼東西——例如拐角的圓弧或者顏色，建立9個小塊要比建立位元影像更多被涉及，這就像回到了影像編輯器的時代。許多用9-patches獲得的效果也可以通過XML獲得。

　建議15: 通過覆蓋onDraw()建立自訂views. 有些事情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等等），預設的buttons和其他UI組件會跟原生系統裡的看起來差別很大。我希望這不是真的，但事實卻是如此。

　　建議20：自訂你的UI組件。為了確定你的app在所有的裝置裡看起來是一致的，你將需要自訂所有的東西。這其實沒有你想象中那麼難，只要你做到了，你將能更加好地把握到你的app的展示外觀。

　　建議21：Selectors是建立buttons的利器。我們在上面提到了如何在XML裡定義button的背景，但是你將如何建立一個當按下去會改變的button呢？很簡單：像下面那樣在xml檔案裡定義背景。該xml檔案將接收到button目前狀態並且在外觀上做出相應的改變。

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

　　建議22:在Honeycomb之前的版本裡時不存在ActionBar跟很多 animation  樣式的，所以可以使用ActionBarSherlock 跟NineOldAndroids來代替。Jake Wharton寫的Android開源 組件都是往下相容的精心傑作。更為驚喜的是，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吧，因為它可以讓你減少視圖層次。比如，你想實現一個如下視圖：

<LinearLayoutandroid:layout_width=”match_parent”android:layout_height=”wrap_content”android:orientation=”horizontal”><TextViewandroid:text=”Box A takes up left half of the screen”android:layout_width=”0dip”android:layout_height=”wrap_content”android:layout_weight=”1″/><TextViewandroid:text=”Box B takes up left half of the screen”android:layout_width=”0dip”android:layout_height=”wrap_content”android:layout_weight=”1″/></LinearLayout>That works just fine, but you could also use:<RelativeLayoutandroid:layout_width=”match_parent”android:layout_height=”wrap_content”android:orientation=”horizontal”><TextViewandroid:text=”Box A takes up left half of the screen”android:layout_width=”match_parent”android:layout_height=”wrap_content”android:layout_toLeftOf=”@+id/dummy_center”/><Viewandroid:id=”@+id/dummy_center”android:layout_width=”0dip”android:layout_height=”0dip”android:layout_gravity=”center”/><TextViewandroid:text=”Box B takes up left half of the screen”android:layout_width=”match_parent”android:layout_height=”wrap_content”android:layout_toRightOf=”@+id/dummy_center”/></RelativeLayout>

　　建議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)
 

　　建議35:在Android開發人員控制台裡檢查所有被自動檢測出來的bugs.　

　　建議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條寫什麼是了。