app 里的 A_B 测试简介，Android篇

A/B 测试是一种对照实验方法，用来根据假设比较两个及以上版本之间的差别，其假设可以被证实或推翻。该测试会根据原有版本派生出特定的测试版本，以此来产生可靠的结果。当 A/B 测试在被测人不知情的真实场景中测试，其得出的结果才是最有效的。

要构建每个版本的代表性样本群体，A/B 测试平台需要随机地让用户使用版本 A 或版本 B，或者将其排除在测试之外。然后确保用户在整个测试中保持一致的 A/B 体验（总是 A 或总是 B），并向分析平台提供额外的元数据以确定指标的影响。一旦指标分析完成，表现最佳的版本将会被选中，您可以使用 A/B 测试平台逐步向所有用户推出获胜版本。

例如，你可以假设在你的 app 中 底部导航 的用户参与度将超过 标签。您可以设计一个 A/B 测试比较标签（版本 A）和底部导航（版本 B）。 然后，你的 A/B 测试平台将生成一个样本，该样本基于用户随机分配到版本 A 或版本 B。并且每个用户在测试期间会持续看到相同的版本。当测试结束时，可以将版本 A 用户参与度与版本 B 的用户参与度进行比较，看看版本 B 是否具有统计显着性 的改进。如果版本 B 更好，这就有数据支持你把导航风格改为底部导航，并让所有用户看到这一版本。

左边 —— 版本 A，标签；右边 —— 版本 B，底部导航

关于 Google Play 控制台中商品详情实验的说明

Google Play 控制台还支持在你的商品详情中进行 A/B 测试，本文不会重点关注这一部分。商品详情实验，让你在商品详情中测试不同的图标，功能图，促销视频，简短描述和详细描述，看看这些变化是否可以增加应用的安装。 商品详情实验侧重于提高转化次数，而我的文章的其余部分讨论了应用内的 A/B 测试，旨在改善用户存留率，用户参与度和应用内购买收入等安装后的指标。

在我的文章中，我将介绍 app 里 A/B 测试的五个关键步骤：

1. 建立假设
2. 整合 A/B 测试平台
3. 测试假设
4. 分析并得出结论
5. 采取行动

然后，我还会涉及更多可以探索的高级技巧。

第一步，建立假设

假设是根据一种现象提供相应的解释，而 A/B 测试是一种确定假设是否为真的方法。这个假设可能是通过检查现有的数据而产生的，也可能猜测的成分多一点，或者仅仅只是一种“预测”。（对于新功能所涉及到的新指标，假设常常是基于“预测”。）在导航的例子中，可以用这种方式来表达假设：“采用底部导航会较标签增加用户的参与度“。然后，如果你的 app 有对导航风格进行了更改，以及该更改对用户参与度的有影响，你可以根据这个假设来进行相应决策。重要一点的是要记住，测试的唯一目的是证明底部导航对每个用户的平均收入（或者 ARPU）有着直接，积极的影响。

要测试什么（A 是什么？B 又是什么？）

下面的表格列出了大部分的情景，可以帮助你确定要如何选择测试的版本。以我们假设的导航实验为例。

“排除测试”这一列表示不参与测试的用户。他们的行为将不会有助于测试结果。我们看看谁是测试用户。

我们根据假设想要度量什么来选择情景 2 或者情景 3。如果仅与新功能有关（例如，如果新功能是需要 app 内购，则这个功能仅和 app 内购买收入相关），那么选择情景 2。如果假设要实现的新功能（例如，如果新功能是“最爱”机制，并且度量指标是用户参与度）与之前的东西（并且是可测量的）相关，则选择情景 3。

注意： 在接下来的部分中，为了简洁起见，我将使用情景 1。 同样的方法同样适用于情景 2 和情景 3，以“现有”和“新”版本这些称号代替“新 1”和“新 2”版本。

谁来测试

如果已知观察到的行为会因为假设外的某个因素发生变化 —— 例如，当假设仅考虑全球收入的影响时，已知行为会因居住国而异 —— 需要让该因素（单一国家）的值唯一，或者使用全体人口（所有国家）的代表性样本。

受控的代表性样本的大小也可以设定为总人口的百分比。例如，测试样本大小是总人口的 10％，其中 5％ 收到版本 A，5％ 收到版本 B，其余 90％ 排除在测试之外。也就是 90％ 的用户只会看到现有的功能，并不会看到任何新功能，他们的行为被排除在测试指标之外。

要测试多久

最长时间： 用户的行为通常会随着时间，这周的第几天，月份，季节等类似因素而变化。为了让版本之间体现出足够的差异，您需要平衡统计显着性和业务的需求。（您的业务可能无法等到你有足够的数据可以完整的统计。）如果知道某个特定指标会在较短的时间段内发生变化，例如一天中的某个时间或一周中的某一天 —— 那么就尝试让测试涵盖这一整个时期。对于需要较长的时间段的指标，只测试几周可能会更好一点，并要根据度量标准随时间的变化进行相应地推测。

最短时间： 测试运行的时间要足够长，来获取足够的数据从而能够提供具备统计意义的结果。通常对应的测试人数是 1,000 个用户（至少）。但是，能否得到明显的结果取决于从假设推导出来的指标分布。你可以通过估计有多少用户能够在所需的时间段内进行测试，从而在合理的时间内完成此操作，然后选择估计用户数量的百分比，以便让你的测试在这个时间段内达到统计显著性。一些 A/B 测试平台能自动管理这些操作，同时也可以提高你的测试采样率，让你的测试更快地达到统计显著性。

第 2 步，整合 A/B 测试平台

已经有几种 A/B 测试平台，既可以作为一个独立产品进行测试，也可以作为一个更大分析平台的组件，例如 Firebase 远程配置分析。通过客户端库，平台会向 app 发送一组配置指令。app 不知道为什么要返回某个参数，因此不知道它在测试哪一部分，甚至不知道是否这是测试的一部分。客户端应该按照配置指令自己进行相应配置，由客户端来解释其中的价值。 在最简单的情况下，返回的参数可以是简单的键值对，用于控制是否启用给定功能，如果是，则激活对应的版本。

在更复杂的情况下，如果需要进行大量的远程 app 配置，app 会将参数发送到 A/B 测试平台，测试平台会跟据这些参数来选出更精细的测试配置。例如，如果假设只涉及具有 xxxhdpi 屏幕密度的设备，那么 app 将需要将其屏幕密度发送到 A/B 测试平台。

不要重复发明轮子

直接从现有平台中选择一个可以满足 A/B 测试需求的。注意：需要养成相应习惯来做到 A/B 测试和数据驱动决策。

注意： 管理许多用户，让其保持一致的测试状态，并公平地分配测试参与者很难。没有必要从头开始写。

当然，你要为每个要测试的版本写代码。但是，不应该由 app 或某个定制服务来决定在给定时间内使用哪个版本。这要交给 A/B 测试平台来处理，应用这种标准方法，可以在集中管理同一时间内同一人群的多个测试。当你在平台上只执行一个测试时，亲自实现一个简单的 A/B 测试机制才有意义。 对于硬编码两个测试的成本，您可以集成一个现成的 A/B 测试平台。和写两个硬编码测试的成本相比，不如把这些测试集成进一个现成的 A/B 测试平台。

整合分析功能

选一个可以提供详细的测试状态信息的现有分析平台，可以自动帮你可以把测试人群进行分类。要紧密地把这两个平台集成在一起，取决于每个测试的具体配置，和要直接在 A/B 测试平台和分析平台之间传递的版本。A/B 测试平台会为每个版本分配一个唯一的引用，并将其传递给客户端和分析平台。然后，只允许客户端把该引用而不是整个版本的配置传递给分析平台。

远程配置

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

总结

**其实上面说了这么多，钱是永远赚不完的，在这个知识付费的时代，知识技能提升才是是根本！我作为一名8年的高级工程师，知识技能已经学习的差不多。**在看这篇文章的可能有刚刚入门，刚刚开始工作，或者大佬级人物。

像刚刚开始学Android开发小白想要快速提升自己，最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以这里分享一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

这么重要的事情说三遍啦！点赞+点赞+点赞 免费分享所有学习秘籍！
直达领取链接：点击链接免费领取【Android高级架构师】

【Android高级架构师系统学习资料】高级架构师进阶必备——设计思想解读开源框架

第一章、热修复设计
第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack

第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack