iOS组件化实践(一):简介

前言

iOS的组件化这块在去年3月起就有很多大神们讨论过,不过由于之前我们的项目结构比较简单,再加上用的swift做的开发,也没有去尝试做这块。直到前段时间公司准备用OC重构项目以符合新需求,于是于组内的小伙伴们研究了一下新项目的架构选型,经过一番讨论,决定使用组件化的架构。大约2周过后,组件化基本完成,决定写篇博客记录下我们组件化的过程,给想对项目做组件化的同学们做一个参考。

一、什么是组件化

想要做组件化的前提当然得知道什么是组件化。顾名思义,组件化就是将APP拆分成各个组件(或者说模块也行),同时解除这些模块之间的耦合,然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块,如果新项目中有类似的需求,直接将模块引入稍作修改就能使用了。

这种设计是不是很像引入三方库做快速开发?其实制作组件的过程就相当于做二方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。

二、组件化的优缺点

组件化的优点:

  1. 组件可独立运行,提高的代码的复用性,组件化的颗粒度越细,可复用度就越高。
  2. 当组件库的数量足够庞大时,项目只需要组合组件即可完成大部分的开发工作。
  3. 组件化后项目的代码结构更加清晰,追踪问题、修复bug、增加需求更方便
  4. 不同业务组件相互独立,明确团队开发的业务边界,增加团队协作效率

组件化的缺点:

  1. 增加开发人员的学习成本
  2. 增加了代码的冗余,组件化颗粒度越细,中间代码越多
  3. 增加了项目的复杂度,复杂度越高越容易出问题

总体上组件化对于项目的开发来说是利大于弊的,当然如果你的项目非常简单的话就没必要做这些了。

三、常见的组件化中间件方案的选择

项目在做组件化时必然要对各个组件之间做解耦。因为如果组件之间的耦合没有被剔除,想要使用某个组件的话就有可能会引用与所需业务无关的其他组件,这也就是casatwy大神常说的拔萝卜带出泥。但是耦合这东西本身就是天然存在的,没有耦合、没有依赖本来就无法形成一个项目,我们能做到的只有尽量避免不必要的耦合带来的麻烦。

想要达到每个组件之间相对低耦合,比较常用的方案就是断掉横向依赖,使用中间人模式将依赖下沉至中间件。想想cocoapods是不是也类似这种模式?通过pod统一管理所有的三方库,然后项目持有Pod这个Target就可以使用所有的三方库了。

组件化之前的项目依赖关系
组件化之后的项目依赖关系

当然这种模式也有缺点,太过于集中、随着组件的增加,这个中间件会越来越臃肿,最后变成中间件自身难以维护的情况。不过iOS项目中很少出现非常庞大的架构,一般来说不会造成瓶颈。另外,在这种组件化的中间件中,有一个非常重要的特性,那就是必须实现组件对中间件的单向依赖。原因引用casatwy大神的一句话:

中间件对组件产生了依赖的话,其他模块也需要耦合中间层才能发起调用。这样还是存在之前的相互耦合的问题,而且本质上比之前更麻烦了。

只有单向依赖的组件化之后的项目依赖关系

对于中间件的设计方案,目前国内讨论比较火热的就两种。一是蘑菇街limboy大神的URLRoute+Procotol,另一种则是casatwy大神的Target-Action。我对这两种方案的归纳如下:

相同点:

  1. 这两种中间件方案都实现了组件对中间件单向依赖
  2. 结构基本一致,都将业务分成了调用方中间件服务方

不同点:

服务方响应调用方的实现方式不同

URLRoute+Procotol

  1. 需要注册组件,通过注册组件使得服务方可以被中间件发现
  2. 调用方通过URL调用服务方页面,URL和服务方页面的关系通过路由表映射,路由表需要人工维护(硬编码),使用持续集成环境简化操作
  3. 调用方通过Procotol调用非页面类服务组件,可以传递复杂对象

Target-Action

  1. 不需要注册组件,通过runtime+约定命名规范(硬编码)的方式查找服务方
  2. 区分本地调用和远程调用,本地调用通过Target-Action获取服务,同时为远程调用提供服务,远程调用的规则需约定好
  3. 参数传递统一用Dictionary实现,获取Dictionary内所需要的内容需要通过文档或者其他说明
  4. 通过category的形式拆分中间件的代码,使其分属不同组件

这两种方式谁优谁劣不好直接做判断,综合来看URLRoute+Procotol更适用于页面跳转这种业务较多的场景,同时配合持续集成环境,动态性更好(通过文本信息配置代替代码),缺点是调用关系复杂,中间层比较庞大,需要配合持续集成环境才能有比较好的使用体验;Target-Action则更适合业务较杂的情况,核心代码很少,调用关系相对简单,缺点是硬编码场景较多,不过硬编码基本都在中间件里。

由于URLRoute+Procotol更适合有完整系统支持的场景,因此我们采用了Target-Action。该模式的特点也被充分验证:中间层代码量少、对项目的侵入性低,因此很快我们就完整组件化的工作了。

下一篇将介绍我们组件化的具体过程,以及需要做的准备工作。

参考文章

念纪-模块化与解耦

limboy-蘑菇街组件化之路

limboy-蘑菇街组件化之路-续

Casa Taloyum-iOS应用架构谈-组件化方案

Skyline75489-浅析iOS应用组件化设计

philon-iOS组件化思路-大神博客研读和思考

philon-iOS组件化实践方案-LDBusMediator练就

bang-iOS组件化方案探索

携程移动端架构演进与优化之路

iOS-组件化架构漫谈

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容