iOS 的組件化開發
在一個APP開發過程中,如果項目較小且團隊人數較少,使用最基本的MVC、MVVM開發就已經足夠了,因為維護成本比較低。
但是當一個項目開發團隊人數較多時,因為每個人都會負責相應組件的開發,常規開發模式耦合會越來越嚴重,而且導致大量代碼沖突,會使後期維護和升級過程中代碼“牽一發而動全身”,額外帶來很大的工作量,並且會導致一些潛在的BUG。
在這時,組件化開發就派上很大用場了,所謂的組件化開發,就是把APP根據業務拆分為各獨立的組件,各個組件相互寫作,組成完整的APP。
一、各組件的引入
關於組件的拆分,就根據具體項目進行拆分,假如APP被拆分了AModule、BModule、CModule,那麽,應該如何引入這些組件呢?你可能會想到APP的入口AppDelegate。在平時開發中,AppDelegate中往往初始化了好多組件,比如推送、統計等組件,這樣就會導致AppDelegate的臃腫。
所以,我們可以增加一個ModuleManager
,專門用來初始化各組件。
首先增加一個 ModuleProtocol
:
#import <Foundation/Foundation.h>
@import UIKit;
@import UserNotifications;
@protocol ModuleProtocol <UIApplicationDelegate, UNUserNotificationCenterDelegate>
@end
我們在ModuleManager
中hook住UIApplicationDelegate
和 UNUserNotificationCenterDelegate
#import "ModuleManager.h" #import "AppDelegate.h" #import <objc/runtime.h> #define ALL_MODULE [[ModuleManager sharedInstance] allModules] #define SWIZZLE_METHOD(m) swizzleMethod(class, @selector(m),@selector(module_##m)); @interface ModuleManager () @property (nonatomic, strong) NSMutableArray<id<ModuleProtocol>> *modules; @end @implementation ModuleManager + (instancetype)sharedInstance { ...... } - (NSMutableArray<id<ModuleProtocol>> *)modules { ...... } - (void)addModule:(id<ModuleProtocol>) module { ...... } - (void)loadModulesWithPlistFile:(NSString *)plistFile { ...... } - (NSArray<id<ModuleProtocol>> *)allModules { ...... } @end @implementation AppDelegate (Module) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ Class class = [self class]; SWIZZLE_METHOD(application:willFinishLaunchingWithOptions:); SWIZZLE_METHOD(application:didFinishLaunchingWithOptions:); ...... }); } static inline void swizzleMethod(Class class, SEL originalSelector, SEL swizzledSelector) { ...... } - (BOOL)module_application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions { BOOL result = [self module_application:application willFinishLaunchingWithOptions:launchOptions]; for (id<ModuleProtocol> module in ALL_MODULE) { if ([module respondsToSelector:_cmd]) { [module application:application willFinishLaunchingWithOptions:launchOptions]; } } return result; } - (BOOL)module_application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { BOOL result = [self module_application:application didFinishLaunchingWithOptions:launchOptions]; for (id<ModuleProtocol> module in ALL_MODULE) { if ([module respondsToSelector:_cmd]) { [module application:application didFinishLaunchingWithOptions:launchOptions]; } } return result; } ...... @end
ModuleManager.h
:
#import <Foundation/Foundation.h>
#import "ModuleProtocol.h"
@interface ModuleManager : NSObject
+ (instancetype)sharedInstance;
- (void)loadModulesWithPlistFile:(NSString *)plistFile;
- (NSArray<id<ModuleProtocol>> *)allModules;
@end
之後我們通過一個 ModulesRegister.plist
文件管理需要引入的組件:
如上圖,假如我們要引入AModule、BModule、CModule,那麽這三個Module只需要實現協議ModuleProtocol
,然後實現AppDelegate
中對應的方法,在對應方法中初始化自身即可:
AModule.h
:
#import <Foundation/Foundation.h>
#import "ModuleProtocol.h"
@interface AModule : NSObject<ModuleProtocol>
@end
AModule.m
:
#import "AModule.h"
@implementation AModule
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
//初始化AModule
return YES;
}
@end
之後在AppDelegate
的load
方法中通過ModulesRegister.plist
引入各組件即可:
@implementation AppDelegate
+ (void)load {
//load modules
NSString* plistPath = [[NSBundle mainBundle] pathForResource:@"ModulesRegister" ofType:@"plist"];
[[ModuleManager sharedInstance] loadModulesWithPlistFile:plistPath];
}
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
......
}
@end
這樣,各組件的開發者在自己的組件中初始化自己,其他人需要使用時只需要加入ModulesRegister.plist
文件中即可。
二、組件間協作
簡單來看,假設APP的每個頁面就是一個組件,假如我們的APP有AViewController、BViewController、CViewController、DViewController、EViewController,各ViewController必然設置各種相互跳轉。那麽,我們APP的跳轉邏輯可能是下面這個樣子:
為了解決這種復雜的耦合關系,我們可以增加一個Router中間層去管理各ViewController之間的跳轉關系(也就是實際開發中組件間相互調用的關系)。
所以,根據需要,某開源作者開發並開源了一個支持URL Rewrite的iOS路由庫— FFRouter,通過FFRouter去管理各ViewController之間的跳轉關系:
這樣,各ViewController之間的跳轉關系就變的清晰了許多。
FFRouter通過提前註冊對應的URL,之後就直接通過打開URL去控制各ViewController之間的跳轉(或各組件間的調用)。
FFRouter支持組件間傳遞非常規對象,如UIImage等,並支持獲取組件返回值。
基本使用如下:
/**
註冊 url
@param routeURL 要註冊的 URL
@param handlerBlock URL 被 Route 後的回調
*/
+ (void)registerRouteURL:(NSString *)routeURL handler:(FFRouterHandler)handlerBlock;
/**
註冊 URL,通過該方式註冊的 URL 被 Route 後可返回一個 Object
@param routeURL 要註冊的 URL
@param handlerBlock URL 被 Route 後的回調,可在回調中返回一個 Object
*/
+ (void)registerObjectRouteURL:(NSString *)routeURL handler:(FFObjectRouterHandler)handlerBlock;
/**
判斷 URL 是否可被 Route(是否已經註冊)
@param URL 要判斷的 URL
@return 是否可被 Route
*/
+ (BOOL)canRouteURL:(NSString *)URL;
/**
Route 一個 URL
@param URL 要 Router 的 URL
*/
+ (void)routeURL:(NSString *)URL;
/**
Route 一個 URL,並帶上額外參數
@param URL 要 Router 的 URL
@param parameters 額外參數
*/
+ (void)routeURL:(NSString *)URL withParameters:(NSDictionary<NSString *, id> *)parameters;
/**
Route 一個 URL,可獲得返回的 Object
@param URL 要 Router 的 URL
@return 返回的 Object
*/
+ (id)routeObjectURL:(NSString *)URL;
/**
Route 一個 URL,並帶上額外參數,可獲得返回的 Object
@param URL 要 Router 的 URL
@param parameters 額外參數
@return 返回的 Object
*/
+ (id)routeObjectURL:(NSString *)URL withParameters:(NSDictionary<NSString *, id> *)parameters;
/**
Route 一個未註冊 URL 時回調
@param handler 回調
*/
+ (void)routeUnregisterURLHandler:(FFRouterUnregisterURLHandler)handler;
/**
取消註冊某個 URL
@param URL 要被取消註冊的 URL
*/
+ (void)unregisterRouteURL:(NSString *)URL;
/**
取消註冊所有 URL
*/
+ (void)unregisterAllRoutes;
/**
是否顯示 Log,用於調試
@param enable YES or NO,默認為 NO
*/
+ (void)setLogEnabled:(BOOL)enable;
而且參考天貓的方案增加了URL Rewrite功能:
可以使用正則
添加一條 Rewrite 規則,例如:
要實現打開 URL:https://www.taobao.com/search/原子彈
時,將其攔截,改用本地已註冊的 URL:protocol://page/routerDetails?product=原子彈
打開。
首先添加一條 Rewrite 規則:
[FFRouterRewrite addRewriteMatchRule:@"(?:https://)?www.taobao.com/search/(.*)" targetRule:@"protocol://page/routerDetails?product=$1"];
之後在打開URL:https://www.taobao.com/search/原子彈
時,將會 Rewrite 到URL:protocol://page/routerDetails?product=原子彈
。
[FFRouter routeURL:@"https://www.taobao.com/search/原子彈"];
可以通過以下方法同時增加多個規則:
+ (void)addRewriteRules:(NSArray<NSDictionary *> *)rules;
其中 rules 格式必須為以下格式:
@[@{@"matchRule":@"YourMatchRule1",@"targetRule":@"YourTargetRule1"},
@{@"matchRule":@"YourMatchRule2",@"targetRule":@"YourTargetRule2"},
@{@"matchRule":@"YourMatchRule3",@"targetRule":@"YourTargetRule3"},]
Rewrite 規則中的保留字:
- 通過
$scheme
、$host
、$port
、$path
、$query
、$fragment
獲取標準 URL 中的相應部分。通過$url
獲取完整 URL - 通過
$1
、$2
、$3
...獲取matchRule
的正則中使用圓括號取出的參數 $
:原變量的值、$$
:原變量URL Encode後的值、$#
:原變量URL Decode後的值
例如:
https://www.taobao.com/search/原子彈
對於Rewrite 規則(?:https://)?www.taobao.com/search/(.*)
$1=原子彈
$$1=%e5%8e%9f%e5%ad%90%e5%bc%b9
同樣,https://www.taobao.com/search/%e5%8e%9f%e5%ad%90%e5%bc%b9
對於Rewrite 規則(?:https://)?www.taobao.com/search/(.*)
$1=%e5%8e%9f%e5%ad%90%e5%bc%b9
$#1=原子彈
考慮到經常用路由配置UIViewController
之間的跳轉,所以增加了額外的工具FFRouterNavigation
來更方便地控制UIViewController
之間的跳轉。
三、其他組件化方案
目前這種組件化方案參考了蘑菇街、天貓、京東的的實現方案。除這種方案外,Casa(查看文章)之前提出了解耦程度更高的方案,這種方案組件仍然使用中間件通信,但中間件通過 runtime 接口解耦,然後使用 target-action 簡化寫法,通過 category 分離組件接口代碼。
但是,這種方案雖然解耦程度更高,但是也增加了組件化的成本,綜合考慮,直接使用中間件通信的方式更好一點。具體哪種方案好,也就仁者見仁、智者見智了~
iOS 的組件化開發