隨著android技術的提升，app在效能優化方面做的越來越好，在公司做專案的時間內，或多或少學了一些初級優化的方案，在這裡分享給大家看，不過大多數都是前人的經驗教訓總結，在這裡進行重述罷了。

每一個專案裡面都不可缺少的app的元件 activity，站在開發人員的角度來說，其實就是一個視覺化介面，所做的功能就是繪製介面，填寫資料，和使用者進行互動。看起來在activity裡面做的事情特別的多，優化也成了一大難題，但我們可以慢慢來拆分一下。

首先要了解的是android系統按照app的優先級別給每個app都分配的有不同大小的記憶體，所以一旦超出了這部分的記憶體，就是我們最鬱悶的OOM問題。故而我們最簡單最直接最粗暴的方式，回收。將不需要再次飲用的物件置空，通過system.gc()，可這都只是一個指標不治本的辦法。那何謂治本？

第一步，要提到的一個詞語：渲染，在我看來，基礎的渲染工作就是android將你的xml佈局檔案繪製到螢幕上。如果xml太過於複雜，造成的後果當然就是渲染時間過長，app卡頓現象嚴重，於是優化方案一就出來了，

一、簡化佈局，儘量使用相對佈局，減少巢狀；

在寫佈局的時候，儘量做到能不巢狀佈局的不要巢狀，也不是說整個頁面都不進行多層巢狀，而是省去那些不必要進行的潛逃，儘量處理好控制元件的位置關係，做到能做到的最優方案。而使用相對佈局比線性佈局更好的原因是在於，在渲染過程中，使用線性佈局使得在繪製這個佈局的時候會先去檢視裡面的所有子元素，然後計算出他們所佔的大小，尤其在設定了weight這個引數的時候，他們會被反覆的測量大小，那麼尤其在在adapterview繪製的時候，無疑減慢了執行速度，而且更多的耗費了效能。

第二步，依舊是渲染層面的，這個時候不能不提到一個關鍵，圖片。在一個頁面中，對於圖片的優化更是重中之重，因為圖片對app的效能起到了最重要的作用，尤其是大量圖片展示的那種app，當圖片本身的體積太過龐大，那麼就會使app被分配的記憶體一點點的佔滿，一旦超出這個值域，後果就是崩潰。那麼對於圖片的優化有什麼方案呢？

二、儘量減少drawable圖片的體積，載入網路圖片的時候別忘了對圖片本身進行壓縮

壓縮圖片顯然在這裡是重點，當圖片的體積非常之輕的時候，那也就意味著你可以載入更多的圖片，也可以毫無壓力的減輕app卡頓的問題。但是壓縮只是處理的第一步。很多人喜歡使用background設定圖片背景，那麼這裡就要注意了，在xml使用的圖片背景可以優化的那就大膽的優化，當然要保持和產品原型一致，但是你所做的工作就是選擇合適圖片進行載入設定。還有一個地方的陷阱－－bitmap，當你的頁面使用了bitmap的時候，那麼回收就是必不可少的，這也是老生常談了。

第三步，android中還有一個不知道是另開發者痛苦還是讓使用者舒適的一個設定，頁面快取機制。也就是說當我們在呼叫finifsh的時候，表面上看頁面被銷燬了，那麼，這個頁面所建立的記憶體就應該被回收才對。其實不然，頁面看似被finish掉了，但是儲存頁面的棧並沒有對activity移除，這是一個快取機制，為了使使用者在短時間內再次訪問這個頁面的時候，可以快速的被重現該頁面。帶來的痛苦就是，開啟的頁面過多時，消耗的記憶體也是相當的可觀的。所以我們可以對頁面進行頁面管理，

三、通過建立stack<object>等，進行頁面管理。

建立BaseActivity，通過繼承BaseActivity，建立頁面管理。於此同時，BaseActivity也可以寫一些公共方法，也是一個非常好的程式碼習慣。

第四步，更是我們平時寫程式碼中必不可少的習慣啦，adapter的複用更是不得不做的事情。

四、adapter的複用

不知道各位小夥伴們的複用模式是否正確？並且在adapter的方法getView的方法內儘量不要重複大量的用類.getInstance()這種方式獲取物件，最佳的選擇就是提取出來成為adapter的自身屬性了。

以上只是對於一個新手來說所需要明白掌握的優化方案，在這種情況下，app優化出來的效果明顯提升了很多。