美文网首页iOS高级开发设计模式iOS开发
一种简单的iOS 的组件化设计

一种简单的iOS 的组件化设计

作者: 沉思者Tiebreaker | 来源:发表于2018-07-09 19:17 被阅读2030次

    前言:如今iOS的开发中,组件化设计都成为一种标配了,要是不用上好像就赶不上潮流了。网上相关的方案分析也多如牛毛。分析比较多的是URLRoute / 蘑菇街的 url-block 和 Protocol-Class / 和 casa 的target-action。

    一、 方案比较

    URLRoute 与蘑菇街 url-block 和Protocol-Class 都不得不维护一套 url 或 Protocol 与组件间的映射,通过 url 或 Protocol 去寻找组件。先不说效率问题,单是编写和维护这个映射的代码,使用者使用必须先注册,然后才能使用,模板代码会充满整个项目。其实小的觉得这份映射是完全没必要的。

    casa 的target-action 不用维护映射表,这个方案使用 “Target_ + 组件名字” 作 为key 通过runtime 寻找服务。但是 hardcode 的地方太多,宏定义或者const 变量充满了头文件。这样使用起来必须记忆很多const变量,编码效率也稍微下降。在调用组件的时候,cache 了 targetClass。不晓得是否觉得NSClassFromString 方法不够高效。

    二、小的试把两套方案结合起来,弄一个叫protocol-module模式的组件化

    1. 约定

    oc 语言中充满了约定。比如 类的初始化方法 initXXX,系统合成的setter getter方法。更具体的是KVO观察了一个类的属性,被观察的类变更为一个带约定前缀的子类

    - (instancetype)initWithNibName:(nullable NSString *)nibNameOrNil bundle:(nullable NSBundle *)nibBundleOrNil NS_DESIGNATED_INITIALIZER;
    
    image.png

    小的这套方案最主要的是编写代码的约定,思路如下图


    image.png

    2.说明
    小的打个比方。我们把主app称为用户,用户委托商家生产一个组件。用户把需求和想怎么使用这个组件告诉商家。“需求”的实现就是组件本身,“怎么使用”对应的就是协议了。因为协议是双方都知晓的,所以是公开的。这样的好处是,用户不管组件是怎么实现的,我只要按协议使用就行了。

    图中public protocol 是定义好的组件调用协议,基本协议规定了组件回调的 callback,和服务体 serverBody,也就是组件提供服务的 controller。组件moduleA 、moduleB等为了使用者方便,都会实现一个interface的类。这个类遵守对应的协议,类名必须是 “协议名 + SI”。比如协议名是ModuleA,那么interface类的类名就是ModuleASI。

    1)编写协议和组件
    基本协议定义如下

    #ifndef MoudleProtocol_ServerInterface
    #define MoudleProtocol_ServerInterface @"SI"
    #endif
    
    @protocol BaseModule <NSObject>
    @required
    // server body
    @property(nonatomic, weak) __kindof UIViewController *serverBody;
    
    @optional
    // callback
    @property(nonatomic, copy) void (^callback) (id params);
    
    @end
    

    通过将 BaseModule 协议子协议化,定制特定组件调用协议。例如我们要调用组件moduleA,我们可以定义一个叫ModuleA的协议,这个协议遵守BaseModule协议

    @protocol ModuleA <BaseModule>
    
    @required
    // input
    @property(nonatomic, strong) NSString *name;
    
    @end
    

    这个协议很简单,只有一个属性name,指定了我们调用组件时要传入的参数是name。

    定好了协议,商家生产出组件后,他还要做一件事就是实现interface接口类ModuleASI
    这个类实现如下

    @interface MouduleASI : NSObject <ModuleA>
    
    @end
    
    @implementation MouduleASI
    
    @synthesize callback;
    
    @synthesize name;
    
    @synthesize serverBody;
    
    - (UIViewController *)serverBody {
      if (!serverBody) {
        UIStoryboard *sb  = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
        serverBody = [sb instantiateViewControllerWithIdentifier: @"OhgRacViewController"];
        ((OhgRacViewController *)serverBody).interface = self;
      }
      return serverBody;
    }
    @end
    

    好了,代码很简单不是吗,商家不会抱怨让他多干活的。在MouduleASI的.m文件里,商家简单的返回一个serverBody。

    2)大功告成了吗?还差一点

    组件化最重要的路由忘了。不过放心,小的这个路由很简单的,老规矩,先看代码,路由定义

    @interface OHGRouter : NSObject
    
    + (instancetype) router;
    - (id) interfaceForProtocol:(Protocol *) p;
    - (id) interfaceForURL:(NSURL *) url;
    
    // for unit test
    - (void) assertForMoudleWithProtocol:(Protocol *) p;
    - (void) assertForMoudleWithURL:(NSURL *) url;
    
    // navi type for vc
    // push present
    - (UIViewController *) findVcOfView:(UIView *) view;
    
    @end
    

    同样简单的要死,小的不用说各位看官都基本明白了,不过,还是啰嗦一下...别打脸

    • (instancetype) router;这个方法略
    • (id) interfaceForProtocol:(Protocol *) p;这个方法是通过协议找到对应的组件接口类,实现如下
    - (id)interfaceForProtocol:(Protocol *)p {
      Class cls = [self _clsForProtocol:p];
      return [[cls alloc] init];
    }
    
    - (Class) _clsForProtocol:(Protocol *) p {
      NSString *clsString = [NSStringFromProtocol(p) stringByAppendingString: MoudleProtocol_ServerInterface];
      return NSClassFromString(clsString);
    }
    

    好吧,就这么点代码,获取协议名,拼接上前面public protocol的宏定MoudleProtocol_ServerInterface @"SI",就是我们的接口类名。这就是我们为啥提前做了约定的原因。(类似苹果实现的KVO),这个约定好处在于,我们完全不用维护 url-block / protocol-class / target-action等在内存的映射,也就不需要注册组件了。

    • (id) interfaceForURL:(NSURL *) url;这个方法可以处理远端调用组件,我们稍后再说

    // for unit test

    • (void) assertForMoudleWithProtocol:(Protocol *) p;
    • (void) assertForMoudleWithURL:(NSURL *) url;
      这两个方法很有意思,在单元测试的时候,我们容易通过协议和url检查,组件是否实现了 interface 接口类,看代码
    - (void)assertForMoudleWithProtocol:(Protocol *)p {
      if (![self _clsForProtocol:p]) {
        NSString *protocolName = NSStringFromProtocol(p);
        NSString *clsName = [protocolName stringByAppendingString: MoudleProtocol_ServerInterface];
        NSString *reason = [NSString stringWithFormat: @"找不到协议 %@ 对应的接口类 %@ 的实现", protocolName, clsName];
        [self _throwException: reason];
      }
    }
    

    如果我们找不到接口类,说明组件还没写好,抛出异常。
    以上,路由也就写好了。

    3)很快就完成了,看看怎么使用
    在ViewController.m下

    #import "ViewController.h"
    #import "OHGRouter.h"
    
    @implementation ViewController
    - (IBAction)showModlue:(id)sender { 
      id <ModuleA> obj = [[OHGRouter router] interfaceForProtocol: @protocol(ModuleA)];
    //  id<ModuleA> obj = [[OHGRouter router] interfaceForURL:[NSURL URLWithString:@"ModuleA://?name=xiaobaitu"]];
      obj.name = @"小白兔";
      obj.callback = ^(id params) {
        NSLog(@"%@", params);
      };
      [self.navigationController pushViewController: obj.serverBody animated: YES];
    }
    @end
    

    在showModlue方法里,小的简单的传入协议ModuleA,就能调用组件了,传入参数name, 实现回调callback。并且咱基本上没有hardcode,所以还有编码过程编译器还能给温馨提示。在整个ViewController.m,咱并没有导入任何组件相关的信息,路由里也没有,很简单的咱就实现了组件的解耦。这一切就是因为我们一开始就明确了协议和组件接口的约定。

    4)还没完
    前面说到路由- (id) interfaceForURL:(NSURL ) url;方法,从使用就可以看出来这事怎么回事了id<ModuleA> obj = [[OHGRouter router] interfaceForURL:[NSURL URLWithString:@"ModuleA://?name=xiaobaitu"]];
    只要我们按格式|
    协议名://参数 *| 调用就大功告成了,例如: ModuleA://?name=xiaobaitu。


    好了,完了

    附上demo地址:https://github.com/ovcv8/a_simple_router

    相关文章

      网友评论

      • Ronda:做组件化一般是需要私有pods把一个模块封装起来。pods管理的模块是不能直接引入主项目里面的文件的。
        但是楼主的设计是需要把BaseModule,ModuleA这种协议类放在主工程吧
        ModuleASI是放在模块里面的。但是ModuleASI里面直接引用了ModuleA协议
        这在pods管理的模块里面是不能直接这样包含的
        楼主能否基于pods来管理模块,然后使用本文的组件化设计思路写一个demo。看看到底是如何不利用硬编码解耦的
      • MemoryReload:看你把前两种都BlaBlaBla了一遍,用文件映射,你说配置文件不好。用动态参数,你说常量太多。你说的基于接口用协议实现的方式,我敢问你一句:你项目里协议,估计不要太多哦!种基于协议,抽象组件接口为一个protocol的方式,早就有了,详情请参阅Alibaba开源框架BeeHive。老兄,其实,每种方法都有自己的弊端。你要说最简单的解耦合方式,我强烈推荐你CTMediator足够用了。:relieved:
        inxx:@MemoryReload bingo, 理解万岁兄弟,楼主的中间件是一个遵守协议的接口类,尽量去往动态的接口实例化去靠拢了. 静态协议依赖的情况,逃是逃不掉的:smile: 但是有一个换汤不换药的方式去处理一下:可以把所有的协议和中间件放在一个类里去维护.这样总归会更清晰一点,利于维护. 总之期待有高手可以创造出新的颠覆性的设计吧
        MemoryReload:@inxx 我没说他的不好,我的意思是,不要嫌弃。没有前人走过的路,创新也乏善可陈。连牛顿都说,他是站在巨人的肩上。如你所说,两种毒药,你必饮一杯。除非,OC可以像Java一样支持Protocol的实例化,或者说,就是支持动态的接口实例化。那么,就可以像Spring所做的那样,完全的动态化IoC(控制反转),然后再用注解来实现绑定,就可以避免配置文件的问题了。我个人的看法是这样。最终,再明确下我的观点,我不是说楼主的东西不好。而是他不应该“欲扬先抑”,关键抑的都是探路者。楼主的设计,也会充斥着大量的静态协议依赖的情况,相信我,逃不掉的。:smile:
        inxx:不能否定楼主的想法具有创新性兄弟. BeeHive和楼主的方式都会有很多协议,CTMediator虽说解耦,同样的也会有很多的Target_xx和 其内部的Action_xx(中间件的同时带有了约定), 依赖这些中间件来使用服务.我认为楼主是吸取了BeeHive(或者说protocol-class)和CTMediator(target-action)内比较好的一面去做的一个结合. 楼主用protocol-class的形式增加了一个中间件,我认为这是可取的.当然有一个弊端是 映射表/约定 两杯毒药必须2选1这件事. 以上只是我的个人观点.
      • Icoder_e90d:仰望学习一下
      • inxx:有个地方好像有点问题,在模块的.h头文件ModuleAViewController.h 里:

        最好写:
        @property(nonatomic, strong) ModuleASI *interface;

        而不是:
        @property(nonatomic, strong) id <ModuleA> interface;

        不然会引起内存的释放问题. 在协议基类里把
        @property(nonatomic, weak) __kindof UIViewController *serverBody; 声明为 weak 了,用 SB 创建时不会出现问题, SB 会一直存在于文件内,但是用代码创建时实例化后会直接销毁, push 或者 present 时会出内存问题. 楼主可以用代码实例化控制器 A 然后在 dealloc 里打印释放测试一下.
        inxx:@沉思者Tiebreaker 哈哈,解决了。并不用在主app调用方持有相关组件,还是在SI类里处理一下就好了,serviceBody依然声明为weak属性,代码创建模块在他释放销毁前拿到返回值甩出给组件就好了
        沉思者Tiebreaker:@inxx 好的,还没测试过代码的。确实这里因为SI类和组件是共生的,必须相互持有。一个解决方案是主app调用方持有接口类可以解决这个问题,但是总感觉不够优雅。看看有没有优雅的解决方案
      • yamao123:@沉思者Tiebreaker 你所描述的SI的优势是我没有想到的,厉害。既然采用了这种模式为何不把子协议也分开来,维护在一个类中总是会出现很多的麻烦事儿,就好比项目中经常出现的common类一样,汇集了整个项目中的公用方法,久而久之就杂糅在了一起。
        inxx:我觉得现在的设计很 OK 的,为作者大兄弟点赞! 关于子协议是否独立出来的问题,我觉得可以根据项目实际情况去考虑,并且独立出来了的话,每个模块就会有 SI接口类+独立协议类 两个模板类,模块多了之后可能会有冗杂的感觉. 那么在基本协议和子协议放在一个类里的前提下,再一个如果是涉及到多人开发的话,只需要给协议类增加category 供其他人使用就 OK 了. 我是这么认为的.
        沉思者Tiebreaker:@yamao123 确实,实际中子协议是可以独立文件的,如果工程变大的话:grin:
      • 路_远方:SI类和Controller 深入绑定了,这样理解的话每一个Module必须要存在相应的SI类,那么SI类 就相当于与外界的“桥梁”了。有一个思考,SI只做了两件事情,一个是初始化,一个是协议变量赋值;是否可以只存在一个公共的SI,所有Module的初始化都通过此类;

        想法:
        为UIViewController写了一个扩展类,类中声明
        @property (nonatomic, strong) id<BaseModule> interface;
        这样在SI中对此进行赋值
        serverBody.interface = self;
        此时,所有的controller可以直接调用
        id<ModuleA> moduleA = (id<ModuleA>)self.interface;
        NSLog(@"%@",moduleA.name);
        moduleA.callback(@"success");
        不过此种方式产生了不好的结果,interface不可赋值,因为在赋值的时候无法识别到controller中的setter方法;

        第二种方式:
        在router类中定义
        @property (nonatomic, strong) id<BaseModule> module;
        _module = [[cls alloc] init];赋值
        然后在Controller中使用
        id<ModuleA> moduleA = (id<ModuleA>)[OHGRouter router].module;

        这样就只会存在一个protocol、SI、router 来处理所有的跳转;

        理解的是否有偏差?!
        沉思者Tiebreaker:@你的方向 谢谢你的提醒 为UIViewController写了一个扩展类这个想法很好。不过本方案确实需要每一个Module必须要存在相应的SI类。SI类的一大作用是区分不同组件,比如ModuleASI对应组件A,ModuleBSI对应组件B。没有这样细分路由就不知道如何寻找组件了。当然有方案时候是传入组件的controller的字符串去发现组件,个人觉得这样做需要硬编码,特别是传参的时候不太方便,因为没代码提示了。其实细分SI类有一个很大的好处,demo没有体现。因为si类伴随了组件的出生和消亡,一些统计的代码可以放在SI类,比方说组件的使用次数或频率。一些第三方控件不符合自身项目的组件化,简单的编写一个协议和一个SI类就很方便的成为自身项目的组件,可以达到统一入参和回调的目的。刚接手的同事也可以查看SI类就知道要给组件传什么参数,写什么回调。
      • 7d24c0461ee8:刚好正在做这部分。
      • Ly梦k:楼主,请问一下这个:
        组件moduleA 、moduleB等为了使用者方便,都会实现一个interface的类。这个类遵守对应的协议,类名必须是 “协议名 + SI”。比如协议名是ModuleA,那么interface类的类名就是ModuleASI。
        为什么类名必须是 “协议名 + SI”,不用这个也没什么问题吧
        Ly梦k:@沉思者Tiebreaker 明白了,谢谢解答
        沉思者Tiebreaker:@Ly梦k 这是一个约定,路由可以通过这个约定规则发现组件。它是用来替代放在内存中的映射的(一些方案如果要调用服务组件,需要注册组件,注册这个动作会在内存中维护一套组件映射)。当也可以用其他的约定,只要能让路由发现组件就行了
      • 974aa22baaa2:通过 id<ModuleB> obj = [[OHGRouter router] interfaceForURL:[NSURL URLWithString:@"ModuleB://"]];
        1.URL的scheme名字,找到对应的协议ModuleB,通过协议ModuleB拼接SI找到Class类名ModuleBSI,
        2.Class类名(ModuleBSI),实现serverBody的get方法,返回具体的控制器类型,然后内部引用了该控制器的类名。内部初始化具体实例变量。
        3.每扩展一个路由,创建个协议,还有一个对应协议加SI的管理文件,去引入需要导入的类名。

        我认为不好的地方,
        1.协议类名,完全依赖于URL的scheme。
        2.Class类名(ModuleBSI)内部引用了对应controller名称这就是耦合,而且会额外开销过多的文件,编译会变慢。
        3.这么设计还不如,直接:controler名称://params.....。体会不到核心思想在哪里。

        最近一直在看组件化的方案:望作者赐教。
        沉思者Tiebreaker:你好,谢谢你宝贵的意见。
        1,远端返回的url,scheme都是组件接口编写者与后台协商好的对应的。
        2,ModuleBSI接口类,其实是对 B 组件的一个包裹 他属于组件的一部分,所以引入组件controller 的头文件不会造成与其他组件的耦合。主app调用的时候,不需要导入组件的接口类ModuleBSI头文件,只需要知道对应的ModuleB协议(ModuleB协议不是组件 B的一部分,是一个公共的协议,但是ModuleBSI接口类 却是 B 组件的一部分)就好了。假如用 controller名称://params..... ,那么主app调用方通过路由寻找出来的是一个B 组件的 controller,就难免要引入组件的头文件了。这套方案的本意是:能够实现组件化,同时保留编译器的编码提示和联想。

        有问题欢迎一起讨论
      • sankun:ModuleASI实现里面 serverBody 对没有使用xib的项目 需要NSClassFromString() 避免引入头文件吧
        沉思者Tiebreaker:ModuleASI 属于组件的接口类,引入头文件不妨碍模块化
      • BoooBooo冰Booo:864562082@qq.com 给我来一份demo 谢谢
        沉思者Tiebreaker:demo已经附在文章后面
      • 小小刚abc:你好,请问能发下 demo 吗?
        邮箱地址 : 289601941@qq.com
        感谢
        沉思者Tiebreaker:demo已经附在文章后面
      • 宇立:我的邮箱是 345307478@qq.com
        请有空,把你说的组件化Demo发给我。谢谢啊!
        沉思者Tiebreaker:demo已经附在文章后面
      • 绿梨子红苹果:router传入的name最后用到哪去了?没太看明白
        沉思者Tiebreaker:router没有传入name入参,入参统一传到组件的接口类ModuleASI
      • 宇立:发一个Demo过来
        沉思者Tiebreaker:demo已经附在文章后面
      • Catalina諾:你好,github多少啊?急!!
        沉思者Tiebreaker:demo已经附在文章后面
      • 小微向前冲:有个demo更好了!!
        沉思者Tiebreaker:你好,迟点放在githup上
        suncorex:我去看错了。 我照着写了下。。。报错啊。。。我去。。。 :smile:
        suncorex:有链接么?
      • lcus:确实这样不引入各种类的头文件了 但是得引入各种协议
        沉思者Tiebreaker:tks,是的,协议可以放在公共区域,协议的目的是组件头文件不会相互引用,引入协议开销不大,还有一个好处是传值的时候编译器能提供联想,不用硬编码
      • 何梓杰:大佬能发一下demo吗
        suncorex:@沉思者Tiebreaker serverBody 这个地方 getter方法里面 找不到。
        suncorex:@沉思者Tiebreaker 有demo么。 大概思想是 熟悉了点,我照着你上面的写 有问题呀。
        沉思者Tiebreaker:你好,迟点我会放上github的

      本文标题:一种简单的iOS 的组件化设计

      本文链接:https://www.haomeiwen.com/subject/bbstpftx.html