组件化开发之06 拼车组件是如何形成的

一个业务组件在 APP 中可能是一个业务模块,但它同时又是一个工程可以单独的调试和编译

image.png

只要给这个组件相应的依赖组件 它就能运行起来 比如给拼车组件一个 登录注册组件 它就能完成登录注册,给它一个个人中心组件 ,它就能打开个人中心

image.png

笔者建议 当你没有时间做组件时候 一定要将某个模块用到的控制器 模型 views 单独放到一个文件夹下 包括图片资源 ,将来抽取组件时候 单独对这个文件夹拿出来建一个工程 ,需要什么依赖 就引入依赖组件库 , 我们喜欢把所有头文件放到 pch 里边,当我们抽取模块时候 会发现 很多地方报错,所以当你决定使用组件化的时候,写代码时候 某个类用到了那些类 就老老实实导下头文件,将来抽离组件时候 就不会报太多错误 ,因为这些头文件在你使用到时候就已经 #import 过了

拼车组件结构示意图

image.png

2.0.0版本之前拼车只是一个业务组件,3个 APP 同时拥有这个模块,导致用户分不清这3个 APP 有什么区别,2.0.0版本以后 公司需要将顺风车单独做的跟其他2个 APP 不一样,于是在拼车组件基础上 又产生了顺风车组件

image.png

于是关于顺风车新版的代码 全部放在 PinRide 文件夹下边,跟原有的拼车组件没有太多联系,保证了原来拼车模块不受影响.

1个主 APP 多个分 APP 就需要管理好每个 APP 渠道,将来知道用户在那个 APP 上边下单支付,于是在基础组件 YVBase 里边定义了几个宏定义

image.png

然后根据不同的渠道 配置 QQ 微信 支付宝等一些 Appkey AppId

笔者是如何1个 iOS 同时负责3个 APP 开发和维护 并且1次提交3个 APP 审核,毫无疑问还是组件化 将代码复用性提高 基本上改下组件 3个 APP 就能呈现新的代码