iOS架構實踐乾貨：AOP替代基類 + MVVM + ReactiveObjC + JLRoutes組件化
前言：最近公司應用架構重構，受到反革命工程師去基類，去Model等影響，將一些已經作的架構工做和思想稍微作一些總結，故此有了這篇文章，若有錯誤，漏洞，或者傻x之出，請包涵付之一笑，或請留言html
概覽：文章主要內容以下：ios
- 採用AOP思想，使用 Aspects 來完成替換 Controller ，View，ViewModel基類，和基類說拜拜
- View層採用 MVVM 設計模式，使用 ReactiveObjC 進行數據綁定
- 網絡層使用 YTKNetwork 配合 ReactiveCocoa 封裝網絡請求，解決如何交付數據，交付什麼樣的數據（去Model化)等問題
- 採用 JLRoutes 路由 對應用進行組件化解耦
Demo 代碼github地址 ：FxxkBaseClass-MVVM-ReactiveObjc 比較完整能夠直接拿來寫項目，若是以爲有用的話請點個star 感激涕零git
1、採用AOP思想，使用 Aspects 來完成替換 Controller ，View，ViewModel基類，和基類說拜拜
Casa反革命工程師 iOS應用架構談 view層的組織和調用方案 博客中提到一個疑問github
是否有必要讓業務方統一派生ViewControllerjson
Casa大神回答是NO，緣由以下swift
- 使用派生比不使用派生更容易增長業務方的使用成本
- 不使用派生手段同樣也能達到統一設置的目的
對於第一點，從 集成成本 ，上手成本 ，__架構維護成本__等因素入手，大神博客中也已經很詳細。設計模式
框架不須要經過繼承即可以對ViewController進行統一配置。業務即便脫離環境，也可以跑完代碼，ViewController一旦放入框架環境，不須要添加額外的或者只需添加少許代碼，框架也可以起到相應的做用 對於本人來講 ，具有這點的吸引力，已經足夠讓我有嘗試一番的心思了。數組
對於OC來講，方法攔截很容易就想到自帶的黑魔法方法調配 Method Swizzling， 至於爲ViewController作動態配置，天然非__Category__莫屬了安全
Method Swizzling 業界已經有很是成熟的三方庫 Aspects, 因此Demo代碼採用 Aspects 作方法攔截服務器
ViewController攔截器部分示例代碼 （與Casa大神中的一模一樣）：
/* FKViewControllerIntercepter.m */
+ (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 的去基類 ？
我以爲能夠，可是我以爲有必要犧牲一些動態性，來保證框架的穩定性，例如：咱們 ViewModel 通常繼承自 NSObject, 咱們對 NSObject 進行攔截不免會攔截到一些不想要的東西，並且侵入性太強，容易出錯。
個人作法是 ：
/* FKViewModelProtocol.h */
@protocol FKViewModelProtocol <NSObject> @required /** viewModel 初始化屬性 */ - (void)fk_initializeForViewModel; @end 複製代碼
/* FKLoginViewModel.h */
@interface FKLoginViewModel : NSObject<FKViewModelProtocol>
複製代碼
/* FKViewModelIntercepter.m */
#pragma mark - Hook Methods
- (void)_initWithInstance:(NSObject <FKViewModelProtocol> *)viewModel
{
if ([viewModel respondsToSelector:@selector(fk_initializeForViewModel)]) {
[viewModel fk_initializeForViewModel];
}
}
複製代碼
經過協議判斷是否須要執行hook方法，這樣即便對 NSObject 也可以必定程度上下降風險，而咱們須要作的僅僅是遵照協議，而且實現協議，兼顧遷移成本和風險
最終咱們 .h 代碼會變成以下，具體協議實如今 .m 中自行實現
@interface FKLoginViewModel : NSObject<FKViewModelProtocol>
@interface FKLoginViewController : UIViewController <FKViewControllerProtocol>
@interface FKLoginButton : UIButton <FKViewProtocol>
@interface FKLoginAccountInputTableViewCell : UITableViewCell <FKViewProtocol>
複製代碼
具體詳細代碼請見文章開頭Demo
總結，咱們經過 Category 和 方法攔截 實現了方法的動態配置，對於 View ViewModel __ViewController__的基類，基本上能夠說一句 Fxxk Off了
2、View層採用 MVVM 設計模式，使用 ReactiveObjC 進行數據綁定
前提，適合本身的纔是最好的
做爲老牌思想MVC，你們早已耳熟能詳，MVC素有 Massive VC之稱，隨着業務增長，Controller將會愈來愈複雜，最終Controller會變成一個"神類", 即有網絡請求等代碼，又充斥着大量業務邏輯，因此爲Controller減負，在某些狀況下變得勢在必行
MVVM是基於胖Model的架構思路創建的，而後在胖Model中拆出兩部分：Model和ViewModel (注：胖Model 是指包含了一些弱業務邏輯的Model)
胖Model__其實是爲了減負 Controller 而存在的，而 MVVM 是爲了拆分__胖Model , 最終目的都是爲了減負__Controller__
咱們知道，蘋果MVC並無專門爲網絡層代碼分專門的層級，按照以往習慣，你們都寫在了__Controller__ 中，這也是__Controller__ 變Massive得元兇之一，如今咱們能夠將網絡請求等諸如此類的代碼放到__ViewModel__中了 （文章後半部分將會描述ViewModel中的網絡請求）
那麼，ReactiveCocoa 是實現MVVM必要的嗎 ?
NO, MVVM 重在是存在 ViewModel 而不是 使用了__ReactiveCocoa__
正常的網絡請求獲取數據，而後更新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 接口對服務器響應數據從新處理，靈活交付給業務層
接下來，本文會回答兩個問題
- 以什麼方式將數據交付給業務層？
- 交付什麼樣的數據 ?
對於第一個問題
1、以什麼方式將數據交付給業務層？
雖然 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"];
}
複製代碼
至此咱們解決了 __如何交付數據__的問題
2、交付什麼樣的數據 ?
如今諸如 JSONModel ，YYModel 之類的Json轉Model的庫也很是多，大多數Json對象，網絡請求成功直接就被轉成Model了
然而 iOS應用架構談 網絡層設計方案 中給出了兩種有意思的交付思路
- 使用 reformer 對數據進行清洗
- 去特定對象表徵 （去Model）
- 使用 reformer 對數據進行清洗
Casa文章中好處已經寫得很詳細了，經過不一樣的 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
{
}
複製代碼
2. 去特定對象表徵 （去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 路由 對應用進行組件化解耦
iOS應用架構談 組件化方案 一文中 Casa 針對 蘑菇街組件化 提出了質疑，質疑點主要在這幾方面
- App啓動時組件須要註冊URL
- URL調用組件方式不太好傳遞相似 UIImage 等很是規對象
- URL須要添加額外參數可讀性差，因此不必使用URL
對於 App啓動時組件須要註冊URL 顧慮主要在於，註冊的URL須要在應用生存週期內常駐內存，若是是註冊__Class__還好些，若是註冊的是實例，消耗的內存就很是可觀了 至於後面幾點，你們就仁者見仁，智者見智了
依小的拙見，URL方式，仍是利大於弊的，Demo中採用了 JLRoutes 三方庫進行路由註冊，僅僅註冊路由表規則，不註冊 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)];
複製代碼
雖然仍是有點長，可是是否是好多了
總結與反思
- 適合本身的纔是最好的，沒最好，要恰好
- 脫離業務談架構都是耍流氓，（請叫我小流氓 = =，逃）
- 自身功力仍是不夠，都是在他人基礎上衍生或者照搬，慚愧慚愧，但願有本身變成大牛的那一天
- iOS寒冬路難且艱，你們且行且珍惜
Demo代碼github地址 ：FxxkBaseClass-MVVM-ReactiveObjc 你們按需取用
- 1. Android組件化架構實踐
- 2. iOS組件化實踐（基於CocoaPods）
- 3. iOS組件化實踐
- 4. iOS架構組件化
- 5. Android MVVM組件化架構方案
- 6. Android組件化實踐2——經典組件化項目架構
- 7. iOS 組件化實踐思考
- 8. 乾貨｜敏捷實踐重構
- 9. iOS App組件化開發實踐
- 10. iOS VIPER架構實踐(一)：從MVC到MVVM到VIPER
- 更多相關文章...
- • Docker 架構 - Docker教程
- • Thymeleaf項目實踐 - Thymeleaf 教程
- • Kotlin學習（二）基本類型
- • IntelliJ IDEA安裝代碼格式化插件
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. vs2019運行opencv圖片顯示代碼時，窗口亂碼
- 2. app自動化 - 元素定位不到？別慌，看完你就能解決
- 3. 在Win8下用cisco ××× Client連接時報Reason 422錯誤的解決方法
- 4. eclipse快速補全代碼
- 5. Eclipse中Java/Html/Css/Jsp/JavaScript等代碼的格式化
- 6. idea+spring boot +mabitys(wanglezapin)+mysql (1)
- 7. 勒索病毒發生變種 新文件名將帶有「.UIWIX」後綴
- 8. 【原創】Python 源文件編碼解讀
- 9. iOS9企業部署分發問題深入瞭解與解決
- 10. 安裝pytorch報錯CondaHTTPError：******
- 1. Android組件化架構實踐
- 2. iOS組件化實踐（基於CocoaPods）
- 3. iOS組件化實踐
- 4. iOS架構組件化
- 5. Android MVVM組件化架構方案
- 6. Android組件化實踐2——經典組件化項目架構
- 7. iOS 組件化實踐思考
- 8. 乾貨｜敏捷實踐重構
- 9. iOS App組件化開發實踐
- 10. iOS VIPER架構實踐(一)：從MVC到MVVM到VIPER