iOS组件化（一）-为何做组件化？

本文为博主原创文章,未经博主允许不得转载

我们在做组件化之前，必须要弄清楚，我们为什么要组件化，如果没有明显的优点，或者解决我们的所需，我们没有必要组件化。在app迭代如此快速的情况下，耗费时间精力去做这么一件事情到底值不值得？

一、组件化所解决的问题

1.代码复用

编程发展至今，面向对象语言的技术点发展，大多解决的是代码可复用问题，不管是封装、继承、多态，都是解决代码重用的不同解决方案，而组件化也是为了这个目的，将一个业务、一个功能、甚至一段代码组件化，以达到复用的目的。

2.功能解耦合

功能解耦也可以说是贯穿整个编程发展的任务，为了代码复用的精准，自然也就要求其组件化出去的代码能够解耦，不依赖其他的代码，否则像葡萄似的一串串的，有用的没用的都需要拿走，那代码复用的的初衷就变得很迷了。

3.源码管理

伴随着app的发展，app越来越复杂，开发人员也自然的越来越多，一般的开发人员分为不同等级，水平自然参差不齐，那么对于源码的管理则尤为重要，但是随着人员的增多，git代码上传、merge将会是一个巨大的工作，就算是经验丰富的工程师也未免出错，耗时严重、错误频出将会是一个大团队所经常面对的问题

二、怎么做组件化

基于上述问题，我们的解决方案自然也是呼之欲出：
1. 将可重用的代码提取
2. 将提取的代码去耦合
3. 单独管理提取的代码
4. 为提取的代码添加接入工程的方法

做完上述工作，我们可以说，这段提取的代码已经组件化了。
PS：当然业务组件化的任务不同，更偏向的是业务的解耦而非代码重用。

三、工程组件化

根据工程代码的不同分工，我们分为几个级别的代码，并根据这几个级别的代码分出轻重缓急，然后去相应的做组件化工作。

1. 基础功能

这里的基础功能对应iOS来说，可以分为几类：
（1）宏定义工具
（2）类目功能扩展
（3）工具类
（4）UI类
当然类是死的，对于APP来说，其他的认为是基础的都可以放在这里，但是建议遵循一个原则，基础功能不管放到任何一个app里面都是可以的使用的，而且尽量少的增加该app的负担，比如不常用的库或功能等，基础应为尽量小。

2. 公共业务功能

这里面的东西主要是自己app的公共业务，比如埋点、分享、通讯录等可能各个业务线都需要用的功能，且自己的app有些定制化的功能，这部分根据app规模可能会很大，

3. 独立业务功能

这里面主要就是各个业务的功能，根据业务数量可能会有多个业务组件，另外像登录、注册等功能如果自己的app不适合放到公共业务里面，也可以当做平台业务由平台提供功能。

上述三个分类也相互有了彼此的依赖：基础功能->公共业务->独立业务

四、组件化准备工作

上述分类也明确的给出了一个组件化的进程方案，也就是先做基础功能的组件化，再在此基础上抽离公共业务，最后进行独立业务的组件化。

但是我们开始这些工作前，我们还需要一些技术准备工作，在（二）中，我将讲述准备工作都有什么，并如何去做。