App架構-OC

1.制定安全機制

一個App，最核心的就是數據，而數據的主要來源就是API。

①保證API的調用者是通過本身受權的App

設計簽名：對每一個客戶端，Android、iOS、WeChat，分 別分配一個AppKey和AppSecret。須要調⽤用API時，將AppKey加⼊請求參數列表，並將AppSecret 和全部參數一塊兒，根據某種簽名算法生成一個簽名字符串，而後調用API時把該簽名字符串也一塊兒帶上。服務端接收到這個請求時驗證AppKey和AppSecret和簽名字符串是否一致, 若一致則請求是安全的.每一個端都有一個Key，也⽅便不一樣端的標識和統計。爲了防止AppSecret被別人獲取，這個AppSecret通常寫死在代碼⾥面。另外，簽名算法也須要有必定的複雜度，不能輕易被別人破解，最好是採⽤本身規定的一套簽名算法，⽽而不是採用外部公開的簽名算法。另外，在參數列列表中再加⼊一個時間戳，還能夠防止部分重放攻擊 。

②保證數據傳輸的安全

採用HTTPS, HTTPS由於添加了SSL安全協議，自動對請求數據進行了壓縮加密，在必定程度上能夠防止監聽、劫持、防止重發，主要就是防止中間人攻擊。
爲了安全考慮，建議對SSL證書進行校驗，包括簽名CA是否合法，域名是否匹配、是否是自簽名證書、證書是否過時等。

2.接口協議標準化

每一個技術團隊通常都會有一份接口協議文檔，包括對對每一個接口的描述、入參、輸出結果等。但通常並不嚴謹，不少地方沒有贊成標準，從而容易出現不少坑。有一份標準且嚴格執行的接口協議很是重要。協議的內容除了規定每一個接口中每一個數據具體的數據類型，還須要規定一套共用的數據字典，以及其餘須要統必定義的信息，好比簽名算法等。

3.接口版本控制

接口變更會致使舊版本App出錯，並且變更不必定是修改了接口自己，有多是增長了一種新的數據結構，客戶端舊版本解析不了，從而就致使出錯。
爲了解決接口的兼容性問題，須要作好接口版本控制。實現：
1.每一個接口有各自的版本，通常爲接口添加個version參數
2.整個接口系統有統一的版本，通常在URL中添加版本號，好比http://api.domain.com/v2
平時小版本更新，就採用第一種方式, 根據不一樣版本號作不一樣分支的處理；大版本採用第二種。(跟舊版本相對獨立)
太舊的版本提醒用戶強制升級或者普通升級。

4.架構分層(高內聚、低耦合)

數據管理、數據加工、數據展現，三層架構：數據層、業務層、展現層

• 數據層是最底層，往下，接入API ；往上，向業務層交付數據;
• 業務層處於中間層，數據的加工，將數據層提供上來的數據加工成展現層須要展現的數據。
• 展現層處於最上層，主要將業務層取得的數據展現到界面上。

數據層：(數據管理者，封裝API，並將數據交付給上層，中間會再加個數據緩存)

1>業務層向數據層請求數據;
2>數據層檢查緩存中有沒有請求須要的數據;
3>若是有緩存直接返回緩存數據;
4>若是沒有緩存，則從網絡API獲取數據，並將數據加入緩存，而後返回數據。
調用API 時，還要判斷網絡狀態，根據不一樣狀態作不一樣處理。若是網絡不可用，就無需發起請求。無網絡可用時，也要區分是WIFI仍是移動網絡。鏈接移動網絡時，通常要限制比較耗流量的請求。
獲取分頁數據時, 能夠將下一頁的數據預先請求、
緩存策略：對於獲取數據的接口設置緩存。
數據層與外部交互：提供對外開放的數據接口。參數分爲兩類：系統參數和業務參數，像appKey、version、sign、time這些屬於系統參數，而currentPage,或usderName的類則屬於業務參數。
數據層開發的接口參數只須要包含業務參數就能夠了，業務層並不須要關心繫統參數是什麼，系統參數在內部封裝API時就已經指定了。

業務層：(數據加工者)

從數據層獲取數據，而後通過業務邏輯處理後轉化成展現層須要的數據。（參數的有效性檢查，註冊成功後自動登陸）
業務層交付給展現層的數據也是經過接口的方式，不一樣於數據層交付給業務層的是，給展現層的數據應該是經過異步回調返回的。由於獲取數據是一個比較耗時的任務，經過異步回調纔不會阻塞UI主線程。

展現層：(數據展現者)

關心數據如何展現：
界面佈局、屏幕適配、圖片資源、文本資源、顏色資源等等、
保持高質量代碼：
1>保持規範性：定義好開發規範，包括書寫規範、命名規範、註釋規範等，並按照規範嚴格執行;
2>保持單一性：佈局就只作佈局，內容就是隻作內容，各自分離好，每一個方法、每一個類，也只作一件事情；(保持單一性是減低耦合度的關鍵標準，界面的單一就是要保持界面上每一個維度作好分離，從界面佈局到數據獲取，數據檢查，數據展現)。
3>保持簡潔性：保持代碼和結構的簡潔，每一個方法，每一個類，每一個包，每一個文件，都不要塞太多代碼或資源，感受多了就應該拆分。
代碼混亂的問題必須嚴格執行開發規範。

• 環境分離：不一樣環境有不一樣的App。iOS能夠經過建立多個環境的Target來實現環境分離，不一樣target能夠設置不一樣的Bundle Identify , Bundle display name ， 更換圖標。每一個Target也各自有本身的一份Plist文件，環境變量和第三方設置之類的，均可以設置在相應的plist文件裏。
  模塊之間不要存在相互調用的關係，以framework的形式存在。高內聚，高複用。

MVC

MVC 架構問題：
繁重的UI ，囉嗦業務邏輯，難受的用戶代理,很長的網絡層,內部方法，

• VC代碼過於繁重
• 代碼耦合性太高 （View和控制器耦合性強）

解決辦法：

• 代碼繁重(代碼封裝、抽取:誰的事情，誰幹)
• 耦合性高(解耦 eg:cell,setModel)
• VC的任務是要創建依賴關係(依賴綁定)

MVP

面向協議，View和Model徹底解耦，Controller層不顯示網絡請求數據的過程,只要遵循協議就能拿到數據
V層UI改變，通知P層，P層更新數據通知M層，M層拿到新數據通知P層，P層通知V層UI改變。
MVP 優缺點：
①模型與視圖徹底分離，咱們能夠修改視圖而不影響模型
②能夠更高效的使用模型，由於全部的交互都發生在一個地方，Presenter內部
③咱們能夠將一個Presenter用於多個視圖，而不須要改變Presenter的邏輯。這個特性很是的有用，由於視圖的變化老是比模型的變化頻繁。
④若是咱們把邏輯放在Presenter中，那麼咱們就能夠脫離用戶接口來測試這些邏輯（單元測試）

MVVM

KVO雙向綁定
ViewModel做爲樞紐，溝通View和Model之間的關係。

- (void)setWithViewModel:(MVVMViewModel *)vm {
    self.vm = vm;
    //KVO
    [self.vm addObserver:self forKeyPath:@"nameStr" options:NSKeyValueObservingOptionOld|NSKeyValueObservingOptionNew context:nil];
    self.label.text = vm.nameStr;
}

-(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:    (NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context{
    if ([keyPath isEqualToString:@"nameStr"]&&[change objectForKey:NSKeyValueChangeNewKey]) {
        NSNumber *new = [change objectForKey:NSKeyValueChangeNewKey];
        self.label.text = [NSString stringWithFormat:@"%@",new];
    }
}

-(void)mvvmClickChangModel{
    [self.vm clickChangeName];
}

//MVVMModel
#import "MVVMViewModel.h"

@implementation MVVMViewModel
-(void)setWithModel:(MVVMModel *)model{
    self.model = model;
    self.nameStr = model.name;
}
-(void)clickChangeName{
    self.model.name = [NSString stringWithFormat:@"name%d",arc4random()%10];
    self.nameStr = self.model.name;
    NSLog(@"%@",self.nameStr);
}
@end

架構模式選擇

• 面向需求編程，以需求驅動編程