跨平台开发时,我们为什么不封装http请求的sdk

为什么要封装sdk

相信很多开发团队都同时需要开发各种平台的客户端,有android、ios,甚至是pc版客户端。于是,怎么尽可能复用同一套业务代码,成了很多开发讨论的话题。

比如,开发照片处理软件,核心的处理算法一定都是c++写的,除了计算效率高之外,算法的实现也肯定是很复杂的,不可能每个客户端都用各自编程语言实现一套。这样带来的好处有:

  1. 代码量更少,开发效率高。
  2. 减少了不同语言实现时产生相同bug的可能。
  3. 减少了因不同语言开发人员开发水平不一致,出现各种bug的可能。
  4. 后期维护更方便。
  5. 测试更方便。

同样地,当你引入一个新的通信库时,如grpc。它提供了不同语言的实现,java、go、c++。如果每个语言都基于grpc封装一套通信逻辑,意味着每个语言的人都要了解grpc的使用,如果要求高一点,我们对引入的第三方库一定要读懂核心代码,那耗费的时间就更多了。更别说后期维护的时间。

什么时候要封装sdk

所以,我们到底什么时候该封装sdk呢?我认为出现下面几种情况,你可能就得考虑封装sdk了。

  1. 业务逻辑复杂,并且多平台客户端都需要。
  2. 复杂的算法。
  3. 网络通信中间件。比如我上面提到的grpc,还有一些基于tcp数据的封装、发送、解析。
  4. 多个项目可能会使用的公共模块。

http请求,是否要封装?

我们常说的一句话,架构设计不能脱离业务。诚然,我们很多时候的技术选型都是在权衡,权衡开发成本,权衡产品状态,权衡现有开发人员的水平等等。有的时候具体问题还是要具体分析。
上面说了那么多什么时候要封装sdk。那对于提供http接口的服务,有必要封装sdk吗?
我认为如果只是封装http的请求和响应,而不包含其他业务逻辑时,必要性不大,原因如下:

  1. 如果将http的请求和相应封装成sdk,我们看看是否提高了开发效率。首先确实只有一处公共代码发起http请求和响应,但为此,需要为各个客户端封装接口,以便能调用sdk。比如,c#需要封装托管c++或是提供c语言形式地接口,然后c#在以invoke的方式调用。比如,java和andriod,我们需要封装jni接口。其他语言就更别说了,能间接调用c接口,但都要简单的封装。于是,后期我们每增加一个接口都需要修改sdk,需要修改调用接口。这样做提高效率了吗?有人可能会说,sdk中发起http请求和相应的代码复用了,我减少了开发和维护成本呢。
  2. 但不要忘记了,各个语言都有非常成熟且经过充分验证的http client api。也就是说,各个高级开发语言(除了c++)不需要额外的开发精力,我们就能实现稳定的http调用。
  3. 对于http服务来说,如果设计人员的水平还行的话,我们不可能需要频繁修改接口,更多的是新增接口。而对于新增接口而言,我们并没有节省什么开发成本。
  4. 你能保证你封装的接口一次性交付么?

封装sdk可能带来的问题

再说远一点,并不是说为了增加复用,提高开发效率就一定要封装sdk。如果是服务端开发人员,如果多个项目都包含同一份sdk,一旦该sdk出了问题,就意味着所有相关项目都需要重新升级部署。
这个时候就该考虑服务化了,如果该sdk相关逻辑在一个单独的服务里面,我们只需要更新该服务就行,这样相关项目与那段逻辑就实现了解耦。沈剑的这篇文章《小小的公共库,大大的耦合,你痛过吗?》,大家可以关注下。


本文链接:http://www.servercoder.com/2017/12/11/sdk-without-http/