android 缺點認知

標籤：android   style   color   ar   使用   sp   檔案   資料   on   

經過本人的面試經驗，以及接觸的android項目，總結了一下android的一些類庫的優缺點：

一，線程方面

1.AsyncTask首先是線程最佳化以及缺陷方面，針對目前大多數類庫來說，都有好的設計方面和缺陷的方面，比如內部內建的AsyncTask,這個類優點很多，使用方便，加快快速開發，但是每次都需要new 一下然後把對應的參數放在裡面，感覺這個過程不是十分穩妥，效能有待加強，主要是內部的一個多線程單任務隊列的這麼一個機制，其實很噁心，只要大多數人仔細用過這個類，都能夠發覺他其實是順序執行你的任務 的，只要稍不注意 感覺就像是單線程執行了，我對這個類的設計方面有待加強，一直不明白為何要這麼去設計，優點在哪，當然他也有他好的地方，就是能夠讓我們自訂一個線線程池去執行任務，可以完全拋棄他得單任務的思想。（據說是google工程師說得一段話：多線程是個複雜的事情，我們簡化來避免開發人員犯錯，如果你們要多線程，調用新方法就行了）

2.Vollery這個類是google 2013年提倡一個類,他適用於網路通訊頻繁，大量網路請求的情境，我大概的看了一下源碼，裡面實現機制卻是不錯，提供了緩衝的實現，其次還提供了任務取消機制，能夠在activity結束的時候取消一些未完成的請求。但是也有不好的地方，如果只是一兩個請求，就沒有必要追求這個類，因為他初始化的時候就會去開啟好幾個線程，有點類似於master-woker的執行緒模式。其次在緩衝管理方面不是很靈活，在需要仔細管理緩衝方面的時候，不能夠去細分緩衝的管理，最後在單個資料比較大得時候，最好別用這個，比如下載檔案的時候。其實為啥想想就知道，他會快取資料，如果把那麼大得資料也緩衝了，其實也挺噁心的。

    3.有關線程的一些內部管理，雖然可以用多線程來改善android的運行效率和速度，但同時也會帶來一些負面的效應，他會增加耗電量，同時如果不限制線程的開銷，可能會導致anr，畢竟線程是擷取時間片去執行的，但是如果大量的線程都耗費時間的話，這樣也會引起一定的卡頓。最好的辦法就是統一線程管理，不用隨便的使用new Thread(){}.start(),這種方式去開啟線程，呆了兩個創業公司的感覺，這種代碼隨處可見。

二，ui方面

1.其實在ui適配這個方面，有很大的爭議，很多人的做法都是不同檔案夾下放入不同的圖片，但是這樣也會有一個不好的地方，他會導致整個應用變得很大，最近也再關注一些牛人的部落格，stormzhang這個說得我感覺是挺有道理的，其實只需要適配一下大的手機圖片，保證圖片盡量不被展開，其實縮小的話就沒有那麼大的必要了，最近跟一些群裡面的朋友交流，其實也可以用向量圖來解決這個問題，因為向量圖不會失真，然後判斷哪些會被拉鎖的圖片，用.9來處理 其實也能很好的解決適配的問題。

2.然後有關於布局方面的最佳化，比如說你在用一個include這個標籤的時候，被匯入進來的布局很多時候可以用merge這個標籤，能夠動態替代frameLayout，減少一層標籤，有關RelativeLayout和LinearLayout這兩個類一直是相互替換的，很多時候如果你的布局只有一層的時候那麼就用LinearLayout，因為他效率高，比較布局的形式相對簡單很多，如果布局層次很複雜，那麼最好使用RelativeLayout這個去進行布局。可以有效改善效率。很多時候都會採用到一個VISIBLE的控制項在布局上面，這些控制項其實在不用的時候可以用viewStub這個標籤去改善一下，等待使用的時候再去載入進來.

三，資料庫方面

android的資料庫並發效能不好，因為本來就不是為了並發去設計的，所以最好使用單例模式，否則多個線程操作資料庫會拋出異常的，其次是在批量插入時的最佳化，sqlite預設會加上事務，所以批量插入的時候千萬要先開啟事務在事務中進行大量操作，否則大量操作就會開啟多個事務，導致效能下降。

四，緩衝方面

基本上很通用的，因為緩衝基本上都養成了習慣，首先是listview 的view用ViewHolder進行緩衝，其次是對圖片的緩衝，第三是對網路的緩衝，第四是網路流的時候採用合理的利用緩衝機制能夠更快的加快下載速度和通訊速度。

五，延遲方面

這個常常使用在一些介面比較複雜和業務也很複雜的情境，比如說其實很多東西可以在調用onstart的時候去載入，因為onstart這個方法調用的時候使用者已經可以看見介面了。可以很好的防止介面過於複雜導致的黑屏時間過長，但是這個只是一個提高使用者體驗的方法，要治根還是得最佳化介面。然後把資料的載入都非同步化。最後還有一個handler使用的小策略，當資料比較多得時候可以適當的延遲一下handler的發送，比如說可以調用handler.sendEmptyMessageDelayed,設定一下延遲的時間。

六，網路方面

網路最佳化一直是一個很常問的話題，但針對於用戶端來說基本上做最佳化的地方不是太多，首先保證開啟gzip壓縮，二 ，給網路請求加上timeout到期時間，三，資料格式的定義，跟android最好的通訊方式就是json，因為資料量比較小，盡量能夠合并請求，這是一個能夠提高不少效率的做法，四，減少重新導向的次數

七，代碼最佳化

這個無論是任何語言都通用的最佳化方式，也是最根本的方式，這個話範圍太大了，只能用調優工具去跟蹤。然後去改善代碼品質，沒有絕對的調優方式。

android 缺點認知