APP灰度发布（灰度发布的好处）

本篇文章给大家谈谈APP灰度发布，以及灰度发布的好处对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享APP灰度发布的知识，其中也会对灰度发布的好处进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、灰度发布（一）
• 2、iOS实现灰度发布App
• 3、因果推断——准实验法评估App新版本整体效果
• 4、CPU 架构指定 ABI
• 5、IOS APP由于IPV6问题被拒怎么解决

灰度发布（一）

一、术语
1、灰度周期，由测试/用户决定
2、金丝雀的故事
3、产品说的AB测试
4、客户端APP的灰度，版本更新交由后台控制
5、java Agent
6、互联网APP常见的玩法

最后灰度发布是什么？
---- 灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

二、灰度能做什么
1、白天发布，不用等到晚上11点，夜深人静的时候。
2、应用程序的新旧版本需要共存一段时间，用于做AB测试。
3、把新版本程序当做金丝雀，不影响真实用户的请求。

三、灰度不能做什么
1、应用程序在发布的时候，重启的时候足够安全吗，会影响线上用户吗？
2、线上灰度验证的时候，发现出问题然而开发不能及时修复，程序需要回滚，假如有已执行的数模，也需要回滚，怎么办？
3、它能够帮助我们远程断点或btrace新版本的应用程序吗？

四、灰度的实现
1、必备的条件有：

2、染色的流程

3、灰度规则
支持按流量比例和精准分配两种。精准可以是userId、IP、设备号等，只要http header能取出的key，都将支持配置到灰度规则。

4、传递灰度标识
在网关层进行打上标签，常用做法就是http header增加一个key。（kong plugin 安装灰度插件）
按链路访问顺序，由上往下进行传递，这里为了减少业务方的接入成本，采用java agent技术，做到对业务的完全透明。（java应用程序加载灰度agent的jar包）

5、灰度发布的流程

五、发布的方式有哪些
除了灰度发布，还有重要的蓝绿发布。
（灰度是允许新旧版本同时存在，蓝绿则规定在同一个环境下，要么是新版本，要么是回滚到旧版本）。
一般地，建议在预发环境下，实现蓝绿发布。在预发环境未验证通过前，预发环境是新版本，而生产环境是旧版本。

六、灰度发布带来了哪些问题
1、预期的流量是要打到灰度节点的，最后却打到正常节点了。如何核实？
现在一般的做法是通过traceId，查询kibana的日志。

2、灰度标识在全链路的整个链路传递的过程中，容易被服务或组件丢失。如何排查到底是哪个组件导致的？

3、日志与监控
日志需要采集，做法和jvm日志一样采用ELK。日志中需要包含程序的版本号、IP等关键信息。

iOS实现灰度发布App

1、进入 App Store Content APP灰度发布，输入 Apple 开发者账号登录。
2、登录成功之后，选择"APP灰度发布我APP灰度发布的 App"，进入 App 列表。（如果没有 App，需要创建 App）
3、选择"TestFlight"，“新群组”，“构建版本”，“选择要测试APP灰度发布的构建版本”，“测试信息”，提交审核。
4、审核通过之后，选择“开启链接”，将“https”替换成“itms-beta”即可。

【 TestFlight 公开链接 】 转 【 TestFlight 安装链接 】

iOS 跳转 TestFlight 实现

因果推断——准实验法评估App新版本整体效果

做A/B实验相关工作中遇到一些问题，其中之一就是如何判断新版本对用户影响，以前的做法：
1.所有新功能都预埋开关(默认关)，对新版本用户随机分桶后对实验组开启，用标准A/B实验方法评估。但是这在需要很高开发成本，而且容易出错；
2.同时构建两个新版本，a版本不包含任何新功能，b版本包含全部新功能，对用户随机分桶后，分别开放不同版本的升级，之后对a版本用户、b版本用户用随机实验法进行评估。这也需要较高成本，而且对第三方渠道不能自由控制用户是否可以，仅能用在灰度发布阶段，样本量较小；
3.随机分桶后，仅对实验组开放升级，之后与对照组对比，并可对实验组中升级用户作为训练集，通过机器学习方法判断对照组中愿意升级的用户，对他们进行评估。本方法同样存在2中的问题，只是免去了打a版本发布的过程。

上述问题都有实现难度、成本方面、样本量的问题，那么有没有办法不改变发布流程，科学的评估效果呢？有，LinkedIn用准实验方法做过相同的事情： Evaluating Mobile Apps with A/B and Quasi A/B tests 。下面记录下我的个人理解。

众所周知，相关不一定等于因果，判断因果效应的黄金工具是随机实验。准实验是在没有办法进行随机实验时，对观测数据因果推断的方法。一个详细的介绍可以参考： https://www.scribbr.com/methodology/quasi-experimental-design/ 。

LinkedIn发布了一个大的更新版本，没有办法把所有的功能做成开关，而且他们不能自己灰度升级发布。因此需要用准实验方法来进行评估。目的是研究版本效果差异，对比的是新版本用户与旧版本用户数据，但是用户是否会升级与个人意愿、是否有wifi、渠道策略等因素有关，直接做diff是有偏的，需要采用因果推断中的准实验法。

由于当时苹果市场只支持全量发布，是否升级对是用户自身影响因素决定的，所以是一个经典的准实验问题，可以用上述方法解决。关于方案效果测试，可以对之前没有附带新功能的版本进行" A/A "，看能否有效消除偏差。

测试结果：
从上图可看到，bias大幅降低，endogenous OLS模型效果最好。

图中A1、B1代表愿意升级的用户，其它为不愿意升级用户，而A1、A2代表有资格升级的用户(在分阶段发布里命中)，也就是仅有A1群体成功升级。在用户意愿和分阶段发布共同作用下，上述iOS的方案会表现很差。
这种机制带来了另一种好处，比如在20%放量阶段，对每个升级者来说，期望有4个与他相似的用户。如果我们识别出其它相似用户，那就可以近似为随机实验。所以需要一种低假阳性的识别方法，哪怕假阴性较高(因为有4个相似用户，召回率没有那么重要)。

由于A1与B1是可比较的，S(A1)与S(B1)也是可以比较的，下面介绍两种基于此的策略。

思路是将愿意升级用户B1从未升级用户中识别出，不同于iOS那边将升级用户参与模型训练，这里仅使用历史数据来训练，对识别出的用户再按是否升级，判断是否属于B1。
由于随着时间推进，用户升级的概率越来越高，我们需要建模获取 ，代表i个用户t日升级概率。假设每日概率恒定为 ，则：
，其中 代表活跃天数。
基于历史数据，可以计算 的最大似然估计：

代表用户i在可以升级版本j到升级版本j前的活跃天数， 代表用户i是否升级了版本j。
最后，在发布新版本后，每个用户每天计算累计概率 。选择超过阈值的用户认为是会升级用户。

由于非升级组有更多的用户与升级用户相似，直接通过协变量将他们与升级用户匹配变得更容易。最基础的两种匹配方法：

两种策略都不容易通过GPU运算，尤其在有大量协变量时，带来性能上的问题。
因此，LinkedIn采取了“Doubly Robust” 方法，先进行匹配算法，在其基础之上进行线性回归。第一阶段仅适用10个重要的连续变量进行匹配分桶，线性回归阶段有大量的协变量，对偏斜进行补偿。此方法可以从第一天起就有不错的表现，是LinkedIn的最终方案。

结果看起来很棒，在第一天也只有很小的偏差。

大的变更会有强的新奇效应，用户开始阶段会进行很多探索。
需要判断两个问题：1.是否有新奇效应；2.新奇效应持续多久？
标准ab实验中，可以观测随着效果随着时间的推移是否变弱，以此来判断。在准实验方法中，结合上文相关方法，也可以进行类似的判断。

对因果推断来说，随机实验总是第一选择，但有时随机成本过高或者根本不可能。准实验方式是流行病学、经济学等领域常常用到的方法，它不失为不能A/B实验时的一种很好补充。

CPU 架构指定 ABI

尊敬的开发者：

您好， 为提升App性能，降低App运行功耗，vivo、OPPO、小米共同推进国内安卓生态对64位架构的升级，协助开发者快速对接全球64位开发环境。 适配计划如下：

2021年12月底：现有和新发布的应用/游戏，需上传包含64位包体的APK包（支持双包在架，和64位兼容32位的两个形式，不再接收仅支持32位的APK包）。

2022年8月底：硬件支持64位的系统，将仅接收含64位版本的APK包。

2023年底：硬件将仅支持64位APK，32位应用无法在终端上运行。

为帮助开发者顺利完成架构升级，vivo现已支持64位应用上架，您可点击以下文档指南进行阅读：

vivo 64位架构适配指南

vivo 64位安装包上传操作指南

开发者需积极采取措施完成64位架构升级，若逾期未适配，用户可能会收到“搜索标签提示”、“安装环节未适配提醒”等。
如有疑问，欢迎联系平台客服咨询。感谢您的支持。
2021年7月13日
vivo开放平台

灰度发布介绍：在当前上架版本为全网发布时，您可以采用灰度发布的方式进行应用升级。采用灰度发布，您可以先向一定比例的用户发布更新的版本，通过对小范围进行版本更新，您可以快速获取用户对新版本的反馈意见，降低版本全网发布后出现问题的风险。

Android的.so文件,32位处理器与64位处理器

小米上次打电话说，后期安装包要64位或32/64位的，这样更兼容，32位的话怕不兼容，有可能审核不通过

Android adb安装时强制应用App以32位或者64位运行

Android arm64-v8a、armeabi-v7a、armeabi、x86详解

当我们想在电脑的Android模拟器中安装APP的时候，会报INSTALL_FAILED_NO_MATCHING_ABIS错误【如图1】，导致APP无法在模拟器中运行。

由于安装的APP中使用了与当前CPU架构不一致的native libraries,所以导致报错，因为现在绝大多数的智能手机还都是采用ARM架构的，虽然android是支持ARM和x86架构，但是它们的指令集是有差别的，APP在开发的时候使用的是ARM的本地库，而我们在用AVD创建模拟器的时候使用的是x86的CPU，因此导致报错。所以，如果APP是在x86架构下编译的我们就创建x86cpu的模拟器，如果APP是在ARM架构编译的我们就创建ARMcpu的模拟器。

首先要看你的模拟器CPU类型是哪一种结构，然后直接修改模拟器的CPU类型来适应你的native libraries就可以解决此问题。

Android模拟器安装APP出现INSTALL_FAILED_NO_MATCHING_ABIS错误解决方案

IOS APP由于IPV6问题被拒怎么解决

自2016年6月1日起，苹果要求所有提交App
Store的iOS应用必须支持IPv6-only环境，背景也是众所周知的，IPv4地址已基本分配完毕，同时IPv6比IPv4也更加高效，向IPv6过渡是大势所趋。
然而在对IPv6进行兼容适配过程中，很多开发者在本地环境测试通过，却在App Store审核时被拒，这种情况下可以首先排查是否由DNS解析失败引起，那么如何验证DNS服务器是否正确响应了IPv6地址的解析请求呢？搭建好DNS64环境后，可以通过以下命令查询：
$dig dnspod- aaaa
验证DNS解析的原因是，App访问网络的第一步就是进行DNS解析，App Store审核时会先访问DNS服务器，获得iOS应用服务器的IPv6地址，再进行访问，如果这时DNS服务器无法成功解析到IPv6地址，即使在本地搭建的IPv6-only环境中测试成功，仍然会出现在提交App Store审核时被拒的情况，所以选择一个稳定性、兼容性俱佳的域名解析服务至关重要！
经过全面的测试和灰度发布，腾讯云DNSPod域名解析已全面支持App
Store IPv6-only网络环境，已有成功通过审核案例，并且在境内外均验证解析成功 关于APP灰度发布和灰度发布的好处的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 APP灰度发布的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于灰度发布的好处、APP灰度发布的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。