使用工具來提高Android開發效率

正所謂工欲善其事，必先利其器。學習並應用優秀的輪子，可讓咱們跑的更快，走的更遠。這裏所指的工具是廣義的，泛指能幫助咱們開發的東西，或者能提升咱們效率的東西，包括：開發工具，監測工具，第三方代碼庫等。 

優質的第三方開源類庫

圖片加載與緩存

現代的應用程序不免會有圖片顯示給用戶，對於資訊類，旅遊類，購物類等應用程序而言，圖片的展現更是應用裏面關鍵的一環。而圖片從加載，到緩存再到顯示是一個比較複雜的過程，中間還要處理網絡異常，解析異常等。圖片又是極其耗費內存的，稍不注意就會出現OutOfMemory（OOM）的錯誤。若是你的圖片在你的應用中不是主要的東西，僅是偶爾顯示個Icon和圖標之類的，那還好，普通的異步加載和解析（BitmapFactory）就好。但若是要在應用中展現大量的圖片時，甚至應用的主要內容就是圖片時，這時就要藉助於優秀的開源庫了：

• Universal Image Loader

  這個庫很是強大，從加載，到解析到顯示，你只配置參數，告訴它如何作，再給它一個ImageView就能夠了，而後你就能夠去喝茶去了。

• Picasso

EventBus徹底解耦模塊

觀察者模式，或者生產者消費者模型在開發中是很常見的，好比說異步加載數據，之類的都會用到相似的結構。一般的作法就是建立一個Listener用於回調，以返回數據。若是有一個二個還好，但若是多了，應用須要獲取大量的不一樣的數據，就會出現大量的線程和Listener，處處是addListener和implements Listener，這會形成大量的代碼和依賴，程序會變得混亂，業務邏輯會迷失在Listener之中，並且還要及時的unregisterListener，以防不應被回調到時能取消。這還會形成代碼和模塊之間的強耦合，也就是寫代碼的時候必要在有另外一方，不然不會編譯過。這時就能夠用EventBus來解耦了，它是一個框架能讓雙方很容易的進行通信，而沒必要知道彼此的存在與否：

• EventBus 這個庫很是的高效與方便，它徹底不依賴於註解。
• Otto 這個要使用註解，因此在效率上可能會略差一些。
• Guava 這個是Google Java增長庫Guava中的一個

這些的庫的基思想和目的都是一致的，都是以總線的方式，讓強耦合的雙方解耦，不妨在你的應用中使用一下，體驗一下。

CirclImageView

這彷佛是一個比較小型的庫，它只是一個特殊的ImageView用圓形的方式來顯示圖片。

XListView

這是一個支持下拉刷新(PulltoRefresh)和上拉加載更多(Load more)的定製ListView。

ViewPageIndicator

這個是要與官方的ViewPager一塊兒使用的，爲ViewPager添加indicator的類庫，很是的有名，不少應用都在使用。

ActionbarSherlock

這個庫很是的有名，不少優秀的應用都基於此。ActionBar是一個不錯的用戶體驗，它能集導航，操做和信息於一體的導航欄，Google也極力推薦使用它。可是有一個問題就是它是HoneyCombe（API 11）才引及的一個組件，而對於大多數開發者來講，GingerBread(2.3)仍是不能放棄的肉，因此這個類庫應運而生。這個庫易於使用，根據手機版原本選擇實現方式，若是是3.0以上就直接使用系統的Actionbar。其中的代碼也是值得全部開發者去拜讀。

DragSortListView

用過iOS設備的人可能會注意到iOS裏面的全部列表都有一個很是酷的功能，那就是在編輯模式下，能夠任意對列表進行從新排庫。可是令開發沮喪的是，這是iOS中UITableView的標準內嵌功能。而Android的ListView只提供最基本的功能。所以就有了此類庫的出現。其實除了此庫，還有不少其餘的庫的出現也都是爲了實現相似iOS體驗而作的。 固然這個類庫有一個小問題須要注意，就是它內部會建立一個ItemView來Wrapper客戶代碼提供的ItemView，而在Wrapper時，它會使用WRAP_CONTENT作爲高和寬，因此，用了這個類庫會發現寬度不會Match整個屏幕。解決的辦法就是在建立Adapter#getView時再用代碼指定一扁LayoutParams，把寬設爲MatchParent就行了。

NineOldAndroid

這個庫也是解決低版本之痛的。從3.0開始，Google引入了新的動畫庫，稱做Property動畫，使實現動畫不但變得很是簡單，同時也能實現更加複雜的動畫。只要對對象的屬性進行計算，就能讓這個對象動起來。可是一樣，對於2.3之前就只能用舊的補間動畫(Tween Animation)，這種動畫複雜，須要寫大量的代碼。這個庫就能統一操做，讓動畫變得簡單 這裏介紹的，只是一些比較經常使用的也是比較有名的類庫。這些庫不但優秀，好用，並且最重要的是還開源，你能夠去學習，去研究，甚至去改進。那麼，這些還遠遠不夠，咱們的應用日益複雜，各類需求，怎麼辦呢？

如何獲取更多的類庫

學習編程的第一天起，前輩們就說，不要重複製造輪子，老手與新手的區別也在於，老手善於利用已有的東西，而不是一塊兒都從0開始，無數的優秀的類庫已經能幫忙解決不少問題，它們健壯，方便，好用，因此爲何還要本身費勁去從新造輪子呢？

二個開發者必備之神器

如今的開源類庫很是之多，有些咱們可能不知道，即便看到一個類庫的主頁或者源碼，也要花時間研究下，它究竟能幹什麼，適合幹什麼，以及可否解決咱們遇到的問題，這是介紹三款神器：

• Developer Library for Android
• DevAppsDirect
• LiME Creative Labs

這三款都是Android應用，只是它們的內容是介紹衆多優質的開源類庫，它會列出每一個類庫的信息，如做者，源友位置，簡要說明。最最重要的是它把類庫的例子也集成起來了，你能夠立馬運行類庫的Demo以體驗這個類庫究竟是幹啥的，這真的是良心之做。等什麼呢，趕快去下載安裝吧。

Github

提起開源，Github固然是首屆一指的，其上託管着無數的優秀的開源庫，沒事常去逛逛總會有好處，甚至是驚喜的。惟一麻煩的就是，裏面的內容太多了，容易看花眼和找不到想要的東西。因此仍是上面的應用來的乾脆直接。

優質的聚合平臺

除此以外，還有一些優秀的網絡社區和博客會收集和整理優秀的開源類庫，這也是咱們須要關注的，好比：

• 伯樂 這裏面羅列了大量的優秀的庫和工具，這裏不只有庫還有工具。此外這個網站也值得全部開發者收藏，裏面會聚合優秀的博客和資源。
• CodePath

每一個應用程序必不可少的組件

如今的應用程序有一些東西是必要的，好比分享功能，好比推送消息，好比應用程序統計和崩潰報告等，若是你是一個大型公司，擁有大團隊，或者已經發現成爲行業領頭羊，那麼這些東西最好本身實現，以達到更好的控制和運營，也防止數據外泄。但對於小團隊，或者我的開發者，來講，仍是利用現成的解決方案好比靠譜。

分享到社交平臺

ShareSDK和友盟都提供了免費的SDK用以實現分享到各大社交平臺。 其實每一個社交平臺都有提供了SDK，可是有些麻煩的是開發者必需要一一去註冊，以獲取APP_KEY，同時還要處理用戶受權以得到訪問社交數據，不一樣的SDK，雖然基本思想是一致的，可是具體開發過程不免會有坑。ShareSDK就是幫助開發者解決了這些問題，它在各個媒體平臺上都註冊了，也封裝處理了受權過程，可是帶來方便的同時，它有缺點： * 分享到社交媒體上的信息會顯示「來自ShareSDK」，而非你的應用。這個一般是顯示開發者在社交媒體上註冊的信息。 * ShareSDK的受權方式是經過網頁形式，而非API，過於簡單且受權信息不容易持久化，也就是用戶可能會常常（甚至每次）分享時都須要受權。而若是直接使用媒體受權API，能夠直接獲取APP_SECRETE，在未過時（通常Expiration會比較長）以前均可以直接分享，無需受權。

因此你看全部的用戶量超大的應用，各大新聞客戶端等，都是本身集成和綁定社交媒體，不會經過第三方的庫。

推送消息

如今的應用程序基本上都會有後臺服務提供數據，也會增長推送消息，這個是運營的重要手段，能保持應用的活躍，雖然我不喜歡推送消息，由於早上一打開手機，全都是推送消息。可是推送仍是必要的，也有現成的方案能夠用：

• 個推
• 友盟

這二個也都很是好用，它包括客戶端SDK和Server端後臺，是全套的，很是方便實用。 除此以外，若是是面向海外用戶，能夠用Google提供的，Google Clould Messaging，它也很是好用，由於畢竟是官方的，能夠與Apple的推送服務媲美。可是它的最大的缺點在於，Google Services都依賴於Google Play，也就是說運行時手機上必需要有Google Play Services，也即必需要安裝有GMS才能夠。但中國大陸的手機所有沒有GMS，所以GCM也用不了。因此個推和友盟也纔有機會。

應用統計信息

移動開發不僅僅只有開發出一個出色的APP這麼簡單，開發完了還要運營，而應用的統計絕對是運營的一個重要手段，後期的新功能，以及發展方向要取決於應用的統計數據，統計能看出用戶的特徵，分佈，使用習慣等。固然了，在統計方面友盟絕對是最好的，它開始的最好，如今也是作的最好的，使用也很是的簡單。

應用崩潰報告

如今的Android手機種類極其之多，各類奇葩的設備都有，在標準的手機和模擬器上運行沒有問題，可是在某些定製ROM的手機上可能就會掛。另外，程序也會有你想不到Bug致使崩潰。所以咱們須要收集應用的崩潰信息，之後期改進。若是你集成了友盟統計，它會自動收集崩潰信息，可是它只能收集Java層的，且信息比較簡單，只有一個StackTrace。若是想要收集Native層的，以及得到更多的信息的話，就要使用其餘庫，或者本身實現。本身實現也不難，就是要處理unhandledException，而後把客戶端的信息，如版本，配置，再把手機的信息收集一下，發到後臺，後臺再作個報表，能查看錯誤信息就能夠了。但若是不想本身作，可使用Application Crash Reports for Android這個庫能夠解決客戶端的問題，也就是說它能在發生Crash時，收集足夠的信息(哪配置要收集哪些信息)，而後發送，它能夠配置成發送到Server後臺，也能夠發送到開發者的郵箱，很方便和實用，特別是對於我的開發者來講。須要注意的是，要想能發送到郵箱，手機用戶必須配置了Email賬戶，國內用戶貌似沒有這習慣，由於國內用戶不習慣用郵件，更不要說給手機配置郵件賬戶。可是對於國外用戶，這是沒有問題的，國外用戶習慣電子郵件，並且手機上都會配置。