android的一些類庫的優缺點

 

通過本人的面試經驗，以及接觸的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，由於數據量比較小，儘可能可以合併請求，這是 一個可以提升很多效率的作法，四，減小重定向的次數

七，代碼優化

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