淘宝Buy+本地开发的适配问题

Buy+成为了全球首个VR购物软件，不过这软件在本地开发的时候还是会出现适配的问题。

本地开发的适配问题

除了工作量跟没有经验可以借鉴外，其实还有一个蛮重要的问题，这次所有开发用的是原生Native，而不是H5的方案。

由于双十一所有的产品都要做一程度的保密，所以没办法做大规模灰度验证。

因为按以往的开发惯例和经验，Native的东西上线需要做一些线上的灰度，让线上一些真实的用户来发现一些隐藏的问题。

既然不能去做线上灰度，如何保障线上技术稳定呢?我们做了几个方面的事情，首先，我们适配了目前70几款主流的设备，保证其在这些设备上的运行是没有问题的。

并且每一次改版都需要重新去适配，因为也不知道改版对兼容性会造成什么样的问题。

特别是Android，它有4.X、5.X、6.X，甚至7.X的系统，在每个版上的表现是不一样的，适配问题上真的是投入了巨大的人力物力。

另外，我们做了很多的降级预案，比如我们把性能比较差的机器直接列入了降级名单，让它看全景的图片，而不是像现在看有标定又有移动的全景视频方案。

当然，所有的机型都可以加白名单和黑名单，也准备了很多降级开关，比如万一崩溃比较多，而且是针对某些机型的话，也可以顺手将这些机型降成全景图片，甚至屏蔽其玩Buy+。

听起来加白名单黑名单这件事很简单，其实并不是这样。

特别针对Android来说，不可能将市面上所有机器都做一轮适配，行的加白名单，不行的黑名单，这个事情是几乎做不到的。

白名单的事每年都在提，但根本没多少用处，因为不可能将所有机器都列出来。

唯一可能采用的方案就是黑名单，但也有问题，就是只能发现一款加入一款，这样很难确保线上不会出现大面积崩溃。

这次我们基本上把Android 4.X以下的机器都降级了。Android上还有部分机器陀螺仪不行，这部分也全部降级了。

iOS也不是完全没有问题，如果操作系统升上10.0时也会遇到陀螺仪调不同接口返回的情况不一样。

总之，如果采用Native的方案，要保证线上尽量少的崩溃，需要考虑的问题是非常多的。

其实到上线的最后一刻，我们还是没有信心说这个东西上去完全没有问题，不会出现大面积崩溃，当然最后的结果验证我们的努力是没有白费的。