iOS 的组件化开发

在一个APP开发过程当中，若是项目较小且团队人数较少，使用最基本的MVC、MVVM开发就已经足够了，由于维护成本比较低。

可是当一个项目开发团队人数较多时，由于每一个人都会负责相应组件的开发，常规开发模式耦合会愈来愈严重，并且致使大量代码冲突，会使后期维护和升级过程当中代码“牵一发而动全身”，额外带来很大的工做量，而且会致使一些潜在的BUG。

在这时，组件化开发就派上很大用场了，所谓的组件化开发，就是把APP根据业务拆分为各独立的组件，各个组件相互写做，组成完整的APP。

1、各组件的引入

关于组件的拆分，就根据具体项目进行拆分，假如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文件中便可。

2、组件间协做

简单来看，假设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之间的跳转。

3、其余组件化方案

目前这种组件化方案参考了蘑菇街、天猫、京东的的实现方案。除这种方案外，Casa（查看文章）以前提出了解耦程度更高的方案，这种方案组件仍然使用中间件通讯，但中间件经过 runtime 接口解耦，而后使用 target-action 简化写法，经过 category 分离组件接口代码。 可是，这种方案虽然解耦程度更高，可是也增长了组件化的成本，综合考虑，直接使用中间件通讯的方式更好一点。具体哪一种方案好，也就仁者见仁、智者见智了～