背景
随着公司业务的不断扩展,我们需要做的APP也越来越多,团队从几个人上升到了十几个人,维护五六个app,各端架构和框架使用的不一致,无形中增加了维护的成本,如果一个人一直负责一个项目还好,但这是不可能的,总会遇到江湖救急,哪端重要,资源就会偏向哪端,通过大家的讨论,准备从网络框架入手,做一个统一的示范,找到适合我们团队的统一方式。
封装的意义
我的观点,封装的核心意义是代码复用,减少样板代码,隐藏实现细节,让上层只关注业务逻辑,完善产品而不是想着完善技术。还有就是减少新成员的试错成本,有一个好且稳定的框架,可以让其稳定输出,无形中提高代码质量。封装可以做到一种特定领域的解决方案,更专注一种领域模型,可以做到极致。
封装的原则
首要原则要保证扩展性:为什么这么讲,举个例子,比如你在okhttp的基础上,加了很多便捷的实现,各个团队都做了集成,突然有一天一个端的朋友说,我要加一个功能,需要断点续传,而你没有留入口提供扩展,你说等两天,开发完了再通知你,你有没有发现一个矛盾点,如果一个人来找你需要等两天,如果团队一百人呢,很可怕的,所有你不光要封装起来,还要做好扩展的准备,哪怕不来找你,也可以通过扩展实现,再说了,如果这些功能都加框架上,有些团队说我们不需要这个功能,为啥要加给我,还要占我们包的大小,毕竟C端产品包体大小又是一个很高的衡量标准。
接口原则:在保证框架不被改变原有功能的情况下,提供接口替换功能,这就是所谓的依赖接口,而不依赖实现。这里强调不是所有功能都要暴露出来,而是在不影响框架本身行为的情况下。
不要为上层做过多的假设:这是我们讨论这么多次,对我感触最深的一点,这是一种吃力不讨好的做法,把应用需要做的事情,全揽过来自己做,但又不能满足应用的所有场景,图个啥?倒不如给个接口,你自己来吧,我有默认实现,想用就用,不用就自己实现对吧。
轻量级:说白了就是说,一定不要把框架封装的太重,我只需要一棵树,你给我一片森林,保持轻量,按需所取。
弱侵入性:就是减少对你的依赖,能在一处依赖就ok的时候,绝不能说,我需要用的时候就要对你有一次依赖,如果我想换掉怎么办,疯了吧,改那么多地方,在这一点大家都做过一件事就是,自己实现一个类专门去调你的,比如日志的包装类,为啥要有,不就是为了后期换了日志框架轻而易举,改一个类OK了。
封装实践
经历多次的讨论,我们定出了以下方案,架构图:
![](https://i-blog.csdnimg.cn/blog_migrate/8d857324290095446c59aacfc9cc281b.png)
最上层是我们的业务APP,中间层可有可无,有是为什么?为了兼容原有的业务代码,让其以最小的改动,将Retrofit和okhttp的依赖直接下沉到框架层的内部。降低侵入性。
JLRetrofit是对Retrofit的扩展,我们更倾向去重写一个,因为我们用的其实也就几个依赖注入,比如@POST。这样也更便于跟okhttp的包装结合。
okhttp封装功能规划:
![](https://i-blog.csdnimg.cn/blog_migrate/197aaffdf6a9e70592ce242f2b93a1db.png)
功能就不一一介绍了,一看就明白。
总结
再统一的道路上坎坎坷坷,有很多的技术观点的碰撞,但我们每个人都在成长。