iOS大型项目解耦方案有难度？BeeHive设计优化来帮助.docxVIP

iOS大型项目解耦方案有难度？BeeHive设计优化来帮助本文章来自于阿里云云栖社区摘要：?在2017年在线技术峰会——阿里开源项目最佳实践上，来自天猫的戴鹏带来了BeeHive关于iOS大型项目解耦方案的分享。他从多人开发的问题介绍了业界的三种模块方案，将传统Init与BeeHive Module进行了比较，对BeeHive的架构进行了分析，并对Module Manager和Module的实现进行了详细介绍。在2017年在线技术峰会——阿里开源项目最佳实践上，来自天猫的戴鹏带来了BeeHive关于iOS大型项目解耦方案的分享。他从多人开发的问题介绍了业界的三种模块方案，将传统Init与BeeHive?Module进行了比较，对BeeHive的架构进行了分析，并对Module Manager和Module的实现进行了详细介绍。?以下内容根据直播视频整理而成。?视频回顾：点击进入（原文链接：/edu/lesson/play/639?spm=5176.100239.blogcont71685.13.zmAply）Pdf下载：点击进入?在iOS大型项目中如何抽丝剥茧把对应的需要优化的地方进行优化、多人协作开发中如何避免冲突？本文为你详细解答。背景?2015年上半年，开始参与天猫iPad开发，负责的主要内容包括我的天猫以及首页一些程序框架性的东西。2015年下半年之后，开始参与天猫iPhone开发，主要负责直播项目。多人开发模式下遇到的问题在多人开发模式中涉及到了沟通交流以及互相合作的问题。在代码依赖层面，功能调用比较繁琐，功能之间互相依赖，底层功能反向依赖上层业务。在协同开发层面，合并冲突，费时费力，合作开发、接口不稳定，频繁更新接口。在量化分析层面，代码耦合难以分析性能、难以做单元测试。在性能优化层面，每个库侵入App生命周期，难区分库初始化必要性，导致启动卡顿。恶劣的开发环境像面条式的逻辑文化。老练的开发人员也会畏手畏脚，因为整个迭代周期流程中包含了开发过程以及修bug过程，如果在一个耦合严重的情况下做这些操作的话，可能造成更多bug的引入。整个工程如果没有做到合理的分类的话，其实业务和基础逻辑就会交织缠绕在一起，可维护性降低。多人开发的小目标在开发过程中，为了支持业务的快速发展，并没有认真思考整个应用该具备哪些特点。而所有的应用必须具备以下三个特点：维护性，支持多人持续开发；可用性，有良好性能及功能完备；可分析性，支持优化、用户行为分析。业界的模块方案?URL?Router可以参考开源界比较成熟的方案JR?Route，把每一个模块以一个URL的形式作为独立存在的界限范围。URL?Router需要在内存中维护一张URL表作为key来实现对应的push或者唤起对应的模块。它在传递参数过程中不能传递类似于对象这样的数据，只能传递String这类的数据。Target?Action也是基于苹果原生的Runtime的优势，其优势很大在于可以做到无需加载内存，并且在调用中没有相关的依赖。在调用中的缺陷在于只有在运行池中才可以知道对应的组件是否存在，若不存在会造成对应的Crash。Protocol?class是利用原始class以及对应的Protocol用到的Service?interface去进行实现以及接口的分离，让大部分的业务方只需要基于Protocol的interface进行调用。其过程中会涉及到内存占用的问题。BeeHive实践之路?BeeHive相当于一个蜂巢，我们希望每个模块都像六角形的蜂窝可以独立存在，可以同时对外有很好的接口。一个App的层次关系?iOS分层有几种层次：核心的Core?OS层、其上的Core?Services和Media?Layer、Cocoa?Touch对于开发者人员来说是比较黑盒的东西。而一个个独立的App也类似于插件的形式插在系统当中。最上层的应用生命周期是管控平台。传统Init与BeeHiveModule?传统的Init有三个层次，此过程中Init没法做到很好的区分，并且其中有些比较耗时的操作是没有必要的。对应的BeeHive?Module是把一个个module进行了细粒度的拆分，通过Module?Manager的形式将整个应用的生命周期进行了发放，每个module在自己的回调过程中只需要遵循module?protocol就可以感应到整个应用的生命周期，在不同场景下做对应的程序响应。Module Manager?Module Manager除了拆分应用的生命周期还扩充了生命周期。从上下图对比当中我们可以知道，BeeHive中加了三块流程，ModuleSetup、ModuleInit、ModuleSplash，这三个流程对于大部分模块的初始化来说已经足够用了。在这个过程中，还支持了自定义的ModuleE