IOS组件化开发架构设计
背景
目前公司的APP是一个面向特定业务群体的产品化应用，可针对不同的客户需求和具体业务差异性进行适当的功能调整和裁剪，是一个以核心业务为主,同时具有多样性的产品。产品的开发按照多版本迭代、逐次分发的方式进行，如何能够更好的适用客户的需求,同时降低我们的版本迭代的工作量，是我们在构建系统之处初要重点解决的问题。
目的
引入业务的组件化封装，使得我们可以像搭积木一样动态的构建我们的产品，降低整体的迭代和升级频次，满足客户个性化需求。业务组件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原则，通过一定程度的分离，实现软件重用（Software Reuse）。
组件的定义和划分
- 核心业务组件：是包含在APP内部，随APP发布出去的业务核心。
- 扩展业务组件：是对部分业务单独封装的组件库，由App负责对其进行管理和运行，可以和App进行交互最大程度的数据共享。通过APP加载启动，不能单独运行。
- 扩展业务APP：本身并不属于组件范畴包含完整的业务处理，是一个可单独发布、运行的APP。它做为我们核心业务的补充和扩充产生而来，也可以通过主APP对其进行管理和数据共享。
扩展业务APP可以是来自面向企业分发或者是来源于AppStore的产品，可以通过主业务APP进行下载和启动。
业务组件内部可能还存在大量的技术组件，技术组件之间也可能是一种紧耦合的关系，这些都无关紧要，重要的就是抽象出业务组件和业务组件的服务后，屏蔽掉内部技术组件之间交互的复杂度。
整体架构
arc.png
层次划分是为了进一步的组件化为了能实现最大程度的实现共通化和产品复用度，将基础服务层、基础业务层和基础模块层抽离出来进行组件化，复用到每个子业务系统和模块库中。
组件的管理
组件管理模块的主要职责负责扩展业务组件和扩展业务APP的基本管理，组件的下载、升级、加载、启动和APP的下载、升级、启动。
技术实现
基于IOS 我们的业务组件方案主要有以下 2 种：
- HTML5
- framework
Html5的方式大家都懂不做介绍。
使用framework 的方式来更新可以不依赖第三方库，使用原生的 OC/Swift 来开发，体验更好，开发成本也更低。将APP中的某个模块（比如一个 tab）的内容独立成一个 framework 的形式动态加载在 APP的 main bundle 中。当 app启动后通过组件管理模块从服务器上下载新版本的 framework 并加载即可达到动态更新的目的 。
关于动态的使用的基本事项
-
创建与编译
具体操作参见相关文章 。 -
加载和启动
目录下寻找更新后的framework。利用 OC 的动态特性 NSClassFromString 进行加载通过performSelector 执行加载 framework的类的具体方法 -
资源共享
在storyboard/xib 中可以直接访问图片。
使用代码方式访问的图片不可以放在xcassets 中，需要单独创建专属的Bundle。
总结
基于组件化业务基础平台和传统的业务基础平台主要的差异在于组件化业务基础平台具有更多的灵活性、可扩展性，能够更加方便的进行组件升级和组件维护。特别是对于大型的行业APP来说，易于升级、易于维护，能够灵活的扩展成为评测一个业务基础平台的一个重要标准，随着业务的不断发展，很多行业APP软件包的尺寸已经达到几十M，如何对如此庞大规模的代码进行维护、升级成为软件开发者和运维管理者日益关注的一个课题，代码关系复杂、系统启动慢成为一个大型APP所面临的一个主要矛盾。
组件化业务基础平台主要用于解决简化开发，快速系统维护的问题。业务的组件化，并不是所有的内容全部组件化，有些内容是无法分离出去的。因此首先要确定APP业务的基本定位，业务定位中核心业务保留在APP中可以根据技术特征选择性组建化，保证核心业务和每一个业务组件紧密相关性。
