1. 程式人生 > >【架構篇】Android移動app架構設計淺談

【架構篇】Android移動app架構設計淺談

前言

架構,又名軟體架構,是有關軟體整體結構與元件的抽象描述,用於指導大型軟體系統各個方面的設計。

軟體架構設計目標:

1.可靠性(Reliable)。軟體架構的可靠是產品設計的前提。
2.安全性(Secure)。軟體架構的安全性是產品可持續發展的條件。
3.可擴充套件性(Scalable)。軟體架構必須能夠不同的功能需求情況下,支援可擴散性。
4.可定製化(Customizable)。同樣的一套軟體,可以根據客戶群的不同和市場需求的變化進行調整。
5.可伸縮 (Extensible)。在新技術出現的時候,一個軟體架構應當允許匯入新技術,從而對現有系統進行功能和效能的擴充套件。
6.可維護性(Maintainable)。軟體系統的維護包括兩方面,一是排除現有的錯誤,二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低技術支援的花費。

架構是專案形成到一定階段的趨勢。是對整個產品是否合格的有效保證。對於很多專案設計人員,在不考慮產品本身,不考慮團隊,不考慮時間週期的前提下,一味的強調軟體構架,是不合理的,也不利於整個產品的發展。當然,一個好的專案架構師,是很能清楚,專案在不同階段,所需要處理的不同職責。能夠最大限度的發揮能效,將產品週期,與功能模組做出最合適的匹配規劃,這才是一個架構師所必須追求的。

以下是個人對Android移動專案架構設計簡單的經驗之談。歡迎與更多的朋友交流,若有疑問,或不合理之處,都可以隨時交流。

從專案功能開始

每一個專案架構師,在拿到一個新專案的時候,都會不同的著重點。在專案規劃風格上,都會有不同的考慮。而我個人在著手專案時,都會從功能上去著手。先了解專案整體的功能模組,區分出主體功能模組有哪些類,對不同的功能模組進行細緻的劃分。這是我開始的第一步。因為,只有對專案整體有個把握,才能更快的對專案有了解,才能知道怎樣去合理安排專案的研發,才能更好的去安排專案進度流程,和人員的安排排程。

功能劃分之後,接下來就是專案的實際研發階段。這個階段就是專案實際進展階段了。必須要有合理的安排排程,才是保證專案的高效。比如:我們進行的大部分專案,都有網路互動的部分,也有本地功能部分,還有一些基礎資料模組部分,這些功能必須要有合理的時間安排。

專案研發之前,幾點提要說明:
一、團隊之間統一編碼規範。
二、需求文件統一管理。
三、多人協同開發,根據文件開發(一切以文件為主)。

專案以功能劃分,功能以模組劃分。在專案初期,除了產品原型可能是提前設計成形外,其它的專案文件都還未出來,產品也是有個確定功能,但是細節文件還未成形,這個時候已經是專案開始階段,即使在有一些文件還未成形前,也可以開始專案的基礎開發了。

功能模組

網路模組,資料庫儲存模組,資料加密模組,資料快取模組,資料解析器,日誌資訊收集模組等。這些都是專案的基本模組,也可以獨立於功能的模組,可以提前開發,測試。便於後期直接使用。

移動安全機制

做過移動專案的都知道,移動安全是專案前期需要考慮的一個重要環節。所以,在專案之初,就應該對自身的資料儲存做必要的資料加密,對網路傳輸的資料進行必要加密。
移動資料加密分為兩種:
一種是本地資料加密,只是本機儲存的資訊,本地加密儲存。
一種是網路傳輸資料加密,這是涉及到網路協議,與伺服器之間的加密協議。

本地加密方式有很多種:
一、MD5加密演算法。 MD5是個不可逆的演算法 沒有解密的演算法(目前據說也有方法破解)。
二、DES加密。可逆。
三、RSA加密。可逆
對於不是需要絕對足夠安全的專案,以上三種加密足夠用。

網路資料加密主要從兩個方面考慮:
1. 保證API的呼叫者是經過自己授權的App;
2. 保證資料傳輸的安全。

保證API是自己授權的App,採用設計簽名的方式。對每個移動平臺,都會有不同的AppKey和AppSecret。在呼叫API時,將AppKey加入到請求引數中,然後,把AppSecret與其它引數,通過某種簽名演算法生成一個簽名字串,把資料傳輸給伺服器端。而伺服器根據AppKey和AppSecret,用相同的簽名演算法生成的簽名與之一致,則說明請求安全。簽名演算法可以採用自己規定的一套簽名演算法(更安全),也可採用外部公開的簽名演算法(初期使用)。另外,在引數列表中再加入一個時間戳,還可以防止部分重放攻擊。
對於資料傳輸安全,可以使用HTTPS。因為HTTPS添加了ssl安全協議。但是android專案開發,大部分都沒有去實現。主要是沒有對ssl證書進行安全性檢查。

API協議標準化

專案開發,協議一定需要標準化,並且需要嚴格執行介面協議。完成每個版本的協議文件更新,方便後續使用者檢視。
目前協議都是使用Json格式傳輸。需要注意的是,JSON資料和實體物件在傳輸時,序列化和反序列化因平臺不同,會產生不同的區別。比如:JSON庫將Date型別的資料序列化時會轉為String,傳輸到伺服器時,伺服器反序列化經常會出現不同的結果。

API介面版本控制

一般解決介面更新變化問題,我們採取的做法是,每個API介面,都會帶有協議的版本,若是協議發生改變,則版本號相應改變,在處理資料請求時,則可以根據不同協議的版本進行處理,解決了版本的相容性問題。

架構分層

架構設計,主要的目的就解決功能和程式碼的複用,減少重複開發,方便功能擴充套件,降低功能和程式碼層級的耦合。
目前移動設計框架,主流的有三種:MVC、MVP、MVVM三種方式(具體詳情,請參考框架小結)。
任何的框架設計都是在滿足開發需求為前提,千萬不能為了設計而設計,不要問我這三種設計,哪種最合適開發?如果你還這樣去問,那隻能說你還不是一個成熟的產品設計者。三種框架都有各自的利弊,是應該在不同的階段和不同人員的配備情況下,選擇更合理的方式。我曾經參與一個創業團隊開發視訊專案,前期只有兩個移動開發人員,專案時間緊的情況下。專案負責人就只會天天在那裡修改需求,談專案架構。初期的專案,在產品驗證功能階段,在專案需要快速迭代階段,應該使用最有效的框架,才是合理的選擇。而且專案的發展,一定是隨著專案功能的確立,產品的定型和需求完善,對專案本身的穩定性和效能的要求,才是一個逐步提高的過程。想要一步達到完美的產品,不僅是在設計上很難做到,而且在目前所有的產品中,都是很難達到的。

任何框架都是在此三層資料模型上。View,Model,Controller/Presenter/ViewModel。上層View:使用者行為操作,資料結果顯示。底層Model:資料處理,提供顯示資料。中間的就是業務邏輯層。

Android專案設計,重在對專案的理解,重在對需求功能的劃分,重在對團隊合理分配。高效的產出,快速的迭代,才是移動專案的生存之道。

Android測試

移動開發,為保證質量產出,需要進行必須要邏輯測試。而在專案框架設計中,簡單的mvc模式,若view和model中混有業務邏輯,則不利於介面測試。所以,在後續版本的迭代中,需要逐漸使用mvp或mvvm框架設計,讓view和model與業務邏輯實現完整的解耦合。

Android環境

自從Android提供了更高效穩定的android studio之後,對於開發者來說是更便捷,更方便了。在android gradle多平臺打包。proguard程式碼優化,混淆。隨著android studio的越來越強大,越來越穩定,相信開發android專案也會變得越來越so easy了。

總結在最後

一個合格的移動專案架構師,必須是在不斷的專案開發中成長的。不僅僅懂得專案的高效快速部署,也懂得怎樣合理優化團隊,才能有更優質的產品產出。移動產品,是一個快速產出的產品,怎樣做出適合團隊產出的產品,才是移動架構師的學習之道。

android移動高階開發,請加入群交流:247039470

轉載,請說明出處!謝謝!