android線程優化
❶ Android性能優化總結
常用的Android性能優化方法：
一、布局優化：
1）盡量減少布局文件的層級。
層級少了，繪制的工作量也就少了，性能自然提高。
2）布局重用 <include標簽>
3）按需載入：使用ViewStub,它繼承自View,一種輕量級控制項，本身不參與任何的布局和繪制過程。他的layout參數里添加一個替換的布局文件，當它通過setVisibility或者inflate方法載入後，它就會被內部布局替換掉。
二、繪制優化：
基於onDraw會被調用多次，該方法內要避免兩類操作：
1）創建新的局部對象，導致大量垃圾對象的產生，從而導致頻繁的gc，降低程序的執行效率。
2）不要做耗時操作，搶CPU時間片，造成繪制很卡不流暢。
三、內存泄漏優化：
1）靜態變數導致內存泄漏 比較明顯
2）單例模式導致的內存泄漏 單例無法被垃圾回收，它持有的任何對象的引用都會導致該對象不會被gc。
3）屬性動畫導致內存泄漏 無限循環動畫，在activity中播放，但是onDestroy時沒有停止的話，動畫會一直播放下去，view被動畫持有，activity又被view持有，導致activity無法被回收。
四、響應速度優化：
1）避免在主線程做耗時操作 包括四大組件，因為四大組件都是運行在主線程的。
2）把一些創建大量對象等的初始化工作放在頁面回到前台之後，而不應該放到創建的時候。
五、ListView的優化：
1）使用convertView，走listView子View回收的一套：RecycleBin 機制
主要是維護了兩個數組，一個是mActiveViews,當前可見的view,一個是mScrapViews，當前不可見的view。當觸摸ListView並向上滑動時，ListView上部的一些OnScreen的View位置上移，並移除了ListView的屏幕范圍，此時這些OnScreen的View就變得不可見了，不可見的View叫做OffScreen的View，即這些View已經不在屏幕可見范圍內了，也可以叫做ScrapView，Scrap表示廢棄的意思，ScrapView的意思是這些OffScreen的View不再處於可以交互的Active狀態了。ListView會把那些ScrapView（即OffScreen的View）刪除，這樣就不用繪制這些本來就不可見的View了，同時，ListView會把這些刪除的ScrapView放入到RecycleBin中存起來，就像把暫時無用的資源放到回收站一樣。
當ListView的底部需要顯示新的View的時候，會從RecycleBin中取出一個ScrapView，將其作為convertView參數傳遞給Adapter的getView方法，從而達到View復用的目的，這樣就不必在Adapter的getView方法中執行LayoutInflater.inflate()方法了。
RecycleBin中有兩個重要的View數組，分別是mActiveViews和mScrapViews。這兩個數組中所存儲的View都是用來復用的，只不過mActiveViews中存儲的是OnScreen的View，這些View很有可能被直接復用；而mScrapViews中存儲的是OffScreen的View，這些View主要是用來間接復用的。
2）使用ViewHolder避免重復地findViewById
3)快速滑動不適合做大量非同步任務，結合滑動監聽，等滑動結束之後載入當前顯示在屏幕范圍的內容。
4）getView中避免做耗時操作，主要針對圖片：ImageLoader來處理(原理：三級緩存)
5）對於一個列表，如果刷新數據只是某一個item的數據，可以使用局部刷新，在列表數據量比較大的情況下，節省不少性能開銷。
六、Bitmap優化：
1）減少內存開支：圖片過大，超過控制項需要的大小的情況下，不要直接載入原圖，而是對圖片進行尺寸壓縮，方式是BitmapFactroy.Options 采樣，inSampleSize 轉成需要的尺寸的圖片。
2）減少流量開銷：對圖片進行質量壓縮，再上傳伺服器。圖片有三種存在形式：硬碟上時是file，網路傳輸時是stream，內存中是stream或bitmap，所謂的質量壓縮，它其實只能實現對file的影響，你可以把一個file轉成bitmap再轉成file，或者直接將一個bitmap轉成file時，這個最終的file是被壓縮過的，但是中間的bitmap並沒有被壓縮。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);
七、線程優化：
使用線程池。為什麼要用線程池？
1、從「為每個任務分配一個線程」轉換到「在線程池中執行任務」
2、通過重用現有的線程而不是創建新線程，可以處理多個請求在創建銷毀過程中產生的巨大開銷
3、當使用線程池時，在請求到來時間 ，不用等待系統重新創建新的線程，而是直接復用線程池中的線程，這樣可以提高響應性。
4、通過和適當調整線程池的大小 ，可以創建足夠多的線程以使處理器能夠保持忙碌狀態，同時還可以防止過多線程相互競爭資源而使應用程序耗盡內存或者失敗。
5、一個App裡面所有的任務都放在線程池中執行後，可以統一管理 ，當應用退出時，可以把程序中所有的線程統一關閉，避免了內存和CPU的消耗。
6、如果這個任務是一個循環調度任務，你則必須在這個界面onDetach方法把這個任務給cancel掉，如果是一個普通任務則可cancel，可不cancel，但是最好cancel
7、整個APP的總開關會在應用退出的時間把整個線程池全部關閉。
八、一些性能優化建議：
1）避免創建過多對象，造成頻繁的gc
2)不要過多使用枚舉，枚舉佔用的空間比整型大很多
3）字元串的拼接使用StringBuffer、StringBuilder來替代直接使用String,因為使用String會創建多個String對象，參考第一條。
4）適當使用軟引用，（弱引用就不太推薦了）
5）使用內存緩存和磁碟緩存。
❷ android 大量多線程怎麼優化
在程序開發的實踐當中，為了讓程序表現得更加流暢，我們肯定會需要使用到多線程來提升程序的並發執行性能。但是編寫多線程並發的代碼一直以來都是一個相對棘手的問題，所以想要獲得更佳的程序性能，我們非常有必要掌握多線程並發編程的基礎技能。
眾所周知，Android 程序的大多數代碼操作都必須執行在主線程，例如系統事件(例如設備屏幕發生旋轉)，輸入事件(例如用戶點擊滑動等)，程序回調服務，UI 繪制以及鬧鍾事件等等。那麼我們在上述事件或者方法中插入的代碼也將執行在主線程。
一旦我們在主線程裡面添加了操作復雜的代碼，這些代碼就很可能阻礙主線程去響應點擊/滑動事件，阻礙主線程的 UI 繪制等等。我們知道，為了讓屏幕的刷新幀率達到 60fps，我們需要確保 16ms 內完成單次刷新的操作。一旦我們在主線程裡面執行的任務過於繁重就可能導致接收到刷新信號的時候因為資源被佔用而無法完成這次刷新操作，這樣就會產生掉幀的現象，刷新幀率自然也就跟著下降了(一旦刷新幀率降到 20fps 左右，用戶就可以明顯感知到卡頓不流暢了)。
為了避免上面提到的掉幀問題，我們需要使用多線程的技術方案，把那些操作復雜的任務移動到其他線程當中執行，這樣就不容易阻塞主線程的操作，也就減小了出現掉幀的可能性。
那麼問題來了，為主線程減輕負的多線程方案有哪些呢？這些方案分別適合在什麼場景下使用？Android 系統為我們提供了若干組工具類來幫助解決這個問題。
AsyncTask: 為 UI 線程與工作線程之間進行快速的切換提供一種簡單便捷的機制。適用於當下立即需要啟動，但是非同步執行的生命周期短暫的使用場景。
HandlerThread: 為某些回調方法或者等待某些任務的執行設置一個專屬的線程，並提供線程任務的調度機制。
ThreadPool: 把任務分解成不同的單元，分發到各個不同的線程上，進行同時並發處理。
IntentService: 適合於執行由 UI 觸發的後台 Service 任務，並可以把後台任務執行的情況通過一定的機制反饋給 UI。
了解這些系統提供的多線程工具類分別適合在什麼場景下，可以幫助我們選擇合適的解決方案，避免出現不可預期的麻煩。雖然使用多線程可以提高程序的並發量，但是我們需要特別注意因為引入多線程而可能伴隨而來的內存問題。舉個例子，在 Activity 內部定義的一個 AsyncTask，它屬於一個內部類，該類本身和外面的 Activity 是有引用關系的，如果 Activity 要銷毀的時候，AsyncTask 還仍然在運行，這會導致 Activity 沒有辦法完全釋放，從而引發內存泄漏。所以說，多線程是提升程序性能的有效手段之一，但是使用多線程卻需要十分謹慎小心，如果不了解背後的執行機制以及使用的注意事項，很可能引起嚴重的問題。