最近，有些U8SDK的合作伙伴向我们反馈， 他们通过U8SDK接入的quick渠道包，在quick平台自检的时候，quick平台上面有提示下面这条警告：
quick_check2.png
U8SDK作为quick的同类产品（功能上），我们非常理解quick的“用意”和“做法”。
但是，为了不给U8SDK的客户或者对U8SDK感兴趣的同学产生误解，我们有必要的针对quick平台的这条警告作以下说明：
1、警告中说的“可能会被渠道拒绝”，这条是子虚乌有+胡编乱造。 为什么我们敢这么说呢？
U8SDK，我们其实一直就定位为聚合SDK技术方案提供者，而不是做第三方的SDK接入平台。 所以合作之后，我们不仅会提供全套源码，服务端也是直接部署在客户自己的服务器上，不存在用户数据和订单数据都集中走U8SDK这边的情况。 而这一点，恰恰是有些渠道平台不愿意游戏使用“第三方SDK接入平台”来接入SDK的原因。 举个栗子， quick上面有1000家游戏， 这1000家游戏通过quick平台接入了vivo渠道sdk， 那么当quick平台服务挂了之后，相当于vivo平台上面这1000款游戏，集中暴雷，因为这1000个游戏的用户登陆和支付都需要经过quick平台。
到目前为止(2020年08月26日)，还没有任何一家游戏因为使用了U8SDK而导致上不了渠道平台的情况。 所以我们说，quick上面的警告是“无中生有”了。
正式基于这点点的自信，我们和所有合作伙伴签订的协议中，有这么一条：“如果因为使用U8SDK，导致游戏被渠道平台下架，U8SDK退还所有的购买费用，并免费帮客户解决上架问题”。我相信这点，是quick这样的平台，无论如何也不敢提供的保障。 因为quick这种平台，反而更容易被渠道平台拒绝，理由除了上面提到的集中暴雷，还有很多其他的原因，这里不一一列举。 如果不信， 你若有主流渠道的商务朋友， 简单了解一下即可知道。
2、额外补充
其实U8SDK和quick并不冲突，也不算直接的竞争者。 我们的游戏客户当中，有很多的发行业务架构都是类似下图这样：
u8sdk_quick2.png
基于U8SDK搭建一套自己的聚合发行平台， 然后主流渠道直接用U8SDK打包上架。一些长尾渠道， 通过U8SDK打出quick分包，再通过quick的分包工具分长尾渠道包。 这样既保证了主流渠道上架的灵活性和可控性，也兼顾了长尾渠道上架的简便性。
网友评论