#Android性能優化 --- ##合理管理內存 --- ###節制的使用Service 如果應用程序需要使用Service來執行后臺任務的話，只有當任務正在執行的時候才應該讓Service運行起來。當啟動一個Service時，系統會傾向于將這個Service所依賴的進程進行保留，系統可以在LRUcache當中緩存的進程數量也會減少，導致切換程序的時候耗費更多性能。我們可以使用IntentService，當后臺任務執行結束后會自動停止，避免了Service的內存泄漏。 ###當界面不可見時釋放內存 當用戶打開了另外一個程序，我們的程序界面已經不可見的時候，我們應當將所有和界面相關的資源進行釋放。重寫Activity的onTrimMemory()方法，然后在這個方法中監聽TRIM_MEMORY_UI_HIDDEN這個級別，一旦觸發說明用戶離開了程序，此時就可以進行資源釋放操作了。 ###當內存緊張時釋放內存 onTrimMemory()方法還有很多種其他類型的回調，可以在手機內存降低的時候及時通知我們，我們應該根據回調中傳入的級別來去決定如何釋放應用程序的資源。 ###避免在Bitmap上浪費內存 讀取一個Bitmap圖片的時候，千萬不要去加載不需要的分辨率。可以壓縮圖片等操作。 ###是有優化過的數據集合 Android提供了一系列優化過后的數據集合工具類，如SparseArray、SparseBooleanArray、LongSparseArray，使用這些API可以讓我們的程序更加高效。HashMap工具類會相對比較低效，因為它需要為每一個鍵值對都提供一個對象入口，而SparseArray就避免掉了基本數據類型轉換成對象數據類型的時間。 ###知曉內存的開支情況 * 使用枚舉通常會比使用靜態常量消耗兩倍以上的內存，盡可能不使用枚舉 * 任何一個Java類，包括匿名類、內部類，都要占用大概500字節的內存空間 * 任何一個類的實例要消耗12-16字節的內存開支，因此頻繁創建實例也是會在一定程序上影響內存的 * 使用HashMap時，即使你只設置了一個基本數據類型的鍵，比如說int，但是也會按照對象的大小來分配內存，大概是32字節，而不是4字節，因此最好使用優化后的數據集合 ###謹慎使用抽象編程 在Android使用抽象編程會帶來額外的內存開支，因為抽象的編程方法需要編寫額外的代碼，雖然這些代碼根本執行不到，但是也要映射到內存中，不僅占用了更多的內存，在執行效率上也會有所降低。所以需要合理的使用抽象編程。 ###盡量避免使用依賴注入框架 使用依賴注入框架貌似看上去把findViewById()這一類的繁瑣操作去掉了，但是這些框架為了要搜尋代碼中的注解，通常都需要經歷較長的初始化過程，并且將一些你用不到的對象也一并加載到內存中。這些用不到的對象會一直站用著內存空間，可能很久之后才會得到釋放，所以可能多敲幾行代碼是更好的選擇。 ###使用多個進程 謹慎使用，多數應用程序不該在多個進程中運行的，一旦使用不當，它甚至會增加額外的內存而不是幫我們節省內存。這個技巧比較適用于哪些需要在后臺去完成一項獨立的任務，和前臺是完全可以區分開的場景。比如音樂播放，關閉軟件，已經完全由Service來控制音樂播放了，系統仍然會將許多UI方面的內存進行保留。在這種場景下就非常適合使用兩個進程，一個用于UI展示，另一個用于在后臺持續的播放音樂。關于實現多進程，只需要在Manifast文件的應用程序組件聲明一個android:process屬性就可以了。進程名可以自定義，但是之前要加個冒號，表示該進程是一個當前應用程序的私有進程。 ##分析內存的使用情況 --- 系統不可能將所有的內存都分配給我們的應用程序，每個程序都會有可使用的內存上限，被稱為堆大小。不同的手機堆大小不同，如下代碼可以獲得堆大小： ``` ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE); int heapSize = manager.getMemoryClass(); ``` 結果以MB為單位進行返回，我們開發時應用程序的內存不能超過這個限制，否則會出現OOM。 ###Android的GC操作 Android系統會在適當的時機觸發GC操作，一旦進行GC操作，就會將一些不再使用的對象進行回收。GC操作會從一個叫做Roots的對象開始檢查，所有它可以訪問到的對象就說明還在使用當中，應該進行保留，而其他的對系那個就表示已經不再被使用了。 ###Android中內存泄漏 Android中的垃圾回收機制并不能防止內存泄漏的出現導致內存泄漏最主要的原因就是某些長存對象持有了一些其它應該被回收的對象的引用，導致垃圾回收器無法去回收掉這些對象，也就是出現內存泄漏了。比如說像Activity這樣的系統組件，它又會包含很多的控件甚至是圖片，如果它無法被垃圾回收器回收掉的話，那就算是比較嚴重的內存泄漏情況了。 舉個例子，在MainActivity中定義一個內部類，實例化內部類對象，在內部類新建一個線程執行死循環，會導致內部類資源無法釋放，MainActivity的控件和資源無法釋放，導致OOM,可借助一系列工具，比如LeakCanary。 ##高性能編碼優化 --- 都是一些微優化，在性能方面看不出有什么顯著的提升的。使用合適的算法和數據結構是優化程序性能的最主要手段。 ###避免創建不必要的對象 不必要的對象我們應該避免創建： * 如果有需要拼接的字符串，那么可以優先考慮使用StringBuffer或者StringBuilder來進行拼接，而不是加號連接符，因為使用加號連接符會創建多余的對象，拼接的字符串越長，加號連接符的性能越低。 * 在沒有特殊原因的情況下，盡量使用基本數據類型來代替封裝數據類型，int比Integer要更加有效，其它數據類型也是一樣。 * 當一個方法的返回值是String的時候，通常需要去判斷一下這個String的作用是什么，如果明確知道調用方會將返回的String再進行拼接操作的話，可以考慮返回一個StringBuffer對象來代替，因為這樣可以將一個對象的引用進行返回，而返回String的話就是創建了一個短生命周期的臨時對象。 * 基本數據類型的數組也要優于對象數據類型的數組。另外兩個平行的數組要比一個封裝好的對象數組更加高效，舉個例子，Foo[]和Bar[]這樣的數組，使用起來要比Custom(Foo,Bar)[]這樣的一個數組高效的多。 盡可能地少創建臨時對象，越少的對象意味著越少的GC操作。 ###靜態優于抽象 如果你并不需要訪問一個對系那個中的某些字段，只是想調用它的某些方法來去完成一項通用的功能，那么可以將這個方法設置成靜態方法，調用速度提升15%-20%，同時也不用為了調用這個方法去專門創建對象了，也不用擔心調用這個方法后是否會改變對象的狀態(靜態方法無法訪問非靜態字段)。 ###對常量使用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>方法了，因為所有的常量都會在dex文件的初始化器當中進行初始化。當我們調用intVal時可以直接指向42的值，而調用strVal會用一種相對輕量級的字符串常量方式，而不是字段搜尋的方式。 這種優化方式只對基本數據類型以及String類型的常量有效，對于其他數據類型的常量是無效的。 ###使用增強型for循環語法 ``` static class Counter { int mCount; } Counter[] mArray = ... public void zero() { int sum = 0; for (int i = 0; i < mArray.length; ++i) { sum += mArray[i].mCount; } } public void one() { int sum = 0; Counter[] localArray = mArray; int len = localArray.length; for (int i = 0; i < len; ++i) { sum += localArray[i].mCount; } } public void two() { int sum = 0; for (Counter a : mArray) { sum += a.mCount; } } ``` zero()最慢，每次都要計算mArray的長度，one()相對快得多，two()fangfa在沒有JIT(Just In Time Compiler)的設備上是運行最快的，而在有JIT的設備上運行效率和one()方法不相上下，需要注意這種寫法需要JDK1.5之后才支持。 Tips:ArrayList手寫的循環比增強型for循環更快，其他的集合沒有這種情況。因此默認情況下使用增強型for循環，而遍歷ArrayList使用傳統的循環方式。 ###多使用系統封裝好的API 系統提供不了的Api完成不了我們需要的功能才應該自己去寫，因為使用系統的Api很多時候比我們自己寫的代碼要快得多，它們的很多功能都是通過底層的匯編模式執行的。 舉個例子，實現數組拷貝的功能，使用循環的方式來對數組中的每一個元素一一進行賦值當然可行，但是直接使用系統中提供的System.arraycopy()方法會讓執行效率快9倍以上。 ###避免在內部調用Getters/Setters方法 面向對象中封裝的思想是不要把類內部的字段暴露給外部，而是提供特定的方法來允許外部操作相應類的內部字段。但在Android中，字段搜尋比方法調用效率高得多，我們直接訪問某個字段可能要比通過getters方法來去訪問這個字段快3到7倍。但是編寫代碼還是要按照面向對象思維的，我們應該在能優化的地方進行優化，比如避免在內部調用getters/setters方法。 ##布局優化技巧 --- ###重用布局文件 **<include>** <include>標簽可以允許在一個布局當中引入另一個布局，那么比如說我們程序的所有界面都有一個公共的部分，這個時候最好的做法就是將這個公共的部分提取到一個獨立的布局中，然后每個界面的布局文件當中來引用這個公共的布局。 Tips:如果我們要在<include>標簽中覆寫layout屬性，必須要將layout_width和layout_height這兩個屬性也進行覆寫，否則覆寫xiaoguo將不會生效。 **<merge>** <merge>標簽是作為<include>標簽的一種輔助擴展來使用的，它的主要作用是為了防止在引用布局文件時引用文件時產生多余的布局嵌套。布局嵌套越多，解析起來就越耗時，性能就越差。因此編寫布局文件時應該讓嵌套的層數越少越好。 舉例：比如在LinearLayout里邊使用一個<include>布局。<include>里邊又有一個LinearLayout，那么其實就存在了多余的布局嵌套，使用merge可以解決這個問題。 ###僅在需要時才加載布局 某個布局當中的元素不是一起顯示出來的，普通情況下只顯示部分常用的元素，而那些不常用的元素只有在用戶進行特定操作時才會顯示出來。 舉例：填信息時不是需要全部填的，有一個添加更多字段的選項，當用戶需要添加其他信息的時候，才將另外的元素顯示到界面上。用VISIBLE性能表現一般，可以用ViewStub。ViewStub也是View的一種，但是沒有大小，沒有繪制功能，也不參與布局，資源消耗非常低，可以認為完全不影響性能。 ``` <ViewStub android:id="@+id/view_stub" android:layout="@layout/profile_extra" android:layout_width="match_parent" android:layout_height="wrap_content" /> ``` ``` public void onMoreClick() { ViewStub viewStub = (ViewStub) findViewById(R.id.view_stub); if (viewStub != null) { View inflatedView = viewStub.inflate(); editExtra1 = (EditText) inflatedView.findViewById(R.id.edit_extra1); editExtra2 = (EditText) inflatedView.findViewById(R.id.edit_extra2); editExtra3 = (EditText) inflatedView.findViewById(R.id.edit_extra3); } } ``` tips：ViewStub所加載的布局是不可以使用<merge>標簽的，因此這有可能導致加載出來出來的布局存在著多余的嵌套結構。