Android設備作為一種移動設備，不管是記憶體還是CPU的性能都受到了一定的限制，無法做到像PC設備那樣具有超大的記憶體和高性能的CPU，鑒于這一點，這也意味著Android程式不可能無限制地使用記憶體和CPU資源，過多地使用記憶體會導致程式記憶體泄漏，即OOM，而過多的使用CPU資源，一般是指做大量的耗時任務，會導致手機變得卡頓甚至出現程式無法回應的情況，即ANR，由此來看，Android程式的性能問題就變得例外突出了，這對開發人員也提出了更高的要求，為了提高應用程式的性能，本章第一節介紹了一些有效的性能優化方法，

性能優化中一個很重要的問題就是記憶體泄露，記憶體泄漏并不會導致程式功能例外，但是它會導致Android程式的記憶體占用過大，這將提高記憶體溢位的發生幾率，如何避免寫出記憶體泄露的代碼，這和開發人員的水平和意識有很大關系，本章我們也會對記憶體泄漏的常見場景進行介紹，

在做程式設計時，除了要完成功能開發、提高程式的性能以外，開有一個問題也是不容忽視的，那就是代碼的可維護性和可擴展性，如果一個程式的可維護性和可擴展性很差，那就意味著后續的代碼維護代價是相當高的，比如需要對一個功能做一些調整，這可能會出現牽一發而動全身的局面，另外添加新功能時也覺得無從下手，整個代碼看起來可讀性很差，這的確是一份很糟糕的代碼，關于代碼的可維護性和可擴展性，看起來是一個很抽象的問題，其實也并不抽象，它是可以通過一些合理的設計原則去完成的，比如良好的代碼風格、清晰的代碼層級、代碼的可擴展性和合理的設計模式，在本章的第三節對這些設計原則進行介紹，這將在一定程度上提高程式的可維護性和可擴展性，

1.Android的性能優化方法

本節介紹了一些有效的性能優化方法，主要內容包括布局優化、繪制優化、記憶體泄漏優化、ListView優化、Bitmap優化、執行緒優化以及一些性能優化建議，

1.1布局優化

布局優化的思想很簡單，就是盡量減少布局檔案的層級，這個道理是很淺顯的，布局中的層級少了，這就意味著Android繪制時的作業量少了，那么程式的性能自然就提高了，

如何進行布局優化呢？首先洗掉布局中無用的控制元件和層級，其次有選擇地使用性能較低的ViewGroup，比如RelativeLayout，如果布局中既可以用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，這是因為RelativeLayout的功能比較復雜，它的布局程序需要花費更多的CPU時間，FrameLayout和LinearLayout一樣都是一種簡單高效的ViewGroup，因此可以優先考慮使用它們，但是很多時候單純通過一個LinearLayout或者FrameLayout無法實作產品效果，需要通過嵌套的方式來完成，這種情況下還是建議采用RelativeLayout，因為ViewGroup的嵌套就相當于增加了布局的層級，同樣會降低程式的性能，

布局優化的另外一種手段是采用< include >標簽、< merage >標簽和VeiwStub，< include >標簽主要用于布局重用，< merge >標簽一般和< include >配合使用，它可以降低減少布局的層級，而ViewStub則提供了按需加載的功能，當需要時才會將ViewStub中的布局加載到記憶體，這提高了程式的初始化效率，下面分別介紹它們的使用方法，

< include >標簽

< include >標簽可以將一個指定的布局檔案加載到當前的布局檔案中，如下所示：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
	android:orientation="vertical"
	android:layout_width="match_parent"
	android:layout_height="match parent"
	android:background="@color/app_bg"
	android:gravity="center_horizontal">
	
	<include layout="@layout/titlebar"/>
	
	<TextView android:layout_width="match_parent"
		android:layout_height="wrap_content"
		android:text="@string/text"
		android:padding="5dp" />
		
</LinearLayout>

上面的代碼中，@layout/titlebar指定了另外一個布局檔案，通過這種方式就比用把titlebar這個布局檔案的內容再重復寫一遍了，這就是< include >的好處，< include >標簽只支持以android:layout_開頭的屬性，比如android:layout_width、android:layout_height，其他屬性是不支持的，比如android:background，當然，android:id這個屬性是個特例，如果< include >指定了這個id屬性，同時被包含的布局檔案的根元素也指定了id屬性，那么以< include >指定的id屬性為準，需要注意的是，如果< incldue >標簽指定了android:layout_*這種屬性，那么要求android:layout_width和android:layout_height必須存在，否則其他android:layout_*形式的屬性無法生效，下面是一個指定了android:layout_*屬性的示例：

<include android:id="@+id/new_title"
	android:layout_width="match parent"
	android:layout_height="match parent"
	layout="@layout/title"/>

< merge >標簽

< merge >標簽一般和< include >標簽一起使用從而減少布局的層級，在上面的示例中，由于當前檔案是一個豎直方向的LinearLayout，這個時候如果被包含的布局檔案中也采用了豎直方向的LinearLayout，那么顯然被包含的布局檔案中的LinearLayout是多余的，通過< merge >標簽就可以去掉多余的那一層LinearLayout，如下所示：

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

	<Button
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		android:text="@string/one"/>
	
	<Button
		android:layout_width="wrap_content"
		android:layout_height="wrap_content"
		android:text="@string/two"/>
		
</merge>

ViewStub

ViewStub繼承了View，它非常輕量級且寬/高都是0，因此它本身不參與任何的布局和繪制程序，ViewStub的意義在于按需加載所需的布局檔案，在實際開發中，有很多布局檔案在正常情況下不會顯示，比如網路例外時的界面，這個時候就沒有必要在整個界面初始化的時候將其加載進來，通過ViewStub就可以做到在使用的時候再加載，提高了程式初始化時的性能，下面是一個ViewStub的示例：

<ViewStub
	android:id="@+id/stub_import"
	android:inflatedId="@+id/panel_import"
	android:layout="@layout/layout_network_error"
	android:layout_width="match_parent"
	android:layout_height="wrap_content"
	android:layout_gravity="bottom" />

其中stub_import是ViewStub的id，而panel_import是layout/layout_network_error這個布局的根元素的id，如何做到按需加載呢？在需要加載ViewStub中的布局時，可以按照如下兩種方式進行：

((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);

或者：

View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();

當ViewStub通過setVisibility或者inflate方法加載后，ViewStub就會被它內部的布局替換掉，這個時候ViewStub就不再是整個布局結構中的一部分了，另外，目前ViewStub還不支持< merge >標簽，

1.2繪制優化

繪制優化是指View的onDraw方法要避免進行大量的操作，這主要體現在兩個方面，

首先，onDraw中不要創建新的布局物件，這是因為onDraw方法可能會被頻繁呼叫，這樣就會在一瞬間產生大量的臨時物件，這不僅占用了過多的記憶體而且還會導致系統更加頻繁gc，降低了程式的執行效率，

另外一方面，onDraw方法中不要做耗時的任務，也不能執行成千上萬次的回圈操作，盡管每次回圈都很輕量級，但是大量的回圈仍然十分搶占CPU的時間片，這會造成View的繪制程序不流暢，按照Google官方給出的性能優化典范中的標準，View的繪制幀率保證60fps是最佳的，這就要求每幀的繪制時間不超過16ms(16ms = 1000/60)，雖然程式很難保證16ms這個時間，但是盡量降低onDraw方法的復雜度總是切實有效的，

1.3記憶體泄漏優化

記憶體泄漏在開發程序中是一個需要重視的問題，但是由于記憶體泄漏問題對開發人員的經驗和開發意識有較高的要求，因此這也是開發人員最容易犯的錯誤之一，記憶體泄漏的優化分為兩個方面，一方面是在開發程序中避免寫出有記憶體泄漏的代碼，另一方面是通過一些分析工具來找出潛在的記憶體泄漏繼而解決，本節主要介紹一些常見的記憶體泄漏的例子，通過這些例子讀者可以很好地理解記憶體泄漏的發生場景并積累規避記憶體泄漏的經驗，

場景1：靜態變數導致的記憶體泄漏

下面這種情形是一種最簡單的記憶體泄漏，下面的代碼將導致Activity無法正常銷毀，因為靜態變數sContext參考了它，

public class MainActivity extends Activity {
	private static final String TAG = "MainActivity";
	
	private static Context sContext;
	
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		sContext = this;
	}
}

上面的代碼也可以改造一下，如下所示，sView是一個靜態變數，它內部持有了當前Activity，所以Activity仍然無法釋放，

public class MainActivity extends Activity (
	private static final String TAG = "MainActivity";
	
	private static View sView;
	
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);
		sView = new View(this);
	}
}

場景2：單例模式導致的記憶體泄漏

靜態變數導致的記憶體泄漏都太過于明顯，而單例模式所帶來的記憶體泄漏是我們容易忽視的，如下所示，首先提供一個單例模式的TestManager，TestManager可以接收外部的注冊并將外部的監聽器存盤起來，

public class TestManager (
	private List<OnDataArrivedListener> mOnDataArrivedListeners = new ArrayList<OnDataArrivedListener>();
	
	private static class SingletonHolder {
		public static final TestManager INSTANCE = new TestManager();
	}
	
	private TestManager() {
	}
	
	public static TestManager getInstance() {
		return SingletonHolder.INSTANCE;
	}
	
	public synchronized void registerListener(OnDataArrivedListener listener) {
		if (!mOnDataArrivedListeners.contains(listener)) {
			mOnDataArrivedListeners.add(listener);
		}
	}

	public synchronized void unregisterListener (OnDataArrivedListener listener) {
		mOnDataArrivedListeners.remove(listener);
	}
	
	public interface OnDataArrivedListener {
		public void onDataArrived(object data);
	}
}

接著再讓Activity實作OnDataArrivedListener介面并向TestManager注冊監聽，如下所示，下面的代碼由于缺少解注冊操作所以會引起記憶體泄漏，泄露的原因是Activity的物件被單例模式的TestManager所持有，而單例模式的特點是其生命周期和Application保持一致，因此Activity物件無法被及時釋放，

protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	TestManager.getInstance().registerListener(this);
}

場景3：屬性影片導致的記憶體泄漏

從Android3.0開始，Google提供了屬性影片，屬性影片中有一類無限回圈的影片，如果在Activity中播放此類影片且沒有在onDestory中去停止影片，那么影片會一直播放下去，盡管已經無法在界面上看到影片效果了，并且這個時候Activity的View被影片持有，而View又持有Activity，最終Activity無法釋放，下面的影片是無限影片，會泄漏當前Activity，解決方法是在Activity的onDestory中呼叫animator.cancel()來停止影片，

protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	mButton = (Button) findViewById(R.id.button1);
	ObjectAnimator animator = objectAnimator.ofFloat(mButton, "rotation", 0, 360).setDuration(2000);
	animator.setRepeatCount(ValueAnimator.INFINITE);
	animator.start();
	//animator.cancel();
}

1.4回應速度優化

回應速度優化的核心思想是避免在主執行緒中做耗時操作，但是有時候的確有很多耗時操作，怎么辦呢？可以將這些耗時操作放在執行緒中去執行，即采取異步的方式執行耗時操作，回應速度過慢更多地體現在Activity的啟動速度上面，如果在主執行緒中做太多事情，會導致Activity啟動時出現黑屏現象，甚至出現ANR，Android規定，Activity如果5秒種之內無法回應螢屏觸摸事件或者鍵盤輸入事件就會出現ANR，而BroadcastReceiver如果10秒鐘之內還未執行完操作也會出現ANR，

1.5ListView和Bitmap優化

ListView的優化主要分為三個方面：首先要采取ViewHolder并避免在getView中執行耗時操作；其次要根據串列的滑動狀態來控制任務的執行頻率，比如當串列快速滑動時顯然是不太適合開啟大量的異步任務的；最后可以嘗試開啟硬體加速來使ListView的滑動更加流暢，注意ListView的優化策略完全適用于GridView，

Bitmap的優化主要是通過BitmapFactory.Options來根據需要對圖片進行采樣，采樣程序中主要用到了BitmapFactory.Options的inSampleSize引數，

1.6執行緒優化

執行緒優化的思想是采用執行緒池，避免程式中存在大量的Thread，執行緒池可以重用內部的執行緒，從而避免了執行緒的創建和銷毀所帶來的性能開銷，同時執行緒池還能有效地控制執行緒池的最大并發數，避免大量的執行緒因互相搶占系統資源從而導致阻塞現象的發生，因此在實際開發中，我們要盡量采用執行緒池，而不是每次都要創建一個Thread物件，

1.7一些性能優化建議

本節介紹的是一些性能優化的小建議，通過它們可以在一定程度上提高性能，

• 避免創建過多的物件；

• 不要過多的使用列舉，列舉占用的記憶體空間要比整型大；

• 常量請使用static final來修飾；

• 使用一些Android特有的資料結構，比如SparseArray和Pair等，它們都具有更好的性能；

• 適當使用軟參考和弱參考；

• 采用記憶體快取和磁盤快取；

• 盡量采用靜態內部類，這樣可以避免潛在的由于內部類而導致的記憶體泄漏，

2.提高程式的可維護性

本節所講述的內容是Android的程式設計思想，主旨是如何提高代碼的可維護性和可擴展性，而程式的可維護性本質上也包含可擴展性，本節的切入點為：代碼風格、代碼的層次性和單一職責原則、面向擴展編程以及設計模式，下面圍繞著它們分別展開，

可讀性是代碼可維護的前提，一段別人很難讀懂的代碼的可維護性顯然是極差的，而良好的代碼風格在一定程度上可以提高程式的可讀性，代碼風格包含很多方面，比如命名規范、代碼的排版以及是否寫注釋等，到底什么樣的代碼風格是良好的呢？下面是給大家的一些建議，

• 命名要規范，要能正確地傳達出變數或方法的含義，少用縮寫，關于變數的前綴可以參考Android原始碼的命名方式，比如私有成員以m開頭，靜態成員以s開頭，常量則全部用大寫字母表示，

• 代碼的排版上需要留出合理的空白來區分不同的代碼塊，其中同類變數的宣告要放在一組，兩類變數之間要留出一行空白作為區分，

• 僅為非常關鍵的代碼添加注釋，其他地方不寫注釋，這就對變數和方法的命名風格提出了很高的要求，一個合理的命名風格可以讓讀者閱讀原始碼就像在閱讀注釋一樣，因此根本不需要為代碼額外寫注釋，

代碼的層次性是指代碼要有分層的概念，對于一段業務邏輯，不要試圖在一個方法或者一個類中去全部實作，而要將它分成幾個子邏輯，然后每個自邏輯做自己的事情，這樣既顯得代碼層次分明，又可以分解任務從而實作簡化邏輯的效果，單一職責是和層次性相關聯的，代碼分層以后，每一層僅僅關注少量的邏輯，這樣就做到了單一職責，

程式的可擴展性標志著開發人員是否有足夠的經驗，很多時候在開發程序中我們無法保證已經做好的需求不在后面的版本發生變更，因此在寫程式的程序中要時刻考慮到擴展，考慮著如果這個邏輯后面發生了改變那么需要做哪些修改，以及怎么樣才能降低修改的作業量，面向擴展編程會使程式具有很好的可擴展性，

恰當地使用設計模式可以提高代碼的可維護性和可擴展性，但是Android程式容易有性能瓶頸，因此要控制設計的度，設計不能太牽強，否則就是過度設計了，常見的設計模式有很多，比如單例模式、工廠模式以及觀察者模式等，