走在技術前沿的 iOS 架構實現 ?

基於 Objective-C 實現的框架設計，YTKNetwork網路層 + AOP替代基類 + MVVM + ReactiveObjC + JLRoutes路由

我理解的框架，就好比計算機的主機板，房屋的建築骨架，道路的基礎設施配套，框架搭的好，能直接影響開發者的開發心情，更能讓專案健壯性和擴充套件性大大增強。

---

? 要求

• iOS 8.0+
• Xcode 8.0+
• Objective-C

---

? 測試 UI 什麼樣子？

1.展示頁	2.展示頁	3.展示頁	4.說明頁
登入檢視	示例展示	跳轉頁面	介紹頁面

---

? 安裝方法

安裝

在 iOS, 你需要在 Podfile 中新增.

source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '9.0'
use_frameworks!

  # 提示元件框架
  pod 'SVProgressHUD', '~> 2.2.2'
  # 網路請求框架
  pod 'YTKNetwork', '~> 2.0.3'
  # AOP面向切面
  pod 'Aspects', '~> 1.4.1'
  # 響應函式式框架
  pod 'ReactiveObjC', '~> 3.0.0'
  # 路由元件化解耦
  pod 'JLRoutes', '~> 2.0.5'
  # 提示元件框架
  pod 'SVProgressHUD', '~> 2.2.2'
  # 自動佈局
  pod 'Masonry', '~> 1.0.2'
複製程式碼

---

? 框架介紹

1.AOP 模式（Aspects-RunTime 代替基類）+ Category 方法交換

採用AOP思想，使用 Aspects 來完成替換 Controller ，View，ViewModel基類，和基類說拜拜

Casa反革命工程師 iOS應用架構談 view層的組織和呼叫方案 部落格中提到一個疑問 是否有必要讓業務方統一派生ViewController

Casa大神回答是NO，原因如下

1. 使用派生比不使用派生更容易增加業務方的使用成本
2. 不使用派生手段一樣也能達到統一設定的目的 對於第一點，從 整合成本 ，上手成本 ，架構維護成本等因素入手，大神部落格中也已經很詳細。

框架不需要通過繼承即能夠對ViewController進行統一配置。業務即使脫離環境，也能夠跑完程式碼，ViewController一旦放入框架環境，不需要新增額外的或者只需新增少量程式碼，框架也能夠起到相應的作用 對於本人來說 ，具備這點的吸引力，已經足夠讓我有嘗試一番的心思了。

對於OC來說，方法攔截很容易就想到自帶的黑魔法方法調配 Method Swizzling， 至於為ViewController做動態配置，自然非Category莫屬了 Method Swizzling 業界已經有非常成熟的三方庫 Aspects, 所以Demo程式碼採用 Aspects 做方法攔截。

+ (void)load {
    [super load];
    [FKViewControllerIntercepter sharedInstance];
}
// .... 單例初始化程式碼

- (instancetype)init {
    self = [super init];
    if (self) {
        /* 方法攔截 */
        // 攔截 viewDidLoad 方法
        [UIViewController aspect_hookSelector:@selector(viewDidLoad) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo>aspectInfo){
            [self _viewDidLoad:aspectInfo.instance];
        }  error:nil];
        
        // 攔截 viewWillAppear:
        [UIViewController aspect_hookSelector:@selector(viewWillAppear:) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo, BOOL animated){
            [self _viewWillAppear:animated controller:aspectInfo.instance];
        } error:NULL];
    }
    return self;
}
複製程式碼

至於 Category 已經非常熟悉了

@interface UIViewController (NonBase)

/**
 去Model&&表徵化引數列表
 */
@property (nonatomic, strong) NSDictionary *params;

/**
 ViewModel 屬性
 */
@property (nonatomic, strong) id <FKViewControllerProtocol> viewModel;

#pragma mark - 通用類

/**
 返回Controller的當前bounds
 
 @param hasNav 是否有導航欄
 @param hasTabBar 是否有tabbar
 @return 座標
 */
- (CGRect)fk_visibleBoundsShowNav:(BOOL)hasNav showTabBar:(BOOL)hasTabBar;

/**
 隱藏鍵盤
 */
- (void)fk_hideKeyBoard;
@end
複製程式碼

至此，我們已經實現了不繼承基類來實現對ViewController的配置，專案中的 View ViewModel 去基類原理如出一轍。

2.View層採用 MVVM 設計模式，使用 ReactiveObjC 進行資料繫結

-MVC-

作為老牌思想MVC，大家早已耳熟能詳，MVC素有 Massive VC之稱，隨著業務增加，Controller將會越來越複雜，最終Controller會變成一個"神類", 即有網路請求等程式碼，又充斥著大量業務邏輯，所以為Controller減負，在某些情況下變得勢在必行

-MVVM-

MVVM是基於胖Model的架構思路建立的，然後在胖Model中拆出兩部分：Model和ViewModel (注：胖Model 是指包含了一些弱業務邏輯的Model) 胖Model實際上是為了減負 Controller 而存在的，而 MVVM 是為了拆分胖Model , 最終目的都是為了減負Controller。

我們知道，蘋果MVC並沒有專門為網路層程式碼分專門的層級，按照以往習慣，大家都寫在了Controller 中，這也是Controller 變Massive得元凶之一，現在我們可以將網路請求等諸如此類的程式碼放到ViewModel中了 （文章後半部分將會描述ViewModel中的網路請求）

-資料流向-

正常的網路請求獲取資料，然後更新View自然不必多說，那麼如果View產生了資料要怎麼把資料給到Model，由於View不直接持有ViewModel，所以我們需要有個橋樑 ReactiveCocoa, 通過 Signal 來和 ViewModel 通訊，這個過程我們使用 通知 或者 Target-Action也可以實現相同的效果，只不過沒有 ReactiveCocoa 如此方便罷了

/*  View -> ViewModel 傳遞資料示例   */
#pragma mark - Bind ViewModel
- (void)bindViewModel:(id<FKViewModelProtocol>)viewModel withParams:(NSDictionary *)params {
    if ([viewModel isKindOfClass:[FKLoginViewModel class]]){
        
        FKLoginViewModel *_viewModel = (FKLoginViewModel *)viewModel;
        // 繫結賬號 View -> ViewModel 傳遞資料 
        @weakify(self);
        RAC(_viewModel, userAccount) = [[self.inputTextFiled.rac_textSignal takeUntil:self.rac_prepareForReuseSignal] map:^id _Nullable(NSString * _Nullable account) {
            @strongify(self);
            // 限制賬號長度
            if (account.length > 25) {
                self.inputTextFiled.text = [account substringToIndex:25];
            }
            return self.inputTextFiled.text;
        }];
    }
}
複製程式碼

上面程式碼給出了 View -> ViewModel 繫結的一個例子 具體一些詳情，可以直接看Demo MVVM一些總結：

1. View <-> C <-> ViewModel <-> Model 實際上應該稱之為MVCVM
2. Controller 將不再直接和 Model 進行繫結，而通過橋樑ViewModel
3. 最終 Controller 的作用變成一些UI的處理邏輯，和進行View和ViewModel的繫結
4. MVVM 和 MVC 相容
5. 由於多了一層 ViewModel, 會需要寫一些膠水程式碼，所以程式碼量會增加

3.網路層使用 YTKNetwork 配合 ReactiveCocoa 封裝網路請求，解決如何交付資料，交付什麼樣的資料（去Model化)等問題

YTKNetwork 是猿題庫 iOS 研發團隊基於 AFNetworking 封裝的 iOS 網路庫，其實現了一套 High Level 的 API，提供了更高層次的網路訪問抽象。

筆者對 YTKNetwork 進行了一些封裝，結合 ReactiveCocoa，並提供 reFormatter 介面對伺服器響應資料重新處理，靈活交付給業務層。 接下來，本文會回答兩個問題

1. 以什麼方式將資料交付給業務層？
2. 交付什麼樣的資料 ? 對於第一個問題

以什麼方式將資料交付給業務層？

雖然 iOS應用架構談 網路層設計方案 中 Casa大神寫到 儘量不要用block，應該使用代理 的確，Block難以追蹤和定位錯誤，容易記憶體洩漏， YTKNetwork 也提供代理方式回撥

@protocol YTKRequestDelegate <NSObject>

@optional
///  Tell the delegate that the request has finished successfully.
///
///  @param request The corresponding request.
- (void)requestFinished:(__kindof YTKBaseRequest *)request;

///  Tell the delegate that the request has failed.
///
///  @param request The corresponding request.
- (void)requestFailed:(__kindof YTKBaseRequest *)request;

@end
複製程式碼

前文有說過，MVVM 並不等於 ReactiveCocoa , 但是想要體驗最純正的 ReactiveCocoa 還是Block較為酸爽，Demo中筆者兩者都給出了程式碼, 大家可以自行選擇和斟酌哈 我們看一下 YTKNetwork 和 ReactiveCocoa 結合的程式碼

- (RACSignal *)rac_requestSignal {
    [self stop];
    RACSignal *signal = [[RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber>  _Nonnull subscriber) {
        // 請求起飛
        [self startWithCompletionBlockWithSuccess:^(__kindof YTKBaseRequest * _Nonnull request) {
            // 成功回撥
            [subscriber sendNext:[request responseJSONObject]];
            [subscriber sendCompleted];
            
        } failure:^(__kindof YTKBaseRequest * _Nonnull request) {
            // 錯誤回撥
            [subscriber sendError:[request error]];
        }];
        
        return [RACDisposable disposableWithBlock:^{
            // Signal銷燬 停止請求
            [self stop];
        }];
    }] takeUntil:[self rac_willDeallocSignal]];
    
    //設定名稱 便於除錯
    if (DEBUG) {
        [signal setNameWithFormat:@"%@ -rac_xzwRequest",  RACDescription(self)];
    }
    
    return signal;
}
複製程式碼

寫了一個簡單的 Category FKBaseRequest+Rac.h ViewModel 中使用 RACCommand 封裝呼叫：

- (RACCommand *)loginCommand {
    if (!_loginCommand) {
        @weakify(self);
        _loginCommand = [[RACCommand alloc] initWithSignalBlock:^RACSignal * _Nonnull(id  _Nullable input) {
            @strongify(self);
      
            return [[[FKLoginRequest alloc] initWithUsr:self.userAccount pwd:self.password] rac_requestSignal];
        }];
    }
    return _loginCommand;
}
複製程式碼

Block方式交付業務

FKLoginRequest *loginRequest = [[FKLoginRequest alloc] initWithUsr:self.userAccount pwd:self.password];
return [[[loginRequest rac_requestSignal] doNext:^(id  _Nullable x) {
    
    // 解析資料
    [[NSUserDefaults standardUserDefaults] setObject:@(YES) forKey:@"isLogin"];
    
}] materialize];
複製程式碼

Delegate方式交付業務

FKLoginRequest *loginRequest = [[FKLoginRequest alloc] initWithUsr:self.userAccount pwd:self.password];
// 資料請求響應代理 通過代理回撥
loginRequest.delegate = self;
return [loginRequest rac_requestSignal];

#pragma mark - YTKRequestDelegate
- (void)requestFinished:(__kindof YTKBaseRequest *)request {
    // 解析資料
    [[NSUserDefaults standardUserDefaults] setObject:@(YES) forKey:@"isLogin"];
}
複製程式碼

交付什麼樣的資料 ?

現在諸如 JSONModel ，YYModel 之類的Json轉Model的庫也非常多，大多數Json物件，網路請求成功直接就被轉成Model了 然而 iOS應用架構談 網路層設計方案 中給出了兩種有意思的交付思路

1. 使用 reformer 對資料進行清洗
2. 去特定物件表徵 （去Model）

Casa文章中好處已經寫得很詳細了，通過不同的 reformer 來重塑和交付不同的業務資料，可以說是非常靈活了

使用 reformer 對資料進行清洗

在網路層封裝 FKBaseRequest.h 中 給出了 FKBaseRequestFeformDelegate 介面來重塑資料

@protocol FKBaseRequestFeformDelegate <NSObject>

/**
 自定義解析器解析響應引數

 @param request 當前請求
 @param jsonResponse 響應資料
 @return 自定reformat資料
 */
- (id)request:(FKBaseRequest *)request reformJSONResponse:(id)jsonResponse;

@end
然後在對應的 reformer 對資料進行重塑
#pragma mark - FKBaseRequestFeformDelegate
- (id)request:(FKBaseRequest *)request reformJSONResponse:(id)jsonResponse {
    if([request isKindOfClass:FKLoginRequest.class]){
        // 在這裡對json資料進行重新格式化
    }
    return jsonResponse;
}
複製程式碼

也可以直接在子類的 RequestManager 中覆蓋父類方法達到一樣的效果

/* FKLoginRequest.m */

// 可以在這裡對response 資料進行重新格式化， 也可以使用delegate 設定 reformattor
- (id)reformJSONResponse:(id)jsonResponse {
}
複製程式碼

去特定物件表徵 （去Model）

這思路可以說是業界的泥石流了 去Model也就是說，使用NSDictionary形式交付資料，對於網路層而言，只需要保持住原始資料即可，不需要主動轉化成資料原型 但是會存在一些小問題

1. 去Model如何保持可讀性？
2. 複雜和多樣的資料結構如何解析？

Casa大神 提出了 使用EXTERN + Const 字串形式，並建議字串跟著reformer走，個人覺得很多時候API只需要一種解析格式，所以Demo跟著 APIManager 走，其他情況下常量字串建議聽從 Casa大神 的建議， 常量定義：

/* FKBaseRequest.h */
// 登入token key
FOUNDATION_EXTERN NSString *FKLoginAccessTokenKey;

/* FKBaseRequest.m */
NSString *FKLoginAccessTokenKey = @"accessToken";
複製程式碼

在 .h 和 .m 檔案中要同時寫太多程式碼，我們也可以使用區域性常量的形式，只要在 .h 檔案中定義即可

// 也可以寫成 區域性常量形式
static const NSString *FKLoginAccessTokenKey2 = @"accessToken";
最終那麼我們的reformer可能會變成這樣子
- (id)request:(FKBaseRequest *)request reformJSONResponse:(id)jsonResponse {
    if([request isKindOfClass:FKLoginRequest.class]){
        // 在這裡對json資料進行重新格式化
        
        return @{
                 FKLoginAccessTokenKey : jsonResponse[@"token"],
                 };
    }
    return jsonResponse;
}
複製程式碼

複雜和多樣的資料結構如何解析？ 有時候，reformer 交付過來的資料，我們需要解析的可能是字串型別，也可能是NSNumber型別，也有可能是陣列 為此，筆者提供了一系列 Encode Decode方法，來降低解析的複雜度和安全性

#pragma mark - Encode Decode 方法
// NSDictionary -> NSString
FK_EXTERN NSString* DecodeObjectFromDic(NSDictionary *dic, NSString *key);
// NSArray + index -> id
FK_EXTERN id        DecodeSafeObjectAtIndex(NSArray *arr, NSInteger index);
// NSDictionary -> NSString
FK_EXTERN NSString     * DecodeStringFromDic(NSDictionary *dic, NSString *key);
// NSDictionary -> NSString ？ NSString ： defaultStr
FK_EXTERN NSString* DecodeDefaultStrFromDic(NSDictionary *dic, NSString *key,NSString * defaultStr);
// NSDictionary -> NSNumber
FK_EXTERN NSNumber     * DecodeNumberFromDic(NSDictionary *dic, NSString *key);
// NSDictionary -> NSDictionary
FK_EXTERN NSDictionary *DecodeDicFromDic(NSDictionary *dic, NSString *key);
// NSDictionary -> NSArray
FK_EXTERN NSArray      *DecodeArrayFromDic(NSDictionary *dic, NSString *key);
FK_EXTERN NSArray      *DecodeArrayFromDicUsingParseBlock(NSDictionary *dic, NSString *key, id(^parseBlock)(NSDictionary *innerDic));

#pragma mark - Encode Decode 方法
// (nonull Key: nonull NSString) -> NSMutableDictionary
FK_EXTERN void EncodeUnEmptyStrObjctToDic(NSMutableDictionary *dic,NSString *object, NSString *key);
// nonull objec -> NSMutableArray
FK_EXTERN void EncodeUnEmptyObjctToArray(NSMutableArray *arr,id object);
// (nonull (Key ? key : defaultStr) : nonull Value) -> NSMutableDictionary
FK_EXTERN void EncodeDefaultStrObjctToDic(NSMutableDictionary *dic,NSString *object, NSString *key,NSString * defaultStr);
// (nonull Key: nonull object) -> NSMutableDictionary
FK_EXTERN void EncodeUnEmptyObjctToDic(NSMutableDictionary *dic,NSObject *object, NSString *key);
複製程式碼

我們的reformer可以寫成這樣子

#pragma mark - FKBaseRequestFeformDelegate
- (id)request:(FKBaseRequest *)request reformJSONResponse:(id)jsonResponse {
    if([request isKindOfClass:FKLoginRequest.class]){
        // 在這裡對json資料進行重新格式化
        
        return @{
                 FKLoginAccessTokenKey : DecodeStringFromDic(jsonResponse, @"token")
                 };
    }
    return jsonResponse;
}
複製程式碼

解析有可能是這樣子

NSString *token = DecodeStringFromDic(jsonResponse, FKLoginAccessTokenKey)
複製程式碼

好了，至此我們解決了兩個問題

1. 以什麼方式將資料交付給業務層 答：delegate 最佳，block為次
2. 交付什麼樣的資料 答：純字典，去Model

4.採用 JLRoutes 路由對應用進行元件化解耦

帶著問題思考如何才能設計出最好的元件化路由：

• 1）3D-Touch功能或者點選推送訊息，要求外部跳轉到App內部一個很深層次的一個介面。
• 2）自家的一系列App之間如何相互跳轉？
• 3）如何解除App元件之間和App頁面之間的耦合性？
• 4）如何能統一iOS和Android兩端的頁面跳轉邏輯？甚至如何能統一三端的請求資源的方式？
• 5）如果使用了動態下發配置檔案來配置App的跳轉邏輯，那麼如果做到iOS和Android兩邊只要共用一套配置檔案？
• 6）如果App出現bug了，如何不用JSPatch，就能做到簡單的熱修復功能？
• 7）如何在每個元件間呼叫和頁面跳轉時都進行埋點統計？每個跳轉的地方都手寫程式碼埋點？利用Runtime AOP ？
• 8）如何在每個元件間呼叫的過程中，加入呼叫的邏輯檢查，令牌機制，配合灰度進行風控邏輯？
• 9）如何在App任何介面都可以呼叫同一個介面或者同一個元件？只能在AppDelegate裡面註冊單例來實現？

iOS應用架構談 元件化方案 一文中 Casa 針對 蘑菇街元件化 提出了質疑，質疑點主要在這幾方面

1. App啟動時元件需要註冊URL
2. URL呼叫元件方式不太好傳遞類似 UIImage 等非常規物件
3. URL需要新增額外引數可讀性差，所以沒必要使用URL

對於 App啟動時元件需要註冊URL 顧慮主要在於，註冊的URL需要在應用生存週期內常駐記憶體，如果是註冊Class還好些，如果註冊的是例項，消耗的記憶體就非常可觀了

#pragma mark - 路由表
NSString *const FKNavPushRoute = @"/com_madao_navPush/:viewController";
NSString *const FKNavPresentRoute = @"/com_madao_navPresent/:viewController";
NSString *const FKNavStoryBoardPushRoute = @"/com_madao_navStoryboardPush/:viewController";
NSString *const FKComponentsCallBackRoute = @"/com_madao_callBack/*";
複製程式碼

而且JLRoutes 還支援 * 來進行通配，路由表如何編寫大家可以自由發揮 對應的路由事件 handler

// push
// 路由 /com_madao_navPush/:viewController
[[JLRoutes globalRoutes] addRoute:FKNavPushRoute handler:^BOOL(NSDictionary<NSString *,id> * _Nonnull parameters) {
    dispatch_async(dispatch_get_main_queue(), ^{
        [self _handlerSceneWithPresent:NO parameters:parameters];
        
    });
    return YES;
}];

// present
// 路由 /com_madao_navPresent/:viewController
[[JLRoutes globalRoutes] addRoute:FKNavPresentRoute handler:^BOOL(NSDictionary<NSString *,id> * _Nonnull parameters) {
    dispatch_async(dispatch_get_main_queue(), ^{
        [self _handlerSceneWithPresent:YES parameters:parameters];
        
    });
    return YES;
}];

#pragma mark - Private
/// 處理跳轉事件
- (void)_handlerSceneWithPresent:(BOOL)isPresent parameters:(NSDictionary *)parameters {
    // 當前控制器
    NSString *controllerName = [parameters objectForKey:FKControllerNameRouteParam];
    UIViewController *currentVC = [self _currentViewController];
    UIViewController *toVC = [[NSClassFromString(controllerName) alloc] init];
    toVC.params = parameters;
    if (currentVC && currentVC.navigationController) {
        if (isPresent) {
            [currentVC.navigationController presentViewController:toVC animated:YES completion:nil];
        }else
        {
            [currentVC.navigationController pushViewController:toVC animated:YES];
        }
    }
}
複製程式碼

通過URL中傳入的元件名動態註冊，處理相應跳轉事件，並不需要每個元件一一註冊 使用URL路由，必然URL會散落到程式碼各個地方

NSString *key = @"key";
NSString *value = @"value";
NSString *url = [NSString stringWithFormat:@"/com_madao_navPush/%@?%@=%@", NSStringFromClass(ViewController.class), key, value];
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:url]];
複製程式碼

諸如此類醜陋的程式碼，散落在各個地方的話簡直會讓人頭皮發麻, 所以筆者在 JLRoutes+GenerateURL.h 寫了一些 Helper方法

/**
 避免 URL 散落各處， 集中生成URL
 
 @param pattern 匹配模式
 @param parameters 附帶引數
 @return URL字串
 */
+ (NSString *)fk_generateURLWithPattern:(NSString *)pattern parameters:(NSArray *)parameters;

/**
 避免 URL 散落各處， 集中生成URL
 額外引數將被 ?key=value&key2=value2 樣式給出
 
 @param pattern 匹配模式
 @param parameters 附加引數
 @param extraParameters 額外引數
 @return URL字串
 */
+ (NSString *)fk_generateURLWithPattern:(NSString *)pattern parameters:(NSArray *)parameters extraParameters:(NSDictionary *)extraParameters;

/**
 解析NSURL物件中的請求引數
http://madao?param1=value1¶m2=value2 解析成 @{param1:value1, param2:value2}
 @param URL NSURL物件
 @return URL字串
 */
+ (NSDictionary *)fk_parseParamsWithURL:(NSURL *)URL;

/**
 將引數物件進行url編碼
 將@{param1:value1, param2:value2} 轉換成 ?param1=value1&param2=value2
 @param dic 引數物件
 @return URL字串
 */
+ (NSString *)fk_mapDictionaryToURLQueryString:(NSDictionary *)dic;
複製程式碼

巨集定義Helper

#undef JLRGenRoute
#define JLRGenRoute(Schema, path) \
([NSString stringWithFormat: @"%@:/%@", \
Schema, \
path])

#undef JLRGenRouteURL
#define JLRGenRouteURL(Schema, path) \
([NSURL URLWithString: \
JLRGenRoute(Schema, path)])
複製程式碼

最終我們的呼叫可以變成

NSString *router = [JLRoutes fk_generateURLWithPattern:FKNavPushRoute parameters:@[NSStringFromClass(ViewController.class)] extraParameters:nil];
[[UIApplication sharedApplication] openURL:JLRGenRouteURL(FKDefaultRouteSchema, router)];
複製程式碼

---

? 整理製作

Casa Taloyum：https://casatwy.com/modulization_in_action.html

簡書部落格：http://www.jianshu.com/p/921dd65e79cb

---

? 聯絡

• 微信 : WhatsXie
• 郵件 : ReverseScale@iCloud.com
• 部落格 : https://reversescale.github.io
• 原始碼 : https://github.com/ReverseScale/OCTemplate