原文鏈接：http://keeganlee.me/post/architecture/20160303
版權聲明：本文刊載在《程序員》雜誌2016年3期，版權歸《程序員》所有，未經許可不得轉載
架構因人而異，不同的架構師大多會有不同的看法；架構也因項目而異，不同的項目需求不同，相應的架構也會不同。然而，有些東西還是通用的，是所有架構師都需要考慮的，也是所有項目都會有的需求，比如API如何設計？架構如何分層？開發環境和生產環境如何分離？這幾年，我負責研發過的App，有餐飲類的、社交類的、智能家居類的、電商類的、新聞媒體類的等等。當有了一定的經驗之後，你總會有一些自己的心得體會。而以下內容就是根據我的這些經歷提煉出來的關於以上幾個問題方面的經驗總結，內容不多，旨在拋磚引玉。
從API開始
一個App，最核心的東西，其實就是數據，而數據的主要來源，就是API。我之前負責的項目，因爲API的坑已經受過了不少苦，因此，之後對App項目的架構設計我都會先從API開始。
制定安全機制
設計API第一個需要考慮的是API的安全機制。我負責的上一個項目，因爲API的安全問題，就被人攻擊了兩次。之後經過分析，主要存在兩個漏洞：一是因爲缺少對調用者進行安全驗證的方式，二是因爲數據傳輸不夠安全。那麼，制定API的安全機制，主要就是爲了解決這兩個問題：
- 保證API的調用者是經過自己授權的App；
- 保證數據傳輸的安全。
第一個問題的解決方案，我主要採用設計簽名的方式。對每個客戶端，Android、iOS、WeChat，分別分配一個AppKey和AppSecret。需要調用API時，將AppKey加入請求參數列表，並將AppSecret和所有參數一起，根據某種簽名算法生成一個簽名字符串，然後調用API時把該簽名字符串也一起帶上。服務端收到請求之後，根據請求中的AppKey查詢相應的AppSecret，按照同樣的簽名算法，也生成一個簽名字符串，當服務端生成的簽名和請求帶過來的簽名一致的時候，那就表示這個請求的調用者是經過自己授權的，證明這個請求是安全的。而且，每個端都有一個Key，也方便不同端的標識和統計。爲了防止AppSecret被別人獲取，這個AppSecret一般寫死在代碼裏面。另外，簽名算法也需要有一定的複雜度，不能輕易被別人破解，最好是採用自己規定的一套簽名算法，而不是採用外部公開的簽名算法。另外，在參數列表中再加入一個時間戳，還可以防止部分重放攻擊。
第二個問題的解決方案，主要就是採用HTTPS了。HTTPS因爲添加了SSL安全協議，自動對請求數據進行了壓縮加密，在一定程序可以防止監聽、防止劫持、防止重發，主要就是防止中間人攻擊。蘋果從iOS9開始，默認就採用HTTPS了。而關於在Android中如何使用HTTPS，Google官方也給出了很多安全建議。不過，大部分App並沒有按照安全建議去實現，主要就是沒有對SSL證書進行安全性檢查，這就成爲了一個很大的漏洞，中間人利用此漏洞用假證書就可以通過檢查，從而可以劫持到所有數據了。因此，爲了安全考慮，建議對SSL證書進行強校驗，包括簽名CA是否合法、域名是否匹配、是不是自簽名證書、證書是否過期等。
接口協議標準化
API返回的數據，一般都是採用JSON格式進行傳輸。然而，JSON的值只有六種數據類型：
- Number：整數或浮點數
- String：字符串
- Boolean：true 或 false
- Array：數組包含在方括號[]中
- Object：對象包含在大括號{}中
- Null：空類型
我遇到過的，關於API的坑有大部分就是因爲JSON數據和實體對象轉化時出錯導致的，而且是各種各樣的錯誤都有，其中不乏有一些很奇葩的錯誤。
最麻煩的就是處理Date類型，因爲JSON本身沒有Date類型，因此，JSON庫將Date類型的數據序列化時會轉爲String。這時，不同環境，不同平臺，以及用不同的JSON解析庫，轉換後的結果經常會不同。比如，你在開發機上可能得到的結果是”2016-1-1 17:11:11”，但放到服務器後結果卻變成了“Jan 1,2016 5:11:11 PM” ，客戶端進行反序列化時無疑會失敗。後來，我取消了所有Date類型，統一採用時間戳表示，就再沒有轉化的煩惱了。
另外，接口的開發人員有時候會將一些數據錯誤地轉換爲了String，導致客戶端使用時因類型錯誤而異常。例如，本來是數字的1，被轉成了"1"，客戶端做運算時就會出錯，或用switch判斷時也會出錯，或其他無法轉換的情況發生時；例如，爲空時JSON正確地表示應該是null，但如果轉爲了String就變成了"null"，那問題就來了，我遇到的因爲這個錯誤的轉換導致的程序奔潰已經好幾次了，第一次的時候，查了一整天才定位到問題所在。
還有，因爲接口的開發人員不同，很多時候還會出現不同接口同一個意思的參數名稱卻不同。比如，對於有分頁數據的接口，一般都有當前頁的參數，A開發人員可能將參數命名爲currentPage，第一頁是從0開始；B開發人員在另一個接口則命名爲currPage，第一頁卻從1開始；C開發人員在另一個接口又命名爲presentPage，第一頁又是從0開始。客戶端的開發人員看到也是醉了。
每個技術團隊一般都會有一份接口協議文檔，主要內容包括每個接口的描述、入參、輸出結果等，但一般並不嚴謹，很多地方沒有統一標準，從而容易出現很多坑。因此，有一份統一標準且嚴格執行的接口協議非常重要。協議的內容除了規定每個接口，包括接口中每個數據具體的數據類型，還需要規定一套共用的數據字典，以及其他需要統一定義的信息，比如簽名算法等。一旦有了這份統一標準且嚴格執行的接口協議，很多問題都將迎刃而解。
接口版本控制
我們已經不止一次因爲接口發生變動而導致舊版本的App出錯的問題，而且變動不一定是修改了接口本身，有可能是底層增加了一種新的數據結構，接口把新數據也返回給客戶端了，但客戶端舊版本是解析不了的，從而就導致出錯了。
爲了解決接口的兼容性問題，需要做好接口版本控制。實現上，一般有兩種做法：
- 每個接口有各自的版本，一般爲接口添加個version的參數；
- 整個接口系統有統一的版本，一般在URL中添加版本號，比如http://api.domain.com/v2。
平時小版本的更新，就採用第一種方式，我們的做法是根據不同版本號做不同分支處理。大版本的更新，則用第二種方式，這時候，基本就是一套全新的接口系統了，跟舊版本是相對獨立的。
當版本越來越多時，維護就會成爲一個大問題，我們沒那麼多精力去維護所有版本，因此，太舊的版本一般就不會再維護了。這時候，如果有用戶還在使用即將廢棄的舊版本，需要提醒用戶升級到新版本。
架構分層
API的設計完成之後，接下來我就會考慮App項目的整體架構了。整體如何架構，我也曾經做過不少嘗試。早期的時候，Android就是將所有操作都放在Activity裏完成，包括界面數據處理、業務邏輯處理、調用API。後來發現Activity越來越臃腫，代碼越來越複雜，很難維護。於是就開始思考如何拆分，如何才能做到鬆耦合高內聚。
前面也說過，一個App的核心就是數據，那麼，從App對數據處理的角色劃分出發，最簡單的劃分就是：數據管理、數據加工、數據展示。相應的也就有了三層架構：數據層、業務層、展示層。它們之間的關係如下圖，數據層是三層中的最底層，往下，它接入API；往上，它向業務層交付數據。業務層夾在三層中間，屬於數據的加工廠，將數據層提供上來的數據加工成展示層需要展示的數據。展示層處於三層中的最上層，主要就是將從業務層取得的數據展示到界面上。
數據層
數據層是數據管理者，主要任務就是封裝API，並將數據結果交付給上層，中間會再加個數據緩存。整個主流程如下圖：
- 業務層向數據層請求數據；
- 數據層檢查緩存中有沒有請求需要的數據；
- 如果有緩存數據，則直接返回緩存數據；
- 如果沒有緩存數據，則從網絡API獲取數據，並將數據加入緩存，然後返回數據。
調用網絡API時，還要判斷網絡狀態，根據不同狀態做不同處理。如果網絡不可用，就無需發起請求了。網絡可用時，也要區分是連接WIFI還是連接移動網絡。連接移動網絡時，一般需要限制調用比較耗流量的請求。曾經，我們沒有對移動網絡狀態下的請求進行限制，結果，測試時流量DuangDuangDuang地一下子就不見了十幾M。連接WIFI時，則無需設置這種限制，而且還可以預先請求一些接口，比如請求當前分頁數據時，可以將下一頁的數據也預先請求。
緩存也需要緩存策略，不同的接口需要做不同的緩存處理。首先，緩存只適用於獲取數據的接口，對於修改數據的接口則不適用。其次，不同接口緩存時間一般也不同，對於很少變動的數據緩存時間可以設置長一些，而頻繁變動的數據緩存時間則比較短，甚至不進行緩存。最後，緩存數據因爲比較多，我們一般保存在數據庫，而對於調用頻率高、最新的數據，還會在內存中也擁有一份緩存，不過緩存時間比較短。請求緩存數據時，會先檢查內存緩存中有沒有，有則直接將緩存的數據返回，沒有才從數據庫獲取。
那麼，如何將數據交付給業務層呢？這是整個數據層模塊與外部交互的部分，當與外部交互的時候，一般都要符合面向接口編程的原則，因此只要提供開放的數據接口就可以了。對於接口的參數需要說明一下，上面提到的參數有appKey、version、currentPage這幾個，還有簽名sign、時間戳time，其實可以分爲兩類：系統參數和業務參數。像appKey、version、sign、time這些屬於系統參數，而currentPage，或username之類的則屬於業務參數。數據層開放的數據接口的參數只需要包含業務參數就可以了，業務層並不需要關心繫統參數是什麼，系統參數在數據層內部封裝API時指定就可以了。
業務層
業務層是數據加工者，主要就是從數據層獲取數據，然後經過業務邏輯處理後轉化成展示層需要的數據。業務層因爲夾在數據層和展示層中間，起着承上啓下的作用。也因此，業務層很容易淪落爲只是一個數據的中轉站，主要就是因爲對業務層具體的作用和職責沒有理解清楚。
這裏用一個例子來說明業務層具體的工作吧，就舉個用戶註冊的例子。用戶註冊時，界面上需要用戶提供手機號、短信驗證碼、密碼、確認密碼。那麼，最簡單的操作就是，帶上這些參數調用數據層的註冊接口。好了，問題來了，註冊接口並沒有提供確認密碼的參數。那好，調用註冊接口之前先判斷下密碼和確認密碼是否一致，不一致則返回錯誤提示給用戶，一致了才調用註冊接口。好了，第二個問題來了，用戶等網絡請求等了一段時間後，請求結果返回說手機號少了一位。下一次，又等了一段時間，這次又返回說手機號多了一位。就因爲一個小錯誤要讓用戶等那麼久，用戶肯定有意見。後臺也有意見，各種非法的請求都發過來，是嫌服務器壓力不夠大啊。那好，調用接口之前對這些參數做有效性檢查吧，手機號要規範，短信驗證碼只能爲六位數字，密碼不能少於六位。終於註冊成功了，第三個問題又來了，註冊接口是沒有返回用戶的accessToken的，只有登錄接口才會返回。讓用戶手動再登錄一下？這用戶體驗不太好啊。正確的姿勢應該是註冊成功後再自動調用一次登錄接口，如果因爲網絡問題第一次登錄失敗，後面還需要再自動調用多一次，如果還是調用失敗，才讓用戶手動登錄。
上面的例子中，對參數的有效性檢查，註冊成功後的自動登錄，都屬於業務邏輯的處理，也就是說都是業務層的工作。
業務層交付給展示層的數據也是通過接口的方式，不過，和數據層交付給業務層時不同的是：交付給展示層的數據應該是通過異步回調返回的。因爲獲取數據是一個比較耗時的任務，通過異步回調纔不會阻塞UI主線程。
展示層
展示層作爲數據展示者，它只要關心數據如何展示就可以了。不過，數據如何展示卻不是那麼簡單。展示層是三層架構中最複雜的一層了，要考慮的東西遠遠多於其他兩層，涉及的東西包括但不限於界面佈局、屏幕適配、圖片資源、文本資源、顏色資源等等。在開發一段時間後，展示層出現代碼混亂是最常見的。因此，做好展示層，就需要保持高質量的代碼。要保持高質量代碼，我覺得至少應該遵循幾條基本的原則：
- 保持規範性：定義好開發規範，包括書寫規範、命名規範、註釋規範等，並按照規範嚴格執行；
- 保持單一性：佈局就只做佈局，內容就只做內容，各自分離好，每個方法、每個類，也只做一件事情；
- 保持簡潔性：保持代碼和結構的簡潔，每個方法，每個類，每個包，每個文件，都不要塞太多代碼或資源，感覺多了就應該拆分。
所謂無規矩不成方圓，展示層的設計，要從開發規範開始。一份好的開發規範，是保證代碼有較高的可讀性的基礎。iOS方面，蘋果已經有一套Coding Guidelines，主要屬於命名方面的規範。當我們制定自己的開發規範時，首先就要遵守蘋果的這份規範，在此基礎上再加上自己的規範。Android方面，我也在我的博客中分享過一套（Android技術積累:開發規範），主要分爲書寫規範、命名規範、註釋規範三部分。
最重要的不是開發規範的制定，而是開發規範的執行。如果沒有按照開發規範去執行，那開發規範就等於形同虛設，那代碼混亂的問題依然得不到解決。
說到單一性，面向對象設計中，有一個基本原則就是單一職責原則，它規定一個類應該只有一個發生變化的原因。保持單一性是減低耦合度的關鍵標準，其目的就是各方面的解耦。而我這裏說的單一性不只是規定類的單一，也包括界面的單一、方法的單一、資源文件的單一等。
界面的單一，首先是界面的佈局和界面的數據應該分離。另外，界面數據的獲取和展示也應該分離。一句話，保持界面的單一性就是要保持界面上每個維度都做好分離，從界面的佈局，到數據的獲取，數據的檢查，數據的展示。
方法的單一，則表現爲一個方法是對一個行爲的封裝。行爲又可以拆分爲多個步驟，每個步驟其實也是更細化的行爲。因此，方法嵌套方法是一種常態。那麼，保持方法的單一性，關鍵不在於怎麼定義這個方法的行爲，而在於這個行爲要怎麼拆分成更細的行爲。舉個例子，通常在Activity的onCreate方法，做初始化操作，細分出來就分爲了：控件的初始化、邏輯變量的初始化、數據的初始化。數據的初始化又可以再細分：數據的獲取、數據的展示。每個細化的行爲都應該封裝爲一個獨立的方法，這樣，才真正符合方法的單一性。
資源文件的單一，主要是指Android的各類資源文件，包括存放字符串的strings.xml，存放字符串數組的arrays.xml，存放顏色值的colors.xml，存放尺寸值的dimens.xml，等等。資源文件的單一，是說所有相關的資源信息要在資源文件裏定義並引用到代碼或佈局文件裏，而不是在代碼或佈局文件裏直接定義。這樣做，可以很方便地做各種適配和修改，比如支持國際化，比如不同分辨率的屏幕用不同尺寸值。iOS則沒有提供和Android一樣的資源文件分離的機制，但可以參考Android的做法自己去實現。
環境分離
每個App項目，至少都會有兩個環境：測試環境和生產環境。多的甚至有四個環境：開發環境、測試環境、預生產環境和生產環境。開發人員經常需要在環境之間切換，測試人員也同樣。經常出現測試人員今天需要測試環境的最新版本，叫App開發人員打包一個給她，明天需要切換到生產版本，再叫App開發人員打包一個生產環境的給她。我們知道，一個App，在一臺手機上要麼只能是測試環境的，要麼只能是生產環境的。測試人員要測試兩個環境，只能不斷替換不同環境的同個App，這實在太麻煩了。爲了解決此問題，最好的方案就是環境分離，不同環境有不同的App。
一個App的唯一標識，Android是用包名，iOS是用Bundle Identify。那麼，在一個系統想安裝不同環境的App，只要每個環境App的包名和Bundle Identify不同即可。比如，生產版的包名和Bundle Identify命名爲com.mydomain.myapp，測試版的包名和Bundle Identify則命名爲com.mydomain.myapp.beta，這樣，Android和iOS都會識別爲兩個不同的App了。
不過，只改包名和Bundle Identify是不夠的，應用圖標和應用名稱也要修改，不然安裝之後很難區分哪個App是哪個環境的。一般做法就是，非生產環境的App圖標就是在生產圖標的基礎上添加一個環境標籤，同時App的應用名稱也是在生產的基礎上添加環境後綴名。另外，因爲包名和Bundle Identify不同了，微信、微博、百度地圖等這些第三方平臺也都需要爲不同環境的App分別申請不同的appID。
實現上，最笨的方法就是拷貝當前工程，然後修改，缺陷很明顯，維護成本很高。不過，好在Android和iOS都有很方便的修改方式。
Android有了Gradle，可以設置多個不同的Flavors，每個Flavor都有一個applicationId屬性，其實就是App的包名。比如，生產版和測試版的設置如下：
productFlavors { myapp { applicationId "com.mydomain.myapp" } myappBeta { applicationId 'com.mydomain.myapp.beta' } }
這樣，其實就有兩個App了。然後，源代碼新建一個和main同級的目錄，命名爲myappBeta，然後，將圖標、名稱和第三方設置之類的，和main保持一樣的位置、文件名、屬性等，就可以替換成環境相關的了。
iOS則可以通過創建多個環境的Target來實現環境分離，不同Target可以設置不同的Bundle Identify、Bundle display name、更換圖標。另外，每個Target也各自有自己的一份plist文件的，環境變量和第三方設置之類的，都可以設置在相應的plist文件裏。
寫在最後
至此，關於App架構方面的經驗總結就先講這麼多了。其中，部分內容在我以往的博客上也已經有所體現，有興趣的讀者可以前往我的博客瞭解並歡迎參與討論。
