本文從開發工具選擇,UI界面、圖片模塊、網絡模塊、數據庫產品選擇、性能、安全性等幾個方面講述了若是開發一個Android應用。如今整理出來分享給廣大的Android程序員兄弟們。程序員
開發工具我將選用 Android Studio,它是Google官方指定的Android開發工具。 Android Studio的優勢就不需多說了,GitHub上大部分的Android開源庫也都已遷移到Android Studio上來,在未提供 jar文件時,使用Android Studio能夠極爲方便地集成開源庫。最爲重要的是Google已宣佈將在年末前中止對 Eclipse Android開發工具的一切支持(Google Ends Support for Android Eclipse Tools),所以請早日轉移到Android Studio上來。面試
這一點對於一個開發者來講,貌似沒有決定權,最終的決定權在產品部門手裏。儘管這樣,我仍是會盡力說服產品部門將App設計成Material Design風格。算法
這一點說多了都是淚啊,做爲一個Android開發者,卻成天開發着iOS風格的App,相信不少公司都這樣,爲了節省成本和時間,Android和iOS共用一套UI。sql
舉一個最多見的例子,Android App中每一個頁面TitleBar的左上角放一個返回按鈕,這在iOS裏是必須的,但Android有返回鍵啊,這樣設計對於 Android徹底是畫蛇添足。數據庫
真心但願產品設計者尊重每種操做系統的風格及使用習慣,不要再設計不三不四的產品。Material Design正好提供了一種這樣的規範,自MD規範發佈以來,其優雅的設計和清新的風格已吸引了大批設計者和開發者,現在MD設計不止在Android上(已有官方類庫支持 MD風格),甚至在CSS、HTML、JavaScript網頁設計上都愈來愈火。所以,對於App的設計風格,Material Design當仁不讓,也許你曾經錯過了Android Design,請不要再錯過Material Design。json
對於Android要支持的最低版本,能夠參考各個版本的市場佔有率,其實最靠譜的是根據自家App的統計數據來決定,目前咱們的App最低支持2.2。以我的觀點認爲,雖然2.x的版本仍然有一部分用戶,但其實手機更新換代特別快,爲了更好的用戶體驗,也爲了應用更新的API(不少第三方庫也都有版本要求),應該提升最低支持的版本,大概3.0 爲宜,即API Level爲11。小程序
相信你們都有體會,隨着功能模塊的增長,App愈來愈大,若是沒有良好的架構設計,則代碼將會變得臃腫且不易維護,各功能模塊的耦合度會愈來愈高。所以能夠把App模塊化,將一個完整的App劃分紅幾個相對獨立的模塊,這樣便可以下降模塊間的耦合也利於複用。微信小程序
已經不多有單機版的App了吧,大部分都須要聯網,從服務器請求數據,所以網絡模模塊必不可少。GitHub上的開源網絡框架也特別多,我的認爲可使用開源框架,目前我會選okHttp或者Volley,也許之後會有更好的網絡框架出現。注意若是使用開源框架,則必需要閱讀其源碼,必須可以駕馭它,這樣就不至於當bug出現時一籌莫展。固然還能夠本身寫網絡模塊,目前咱們的App網絡模塊就徹底是本身寫的,這樣的好處是本身熟悉所寫的代碼,當有bug時能夠迅速定位問題,同時注意處理一些聯網過程當中的細節,如:緩存
(1)對HTTPS的支持、HTTPS證書的驗證(目前不少作法都是默認容許全部HTTPS證書的,其實這樣作是不安全的,應當真正地作證書校驗)安全
(2)支持Wap方式上網,移動、聯通、電信代理的設置
(3)支持重定向、數據壓縮傳輸等
(4)其餘值得注意的問題
本身寫網絡框架能夠完美地處理這些細節,但時間成本比較大。若是使用開源框架,通常都沒有處理這些細節,所以咱們能夠在第三方框架上作些修改,這樣時間成本將會節省不少。
圖片也是App中不可少的元素,並且圖片是佔用內存的大戶,所以圖片管理框架特別重要,很差的圖片框架容易引發內存泄露甚至致使崩潰。固然能夠本身實現圖片框架(目前咱們也是這樣作的),實現圖片的下載、解碼、緩存等關鍵環節。我的建議能夠採用一些比較好的圖片庫,也許會比咱們本身管理圖片更完善和高效。我會推薦以下幾個圖片管理庫:
(1)Glide,Google的一些官方App,如Google photos都使用了,還要解釋更多嗎?
(2)Fresco,FaceBook的開源庫,功能超級強大,支持WebP、Gif、JPEG漸進顯示,關鍵是其對圖片內存的設計思想,使得圖片內存開銷大大減小。
(3)Android-Universal-Image-Loader,在出現上述圖片庫以前,貌似這個最火吧,以前我的的App中也用了它。
(4)Picasso,Square的開源庫,聽說Glide就是參考Picasso設計的。
也許你的App須要用到本地數據庫,那麼建議你採用流行的ORM框架,如ActiveAndroid或greenDAO,使用第三方庫會大大方便你對sqlite的操做,我的認爲在使用中咱們須要注意數據庫升級以及多線程併發操做數據庫的問題。
一個App,確定會涉及到一些文件,如配置文件、圖片、視頻、音頻、SharedPreferences文件等。咱們能夠提供一個全局的文件管理模塊,負責文件的增、刪、改、查等操做。另外還需支持文件壓縮,文件的上傳與下載操做,對於下載須要支持多線程併發下載、斷點續傳等功能。
對於一個App,組件通訊必不可少,通訊類型能夠分爲點對點和點對面的的通訊,點對點即只有惟一的接收者能夠響應消息,點對面則相似於消息廣播,即全部註冊過的均可以響應消息。在Android 中,一般使用消息機制來實現,但消息機制的耦合度比較高。目前也有一些通訊框架,如EventBus、Otto等事件總線框架,這些框架能夠極大地下降組件間的耦合,但沒法完美地實現點對點通訊,所以建議消息機制和事件總線機制結合使用。
其實還應該有一個數據處理框架,當發出數據請求後(走子線程),經網絡模塊返回數據(通常爲JSON格式),JSON數據通常不能直接交給View層使用,須要解析成對應的Model,同時若有須要,還要緩存數據,所以這些流程能夠抽象成一個數據處理的框架。這個框架能夠認爲接受數據請求的url,並將數據Model返回給Activity或 Fragment。對於JSON數據解析,建議使用fastjson,速度快且穩定,缺省值也比較完善。
其實Android中有不少操做,如請求數據、下載圖片、清除緩存等都是須要在子線程中執行的,每每不少時候都是直接起一個Thread來作了,這樣作就會很亂並且線程多了將難以管理。所以能夠抽象出一個線程調度模塊,它維護一個線程池,若是有須要線程的話就經過線程調度模塊取線程來作,這樣就方便統一管理。固然第三方庫中的線程操做咱們將沒法歸到線程調度模塊來管理,但其餘涉及到線程的操做都應該來統一處理。
業務層大概就是四大組件、Fragment、View了,建議儘量地使用原生組件,少用自定義組件,由於原生組件性能是最好的。另外建議使用MVC模式就好,只要設計管理好本身的邏輯,至於MVP、MVVM等模式我的認爲都有缺陷,總之尋求一個折中吧,有得必有失。
隨着App的增大,功能的擴展,不少App已經採用了APK動態加載的機制,也能夠叫作插件化。因爲本人沒有在實際的App中應用過,因此不便發表過多評論。但這種機制我的認爲頗有前途,這種機制將利於App的解耦、功能擴展和局部升級。具體能夠參考一個商用的解決方案:ApkPlug-移動應用模塊化解決方案和一個開源的APK動態加載框架。
Android App的安全問題不多有人重視,但這的確是一個很嚴重的問題,一些好的App常常被人破解。建議將一些核心算法等寫成.so庫,重要的邏輯放在服務器端,數據請求採用加密等,另外打包APK時至少要混淆代碼,還能夠採用APK加殼機制,總之這類的防範措施永遠不嫌多。
一口氣漫無邏輯地寫了這麼多,可能會有遺漏的內容,後續會補充完善。我想若是按照上述原則,至少能夠開發出一款不錯的App。
若是你看到了這裏,以爲文章寫得不錯就給個讚唄?若是你以爲那裏值得改進的,請給我留言。必定會認真查詢,修正不足,謝謝~
最後針對Android程序員,除了上面的知識體系,我這邊給你們整理了一些資料,包括不限於高級UI、性能優化、移動架構師、NDK、混合式開發(ReactNative+Weex)微信小程序、Flutter等全方面的Android進階實踐技術;但願能幫助到你們,也節省你們在網上搜索資料的時間來學習,也能夠分享動態給身邊好友一塊兒學習!
須要展開更加詳細的架構學習筆記體系路線的戳一下這裏。。。