三方面：Android的渲染機制，記憶體與GC，電量優化。

渲染優化： UI達到60fps需要再16ms內完成繪製 工具：開啟手機裡的開發者選項，選擇Profile GPU Rendering，選中On screen as bars的選項。 1，層疊元件來實現複雜的UI效果，可能造成過度繪製，canvas.clipRect指定繪製區域 2，減少佈局巢狀，推薦使用constraintLayout， 約束集 LinearLayout（線性佈局），RelativeLayout（相對佈局），百分比佈局等的功能於一身，扁平式的佈局方式，無任何巢狀，減少佈局的層級，優化渲染效能。使用merge，viewSub
Refresh Rate：代表了螢幕在一秒內重新整理螢幕的次數，這取決於硬體的固定引數，例如60Hz。 Frame Rate：代表了GPU在一秒內繪製操作的幀數，例如30fps，60fps。 GPU會獲取圖形資料進行渲染，然後硬體負責把渲染後的內容呈現到螢幕上，他們兩者不停的進行協作。
繪製流程 ：Android需要把XML佈局檔案轉換成GPU能夠識別並繪製的物件。這個操作是在DisplayList的幫助下完成的。DisplayList持有所有將要交給GPU繪製到螢幕上的資料資訊。任何時候View中的繪製內容發生變化時，都會重新執行建立DisplayList，渲染DisplayList，更新到螢幕上等一系列操作。
RecyclerView的尺寸在每次改變時，比如你加任何些東西。setHasFixedSize 的作用就是確保尺寸是通過使用者輸入從而確保RecyclerView的尺寸是一個常數。RecyclerView 的Item寬或者高不會變。每一個Item新增或者刪除都不會變。如果你沒有設定setHasFixedSized沒有設定的代價將會是非常昂貴的。因為RecyclerView會需要而外計算每個item的size  控制元件： 1 、 對於自定義控制元件，我們可以通過canvas.clipRect()來幫助系統識別那些可見的區域。這個方法可以指定一塊矩形區域，只有在這個區域內才會被繪製，其他的區域會被忽視。 http://blog.csdn.net/lovexieyuan520/article/details/50698320 2 、避免巢狀太多層控制元件 3 、合理使用include、merge
佈局優化 標籤：    incloud               如果被包含的佈局也指定了id，以incloud的id為準，有layout_width和layout_heights屬性。               Merge               直接繼承父佈局的佈局，去掉多餘的佈局。               viewSub 指定一個佈局layout               按需載入，setVisibility（）或.inflate 繪製優化：        onDraw（）中不要建立新的物件，這個方法可能頻繁呼叫，不要做耗時操作也不能執行成千上萬次的迴圈操作。        記憶體和GC 1、 android的GC機制：Android裡面是一個三級Generation的記憶體模型，最近分配的物件會存放在Young Generation區域，當這個物件在這個區域停留的時間達到一定程度，它會被移動到Old Generation，最後到Permanent Generation區域。 2 、執行GC操作的時候，任何執行緒的任何操作都會需要暫停，等待GC操作完成之後，其他操作才能夠繼續執行。 3、Android系統裡面有一個 Generational Heap Memory 的模型，系統會根據記憶體中不同的記憶體資料型別分別執行不同的GC操作。例如，最近剛分配的物件會放在Young Generation區域，這個區域的物件通常都是會快速被建立並且很快被銷燬回收的，同時這個區域的GC操作速度也是比Old Generation區域的GC操作速度更快的。

• 區域性變數的基本資料型別和引用，儲存於棧中，引用的物件實體儲存於堆中。因為它們屬於方法中的變數，生命週期隨方法而結束。
• 成員變數全部儲存與堆中（包括基本資料型別，引用和引用的物件實體），因為它們屬於類，類物件終究是要被new出來使用的。
• 我們所說的記憶體洩露，只針對堆記憶體，他們存放的就是引用指向的物件實體。

導致頻繁GC的原因：記憶體抖動的原因是大量的物件在短時間建立又被銷燬 AS中的Device Monitor工具： Allocation Tracker來檢視在短時間內，同一個棧中不斷進出的相同物件。這是記憶體抖動的典型訊號之一 http://blog.csdn.net/itfootball/article/details/48750849
Heap Viewer，手動GC還在增長的說明有記憶體洩漏的可能， http://blog.csdn.net/itfootball/article/details/48734553 TraceView，能找到頻繁被呼叫的方法，也能找到執行非常耗時的方法，前者可能會造成Cpu頻繁呼叫，手機發燙的問題，後者就是卡頓的問題 http://blog.csdn.net/itfootball/article/details/48792435
電量：

• 某些非必須馬上執行的操作，例如上傳歌曲，圖片處理等，可以等到裝置處於充電狀態或者電量充足的時候才進行。

消耗電量的幾個主要原因、功能： 1、大資料量的網路傳輸（網路） 2、不停的網路切換（網路） 3、解析大量的資料（CPU）   網路方面的優化： 1 、網路請求之前，檢查網路連線。沒有網路連線不進行請求 2 、 判斷網路型別，針對特定的資料在特定的網路下請求。例如：大量資料傳輸的時候，在wifi下請求。wifi下下載資料耗電量只有2、3、4G的1/3. 4、使用GZIP壓縮方式下載資料，能減少網路流量，縮短下載時間 5 、合理使用快取，避免重複操作 8、是JobScheduler API所做的事情。它會根據當前的情況與任務，組合出理想的喚醒時間，例如等到正在充電或者連線到WiFi的時候，或者集中任務一起執行。我們可以通過這個API實現很多免費的排程演算法。  
1不要過多使用列舉,列舉佔用的記憶體空間比整型大 2常量使用static final修飾 3使用安卓特有的資料結構,sparseArray（替代hashMap，節省儲存空間，折半查詢法提高4效率）和pair 4使用軟引用或弱引用 5採用記憶體快取和磁碟快取 6內部類加靜態
變數常量集合，都應該在destory中釋放掉（集合clear，常量賦值為空 ）
adapter中沒有使用ViewHolder複用，會每次都去findViewById層層 查詢控制元件

沒有複用convertView，為空載入佈局，不為空複用，永遠只加載螢幕可顯示條目數加一的佈局數量。