iOS学习专题小知识点iOS

UIViewController的瘦身计划(iOS架构思想篇)

2018-02-12  本文已影响860人  ZhengYaWei

前言

这篇文章里会涉及如下几个方面:

  • 1、代码的组织结构,以及为何要这样写。
  • 2、那些场景适合使用子控制器,那些场景应该避免使用子控制器?
  • 3、分离UITableView的数据源和UITableViewDataSource协议。
  • 4、MVVM的重点是ViewModel,不是响应函数式。
  • 5、MVVM中,ReactiveCocoa或RXSwift实现数据绑定的带来的弊端。
  • 6、用策略模式替代if-elseswitch这样判断比较多,不利于代码阅读的分支结构。并在特定场景下,用策略模式解决模块调用问题。
  • 7、为什么要较少模块间跨层数据交流。

一、代码结构

在说控制器瘦身之前,首先要做的的是保证代码结构的清晰化。良好的代码结构有利于代码的传承、可读性以及可维护性。通常笔者都是这样控制代码结构的:

#pragra mark - life cycle 

#pragra mark - notification 

#pragra mark - action 

#pragra mark - UITableViewDelegate
.....总之这里是各种代理就对了

#pragra mark - UI

#pragra mark - setter & getter

二、 关于子控制器

对于相对比较复杂的界面,通常情况下还可以考虑添加子控制的实现方式。
优点:
把和该元素相关的业务逻辑分解一部分到子控制器中,主业务逻辑对应的代码量瞬间减少很多,代码封装和分离十分清晰。
缺点:
这种做法最大的缺点就是父控制器和子控制器之间的消息传递有时需要做额外的处理,尤其是子控制器的消息回调。
所以,建议根据实际情况有选择的考虑,如果父控制器和子控制器之间的消息交互较少,完全可以考虑此种方式。如果父控制器和子控制器之间的消息交互较多,建议仔细考虑清楚再做取舍。

实际开发中,苹果专门提供了一个UITableViewController类,专门为tableView服务,但是实际开发中很少有人直接使用。该控制相对于普通的UIViewController的而言,直接实现了下拉刷新功能;除此之外,还能切换编辑模式、响应键盘通知。如果UITableViewController实现的标准刚好同你项目中的tableView一些需求很类似,就可以直接通过使用子控制器的方式,避免了写那些重复的代码。当然,实际开发中出现这种事情的概率非常小。这里仅是简单提示下。

三、UITableView 的瘦身

绝大多数情况下,只要有控制器就会存在UITableView或UICollectionView(这里仅仅以tableView为例),所以对UITableView 的瘦身尤为重要。以下的分析主要参照该文章

3.1 拆分出不重要的东西

毫无疑问,在Controller层中协调View和Model的工作是无法拆除的。那么除此之外,不是必须有Controller层承载的内容便可以被拆除,比如tableView的数据源和UITableViewDataSource协议。下面分两种情况说明,一种是将数据源和UITableViewDataSource协议都拆分出来,另一种是只拆分数据源。

3.1.1 单一的cell和数据源(拆分数据源和UITableViewDataSource协议)

关于这种情况,文章中实现代码如下这样。

//控制器中代码
TableViewCellConfigureBlock configureCell = ^(PhotoCell *cell, Photo *photo) {
        [cell configureForPhoto:photo];
    };
    NSArray *photos = [AppDelegate sharedDelegate].store.sortedPhotos;
    self.photosArrayDataSource = [[ArrayDataSource alloc] initWithItems:photos cellIdentifier:PhotoCellIdentifier configureCellBlock:configureCell];
    self.tableView.dataSource = self.photosArrayDataSource;
    [self.tableView registerNib:[PhotoCell nib] forCellReuseIdentifier:PhotoCellIdentifier];
//抽离的数据源代码
//.h文件
typedef void (^TableViewCellConfigureBlock)(id cell, id item);
@interface ArrayDataSource : NSObject <UITableViewDataSource>
- (id)initWithItems:(NSArray *)anItems
     cellIdentifier:(NSString *)aCellIdentifier
 configureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock;
- (id)itemAtIndexPath:(NSIndexPath *)indexPath;
@end
//.m文件
#import "ArrayDataSource.h"
@interface ArrayDataSource ()
@property (nonatomic, strong) NSArray *items;
@property (nonatomic, copy) NSString *cellIdentifier;
@property (nonatomic, copy) TableViewCellConfigureBlock configureCellBlock;
@end
@implementation ArrayDataSource
- (id)init{
    return nil;
}
- (id)initWithItems:(NSArray *)anItems
     cellIdentifier:(NSString *)aCellIdentifier
 configureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock{
    self = [super init];
    if (self) {
        self.items = anItems;
        self.cellIdentifier = aCellIdentifier;
        self.configureCellBlock = [aConfigureCellBlock copy];
    }
    return self;
}
- (id)itemAtIndexPath:(NSIndexPath *)indexPath{
    return self.items[(NSUInteger) indexPath.row];
}
#pragma mark UITableViewDataSource
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
    return self.items.count;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:self.cellIdentifier forIndexPath:indexPath];
    id item = [self itemAtIndexPath:indexPath];
    self.configureCellBlock(cell, item);
    return cell;
}
@end

上述代码将tableView的数据源以及UITableViewDataSource协议都抽离到ArrayDataSource中,而UITableViewDelegate依然保留在Controller层中。至于数据源的来源(实际中往往是从网络获取),这里主要是通过Store类获取数据,具体体现代码NSArray *photos = [AppDelegate sharedDelegate].store.sortedPhotos;,该行代码你可以理解为实际项目中的网络请求的伪代码。

3.1.2 多种数据源和多种cell(仅拆分数据源和Protocols)

同时拆分数据源和UITableViewDataSource协议这种方式有一定的局限性,如果一个tableView中有多类型cell,下面的这个方法将很难设计,尤其是针对参数aCellIdentifieaConfigureCellBlock。所以针对这种情况仅仅将tableView 的dataSource拆出来即可,实际这种拆分情况就是MVVM模式中的ViewModel。

- (id)initWithItems:(NSArray *)anItems
     cellIdentifier:(NSString *)aCellIdentifier
 configureCellBlock:(TableViewCellConfigureBlock)aConfigureCellBlock;
3.1.3 网络层放在那里?

按照该文章的意思,网络层可以在封装之后放在Cotroller中,这种方案当然是可以。除此之外,按照MVVM的设计模式,网络层同样可以放在ArrayDataSource类中,该类对外提供网络请求接口,数据返回后,同步更新内部的数据源即可。

3.2 cell内部控制cell状态

通常控制cell的状态我们可以实现如下两个代理方法。

- (void)tableView:(UITableView *)tableView
        didHighlightRowAtIndexPath:(NSIndexPath *)indexPath{
    PhotoCell *cell = [tableView cellForRowAtIndexPath:indexPath];
    cell.photoTitleLabel.shadowColor = [UIColor darkGrayColor];
    cell.photoTitleLabel.shadowOffset = CGSizeMake(3, 3);
}
- (void)tableView:(UITableView *)tableView
        didUnhighlightRowAtIndexPath:(NSIndexPath *)indexPath{
    PhotoCell *cell = [tableView cellForRowAtIndexPath:indexPath];
    cell.photoTitleLabel.shadowColor = nil;
}

按照这种方式会纯在两个缺点:

- (void)setHighlighted:(BOOL)highlighted animated:(BOOL)animated{
    [super setHighlighted:highlighted animated:animated];
    if (highlighted) {
        self.photoTitleLabel.shadowColor = [UIColor darkGrayColor];
        self.photoTitleLabel.shadowOffset = CGSizeMake(3, 3);
    } else {
        self.photoTitleLabel.shadowColor = nil;
    }
}

3.3 cell 初始化和更新分离

另外一种好的做法就是将cell的根据model更新的方法,拆分到分类中完成。实际开发中,可能存在复杂的cell代码量很大,此时可以借助分类的方法分离关注点。

3.4 简单谈谈MVVM

四、合理拆分模块

4.1 模块拆分大小要合理

如果模块被拆分的太粗糙,基本就是简单的封装,并没有进一步细化,只是将所有的功能集中在一起,这样做似乎没有太大意义

如果模块被拆分的很细,Controller中很执行相关模块的功能就要调用相关模块代码,似乎代码量并不会减少太多。比如在做即时通信应用开发时,支持的消息类型有文字、语音、图片、视频消息。其中后三种消息类型同文字消息不同,后三者要求发送消息的时候,首先要像后台请求上传资源的权限,获取上传资源权限后,返回对应的字段(该字段以实际情况不同,可能是id,也可能是token之类的),上传成功后获取资源对应的URL,再把资源的URL通过类似文字消息的发送方式发送出去。此时,可以拆分成三个模块数据发送(叫A模块)、上传资源申请(叫B模块)、内容上传(叫C模块)。如果要发送文字消息,直接在Controller中调用模块A即可;但是如果想发送其他消息,就要依次调用模块B、模块C、模块A,按照这种调用方式,Controller必然会膨胀。

4.2 策略模式

在说合理拆分模块之前,先简单说下策略模式,因为接下来举的例子中涉及策略模式。
策略模式一般是指:

1. 可以实现目标的方案集合;
2. 根据形势发展而制定的行动方针和斗争方法;
3. 有斗争艺术,能注意方式方法。

switch,if-else之类的分支语句,此类语句给人的直观感觉是判断条件明确,代码层次清晰,缺点可能是代码繁琐,杂乱无章,而且拆分困难。特别是到后期维护代码的时候,这种状况往往令人有食之无味,弃之可惜的感觉。使用策略模式可以代替switch或if-else之类的代码。
举个例子,以下是小明的计划安排:

    周一打篮球
    周二逛街
    周三洗衣服
    周四打游戏
    周五唱歌
    其他休息

借助策略模式我们可以这样实现代码:

@interface XiaoMing : NSObject
- (void)doSomethingWithDayStr:(NSString *)dayStr params:(NSDictionary *)paramsDict;
@end
#import "XiaoMing.h"
@interface XiaoMing()
@property(nonatomic,copy)NSDictionary *strategyDict;//策略
@property(nonatomic,copy)NSDictionary *paramDict;//参数
@end
@implementation XiaoMing
- (void)doSomethingWithDayStr:(NSString *)dayStr params:(NSDictionary *)paramsDict{
    self.paramDict = paramsDict;
    if (self.strategyDict[dayStr]){
        NSInvocation *doWhat = self.strategyDict[dayStr];
        [doWhat invoke];
    }else{
        [self sleep];
    }
}
- (NSInvocation *)invocationWithMethod:(SEL)selector{
    NSMethodSignature*signature = [[self class] instanceMethodSignatureForSelector:selector];
    if (signature == nil) {
        NSString *reason = [NSString stringWithFormat:@"提示:The method[%@] is not find", NSStringFromSelector(selector)];
        @throw [NSException exceptionWithName:@"错误" reason:reason userInfo:nil];
    }
    NSInvocation*invocation = [NSInvocation invocationWithMethodSignature:signature];
    invocation.target = self;
    invocation.selector = selector;
    NSDictionary *param = self.paramDict;
    //index表示第几个参数,注意0和1已经被占用了(self和_cmd),所以我们传递参数的时候要从2开始。
    [invocation setArgument:&(param) atIndex:2];
    return invocation;
}
- (void)playBasketball:(NSDictionary *)dict{
    NSLog(@"方法:%s 参数:%@",__FUNCTION__,dict);
}
- (void)shopping:(NSDictionary *)dict{
    NSLog(@"方法:%s 参数:%@",__FUNCTION__,dict);
}
- (void)washClothes:(NSDictionary *)dict{
    NSLog(@"方法:%s 参数:%@",__FUNCTION__,dict);
}
- (void)playGames:(NSDictionary *)dict{
    NSLog(@"方法:%s 参数:%@",__FUNCTION__,dict);
}
- (void)sing:(NSDictionary *)dict{
     NSLog(@"方法:%s 参数:%@",__FUNCTION__,dict);
}
- (void)sleep{
     NSLog(@"这是其他情况:%s",__FUNCTION__);
}
- (NSDictionary *)strategyDict{
    if (_strategyDict == nil) {
        _strategyDict = @{
                          @"day1" : [self invocationWithMethod:@selector(playBasketball:)],
                          @"day2" : [self invocationWithMethod:@selector(shopping:)],
                          @"day3" : [self invocationWithMethod:@selector(washClothes:)],
                          @"day4" : [self invocationWithMethod:@selector(playGames:)],
                          @"day5" : [self invocationWithMethod:@selector(sing:)]
             };
    }
    return _strategyDict;
}
@end

外部调用可以完全不再使用if-else的判断了。

XiaoMing *xm = [[XiaoMing alloc]init];
    //各种情况直接赋值给dayStr即可。
    NSString *dayStr = @"day3s";
    [xm doSomethingWithDayStr:dayStr params:@{@"key":@"test"}];

4.3 合理应用策略模式和组合方式解决上述4.2问题

关于上述问题我们可以通过组合和策略模式解决。首先创建一个MessageManager类。对外提供的接口大概是这样的:

typedef NS_ENUM (NSUInteger, MessageSendStrategy){
    MessageSendStrategyText = 0,
    MessageSendStrategyImage = 1,
    MessageSendStrategyVoice = 2,
    MessageSendStrategyVideo = 3
}
@protocol MessageManagerDelegate<NSObject>
  @required
      - (void)messageSender:(MessageSender *)messageSender
      didSuccessSendMessage:(BaseMessage *)message
                   strategy:(MessageSendStrategy)strategy;

      - (void)messageSender:(MessageSender *)messageSender
         didFailSendMessage:(BaseMessage *)message
                   strategy:(MessageSendStrategy)strategy
                      error:(NSError *)error;
@end

@interface MessageManager:NSObject
@property (nonatomic, weak) id<MessageSenderDelegate> delegate;
@property(nonatomic,copy)NSDictionary *strategyDict;//主要在这里定义策略,内部通过Invoke唤起对应方法。
- (void)sendMessage:(BaseMessage *)message withStrategy:(MessageSendStrategy)strategy;
@end

外部调用形式大概是这样的,除此之外还要遵守MessageManagerDelegate协议并实现协议方法。

[self.messageManager sendMessage:message withStrategy:MessageSendStrategyText];

MessageManager.m文件实现大概是这样的:

@interface MessageManager()

@end

@implementation MessageManager
- (void)sendMessage:(BaseMessage *)message withStrategy:(MessageSendStrategy)strategy{
      .....
     if (self.strategyDict[@(strategy)]){
        NSInvocation *doWhat = self.strategyDict[@(strategy)];
        [doWhat invoke];
    }
    ......
    ......
}
......
......
@end

总的来说,基本形式和上面举出的例子类似。

4.4 减少跨层数据交流

前面注意事项。那么接下来就是要使用模块了,使用模块的时候同样有需要注意的地方:减少跨层数据交流。举个例子,假如有模块一、模块二、模块三,按照正常的调用方式是外部使用模块一调用模块二的方法,模块二的方法再调用模块三的方法。但是随着模块功能的完善,突然有一天出现模块一直接调用模块三的情况,那么后续就很难避免其他开发人员可能直接拿模块一调用模块三方法。类似这种跨层的数据交流很不利于项目的后续维护。

五、其它

除此之外,控件的合理拼装也能在很大程度上减少控制器中的代码。另外还有一个要注意的地方,就是UIViewController继承的问题。关于这个问题,可以在笔者之前写的这篇文章的第二部分内容找到答案。

小结

在说UIViewController的瘦身计划之前,第一部分先说了合理的代码结构;第二部分单提了下关于子控制器,并简单的用UITableViewController举了个例子;第三部分重点介绍了UITableView的瘦身,并因此引申出了MVVM的一些内容;第四部分主要介绍了一些模块拆分中遇到的一个问题和解决方案,除此还说明了模块跨层数据交流的问题;最后,提了下控件的拼装和UIViewController继承的问题。

上一篇下一篇

猜你喜欢

热点阅读