一种app快速迭代的套路（emmm，就称之为套路吧）

2019独角兽企业重金招聘Python工程师标准>>>

通常开发套路

通常公司进行app开发，都有会以下2个必要的组件（我是后端）：

1、server提供接口

2、根据ui，移动端设计界面并渲染（动态数据由接口请求返回）

这会产生什么问题呢？

由于国内的环境，大家懂得，开发迭代的速度会非常快，通常一个ui上周说是要这样，这周就要另个一个样子了。

但是，由于客户端的发布和打包审核都有一定周期，导致项目无法准确在准确的时间点上线，所以最好是能由服务端来控制，我到底使用哪个UI进行渲染和操作，会大大加快版本迭代，也可使前端开发更专注在ui的适配性上。

文章背景

目前我就职于国内W公司，马上就要进行离职了（回家种地！哈哈哈），所以想把一些已知的东西做些记录。

w公司，嗯，国内也算几个最活跃的app之一了。那W公司是如何快速进行业务开发的呢？

W公司客户端套路

W公司的每个客户端页面都是一个page，然后里面是card。以图来解释吧：

所以，客户端前期的工作就是渲染大量的card。

而到了后期，只用迭代主ui和交互工作的scheme即可。

W公司服务端套路

W公司的业务是繁重的，每个业务之间几乎有天差地别的处理，那对于客户端来说，他不可能去每个业务方单独调用每个接口，因此，要有一个中心，W公司称之为(mapi 微服务的api getway部分)。

然后业务线很多，每个接口参数也不一样，这时候，假如业务方每次更改，都得和mapi同步信息，好像也不好。因此，衍生出一个对象库(object library)，按照我的理解，就是每个要渲染的对象都拥有唯一的一个id，每个id在对象库里都存在着相应的业务。

同样，以图说话：

请求过程： client->mapi->objcet->modules->mapi(汇总数据)->client

对于每个业务方: 写接口->注入到object->将oid注入给mapi

这样做还有另外一大好处，就是可以充分的解耦每个业务方（当然也有不好的地方，每个业务方实际都是自己维护自己的数据）。

当然，图中并没有提及W公司的核心业务feed，因为我直接想总结下这个套路。

套路的思想

其实，每个公司都有适合自己公司开发的套路。我在这里总结的W公司的，但是可能并不适合别的公司（我觉得，特别是业务快速迭代的公司不要使用这个套路，前期开发成本太大，当业务定型之后，可以根据这个套路进行更符合自己业务的调整）。

文字不太会总结，所以我通常都喜欢以图说话 emmm.

转载于:https://my.oschina.net/lwl1989/blog/2990914