假設讓我又一次設計一款Android App

轉載請註明出處：

本文來自aspook的博客：http://blog.csdn.net/ahence/article/details/47154419

開發工具的選擇

開發工具我將選用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的左上角放一個返回button。這在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了吧，大部分都須要聯網。從server請求數據，所以網絡模模塊不可缺乏。GitHub上的開源網絡框架也特別多，我的以爲可以使用開源框架，眼下我會選okHttp或者Volley。或許之後會有更好的網絡框架出現。注意假設使用開源框架，則必須要閱讀其源代碼，必須可以駕馭它，這樣就不至於當bug出現時一籌莫展。固然還可以本身寫網絡模塊。眼下咱們的App網絡模塊就全然是本身寫的。這種優勢是本身熟悉所寫的代碼，當有bug時可以迅速定位問題，同一時候注意處理一些聯網過程當中的細節，如：

（1）對HTTPS的支持、HTTPS證書的驗證（眼下很是多作法都是默認贊成所有HTTPS證書的，事實上這樣作是不安全的，應當真正地作證書校驗）

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

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

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

本身寫網絡框架可以完美地處理這些細節，但時間成本比較大。

假設使用開源框架，通常都沒有處理這些細節，所以咱們可以在第三方框架上作些改動，這樣時間成本將會節省很是多。

2.圖片管理模塊

圖片也是App中不可少的元素，而且圖片是佔用內存的大戶。所以圖片管理框架特別重要。很差的圖片框架easy引發內存泄露甚至致使崩潰。固然可以本身實現圖片框架（眼下咱們也是這樣作的），實現圖片的下載、解碼、緩存等關鍵環節。

我的建議可以採用一些比較好的圖片庫，或許會比咱們本身管理圖片更無缺和高效。我會推薦例如如下幾個圖片管理庫：

（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了。建議儘量地使用原生組件，少用本身定義組件，因爲原生組件性能是最好的。至於各類層出不窮的架構，如MVP、MVVM等，以及經典的MVC，事實上每種架構都並非十全十美。都有適用的場景。所以這裏不會厚此薄彼，不論什麼一種架構僅僅要用得好都沒問題。

9.APK動態載入機制

隨着App的增大。功能的擴展，很是多App已經採用了APK動態載入的機制，也可以叫作插件化。由於本人沒有在實際的App中應用過，因此不便發表過多評論。

但這樣的機制我的以爲很是有前途，這樣的機制將利於App的解耦、功能擴展和局部升級。詳細可以參考一個商用的解決方式：ApkPlug-移動應用模塊化解決方式和一個開源的APK動態載入框架。

10.App的安全性考慮

Android App的安全問題很是少有人重視，但這的確是一個很是嚴重的問題。一些好的App經常被人破解。

建議將一些核心算法等寫成.so庫。重要的邏輯放在server端。數據請求採用加密等，另外打包APK時至少要混淆代碼，還可以採用APK加殼機制。總之這類的防範措施永遠不嫌多。

一口氣漫無邏輯地寫了這麼多，可能會有遺漏的內容，興許會補充無缺。

我想假設依照上述原則，至少可以開發出一款不錯的App。