关于B端app的组件化

组件化已经不是什么新名词了,大公司好多大型app基本都要经历这个阶段,不同的是我这次是对B端app做了组件化开发的拆分。可能有些人会不明白,B端app为什么会需要组件化。大部分的B端app也确实不需要去组件化,但是我们的app却不同。我们的app集成了有好几条业务线,随着业务线越来越多,每条业务线功能越来越重,我们的app也越来越大。如果不组件化的话我们将面临以下几个问题!

1.虽然每条业务线的代码是分不同文件夹管理,但是一些代码还是不免会写到一起。比如扫码,刚开始可能只有一个业务线需要扫码核销优惠券,所以也就没有去抽出共用的。后面又有一个业务线也需要扫码功能,这时候也不复杂功能都一样,就传入个类型区别下也就可以共用了。但是后来就单单扫描二维码功能就多了好几种类型,有的扫出来的直接是优惠券码,有的扫描出来的是个url,需要截取URL的参数才能进行核销。有的一次核销就结束,有的可以多次核销。这时候有做了些优化,去拆模块,把公共的拆出来,但是毕竟都是一个项目代码都是在一块的。有些修改可能写在基类里面就一行代码就能够解决,但是也在业务类里面去写可能要多写好几行代码才能实现。这时候就无法保证开发人员不会把业务代码写到基类。导致业务代码下沉,没注意的话可能还会影响其他业务线相关功能。所以我必须把基础类抽离出去,当作一个单独的组件,所有业务线都可以依赖它,但不能随意修改。我把基础组件单独的一个git管理,控制写入权限,如果需要修改基础组件必须要有充分的理由。最重要的还是让开发人员养成习惯。

2.每个版本产品可能会同时进行多条业务线功能迭代,这样每次上线都需要协调多个服务端同时上线,只要有一方临时出了问题不能上线,就要等。等它可以上了,另外一条业务线又有别的事情。每次上线发包都是很麻烦的说。所以我们决定按业务线去拆分组件,每个业务线的功能都是一个单独的组件,同样有自己的代码库管理,有自己的代码版本。这样如果某条业务线上不了,我们只要把这条业务线的代码回滚到上个版本就可以。其他业务线正常打包上线。

3.业务线之间的代码不是全部解耦的,可能这次修改了这条业务线的某个功能,可能影响到另外一条业务线的功能,但是测试不知道这2个业务有联系或者忘记了去测试那条业务线的功能,导致出现线上问题。

总的来说就是app越来越大组件化就是必然趋势,不管是c端app还是b端app都是一样需要的。唯一不同的是c端组件化考虑的比较多的是组件动态替换,什么通过路由注册组件切换组件等。而b端不看重这些,b端需要解决的是我们遇到的问题,业务组件不耦合,每个业务组件有自己的代码版本管理。所以这就导致了组件拆分粒度上有很大的区别,我不会把一个详情页、一个首页拆成一个组件,也不需要通过修改配置修改某个页面的路由,来改变进入下个页面/组件路径。

那么在实现技术上是否有区别呢?

我觉得应该是没有啥区别的,每个组件也都是一个个静态库,你可以通过cocospod的私有库来管理,也可以通过.xcworkspace等别的方式来管理你的组件。这些都只是方式不一样应用,原理都是一样的。组件化需要踩的坑我想应该也是差不多的吧!这里简单说下我们组件化踩过的坑越到的难点。

1.全局变量,这个比较头疼,由于是同一个项目所以用的时候就没那么注意。拆的时候只能去分析,需要用到的时候传入到组件。把你组件里面用到的全局变量都改成你需要的入参。

2.宏定义,接口宏都是写在一起的,一个文件。这时候需要去选出你这个组件需要的比把它们移走。

3.用户信息和权限,这个可能是b端app特有的,可以说所有业务线都需要根据权限来判断是否有权限操作某个功能。在更新账号信息或权限变更的时候需要通知到区别业务线(组件)。之前用户信息和权限是全局变量,所以不需要去通知变更。现在不一样了,每个组件需要自己去维护用户信息和权限,但又必须和整个项目保存同步。我把登录拆成一个组件,用户信息和权限是来源于登录组件,但是其他业务组件又需要这些信息,业务组件之前要解藕不能有依赖,也就是说,其他业务组件不能直接依赖登录组件。所以只能通过主工程来协调。

4.我的设置模块,一个app往往就只有一个我的界面,所有业务线的设置都在一起,而这些设置又会直接影响业务线功能。如微客服的设置,我可以设置是否显示消息详情,也可以开启夜间防打扰模式等。这个明显要调用到具体业务线的方法。可以说我的模块和各个业务线都有关联。乍看好像拆不了了,难到我们的组件化之路到这就结束了?最后做了个大胆的决定,把设置页面拆开,属于自己业务线的设置自己移走。对一个页面被拆到不同组件里面去了!我的模块里面的设置页面没有逻辑了,有的只是页面的组装。为了业务组件的解藕,我不能在设置模块引入其它模块的类,只能通过中间件来实现。这和c端的路由有点像,只是配置路径没有放到服务端下发。

5.关于AppDelegate解藕,有些组件的某些数据方法需要在AppDelegate中初值化,这就又让他们耦合在一起了,所以解藕是必须的。具体的技术方案可以看这里

6.图片等资源文件,这个是组件化必须要面对的问题,但是好多c端文章都没提到过,我不知道他们是什么处理的。这里说说我的做法,大家都知道每个组件其实就是一个个静态库(如果不能理解可以看我上一篇文章)。静态库要带资源就必须打包成.bundle文件,而在引用的时候路径就会不一样。这意味着你所有用到的资源文件的地方都需要改代码。这个工作量太大了,而且容易出错。

有没有啥更好的方法吗?

想了好久最后cocospod给我灵感,在编译的时候通过脚本合并资源文件。解压.app文件可以看到所有资源都是放一起的,我们只需要把静态库下的资源复制到.app下就可以了。

有更好的方法欢迎指正交流!

其实对这个图片方法我不是很满意,这里说个思路,有知道做法的欢迎留言。现在多app都用了Assets.xcassets来管理图片资源,这个编译后的图片是不可见的加密过的文件,更加安全。但是组件里面的资源我也想用Assets.xcassets来管理图片,但是编译好的Assets.xcassets无法合并。(简单来说就是如何把Assets.xcassets用到静态库

于是破解了qq,微信等大型app看他们的图片也是没有用Assets.xcassets来管理。不知道是不是和我遇到一样的问题……

有方案的欢迎留言

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值