重新設計一款Android App，我會怎麼做？

開發工具的選擇

開發工具我將選用 Android Studio，它是Google官方指定的Android開發工具，目前是1.2.2穩定版，1.3的預覽版也已經發布了。 Android Studio的優點就不需多說了，GitHub上大部分的Android開源庫也都已遷移到Android Studio上來，在未提供 jar文件時，使用Android Studio可以極為方便地集成開源庫。最為重要的是Google已宣布將在年底前停止對 Eclipse Android開發工具的一切支持（Google Ends Support for Android Eclipse Tools），因此請早日轉移到Android Studio上來。

App設計風格

這一點對於一個開發者來說，貌似沒有決定權，最終的決定權在產品部門手裡。盡管這樣，我還是會盡力說服產品部門將App設計成Material Design風格。這一點說多了都是淚啊，作為一個Android開發者，卻整天開發著iOS風格的App，相信很多公司都這樣，為了節省成本和時間，Android和iOS共用一套UI。舉一個最常見的例子，Android App中每個頁面TitleBar的左上角放一個返回按鈕，這在iOS裡是必須的，但Android有返回鍵啊，這樣設計對於 Android完全是多此一舉。真心希望產品設計者尊重每種操作系統的風格及使用習慣，不要再設計不倫不類的產品。Material Design正好提供了一種這樣的規范，自MD規范發布以來，其優雅的設計和清新的風格已吸引了大批設計者和開發者，如今MD設計不止在Android上（已有官方類庫支持 MD風格），甚至在CSS、HTML、JavaScript網頁設計上都越來越火。因此，對於App的設計風格，Material Design當仁不讓，也許你曾經錯過了Android Design，請不要再錯過Material Design。

一些相關的鏈接：

Material Design官網

Material Design配色模板

MD一個設計案例網站

MD風格的Andorid抽屜源碼：Android-MaterialDesign-NavigationDrawer

MD風格的一個App源碼（有妹子哦）：Android-MaterialDesign-DBMZ

版本支持

對於Android要支持的最低版本，可以參考各個版本的市場占有率，其實最靠譜的是根據自家App的統計數據來決定，目前我們的App最低支持2.2。以個人觀點認為，雖然2.x的版本仍然有一部分用戶，但其實手機更新換代特別快，為了更好的用戶體驗，也為了應用更新的API（很多第三方庫也都有版本要求），應該提高最低支持的版本，大概3.0 為宜，即API Level為11。

App框架設計

相信大家都有體會，隨著功能模塊的增加，App越來越大，如果沒有良好的架構設計，則代碼將會變得臃腫且不易維護，各功能模塊的耦合度會越來越高。因此可以把App模塊化，將一個完整的App劃分成幾個相對獨立的模塊，這樣即可以降低模塊間的耦合也利於復用。

1.網絡模塊

已經很少有單機版的App了吧，大部分都需要聯網，從服務器請求數據，因此網絡模模塊必不可少。GitHub上的開源網絡框架也特別多，個人認為可以使用開源框架，目前我會選okHttp或者Volley，也許以後會有更好的網絡框架出現。注意如果使用開源框架，則必須要閱讀其源碼，必須能夠駕馭它，這樣就不至於當bug出現時束手無策。當然還可以自己寫網絡模塊，目前我們的App網絡模塊就完全是自己寫的，這樣的好處是自己熟悉所寫的代碼，當有bug時可以迅速定位問題，同時注意處理一些聯網過程中的細節，如：

（1）對HTTPS的支持、HTTPS證書的驗證（目前很多做法都是默認允許所有HTTPS證書的，其實這樣做是不安全的，應當真正地做證書校驗）

（2）支持Wap方式上網，移動、聯通、電信代理的設置

（3）支持重定向、數據壓縮傳輸等

（4）其他值得注意的問題

自己寫網絡框架可以完美地處理這些細節，但時間成本比較大。如果使用開源框架，一般都沒有處理這些細節，因此我們可以在第三方框架上做些修改，這樣時間成本將會節省很多。

2.圖片管理模塊

圖片也是App中不可少的元素，而且圖片是占用內存的大戶，因此圖片管理框架特別重要，不好的圖片框架容易引起內存洩露甚至導致崩潰。當然可以自己實現圖片框架（目前我們也是這樣做的），實現圖片的下載、解碼、緩存等關鍵環節。個人建議可以采用一些比較好的圖片庫，也許會比我們自己管理圖片更完善和高效。我會推薦如下幾個圖片管理庫：

（1）Glide，Google的一些官方App，如Google photos都使用了，還要解釋更多嗎？

（2）Fresco，FaceBook的開源庫，功能超級強大，支持WebP、Gif、JPEG漸進顯示，關鍵是其對圖片內存的設計思想，使得圖片內存開銷大大減少。

（3）Android-Universal-Image-Loader，在出現上述圖片庫之前，貌似這個最火吧，之前個人的App中也用了它。

（4）Picasso，Square的開源庫，據說Glide就是參考Picasso設計的。

3.本地數據庫模塊

也許你的App需要用到本地數據庫，那麼建議你采用流行的ORM框架，如ActiveAndroid或greenDAO，使用第三方庫會大大方便你對sqlite的操作，個人認為在使用中我們需要注意數據庫升級以及多線程並發操作數據庫的問題。

4.文件管理模塊

一個App，肯定會涉及到一些文件，如配置文件、圖片、視頻、音頻、SharedPreferences文件等。我們可以提供一個全局的文件管理模塊，負責文件的增、刪、改、查等操作。另外還需支持文件壓縮，文件的上傳與下載操作，對於下載需要支持多線程並發下載、斷點續傳等功能。

5.組件內、組件間通信機制

對於一個App，組件通信必不可少，通信類型可以分為點對點和點對面的的通信，點對點即只有唯一的接收者可以響應消息，點對面則類似於消息廣播，即所有注冊過的都可以響應消息。在Android 中，通常使用消息機制來實現，但消息機制的耦合度比較高。目前也有一些通信框架，如EventBus、Otto等事件總線框架，這些框架可以極大地降低組件間的耦合，但無法完美地實現點對點通信，因此建議消息機制和事件總線機制結合使用。

6.數據處理框架

其實還應該有一個數據處理框架，當發出數據請求後（走子線程），經網絡模塊返回數據（一般為JSON格式），JSON數據一般不能直接交給View層使用，需要解析成對應的Model，同時如有需要，還要緩存數據，因此這些流程可以抽象成一個數據處理的框架。這個框架可以認為接受數據請求的url，並將數據Model返回給Activity或 Fragment。對於JSON數據解析，建議使用fastjson，速度快且穩定，缺省值也比較完善。

7.線程調度模塊

其實Android中有很多操作，如請求數據、下載圖片、清除緩存等都是需要在子線程中執行的，往往很多時候都是直接起一個Thread來做了，這樣做就會很亂而且線程多了將難以管理。因此可以抽象出一個線程調度模塊，它維護一個線程池，如果有需要線程的話就通過線程調度模塊取線程來做，這樣就方便統一管理。當然第三方庫中的線程操作我們將無法歸到線程調度模塊來管理，但其他涉及到線程的操作都應該來統一處理。

8.業務層

業務層大概就是四大組件、Fragment、View了，建議盡可能地使用原生組件，少用自定義組件，因為原生組件性能是最好的。另外建議使用MVC模式就好，只要設計管理好自己的邏輯，至於MVP、MVVM等模式個人認為都有缺陷，總之尋求一個折中吧，有得必有失。

9.APK動態加載機制

隨著App的增大，功能的擴展，很多App已經采用了APK動態加載的機制，也可以叫做插件化。由於本人沒有在實際的App中應用過，所以不便發表過多評論。但這種機制個人認為很有前途，這種機制將利於App的解耦、功能擴展和局部升級。具體可以參考一個商用的解決方案：ApkPlug-移動應用模塊化解決方案和一個開源的APK動態加載框架。

10.App的安全性考慮

Android App的安全問題很少有人重視，但這的確是一個很嚴重的問題，一些好的App經常被人破解。建議將一些核心算法等寫成.so庫，重要的邏輯放在服務器端，數據請求采用加密等，另外打包APK時至少要混淆代碼，還可以采用APK加殼機制，總之這類的防范措施永遠不嫌多。

一口氣漫無邏輯地寫了這麼多，可能會有遺漏的內容，後續會補充完善。我想如果按照上述原則，至少可以開發出一款不錯的App。