为什么要组件化
统一编码规范
业务模块组件化
开发环境动态切换
模块可复用
UI模块双向依赖明显
怎么传递参数
采用字典。会有缺点
妥协方案:公共的model也建立pod库
组件化主要有三种方案:
1. URLRouter。缺点:需要常驻字典维持这个列表。oc一般在load方法来注册这些url-block;swift没有load方法。需要常驻内存,并且影响启动速度,RouterManager需要import所有需要的vc头文件。
2. Target-Action。代表是CTMediator。 缺点: 采用了runtime,swift自身是不支持rumtime的,以及少量的硬编码。
3. Protocal-Class。 代表是BeeHive。总体来说还是最专业的方案。缺点是对代码侵入性高;采用一个全局字典的变量,key为Protocal的字符串,value是class;需要在app启动(swift工程)添加注册的方法。缺点同URLRouter,优点在于没有硬编码。
技术要点:
1. 资源文件比如图片。有的图片是多个模块公用,有的图片只在一个模块使用,如何使图片更好的支持组件化?
2. 有些model是在单个模块使用,有的是多个模块使用,如何规划?
3. 对AppDelegate瘦身,需要对事件进行封装。
组件化开发过程中缺点:
Module内对修改要clean build后生效,太耗时间。感觉项目在相对稳定后可以引入组建化。
组件化中疑难点:
1. swift 调用 oc的库:新建一个swift类对oc的接口进行封装。
2. oc调用swift的。
3. 不同组件中的资源重复。
最好是分配给各个组件,会有一定的浪费; 然后可以脚本去掉重复的图片。或者是iconFont。
4. oc和swift库混编
5. 动态切换环境:如首页双击四次,弹框,选择后,重启app;
组件分层:
最底层:基础组件: 持久化,导航栏,log日志,网络,第三方库sdk,文件服务,分类
中间: 功能组件: 地图服务,数据管理,城市管理,广告管理
上层: 业务模块组件: 业务模块解耦
建议:
少用宏
不出现common组件
使用storyboard:界面元素越多的情况下优势越明显。