android的效能優化多少能代表乙個程式設計師的級別，如果面試的時候，面試官問到你，你是如何對android進行效能優化的，你若簡單的敷衍兩句，那基本認定你就是個初級的程式設計師了。所以作為資深的android工程師，了解效能優化是我們要走的第一步。
主要方式布局優化、繪製優化、記憶體洩漏優化、listview優化、bitmap優化、執行緒優化及一些效能優化的建議。
布局優化：1、如果既能用linearlayout，也能用relativelayout，那麼就使用linearlayout，因為linearlayout和framelayout都是簡單高效的輕量級viewgroup，而relativelayout設計的引數及繪畫細節相對複雜（當然功能也更強大），所以是一種相對重量級的viewgroup，但是如果需要巢狀增加布局層數，同樣會降低程式的效能，這種情況有限考慮relativelayout。但是最終還得盡量使用少的層級去實現複雜的頁面。
2、另一種手段就是採用標籤、標籤和viewstub。 主要用於頁面的重用，而標籤配合標籤可以降低減少一層的布局層數。而viewstub提供了按需載入的功能。當需要時才會將viewstub中的布局載入到記憶體，這提高了程式初始化的效率。比如網路異常的時候，沒有必要每個頁面都載入進來然後設定為gone，通過viewstub就可以實現在使用的時候再載入。
繪製優化：指的是view的ondraw方法要避免執行大量的操作，主要有兩點：
一、盡量不要在draw中建立新的物件，因為draw短時間會執行多次，會照成記憶體突然出現大量的臨時物件，不僅占用過多的記憶體，而且導致系統頻繁的gc，降低效率。
二、不要在draw中做耗時的任務，哪怕是大量的迴圈操作。大量的迴圈依然搶占cpu的時間片，也會影響繪製過程不流暢。
記憶體洩漏優化：記憶體洩漏是開發者常常遇到的問題，資源得不到gc的**，雖然不會照成系統崩潰，使用者幾乎感覺不到，但是大量的記憶體洩漏最終會導致記憶體溢位，嚴重了同樣會崩潰。簡單的了解可能會出現的記憶體洩漏現象
一、靜態變數導致記憶體洩漏：應該所以開發者都知道這點。但是開發中卻未必注意到了， 比如在當前的activity中，你宣告了乙個static的context mcontext；然後在oncreate中進行複製mcontext = this;這樣就好導致當前activity應用無法被**，因為gc在當前activity的物件樹中發現mcontext一直被持久化（被自己持有了），雖然這樣的方法沒人會寫，但難保有人給view設定為static，這依然導致當前的activity無法被**。包括當前activity中的所有物件和資料。
二、單例模式導致記憶體洩漏：如果你設定了乙個單例模式的電量管理類，然後向管理方法傳入了乙個context，那麼你的這個activity同樣不能得到釋放，除非在ondestory的時候讓管理類取消對context的持有。
三、屬性動畫導致記憶體洩漏：android3.0以後google提供了屬性動畫，屬性動畫相比view動畫和幀動畫的區別在於，能改變當前元件的屬性，既然能改變他的屬性，那它肯定持有了對view的引用，不然憑什麼能改變元件的寬高和位置。如果你的屬性動畫在activity退出之後仍未停止，那麼恭喜你！又洩漏了。這句**看似簡單無奇animator.cancle(); 卻有不少人遺忘，直到工具檢測出來才發現。
那出現記憶體溢位後如何檢測出來呢：
我常用的方式就兩種：一種是android studio自帶的mat工具。當然這工具eclipse也有。第二種就是使用leakcanary外掛程式,用法也很簡單。個人覺得要想深入的挖掘洩漏的問題，還得熟練使用mat工具，因為他強大了。
listview優化：無人不曉。這裡沒什麼可說的。話說現在都用recyclelistview了，誰還用adapter，
bitmap優化：我們拿一張1024*1024的來說，如果是採用argb8888（picasso就是如此）配置載入如記憶體，那麼他的記憶體消耗是非常大的，8888是代表透明度（alpha）、紅（
red）、綠（green）、藍（blue）這四種資料分布用八位字（bit）處理，即一位
位元組（byte），就是說每個畫素有4個8bit的記憶體來分布，即4byte，那麼整張圖就是4*
1024*1024
=4m，如果你是乙個viewpager的啟動頁，那麼一啟動光著幾張至少占用4*3=12m，外加應用自身的記憶體消耗，可能低配的手機直接oom，這個時候要做的就是壓縮，大致步驟是：首先通過bitmapfactory.options.injustdecodebounds設定為true，獲取的基本首席資訊官、寬等，拿到長寬資料後針對要壓縮的比率，比如放到乙個512*512的imageview上，那麼得出壓縮比率是2，
即options.in******size = 2，得出取樣率，然後設定injustdecodebounds=false，根據options的配置再次載入源，這個時候顯示的就是512*512*4=1m的大小了，空間瞬間降了四倍。除了壓縮，對進行快取也是乙個很好的優化，順便說一句，google的glide關鍵的載入配置是rgb565，即乙個畫素就是（5+6+5）=16bit =2byte，關鍵是幾乎看不出失真現象，所以個人推薦使用glide載入。
執行緒優化：執行緒優化的思想就是使用執行緒池，避免程式出現大量的執行緒，同時閒置的執行緒也能馬上進入活躍狀態，提高效率。activity關閉的時候記得銷毀。
優化建議：常量使用static final來修飾、不要過多的建立新物件，能復用最好、不要過多的使用列舉，列舉占用空間比整型大、適當使用弱引用和軟引用、採用記憶體快取和磁碟快取、盡量採用靜態的內部類（靜態內部類相當於外部類乙個靜態變數，避免因為內部類持有外部類物件導致的記憶體洩漏）。
如何進行HIBERNATE效能調優
大體上，對於hibernate效能調優的主要考慮點如下 資料庫設計調整 hql優化 api的正確使用 如根據不同的業務型別選用不同的集合及查詢api 主配置引數 日誌，查詢快取，fetch size,batch size等 對映檔案優化 id生成策略，二級快取，延遲載入，關聯優化 一級快取的管理 針...
Android效能調優
1.布局渲染 android螢幕 1000ms60幀的頻率來進行重新整理，如果16ms沒有重新整理完一幀，那就會讓使用者感覺到卡頓 布局優化上解決方案是 優化布局層級 在ondraw的時候避免做耗時操作，同時盡量不要在ondraw中建立區域性物件，ondraw頻繁呼叫會產生大量的臨時物件占用過多記憶...
如何對react進行效能優化
react本身就非常關注效能，其提供的虛擬dom搭配上diff演算法，實現對dom操作最小粒度的改變也是非常高效的，然而其元件的渲染機制，也決定了在對元件更新時還可以進行更細緻的優化。在講react生命週期時，就談到過react元件分為了初始化渲染和更新渲染，初始化渲染會呼叫根元件下的所有元件的re...