【架構篇】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了。

總結在最後

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