iOS 脈絡圖總結匯總 連續更新

語言: objective-c/swift

1.動態性:

1、動態型別<弱型別>（id）：在程式碼的執行階段判斷程式碼的型別，使用id型別可以讓應用在“執行時”使用任何型別來替換。動態型別讓程式更加靈活，但是會使資料的統一性降低和程式碼的可讀性。我們常用靜態型別<強型別>（如NSString）,使用靜態型別編譯器可以完全分析你的程式碼，這讓程式碼的效能和可預知性更高。

2、動態繫結：讓程式碼在執行時判斷需要呼叫什麼方法，而不是在編譯時。動態型別和動態繫結使得選擇哪個接收者已經呼叫什麼方法都放到執行時去完成.

3、動態載入：應用程式可以根據需要載入可執行程式碼以及資源，而不是在啟動時就載入所有資源。

4、SEL型別iOS在編譯的時候會根據方法的名字（包括引數序列），生成一個用來區分這個方法的唯一的ID，這個ID是SEL型別的，SEL的本質就是類方法的編號[函式地址]。（類似C語言裡面的函式指標，但是OC的類不能直接使用函式指標，這樣只能做一個@selector語法來取。注意：@selector是查詢當前類（含子類）的方法。）

2.框架

2.1 MVC、MVCS、MVVM、MVP

MVC ：Model 、View、 Controller

Controller 響應使用者互動 去請求新資料 更新Model 更新Model後再重新整理View，
View上的互動會響應在Controller上
特點：大部分的請求邏輯，資料處理邏輯會放在Controller裡； Model只是接受資料、簡單的資料處理，不進行資料的批次處理；View接受使用者互動行為、傳遞互動，重新整理資料

MVVM：View、ViewModel、Model

別名View、Model繫結（model-view-binder 模式）優點有限，使的Model和View解耦，但是MVVM的上手難度並不低，我感覺主要是RAC（並不是MVVM模式必有的），導致了此模式的上手和維護難度就提升了，有利有弊，此模式提出已經好久還沒有大範圍得到應用，也側面說明了此模式的弊端
雖然MVVM很難上手和維護，但是RAC並不是必須的，這樣就演化出MVVM的簡化版本，借鑑其優點，基於MVC，再生成ViewModel（非雙向繫結的類）來剝離Controller裡複雜的處理邏輯、請求邏輯等，實現解耦、複用等最佳化，舉個例子：每個控制器對應的都有網路請求，然後返回資料，先處理有用資料，再去重新整理View，這個過程再怎麼簡單也不會小，就可以建立個ViewModel類，專門負責請求資料、生成Model，暴露重新整理介面，和要請求的介面，這也算MVVM，也是很多公司在想降低實現和維護難度的目的下產生的。
我在最近的Swift專案中使用了大神的Tempure框架，單向資料流，C-State V-ViewModel Action APPSate C觸發Action更改APPState，也就觸發了ViewModel的變化 ViewModel和View繫結，也會重新整理View，模仿了RN的資料重新整理流程，但是模仿的並不完全，ViewModel的變化觸發的View重新整理，只是會觸發View的方法func update(oldModel: HomeViewModel?),裡面具體的重新整理還是要呼叫 例如reloadData等，這個只是介紹一下Swift的類似模式，總結來說沒有那個好，因為並不能嚴格意義上實現單向資料流，所以也沒達到嚴格意義上的解耦，所以這個模式既然不能完全解決問題，那也沒有推薦使用的意義

MVCS：Model、View、Controller、Services

這個模式也是蘋果官方正在使用的設計模式，提供Service為資料處理提供服務，這個主要是分擔的Model方的任務，不在詳述。

MVP：Model、View、Presenter 角色有：Model、Controller（控制器裡的View，稱作CView）、View、Presenter、Protocal、NetServices，其中Model僅僅是接收資料，Protocal提供可選擇實現的方法宣告；NetServices提供網路層的邏輯，返回資料；Presenter用來分擔Controller的相關邏輯，會在Controller裡初始化的時候賦值Controller的View給Presenter的屬性attachView（weak修飾，避免迴圈引用，面向協議程式設計中遵守協議的類），這裡就體現了面向協議程式設計的優勢來了，協議只宣告方法，具體做什麼怎麼做讓遵守協議的類（Controller的View）自己決定，而呼叫這些方法的邏輯卻在Presenter裡，這就分擔了Controller的負擔。舉例說明，控制器裡除了生命週期，有網路請求資料方法，請求的資料返回後重新整理View，期間還有Loading展示，結束有有資料、無資料兩種情況，協議宣告顯示Loading、隱藏Loading、請求返回、無資料佔位方法；在Controller裡選擇實現協議裡的方法，然後在Presenter裡合適的邏輯呼叫實現的方法
主要是拆分Controller裡的邏輯程式碼

總結：萬變不離其宗，都是從MVC模式演化來的，這個演化都是有目的有針對的，看看分出來的新角色負擔什麼新任務，例如MVVM = MVC + ViewModel；MVCS = MVC + Service；MVP = MVC + Presenter

**
**
待續，如有誤，請留言指正！！！感激不盡