基於 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，原因如下
- 使用派生比不使用派生更容易增加業務方的使用成本
- 不使用派生手段一樣也能達到統一設定的目的 對於第一點，從 整合成本 ，上手成本 ，架構維護成本等因素入手，大神部落格中也已經很詳細。
框架不需要通過繼承即能夠對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一些總結：
- View <-> C <-> ViewModel <-> Model 實際上應該稱之為MVCVM
- Controller 將不再直接和 Model 進行繫結，而通過橋樑ViewModel
- 最終 Controller 的作用變成一些UI的處理邏輯，和進行View和ViewModel的繫結
- MVVM 和 MVC 相容
- 由於多了一層 ViewModel, 會需要寫一些膠水程式碼，所以程式碼量會增加
3.網路層使用 YTKNetwork 配合 ReactiveCocoa 封裝網路請求，解決如何交付資料，交付什麼樣的資料（去Model化)等問題
YTKNetwork 是猿題庫 iOS 研發團隊基於 AFNetworking 封裝的 iOS 網路庫，其實現了一套 High Level 的 API，提供了更高層次的網路訪問抽象。
筆者對 YTKNetwork 進行了一些封裝，結合 ReactiveCocoa，並提供 reFormatter 介面對伺服器響應資料重新處理，靈活交付給業務層。 接下來，本文會回答兩個問題
- 以什麼方式將資料交付給業務層？
- 交付什麼樣的資料 ? 對於第一個問題
以什麼方式將資料交付給業務層？
雖然 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應用架構談 網路層設計方案 中給出了兩種有意思的交付思路
- 使用 reformer 對資料進行清洗
- 去特定物件表徵 （去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形式交付資料，對於網路層而言，只需要保持住原始資料即可，不需要主動轉化成資料原型 但是會存在一些小問題
- 去Model如何保持可讀性？
- 複雜和多樣的資料結構如何解析？
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)
複製程式碼好了，至此我們解決了兩個問題
- 以什麼方式將資料交付給業務層 答：delegate 最佳，block為次
- 交付什麼樣的資料 答：純字典，去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 針對 蘑菇街元件化 提出了質疑，質疑點主要在這幾方面
- App啟動時元件需要註冊URL
- URL呼叫元件方式不太好傳遞類似 UIImage 等非常規物件
- 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¶m2=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