Question

我们正在使用当前版本的Firebase iOS框架（5.9.0），并且在尝试运行具有激活事件的A / B测试实验时遇到一个奇怪的问题。

由于我们要在首次启动上进行实验，因此在应用启动时会出现一个自定义启动屏幕，在获取远程配置时会显示该屏幕。提取完成后，我们立即激活提取的配置，然后检查是否接收到有关实验参与的信息以适当地重新配置下一个UI。在确定当前实例实际上应属于测试（即激活事件）的一部分之前，还需要进行其他检查。基本上，代码如下：

<code that shows splash>

…

[[FIRRemoteConfig remoteConfig] fetchWithExpirationDuration:7 completionHandler:^(FIRRemoteConfigFetchStatus status, NSError * _Nullable error) {

    [[FIRRemoteConfig remoteConfig] activateFetched];

    if (<checks that see if we received info about being selected to participate in the experiment and if local conditions are met for experiment participation>) {

        [FIRAnalytics logEventWithName:@"RegistrationEntryExperimentActivation" parameters:nil];

        <dismiss splash screen and show next UI screen based on experiment variation received in remote config>
    } else {
        <dismiss splash screen and show next UI screen>
    }
}

使用上述方法（完全简单的IMO）无法正常工作。花了一些时间调试器和Firebase启用日志后，我可以在日志中看到出现竞争条件问题。基本上，Firebase activateFetched()调用不会在activateFetched调用中同步设置“条件用户属性实验ID”，而是在稍后的短时间内进行设置。因此，我们在activateFetched之后立即触发激活事件不会触发此条件用户属性，并且后续的实验漏斗/目标事件也没有正确标记为实验的一部分（实验甚至一开始都不被激活）。 / p>

如果我们更改代码以将激活事件的发送延迟一些任意的延迟：

<code that shows splash>

…

[[FIRRemoteConfig remoteConfig] fetchWithExpirationDuration:7 completionHandler:^(FIRRemoteConfigFetchStatus status, NSError * _Nullable error) {

    [[FIRRemoteConfig remoteConfig] activateFetched];

    if (<checks that see if we received info about being selected to participate in the experiment and if local conditions are met for experiment participation>) {

        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

            [FIRAnalytics logEventWithName:@"RegistrationEntryExperimentActivation" parameters:nil];

            <dismiss splash screen and show next UI screen based on experiment variation received in remote config>
        }
    } else {
        <dismiss splash screen and show next UI screen>
    }
}

预先正确设置了实验的条件用户属性并由事件触发（导致实验激活和后续事件被正确标记为实验的一部分）。

现在，此代码显然很丑陋，并且容易出现竞争条件。保守地将0.5秒的延迟设置为在所有iOS设备上都足够，但是__（_）_ //。我已经多次阅读了可用的文档，并尝试查看所有可用的API方法，但未成功确定开始发送事件的正确点。如果activateFetched方法使用重新配置内部对象的异步过程，则可能需要一种回调方法，该方法向调用方指示完成所有重新配置并可供应用程序进一步使用的时间点。似乎当远程配置配置文件激活后，有人需要立即发送激活事件时，框架工程师并没有预料到用例……

其他人遇到过这个问题吗？我们在API中缺少什么吗？有没有更聪明的方法让activateFetched完成任务？

希望一些Firebase工程师也可以用他们的智慧进行编排：）

谢谢

在iOS上使用激活事件时，Firebase A / B测试不对用户进行计数

0 个答案: