iOS组件化简介
去年就开始做组件化,没啥活,就自己找的活儿,一套视频看下来,理论知识有了,但是对着自家的项目,却还是无从下手,所以搁置到现在,下定决心两个月内要把自家项目组件化好。
本文主要讲述基于cocoapods来做组件化的方案
首先针对iOS组件化,我们先针对5W+1H的问题进行分析。
什么是组件化(What)?
组件化就是将APP拆分成各个组件(或者说模块也行),同时解除这些模块之间的耦合,然后通过主工程将项目所需要的组件组合起来。这样组件化过后的项目就变成了很多小模块,如果新项目中有类似的需求,直接将模块引入稍作修改就能使用了。
这种设计是不是很像引入三方库做快速开发?其实制作组件的过程就相当于做二方库。因此常见的组件化方案大多都是使用cocoapods做依赖管理。
为什么要做组件化(Why)?
- 组件可独立运行,提高的代码的复用性和可测性,组件化的颗粒度越细,可复用度就越高。
- 当组件库的数量足够庞大时,项目只需要组合组件即可完成大部分的开发工作(当然这个时候要解决怎么把组件有序的管理起来的问题)。
- 组件化后项目的代码结构更加清晰,追踪问题、修复bug、增加需求更方便。
- 不同业务组件相互独立,明确团队开发的业务边界,增加团队协作效率。
- 减缓代码腐化过程,加快编译时间,模块分权管理,代码规范,bug 减少,独立开发、调试、自动化编译,集成等等工作。
更近一步的讲,我们需要一套自动化的系统来帮助我们完成所有的组件管理工作,让开发人员能更专注于代码层面,无需关心应用配置,渠道,以及如何集成等问题。
组件化的缺点:
增加开发人员的学习成本
增加了代码的冗余,组件化颗粒度越细,中间代码越多
增加了项目的复杂度,复杂度越高越容易出问题
应该在哪里做组件化(Where)?
一般组件化后的小组件源码放在github上(现在github私有库已经免费了,但是有限制,3人/项目的人数限制、私有项目无法使用保护分支、持续集成等高级功能),所以还是建议放在gitlab上,或者码云也可以。
什么时候该做组件化(When)?
在一个项目越来越大,开发人员越来越多的情况下(建议团队成员超过10人的时候),出现了以下情况,需要做组件化:
- 业务模块间划分不清晰,模块之间耦合度很大,非常难维护。
- 所有模块代码都编写在一个项目中,测试某个模块或功能,需要编译运行整个项目。
由谁来做组件化(Who)?
组件化的第一步需要代码解耦,第二步实现Cocoapods的管理。所以将一个项目组件化需要该成员具备以下技能:
- 具备良好的API设计能力,即解耦和封装的能力。
- 熟练使用Cocoapods,会cocoapods本地私有库和远程私有库的使用 Using CocoaPods
- 会常用的git命令 Git教程
- 熟练制作静态库(组件只有制作成静态库,才可以提高项目的编译速度)
- 对项目业务很熟悉
如何做组件化(How)?
组件化原则:
1. 越底层的模块,应该越稳定,越抽象,越具有高复用度。
2. 不要让稳定的模块依赖不稳定的模块, 减少依赖。
3. 提升模块的复用度,自完备性有时候要优于代码复用。
4. 每个模块只做好一件事情,不要让Common出现。
5. 按照你架构的层数从上到下依赖,不要出现下层模块依赖上层模块的现象。
模块解耦并不是说你把工程的代码拆分成 50 个 pod 或者framework就算完事了,要实现模块之间真正的解耦才算真正的模块化,否则如果模块之间还都是互相调用代码,循环依赖,那么和原本放文件夹里面没啥两样。
模块解耦的目标就是, 在基于模块设计原则上, 让模块之间没有循环依赖, 让业务模块之间解除依赖。
模块可分为基础模块和业务模块,基础模块不依赖于业务模块,业务模块之间通过中间件进行沟通。
基础模块:最稳定的代码可以作为基础模块,包括稳定的三方库,底层网络通信模块,常用的 category 等等。这些代码不会频繁改动,可以作为基础模块。
业务模块:根据业务划分,业务跟业务之间的沟通用中间件来,模块之间的通信可以参考
casa的iOS应用架构谈 组件化方案
蘑菇街 App 的组件化之路
参考文章:ios组件化/模块化