1.组件化Pod组件化目的有2个1梳理代码模块关系逻辑更加清晰结构更加合理降低耦合方便后续功能开发和维护。2提高开发效率之前所有代码全在一个工程中开发一个简单的功能都要编译整个项目Pod拆分后在功能开发分支只引入涉及到的Pod库。经常出现工程文件冲突需要手动检查工程文件来处理冲突Pod拆分后极大的减少了工程文件的冲突。整体分成3层架构项目中业务代码按照功能模块进行拆分比如PhotoBusinessArticleBusinessVideoBusinessUserCenterBusiness这些模块作为业务层业务库之间相互独立互不引用位于最高层。抽取公共部分作为中间层比如日志库、CacheManager、ToastManagerSkinManagerUserManager抽取最基础的库作为基础层比如AFNetworking、SDWebImage、FMDB、SNBasicKit这些。上层依赖下层同层之间互不依赖。2.统一路由建设统一路由建设是伴随着组件化一起开发的因为组件化完成后业务之间互不依赖页面如何跳转服务如何调用统一路由应运而生。1大部分的功能iOS端、安卓端和H5前端都实现了为了保持三端统一。2而且App无论是安卓端还是iOS端有着很多被H5呼起的场景以及Hybrid跳转端内页面的需求使用统一路由就能很好的处理这些场景。参考了业界方案CTMediator、BeeHive的实现CTMediator缺点1、直接硬编码方式保存类名和方法名降低了可读性也降低了代码的编写效率。而且还需要新建一个Pod存放一个CTMediator的类别在里面进行硬编码并调用CTMediator里面的方法。2、由于是在运行时才确定的调用方法调用方式由 [obj method] 变成 [obj performSelector:‘‘method’’]。这样的话在调用时就缺少类型检查编译期无法发现问题。综合来说CTMediator的优点是无需注册代码量较少性能较好规范性约束和可读性一般。BeeHive需要注册的过程能提前发现问题性能和代码量一般可读性较好。我在任务中具体负责路由的注册和模型的自动赋值runtime以及参数别名处理。路由格式:sinanews://sina.cn/audio/book/player.pg?dataidxmly:483299554326892544以sinanews开头这个是scheme后面跟着pathaudio表示是音频业务而audio/book/player.pg表示了这个是听书的播放器这个是唯一的是前者的诸多业务之一后面的dataid则是业务方需要的参数。配合路由管理后台负责所有路由的注册、参数、审核、生成地址。处理路由的逻辑由connector、model和pathplayer.pg组成其中model是用来保存路由中的参数并传递给具体的业务方。通常情况下一个业务模块Pod中不止一个ViewController所以connector来根据path来区分具体业务的ViewController。connector都是遵守ConnectorProtocol里面定义了处理路由的方法。在App启动后进行调用各个业务的Model进行注册各个业务的Module定义在.m文件中通过__attribute((used, section(DATA,“#sectname” )))指令编译时写入到Mach-O文件中再定义一个__attribute((constructor))的方法这个方法会在在dyld加载App时当Load方法执行完毕后开始执行contructor时执行。这个方法里面会收集所有的__DATA段定义的Module。等App完成SDK的初始化后调用各个Module进行setup。setup里面的流程1将[connector class]和connectorProtocol进行绑定注册到BeeHive中。2将[model class]和modelProtocol进行绑定注册到BeeHive中。3将connectorProtocol和modelProtocol和path进行绑定注册到路由管理器中。这样路由管理器在处理路由时解析出path和参数根据path能找到modelProtocol在BeeHive中找到[model class]并实例化保存路由中的参数。connector同理最后由connector处理具体的业务逻辑。一般的业务通信和跳转都可以用统一路由来完成但还有一个特殊情况需要传递model这种情况下需要定义协议放在公共Pod中去这算是一个不太优雅的解决方案。参考Category 特性在 iOS 组件化中的应用与管控从预编译的角度理解Swift与Objective-C及混编机制Swift 与 Objective-C 混编时我们是如何将编译时间优化了 35%
