APP架構經驗總結

1、-從API開場一個App，最核心的東西，其實就是數(shù)據(jù)，而數(shù)據(jù)的主要來源，就是API。我之前負責的工程，因為API的坑已經受過了不少苦，因此，之后對App工程的架構設計我都會先從API開場。制定平安機制設計API第一個需要考慮的是API的平安機制。我負責的上一個工程，因為API的平安問題，就被人攻擊了兩次。之后經過分析，主要存在兩個漏洞：一是因為缺少對調用者進展平安驗證的方式，二是因為數(shù)據(jù)傳輸不夠平安。則，制定API的平安機制，主要就是為了解決這兩個問題： 保證API的調用者是經過自己授權的App； 保證數(shù)據(jù)傳輸?shù)钠桨?。第一個問題的解決方案，我主要采用設計簽名的方式。對每個客戶端，Android

2、、iOS、WeChat，分別分配一個AppKey和AppSecret。需要調用API時，將AppKey參加請求參數(shù)列表，并將AppSecret和所有參數(shù)一起，根據(jù)*種簽名算法生成一個簽名字符串，然后調用API時把該簽名字符串也一起帶上。效勞端收到請求之后，根據(jù)請求中的AppKey查詢相應的AppSecret，按照同樣的簽名算法，也生成一個簽名字符串，當效勞端生成的簽名和請求帶過來的簽名一致的時候，那就表示這個請求的調用者是經過自己授權的，證明這個請平安的。而且，每個端都有一個Key，也方便不同端的標識和統(tǒng)計。為了防止AppSecret被別人獲取，這個AppSecret一般寫死在代碼里面。另外，

3、簽名算法也需要有一定的復雜度，不能輕易被別人破解，最好是采用自己規(guī)定的一套簽名算法，而不是采用外部公開的簽名算法。另外，在參數(shù)列表中再參加一個時間戳，還可以防止局部重放攻擊。第二個問題的解決方案，主要就是采用HTTPS了。HTTPS因為添加了SSL平安協(xié)議，自動對請求數(shù)據(jù)進展了壓縮加密，在一定程序可以防止監(jiān)聽、防止劫持、防止重發(fā)，主要就是防止中間人攻擊。蘋果從iOS9開場，默認就采用HTTPS了。而關于在Android中如何使用HTTPS，Google官方也給出了很多平安建議。不過，大局部App并沒有按照平安建議去實現(xiàn)，主要就是沒有對SSL證書進展平安性檢查，這就成為了一個很大的漏洞，中間人利

4、用此漏洞用假證書就可以通過檢查，從而可以劫持到所有數(shù)據(jù)了。因此，為了平安考慮，建議對SSL證書進展強校驗，包括簽名CA是否合法、域名是否匹配、是不是自簽名證書、證書是否過期等。接口協(xié)議標準化API返回的數(shù)據(jù)，一般都是采用JSON格式進展傳輸。然而，JSON的值只有六種數(shù)據(jù)類型： Number：整數(shù)或浮點數(shù) String：字符串 Boolean：true 或 false Array：數(shù)組包含在方括號中 Object：對象包含在大括號中 Null：空類型我遇到過的，關于API的坑有大局部就是因為JSON數(shù)據(jù)和實體對象轉化時出錯導致的，而且是各種各樣的錯誤都有，其中不乏有一些很奇葩的錯誤。最麻煩的就

5、是處理Date類型，因為JSON本身沒有Date類型，因此，JSON庫將Date類型的數(shù)據(jù)序列化時會轉為String。這時，不同環(huán)境，不同平臺，以及用不同的JSON解析庫，轉換后的結果經常會不同。比方，你在開發(fā)機上可能得到的結果是2016-1-1 17:11:11，但放到效勞器后結果卻變成了Jan 1,2016 5:11:11 PM，客戶端進展反序列化時無疑會失敗。后來，我取消了所有Date類型，統(tǒng)一采用時間戳表示，就再沒有轉化的煩惱了。另外，接口的開發(fā)人員有時候會將一些數(shù)據(jù)錯誤地轉換為了String，導致客戶端使用時因類型錯誤而異常。例如，本來是數(shù)字的1，被轉成了1，客戶端做運算時就會出錯，

6、或用switch判斷時也會出錯，或其他無法轉換的情況發(fā)生時；例如，為空時JSON正確地表示應該是null，但如果轉為了String就變成了null，那問題就來了，我遇到的因為這個錯誤的轉換導致的程序奔潰已經好幾次了，第一次的時候，查了一整天才定位到問題所在。還有，因為接口的開發(fā)人員不同，很多時候還會出現(xiàn)不同接口同一個意思的參數(shù)名稱卻不同。比方，對于有分頁數(shù)據(jù)的接口，一般都有當前頁的參數(shù)，A開發(fā)人員可能將參數(shù)命名為currentPage，第一頁是從0開場；B開發(fā)人員在另一個接口則命名為currPage，第一頁卻從1開場；C開發(fā)人員在另一個接口又命名為presentPage，第一頁又是從0開場?？?/p>

7、戶端的開發(fā)人員看到也是醉了。每個技術團隊一般都會有一份接口協(xié)議文檔，主要容包括每個接口的描述、入參、輸出結果等，但一般并不嚴謹，很多地方沒有統(tǒng)一標準，從而容易出現(xiàn)很多坑。因此，有一份統(tǒng)一標準且嚴格執(zhí)行的接口協(xié)議非常重要。協(xié)議的容除了規(guī)定每個接口，包括接口中每個數(shù)據(jù)具體的數(shù)據(jù)類型，還需要規(guī)定一套共用的數(shù)據(jù)字典，以及其他需要統(tǒng)一定義的信息，比方簽名算法等。一旦有了這份統(tǒng)一標準且嚴格執(zhí)行的接口協(xié)議，很多問題都將迎刃而解。接口版本控制我們已經不止一次因為接口發(fā)生變動而導致舊版本的App出錯的問題，而且變動不一定是修改了接口本身，有可能是底層增加了一種新的數(shù)據(jù)構造，接口把新數(shù)據(jù)也返回給客戶端了，但客戶端

8、舊版本是解析不了的，從而就導致出錯了。為了解決接口的兼容性問題，需要做好接口版本控制。實現(xiàn)上，一般有兩種做法：每個接口有各自的版本，一般為接口添加個version的參數(shù)；整個接口系統(tǒng)有統(tǒng)一的版本，一般在URL中添加版本號，比方api.domain./v2。平時小版本的更新，就采用第一種方式，我們的做法是根據(jù)不同版本號做不同分支處理。大版本的更新，則用第二種方式，這時候，根本就是一套全新的接口系統(tǒng)了，跟舊版本是相對獨立的。當版本越來越多時，維護就會成為一個大問題，我們沒則多精力去維護所有版本，因此，太舊的版本一般就不會再維護了。這時候，如果有用戶還在使用即將廢棄的舊版本，需要提醒用戶升級到新版本

9、。架構分層API的設計完成之后，接下來我就會考慮App工程的整體架構了。整體如何架構，我也曾經做過不少嘗試。早期的時候，Android就是將所有操作都放在Activity里完成，包括界面數(shù)據(jù)處理、業(yè)務邏輯處理、調用API。后來發(fā)現(xiàn)Activity越來越臃腫，代碼越來越復雜，很難維護。于是就開場思考如何拆分，如何才能做到松耦合高聚。前面也說過，一個App的核心就是數(shù)據(jù)，則，從App對數(shù)據(jù)處理的角色劃分出發(fā)，最簡單的劃分就是：數(shù)據(jù)管理、數(shù)據(jù)加工、數(shù)據(jù)展示。相應的也就有了三層架構：數(shù)據(jù)層、業(yè)務層、展示層。它們之間的關系如下列圖，數(shù)據(jù)層是三層中的最底層，往下，它接入API；往上，它向業(yè)務層交付數(shù)據(jù)。業(yè)

10、務層夾在三層中間，屬于數(shù)據(jù)的加工廠，將數(shù)據(jù)層提供上來的數(shù)據(jù)加工成展示層需要展示的數(shù)據(jù)。展示層處于三層中的最上層，主要就是將從業(yè)務層取得的數(shù)據(jù)展示到界面上。數(shù)據(jù)層數(shù)據(jù)層是數(shù)據(jù)管理者，主要任務就是封裝API，并將數(shù)據(jù)結果交付給上層，中間會再加個數(shù)據(jù)緩存。整個主流程如下列圖： 業(yè)務層向數(shù)據(jù)層請求數(shù)據(jù)； 數(shù)據(jù)層檢查緩存中有沒有請求需要的數(shù)據(jù)； 如果有緩存數(shù)據(jù)，則直接返回緩存數(shù)據(jù)； 如果沒有緩存數(shù)據(jù)，則從網絡API獲取數(shù)據(jù)，并將數(shù)據(jù)參加緩存，然后返回數(shù)據(jù)。調用網絡API時，還要判斷網絡狀態(tài)，根據(jù)不同狀態(tài)做不同處理。如果網絡不可用，就無需發(fā)起請求了。網絡可用時，也要區(qū)分是連接WIFI還是連接移動網絡。連接

11、移動網絡時，一般需要限制調用比擬耗流量的請求。曾經，我們沒有對移動網絡狀態(tài)下的請求進展限制，結果，測試時流量DuangDuangDuang地一下子就不見了十幾M。連接WIFI時，則無需設置這種限制，而且還可以預先請求一些接口，比方請求當前分頁數(shù)據(jù)時，可以將下一頁的數(shù)據(jù)也預先請求。緩存也需要緩存策略，不同的接口需要做不同的緩存處理。首先，緩存只適用于獲取數(shù)據(jù)的接口，對于修改數(shù)據(jù)的接口則不適用。其次，不同接口緩存時間一般也不同，對于很少變動的數(shù)據(jù)緩存時間可以設置長一些，而頻繁變動的數(shù)據(jù)緩存時間則比擬短，甚至不進展緩存。最后，緩存數(shù)據(jù)因為比擬多，我們一般保存在數(shù)據(jù)庫，而對于調用頻率高、最新的數(shù)據(jù)，還

12、會在存中也擁有一份緩存，不過緩存時間比擬短。請求緩存數(shù)據(jù)時，會先檢查存緩存中有沒有，有則直接將緩存的數(shù)據(jù)返回，沒有才從數(shù)據(jù)庫獲取。則，如何將數(shù)據(jù)交付給業(yè)務層呢.這是整個數(shù)據(jù)層模塊與外部交互的局部，當與外部交互的時候，一般都要符合面向接口編程的原則，因此只要提供開放的數(shù)據(jù)接口就可以了。對于接口的參數(shù)需要說明一下，上面提到的參數(shù)有appKey、version、currentPage這幾個，還有簽名sign、時間戳time，其實可以分為兩類：系統(tǒng)參數(shù)和業(yè)務參數(shù)。像appKey、version、sign、time這些屬于系統(tǒng)參數(shù)，而currentPage，或username之類的則屬于業(yè)務參數(shù)。數(shù)據(jù)層

13、開放的數(shù)據(jù)接口的參數(shù)只需要包含業(yè)務參數(shù)就可以了，業(yè)務層并不需要關心系統(tǒng)參數(shù)是什么，系統(tǒng)參數(shù)在數(shù)據(jù)層部封裝API時指定就可以了。業(yè)務層業(yè)務層是數(shù)據(jù)加工者，主要就是從數(shù)據(jù)層獲取數(shù)據(jù)，然后經過業(yè)務邏輯處理后轉化成展示層需要的數(shù)據(jù)。業(yè)務層因為夾在數(shù)據(jù)層和展示層中間，起著承上啟下的作用。也因此，業(yè)務層很容易淪落為只是一個數(shù)據(jù)的中轉站，主要就是因為對業(yè)務層具體的作用和職責沒有理解清楚。這里用一個例子來說明業(yè)務層具體的工作吧，就舉個用戶注冊的例子。用戶注冊時，界面上需要用戶提供手機號、短信驗證碼、密碼、確認密碼。則，最簡單的操作就是，帶上這些參數(shù)調用數(shù)據(jù)層的注冊接口。好了，問題來了，注冊接口并沒有提供確認密

14、碼的參數(shù)。那好，調用注冊接口之前先判斷下密碼和確認密碼是否一致，不一致則返回錯誤提示給用戶，一致了才調用注冊接口。好了，第二個問題來了，用戶等網絡請求等了一段時間后，請求結果返回說手機號少了一位。下一次，又等了一段時間，這次又返回說手機號多了一位。就因為一個小錯誤要讓用戶等則久，用戶肯定有意見。后臺也有意見，各種非法的請求都發(fā)過來，是嫌效勞器壓力不夠大啊。那好，調用接口之前對這些參數(shù)做有效性檢查吧，手機號要規(guī)，短信驗證碼只能為六位數(shù)字，密碼不能少于六位。終于注冊成功了，第三個問題又來了，注冊接口是沒有返回用戶的accessToken的，只有登錄接口才會返回。讓用戶手動再登錄一下.這用戶體驗不太

15、好啊。正確的姿勢應該是注冊成功后再自動調用一次登錄接口，如果因為網絡問題第一次登錄失敗，后面還需要再自動調用多一次，如果還是調用失敗，才讓用戶手動登錄。上面的例子中，對參數(shù)的有效性檢查，注冊成功后的自動登錄，都屬于業(yè)務邏輯的處理，也就是說都是業(yè)務層的工作。業(yè)務層交付給展示層的數(shù)據(jù)也是通過接口的方式，不過，和數(shù)據(jù)層交付給業(yè)務層時不同的是：交付給展示層的數(shù)據(jù)應該是通過異步回調返回的。因為獲取數(shù)據(jù)是一個比擬耗時的任務，通過異步回調才不會阻塞UI主線程。展示層展示層作為數(shù)據(jù)展示者，它只要關心數(shù)據(jù)如何展示就可以了。不過，數(shù)據(jù)如何展示卻不是則簡單。展示層是三層架構中最復雜的一層了，要考慮的東西遠遠多于其他

16、兩層，涉及的東西包括但不限于界面布局、屏幕適配、圖片資源、文本資源、顏色資源等等。在開發(fā)一段時間后，展示層出現(xiàn)代碼混亂是最常見的。因此，做好展示層，就需要保持高質量的代碼。要保持高質量代碼，我覺得至少應該遵循幾條根本的原則： 保持規(guī)性：定義好開發(fā)規(guī)，包括書寫規(guī)、命名規(guī)、注釋規(guī)等，并按照規(guī)嚴格執(zhí)行； 保持單一性：布局就只做布局，容就只做容，各自別離好，每個方法、每個類，也只做一件事情； 保持簡潔性：保持代碼和構造的簡潔，每個方法，每個類，每個包，每個文件，都不要塞太多代碼或資源，感覺多了就應該拆分。所謂無規(guī)矩不成方圓，展示層的設計，要從開發(fā)規(guī)開場。一份好的開發(fā)規(guī)，是保證代碼有較高的可讀性的根底。

17、iOS方面，蘋果已經有一套Coding Guidelines，主要屬于命名方面的規(guī)。當我們制定自己的開發(fā)規(guī)時，首先就要遵守蘋果的這份規(guī)，在此根底上再加上自己的規(guī)。Android方面，我也在我的博客中分享過一套Android技術積累:開發(fā)規(guī)，主要分為書寫規(guī)、命名規(guī)、注釋規(guī)三局部。最重要的不是開發(fā)規(guī)的制定，而是開發(fā)規(guī)的執(zhí)行。如果沒有按照開發(fā)規(guī)去執(zhí)行，那開發(fā)規(guī)就等于形同虛設，那代碼混亂的問題依然得不到解決。說到單一性，面向對象設計中，有一個根本原則就是單一職責原則，它規(guī)定一個類應該只有一個發(fā)生變化的原因。保持單一性是減低耦合度的關鍵標準，其目的就是各方面的解耦。而我這里說的單一性不只是規(guī)定類的單一，

18、也包括界面的單一、方法的單一、資源文件的單一等。界面的單一，首先是界面的布局和界面的數(shù)據(jù)應該別離。另外，界面數(shù)據(jù)的獲取和展示也應該別離。一句話，保持界面的單一性就是要保持界面上每個維度都做好別離，從界面的布局，到數(shù)據(jù)的獲取，數(shù)據(jù)的檢查，數(shù)據(jù)的展示。方法的單一，則表現(xiàn)為一個方法是對一個行為的封裝。行為又可以拆分為多個步驟，每個步驟其實也是更細化的行為。因此，方法嵌套方法是一種常態(tài)。則，保持方法的單一性，關鍵不在于怎么定義這個方法的行為，而在于這個行為要怎么拆分成更細的行為。舉個例子，通常在Activity的onCreate方法，做初始化操作，細分出來就分為了：控件的初始化、邏輯變量的初始化、數(shù)據(jù)

19、的初始化。數(shù)據(jù)的初始化又可以再細分：數(shù)據(jù)的獲取、數(shù)據(jù)的展示。每個細化的行為都應該封裝為一個獨立的方法，這樣，才真正符合方法的單一性。資源文件的單一，主要是指Android的各類資源文件，包括存放字符串的strings.*ml，存放字符串數(shù)組的arrays.*ml，存放顏色值的colors.*ml，存放尺寸值的dimens.*ml，等等。資源文件的單一，是說所有相關的資源信息要在資源文件里定義并引用到代碼或布局文件里，而不是在代碼或布局文件里直接定義。這樣做，可以很方便地做各種適配和修改，比方支持國際化，比方不同分辨率的屏幕用不同尺寸值。iOS則沒有提供和Android一樣的資源文件別離的機制，

20、但可以參考Android的做法自己去實現(xiàn)。環(huán)境別離每個App工程，至少都會有兩個環(huán)境：測試環(huán)境和生產環(huán)境。多的甚至有四個環(huán)境：開發(fā)環(huán)境、測試環(huán)境、預生產環(huán)境和生產環(huán)境。開發(fā)人員經常需要在環(huán)境之間切換，測試人員也同樣。經常出現(xiàn)測試人員今天需要測試環(huán)境的最新版本，叫App開發(fā)人員打包一個給她，明天需要切換到生產版本，再叫App開發(fā)人員打包一個生產環(huán)境的給她。我們知道，一個App，在一臺手機上要么只能是測試環(huán)境的，要么只能是生產環(huán)境的。測試人員要測試兩個環(huán)境，只能不斷替換不同環(huán)境的同個App，這實在太麻煩了。為了解決此問題，最好的方案就是環(huán)境別離，不同環(huán)境有不同的App。一個App的唯一標識，Android是用包名，iOS是用Bundle Identify。則，在一個系統(tǒng)想安裝不同環(huán)境的App，只要每個環(huán)境App的包名和Bundle Identify不同即可。比方，生產版的包名和Bundle Identify命名為.mydomain.myapp，測試版的包名和Bundle Identify則命名為，這樣，Android和iOS都會識別為兩個不同的App了。不過，只改包名和Bundle Identify是不夠的，應用圖標和應用名稱也要修改，不然安裝之后很難區(qū)分哪個App是哪個環(huán)境的。一般做法就是，非生產環(huán)境的App圖標就是在生產圖標的根底上添加一個環(huán)