1、整体框架：
SNBeeHive + SNRoute方式
2、具体协议约定：
serviceProrocol + DTProtocol + connectorRoute
serviceProrocol：模块对外提供的供外部调用接口协议列表
DTProtocol：模块对外提供的供外部传递model数据类型给模块内部（用于模块间传值）。
connectorRoute：用于模块间跳转。（模块内部需要实现该协议）
注：SNBeeHive 同SNRoute在模块间跳转上有功能上的重合，规定：模块间跳转统一使用SNRoute。
3、具体模块开发：
每个模块开发过程中，如果需要引用公共基础库，方式如下：
在每个模块的podspec文件中：
1、指定该模块依赖的基础库
s.dependency 'SNLib'
s.dependency 'AMapLocation', '2.3.0'
s.dependency 'AMapSearch', '5.1.0'
2、在预编译文件.pch中，指定要用到的头文件，而不是在模块分散的类中导入基础类库的头文件。
s.prefix_header_contents = <<-EOS
#ifdef __OBJC__
#import <SNLib/NSDictionary+SNArticle.h> //用到的基础库中相关文件
#import <SNLib/EXTScope.h>
#endif
EOS
注：仅限于具体模块需要使用基础类库中的类时，如果各业务模块间有调用需要，使用BeeHIve方式，禁止在具体模块中直接导入其他模块的头文件。否则组件化的作用就没了
4、模块开发注意事项：
目前每个模块是基于单独的pod方式来进行，当模块开发过程中需要用到.a静态库时，可能会遇到问题：如果.a静态库命名不规范(例如：SWMXXX.a)在编译链接时，会报错：ld: library not found for -lSWMGeocoder
解决方式：
将SWMXXX.a 修改为标准静态库格式 libSWMXXX.a
编译器在编译时会依据libXX来查找相应的类库。
5、模块内部结构划分
Model + ViewModel + View/Controller + Manager + API + Connector
相关目录结构说明：
Model：数据模型，JSON解析置于该层处理。（JSON解析库：YYModel）
ViewModel：业务逻辑 + 数据存储 + 网络请求
Manager: 通用逻辑处理 (待补充)
API:模块内部网络请求接口封装集中归置于该处，并对返回数据做基本处理。
Connector：实现路由跳转协议（同新闻客户端）
