重新設計一款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。