美学的表现层组件化之路

在很多以内容为主的应用中,比如考拉、严选,以及我们美学,界面内容通常比较复杂丰富,一个页面通常分为多个模块,各个模块之间独立性强,这样势必一个controller里面会有很多很多代码与逻辑来处理模块组合,导致代码日益膨胀。

这是一个表现层模块化组件,按照页面视觉结构,将一个页面划分为多个模块,然后通过模块间的简单组合,来实现复杂页面。并且将部分逻辑功能放到了对应组件,以达到复用与使用简单的效果。

目前,我们大部分展示型页面controller只有请求相关代码,基本能够控制在200行左右。


背景:

由于我们的项目处于一个比较早期的阶段,所以我们需要很多的尝试来改良我们的方案。所以在这期间的页面结构极不稳定,内容以及位置顺序等,都可能会发生较大变化。事实上,在1.0之后的3个版本中,每个版本的首页都在大改。

如下我们的一个首页版本,模块非常明显,并且在其他页面也会使用到类似模块。

用户内容的高自由性,大部分内容为用户选填,如果内容缺省,需要删掉该行,所以需要动态计算布局也是非常麻烦。如下除了用户和产品,都是可选内容,不可控因素太多。

可以看出,我们的内容可能会达到一个非常大的级别,此时性能也会是一个问题,必须采用视图重用才可以避免内存问题。

同时,不同模块的加载可能是异步的,返回结果也可能不同,需要部分显示空态、错误等提示,这样又进一步导致了页面的复杂性。

接下来,我们一个个的解决这样的问题。


方案

布局选型与重用问题:

一种是tableView来实现这些类似于列表的功能,另外一种是使用CollectionView来实现同样的功能。

虽然分别实现了这两种对应方案,但是最终使用最多的还是CollectionView,有几个原因:

  • CollectionView的布局是一次性算出来的,会有缓存,相当于性能优化
  • 模块间的间距控制,CollectionView更加灵活,不需要调整cell就可以改变间距
  • 可以看到我们的模块并不一定一行只有一个元素(比如首页),也不一定一个模块只有固定行数(比如上图的标签模块),如果使用tableView,还是会需要复杂的计算,而使用CollectionView,我们可以控制每个最小复用元素为最小的单位。

组件间组合与顺序问题

有需求是服务器控制组合与顺序,所以这是我们首先需要解决的问题。所以这里引入两个概念:

  1. 视图组件: 只负责视图展示,比如一个包含小列表的模块,或者仅仅只有一个元素的模块。只负责职责内的视图展示。

  2. 容器组件: 只负责组件间的组合,比如按照顺序或者空态等组合模式,当然最顶层的一个组件也是一个容器类组件。

这里容器类组件可以包含任意视图组件及容器类组件,而视图组件不能作为组合使用(这里有个特例HeaderFooterSectionComponent,其实提供了部分容器的概念,可以配置header和footer,一个细化)。

职责明确之后,我们就可以通过这种从属关系来任意组合我们的组件,如果不需要显示该视图,可以从容器组件中移除该组件或者将numberOf返回0个。

空态页、错误页等

有了上一个的两个概念,处理这两个问题就变得简单了。抽象的来说,就是组件依据不同状态,而分别展示不同的子组件。相当于增加一层组件,该组件的功能是控制展示当前子组件。

那么设计一个状态与组件间对应的字典,在需要的时候切换该状态就行了,这就是后来增加的容器类组件StatusComponent,可以根据不同的state来改变当前的子组件。

布局的多样化

可能有些页面需要内容元素需要居中显示,或者FlowLayout默认的居左显示(多行的时候,除最后一行外为两端对齐模式),又或者需要永远居左显示(比如我们的标签)。

当选择了CollectionView作为方案时,这个问题就很好解决了,不需要改动component代码,只需要创建的时候输入自定义的Layout就可以轻松改变布局了。


实现

按照以上的分析结果,最终实现了一套组件化实现方案(TableView结构类似,这里不做说明),源码大家自己看吧,就不介绍了:

上图蓝色的是视图组件,黄色的是容器组件。Group类型为顺序组合,Status组件为状态型组合。


使用流程

其中红色部分为日常开发需要真正关心的,可能需要写代码的部分,其他均由组件化解决,减少了开发一个新页面的成本。


Demo

以我们的首页推荐为例,虽然我们的首页内容多而且复杂,但是Controller代码也在200行左右。下面来看看一个主要流程:

- (void)viewDidLoad {
    [super viewDidLoad];

    // 在这里首先组装外层容器结构
    self.sectionGroupComponent = [DDCollectionViewSectionGroupComponent new];
    self.statusComponent = [MZCollectionViewStatusComponent defaultComponent];
    self.statusComponent.normalComponent = self.sectionGroupComponent;
    self.componentArray = @[self.statusComponent];
}

// 流程:
MZHomeRecommendRequest *request = [[MZHomeRecommendRequest alloc] init];
[request startWithBlock:^(MZHomeRecommendRequest *request, NSError *error) {
    // 网络请求回来后首先判断状态,来切换空态页或者错误页,其实这里还可以加入loading页
    if (!error) {
        if (request.response.groups.count > 0) {
            self.statusComponent.currentState = MZCollectionViewStateNormal;
            // 正常数据会根据数据来生成对应的component
            self.sectionGroupComponent.subComponents = [self componentFromData:request.response.groups];
        }
        else {
            self.statusComponent.currentState = MZCollectionViewStateNoData;
        }
    }
    else {
        self.statusComponent.currentState = MZCollectionViewStateError;
        self.statusComponent.errorComponent.title = error.localizedDescription;
    }
    [self.collectionView reloadData];
}];

再来看看单个component的结构,和一个单一元素的collectionView非常相似。

- (void)prepareCollectionView {
    [super prepareCollectionView];

    // 由于依赖collectionView,所以还是需要注册
    [self.collectionView registerClass:MZRepoNormalStyleCollectionViewCell.class
            forCellWithReuseIdentifier:NSStringFromClass(MZRepoNormalStyleCollectionViewCell.class)];
}

#pragma mark - UICollectionView
- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView {
    return 1;
}

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section {
    return self.repos.count;
}

- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView
                  cellForItemAtIndexPath:(NSIndexPath *)indexPath {

    MZRepoNormalStyleCollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:NSStringFromClass(MZRepoNormalStyleCollectionViewCell.class)
                                                                                          forIndexPath:indexPath];
    // config...
    return cell;
}

- (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollectionViewLayout *)collectionViewLayout sizeForItemAtIndexPath:(NSIndexPath *)indexPath {
    return size;
}

- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
    [collectionView deselectItemAtIndexPath:indexPath animated:YES];
    // push detail view controller
}

如何控制组件的顺序以及显示特性呢?在[self componentFromData:request.response.groups]中,在我们组装视图组件时,可以随意调整组件的顺序,控制组件的显示,而无需关心兄弟组件的情况。

- (NSArray *)componentFromData:(NSArray *)data {
    NSMutibleArray *retArray;
    forEach data switch (data[index].type) {
        case type1:
            // component1 add to array ...
        case type2:
            // component2 add to array ...
    }
}


扩展性

在一些场景下,我们需要额外的delegate方法来满足我们的需求,比如我们的居左对齐,需要把这些事件传入最终的视图component也很简单,只要扩展上面几个容器类组件的方法即可:

@protocol MZRepoAlignLeftCollectionFlowLayoutDelegate <UICollectionViewDelegateFlowLayout>
- (BOOL)collectionView:(UICollectionView *)collectionView shouldAlignLeftAtSection:(NSInteger)section;
@end

@interface DDCollectionViewSectionGroupComponent (MZRepoAlignLeftCollectionFlowLayout) 
<MZRepoAlignLeftCollectionFlowLayoutDelegate>

- (BOOL)collectionView:(UICollectionView *)collectionView shouldAlignLeftAtSection:(NSInteger)section {
    DDCollectionViewBaseComponent *comp = [self componentAtSection:section];
    if ([comp respondsToSelector:@selector(collectionView:shouldAlignLeftAtSection:)]) {
        return [(id<MZRepoAlignLeftCollectionFlowLayoutDelegate>)comp collectionView:collectionView shouldAlignLeftAtSection:section];
    }
    return NO;
}
@end

// 其他组件容器类似

其他所有扩展出来的功能(比如左划删除,3D touch),都可以按照这样的思路把消息传递性到视图组件上,这样也遵守了我们设计的初衷,每个组件只负责自己相关的业务。


一个对比 Facebook ComponentsKit

Facebook

  • 优点:

    • 完全实现了自己的一套布局系统,据说比苹果的效率高,粗略的看了下,反正没看懂(⊙﹏⊙)
    • 能够很好的实现流式布局,类似于iOS的stack,或者说更像网页的flex布局(视图重用性应该不好)
  • 缺点:

    • 完全颠覆了原生的布局方式和代码习惯,学习成本高
    • C++编写而成,所以需要Objective-C++来编写,必须承认C++还是很难掌握的

美学

  • 优点:

    • 和原生CollectionView代码保持一致,学习成本低
    • 从以前代码的转换成本低,我们也是一步步从原来的代码转到组件化的
  • 缺点:

    • 刷新数据需要重新计算整个Layout,此时会有性能损耗(这个要看数据量和视图复杂度,通常发生在页面切换,请求回来的时候,其实此时用户感知不到)
    • 需要按照CollectionView的写法来组建,因此部分接口需要暴露indexPath,如果乱用,可能会因为indexPath不存在导致崩溃


目前

到目前为止,美学大部分页面,都是采用组件化组合而成,随意数数,已经有超过100个组件了,接下来可能需要整理下组件,增加单个组件的复用性了。

历经几个版本,组件化目前已经是比较完善和稳定的一个版本了,也满足了目前所有的需求和日常开发,期间也接受了各种奇怪的需求,目前来看扩展性还是可以的,欢迎大家来讨论和提issue。


本文来自网易实践者社区,经作者段家顺授权发布。