iOS架構實踐乾貨：AOP替代基類 + MVVM + ReactiveObjC + JLRoutes元件化

我不言子不語兩相知發表於2017-12-19

前言：最近公司應用架構重構，受到反革命工程師去基類，去Model等影響，將一些已經做的架構工作和思想稍微做一些總結，故此有了這篇文章，如有錯誤，漏洞，或者傻x之出，請包涵一笑置之，或請留言

概覽：文章主要內容如下：

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

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

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

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

Demo 程式碼github地址：FxxkBaseClass-MVVM-ReactiveObjc 比較完整可以直接拿來寫專案，如果覺得有用的話請點個star 感激不盡

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

Casa反革命工程師 iOS應用架構談 view層的組織和呼叫方案部落格中提到一個疑問

是否有必要讓業務方統一派生ViewController

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

使用派生比不使用派生更容易增加業務方的使用成本
不使用派生手段一樣也能達到統一設定的目的

對於第一點，從 整合成本 ，上手成本 ，__架構維護成本__等因素入手，大神部落格中也已經很詳細。

框架不需要通過繼承即能夠對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了

二、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, 會需要寫一些膠水程式碼，所以程式碼量會增加

三、網路層使用 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）

使用 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

四、採用 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&param2=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)];
複製程式碼

雖然還是有點長，但是是不是好多了

總結與反思

適合自己的才是最好的，沒最好，要剛好

脫離業務談架構都是耍流氓，（請叫我小流氓 = =，逃）

自身功力還是不夠，都是在他人基礎上衍生或者照搬，慚愧慚愧，希望有自己變成大牛的那一天

iOS寒冬路難且艱，大家且行且珍惜

Demo程式碼github地址：FxxkBaseClass-MVVM-ReactiveObjc 大家按需取用

iOS 元件化/模組化架構設計實踐
2021-10-31
iOS元件化架構
實踐乾貨！猿題庫 iOS 客戶端架構設計
2016-01-10
iOS客戶端架構
Android MVVM元件化架構方案
2018-12-10
AndroidMVVM元件化架構
貨拉拉貨運iOS使用者端架構最佳化實踐
2022-11-10
iOS架構
iOS VIPER架構實踐(一)：從MVC到MVVM到VIPER
2017-08-21
iOS架構MVCMVVM
iOS架構：AOP實現區域性模組化
2019-04-02
iOS架構
乾貨｜敏捷實踐重構
2017-11-10
敏捷
iOS元件化實踐
2019-03-03
iOS元件化
Android 基於註解IOC元件化/模組化的架構實踐
2018-04-15
Android元件化架構
移動端APP元件化架構實踐
2023-11-06
APP元件化架構
心遇iOS端會話頁效能最佳化 — ReactiveObjC實踐篇
2023-05-04
iOS會話ReactOBJ
iOS 元件化實踐思考
2017-10-27
iOS元件化
Android 架構設計：MVC、MVP、MVVM和元件化
2019-03-04
Android架構MVCMVPMVVM元件化
MVVM架構在Flutter中的簡單實踐
2019-03-09
MVVM架構Flutter
MVVM架構的一次實踐，重寫iOS頭條客戶端
2016-05-07
MVVM架構iOS客戶端
乾貨分享：容器 PaaS 新技術架構下的運維實踐
2018-11-22
架構運維
iOS架構由淺入深 | MVVM
2018-08-05
iOS架構MVVM
iOS 開發（三） MVVM 架構篇
2017-12-19
iOSMVVM架構
iOS 架構模式–解密 MVC，MVP，MVVM以及VIPER架構
2016-01-11
iOS架構模式解密MVCMVPMVVM
iOS專案開發MVVM架構實踐(第三篇：應用佈局)
2018-05-12
iOSMVVM架構
基於CC的Android MVVM 元件化實現
2018-12-29
AndroidMVVM元件化
iOS 解藕、元件化最佳實踐
2018-11-21
iOS元件化
iOS應用千萬級架構：MVVM框架
2020-07-06
iOS架構MVVM框架
乾貨 | 廣告系統架構解密
2020-12-10
架構解密
乾貨：軟體架構詳解
2018-03-11
架構
Unity應用架構設計(12)——AOP思想的實踐
2019-03-04
Unity應用架構
iOS 元件化實踐方案－LDBusMediator 煉就
2016-05-31
iOS元件化
乾貨 | CDN搭配OSS最佳實踐 ——搭建動靜態分離的應用架構
2019-07-03
應用架構
讓Elasticsearch飛起來!——效能優化實踐乾貨
2019-02-21
Elasticsearch優化
讓 Elasticsearch 飛起來!——效能優化實踐乾貨
2019-01-01
Elasticsearch優化
iOS MVC、MVVM、MVP架構模式淺淺析
2019-03-17
iOSMVCMVVMMVP架構模式
iOS架構淺談從 MVC、MVP 到 MVVM
2021-09-09
iOS架構MVCMVPMVVM
WebRTC 架構優化及實踐
2018-09-28
Web架構優化
乾貨帖 | TDSQL-A核心架構揭秘
2021-09-09
SQL架構
乾貨：軟體架構分析詳解
2018-03-11
架構
乾貨 | 攜程酒店實時數倉架構和案例
2023-01-17
架構
乾貨篇：超多內容微服務架構實戰
2020-09-29
微服務架構
iOS有關架構元件化的文章連結
2016-12-09
iOS架構元件化