[轉]設計一款Android App總結

標籤：驗證   通過   esc   ast   檔案管理   記憶體   image   校正   響應   

開發工具的選擇

開發工具我將選用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了，建議儘可能地使用原生組件，少用自訂群組件，因為原生組件效能是最好的。至於各種層出不窮的架構，如MVP、MVVM等，以及經典的MVC，其實每種架構都並非十全十美，都有適用的情境，因此這裡不會厚此薄彼，任何一種架構只要用得好都沒問題。

9.APK動態載入機制

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

10.App的安全性考慮

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

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

 

http://blog.csdn.net/ahence/article/details/47154419

 

[轉]設計一款Android App總結