ios组件化漫谈

   近期随着项目需求越来越多，着手对项目进行业务划分，思考如何提高团队开发效率，就想到了组件化这个话题，这里来分享一下自己的梳理和思考。

首先组件化的好处，我就不用多说了，直接进入主题；回到组件化的技术方案，最早上Limboy分享的一遍文章蘑菇街组件化（MGJRouter），接着Casa提出了不同的意见（CTMediator），后来Limboy在Casa的意见上做了进一步优化，最后Bang在前面几位大佬的基础上做了清晰的梳理总结。通读之后，获益很多，组件化的方案以及思路变得更清晰。

   因为我们之前用的是蘑菇街路由，但是看了Casa的文章后觉得很有道理。因为注册URL的目的其实就是一个服务发现的过程，在iOS领域中，服务发现的方式是不需要通过主动注册的，使用runtime就可以。另外注册部分的代码的维护也需要成本，服务发现的过程可以用runtime来实现，并且蘑菇街的实现需要我们写很多硬编码，你们都懂。还有就是蘑菇街路由没有区分本地调用和远程调用，其实远程调用应该为本地调用的子集，即远程调用最终都会走本地调用的方法逻辑，最后蘑菇街设计方案考虑到这些问题，又补充了Protocol-class的方案，这种方案解决了URL方案中无法传递非常规参数的问题，似的组件的调用更为方便，但是它依然没有解决组件依赖中间件的问题，内存中维护映射表的问题，组件的分散调用问题。

  然后我们再看CTMediator,Casa的方案是通过runtime，最终走target-action的形式来实现服务的，通过给组件包装一层wrapper来给外界提供服务，然后调用者通过依赖中间件来使用服务；所谓的中间件就是通过runtime来调用组件的服务，该组件最核心的地方了具体过程就是给组件封装一层target对象来对外提供服务，不会对原来的组件造成入侵；然后通过实现中间件的category来提供给调用者，这样使用只需要依赖中间件，而组件不需要依赖中间件。但是缺点也暴露了出来，同样写了很多hardcode，在中间件的分类里有很多硬编码，case的考虑是去model化，所以选择用分类。这种方案虽然解决了组件间传递model的依赖问题，但是把整个model层组件化后暴露给所有组件，容易造成数据泄露，付出的代价有点大。

经过分析感觉将二者作为组件化的方案都不是很完美，后来就查阅资料，看到了阿里的BeeHive框架，可以使优化一下前2种方案吧，首先简单的向大家介绍一下这个框架吧。

BeeHive是阿里巴巴公司开源的一个iOS框架，这个框架是App模块化编程的框架一种实现方案，吸收了Spring框架Service的理念来实现模块间的API解耦。

BeeHive这个名字灵感来源于蜂窝。蜂窝是世界上高度模块化的工程结构，六边形的设计能带来无限扩张的可能。所以就用了这个名字作为开源项目的名字。

  看了介绍相信设计这个框架的大佬一定很钟爱Java的设计模式，当然了，这里咱们只简单介绍一下BeeHive的注册功能实现原理；主要运用的知识点就是__attribute，它其实是一个编译属性，用于向编译器描述特殊的标识、错误检查或高级优化。它是GNU C特色之一，系统中有许多地方使用到。 __attribute__可以设置函数属性（Function Attribute ）、变量属性（Variable Attribute ）和类型属性（Type Attribute)等

 通过__attribute((used,section("segmentname,sectionname")))来注册服务， 通过__attribute__（（constructor））方法，在App启动之前来注册这些服务，相比之前的组件化方案，完美的解决了hardcode的问题；

  总之，组件化是项目架构层面的技术，不是所有的项目都适合组件化，组件化一般针对大中型项目，并且是多人开发，如果开发人员很少，项目业务不是很复杂，考虑到成本和效益就不太适合做组件化。另外组件化需要考虑到团队的情况，根据自己团队的情况选择最合适的技术方案才是王道