在Firebase Remote Config中定义bool变量的最优方式及string类型优劣对比

性能差异 #

两种方式的性能差异极小，基本可以忽略不计。
Firebase Remote Config 底层拉取配置时所有数据都是以序列化后的字符串形式传输，到端上才会由SDK做类型转换。直接使用bool类型仅比字符串类型少了业务层手动做字符串转布尔的逻辑，这点计算开销在常规业务场景下完全感知不到，只有一次性读取上百个参数的极端场景才可能出现可测量的差异。

效果一致性 #

在配置完全正确、业务层转换逻辑无疏漏的前提下，两种方式的运行效果是一致的，但存在很多容易导致效果不一致的风险点：

• 字符串大小写容错问题：如果后台配置时误输入True、TRUE、 False（带空格）等非标准值，业务层如果仅判断等于小写"true"，就会出现解析错误；原生bool类型后台只能选择true/false两个值，不存在输入错误的可能。
• 非法值容错问题：如果后台误输入"1"、"yes"、"开"等非预期字符串，或者清空了参数值，未做容错的业务转换逻辑会直接解析错误；原生bool类型遇到非法配置会自动走预设的默认值，不会出现异常逻辑。

具体影响 #

和原生bool类型相比，用String类型存储布尔值会带来以下额外问题：

• 维护成本更高：多端（iOS、Android、Flutter、Web）都需要单独实现字符串转布尔的逻辑，还要统一容错规则，比直接调用SDK原生的getBool()方法多了大量重复代码，后续迭代很容易出现多端解析逻辑不一致的问题。
• 配置出错概率更高：字符串类型在后台是自由输入框，运营配置时很容易出现多打空格、输错内容的问题；原生bool类型是开关/下拉选择组件，完全不会出现配置错误。
• 可读性更差：后台配置列表中，bool类型会用专门的开关标识或者布尔标签展示，和其他类型参数区分明显；字符串类型的布尔值和普通字符串参数混排，很难快速识别是开关参数。

内容的提问来源于stack exchange，提问作者Daniel Gomez Rico