组件化(一)方案

iOS 底层原理 文章汇总

本文主要讲解组件化的两种方案

组件化

组件化其实就是将模块单独抽离、分层,并指定模块间的通讯方式,从而实现解耦的一种方式,主要运用与团队开发

为什么需要组件化?

主要有以下四个原因

  • 1、模块间解耦
  • 2、模块重用
  • 3、提高团队协作开发效率
  • 4、单元测试

当项目因为各种需求,越来越来时,如果此时的各个模块之间是互相调用,即你中有我,我中有你这种情况时,会造成高耦合的情况。一旦我们需要对某一块代码进行修改时,就会牵一发而动全身,导致项目难以维护

其问题主要体现在以下几个方面:

  • 1、修改某个功能时,同时需要修改其他模块的代码,因为在其他模块中有该模块的引用。可以理解为高耦合导致代码修改困难
  • 2、模块对外接口不明确,甚至暴露了本不该暴露的私有接口,修改时费时费力。可以理解为接口不固定导致的接口混乱
  • 3、高耦合代码产生的后果就是会影响团队其他成员的开发,产生代码冲突
  • 4、当模块需要重用到其他项目时,难以单独抽离
  • 5、模块间耦合的忌口导致接口和依赖关系混乱,无法进行单元测试

所以为了解决以上问题,我们需要采用更规范的方式来降低模块间的耦合度,这就是组件化,也可以理解为模块化

但是,这里还需要说明一点,因为组件化也是需要一定成本的,需要花费时间设计接口、分离代码等,所以并不是所有的项目都需要组件化。如果你的项目有以下这些特征就不需要组件化

  • 1、项目较小,模块间交互简单,耦合少
  • 2、项目没有被多个外部模块引用,只是一个单独的小模块
  • 3、模块不需要重用,代码也很少被修改
  • 4、团队规模很小
  • 5、不需要编写单元测试

如果你的有以下特性,说明你就必须要考虑进行组件化了:

  • 1、模块逻辑复杂,多个模块之间频繁互相引用
  • 2、项目规模逐渐变大,修改代码变的越来越困难(这里可以理解为:修改一处代码,需要同时修改其他多个地方)
  • 3、团队人数变多,提交的代码经常和其他成员冲突
  • 4、项目编译耗时较大
  • 5、模块的单元测试经常由于其他模块的修改而失败

组件化方案

组件化方案的8条指标

一个项目经过组件化后如何来评判,主要有以下几个标准

  • 1、模块之间没有耦合,模块内部的修改不会应该其他模块
  • 2、模块可以单独编译
  • 3、模块间数据传递明确
  • 4、模块可以随时被另一个提供了相同功能的模块替换
  • 5、模块对外接口清晰且易维护
  • 6、当模块接口改变时,此模块的外部代码能够被高效重构
  • 7、尽量用最少的修改和代码,让现有的项目实现模块化
  • 8、支持OC和Swift,以及混编

前4条主要用于衡量一个模块是否真正解耦,后4条主要用于衡量在项目中实践中的易用程度

组件化原则
一个项目主要分为3层:业务层通用层以及基础层,在进行组件化时,有以下几点说明

image.png

  • 只能上层对下层依赖,不能下层对上层的依赖,因为下层是对上层的抽象
  • 项目公共代码资源下沉
  • 横向的依赖尽量少有,最好下层至通用模块,或者基础模块

组件化方案
常用的组件化方案主要有两种:

  • 本地组件化:主要是通过在工程中创建library,利用cocoapodsworkspec进行本地管理,不需要将项目上传git,而是直接在本项目中以framework的方法进行调用
  • cocoapods组件化:主要是利用cocoapods来进行模块的远程管理,需要将项目上传git(需要注意:这里的组件化模块分为公有库私有库,对公司而言,一般是私有库)

本地组件化

1、创建主工程

  • 首先创建一个工程

image.png

  • 集成cocopods,进行本地管理:
$ cd 项目目录
$ pod init
复制代码
  • 编辑podfile,并执行pod install

2、创建组件

假设有以下几个模块:

  • 主工程:承载主要的表层业务代码
  • Core:独立存在,应用加密、接口请求等敏感代码
  • Base:基类封装,拓展,基本的数据处理
  • Service:服务层,封装业务工具类,例如网络层服务、持久化服务等
  • Pods:三方依赖

其中,各个模块间的关系如下所示

image.png

下面,我们来进行模块的创建,以Core模块为例:

  • 选择new -> project -> iOS -> Framework,新建一个模块

猜你喜欢

转载自juejin.im/post/7018478920638922783

相关文章