许多移动开发者或多或少都会碰到这样的事儿，将自己的新产品在应用商店发布之后却发现产品出现故障而不能正常使用。如果这个产品只应用于Web，那么解决这个问题是相当的容易，只要修改错误，然后再将代码上传到服务器上就可以了。但是，在移动平台上，与Web不同，一旦发布就不能再退回，唯一能做的就是修复更新并且尽快将它的下一个版本研制发布。这在Android上需要很长时间，而在iPhone上，时间更长。而KeepSafe的许多移动应用测试的经验，值得我们关注一下。

　　解决方案：SwitchBoard系统

　　尽管KeepSafe为客户进行全方位的测试，但是KeepSafe在所有可能进行的配置中并没有所有需要的设备，那么，他们究竟靠什么进行移动产品的测试？其实，KeepSafe的解决方案很简单，就是SwitchBoard系统。

　　但是，SwitchBoard系统究竟是什么？不用想得太复杂，SwitchBoard系统只是一个即使产品已经在移动应用商店发布却依旧可以进行远程控制的方法。KeepSafe建立SwitchBoard系统主要应用于三个方面：

　　● 分阶段展示

　　由于Android设备的碎片化，分阶段展示是KeepSafe可以提供良好的用户体验。通过SwitchBoard，KeepSafe可以先发布一个新产品的体验版，只有一小部分的用户使用，通过他们对产品进行测试以确保产品是否还存在缺陷。这真的很方便，因为KeepSafe还可以使用Crittercism得到实时的崩溃报告，只要他们看到一个特定的配置问题就会立即对产品进行修复更新。

　　● A/B测试

　　所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。当然，在实际操作过程之中还有许多需要注意的细节。

　　在以前的项目中，KeepSafe致力于网络产品的研发并且能够真正利用起A/B测试。在移动设备上这也许有点困难，尤其是对于部分本土应用程序，因此，KeepSafe并没有真正找到一个适宜的解决方案。所以，过去的分阶段展示只是为现在的A/B测试做铺垫。

　　● 远程配置

　　SwitchBoard系统允许隐藏第三方函数库，这将有利于关闭那些还在可控范围内但却有恶意攻击倾向的第三方程序代码。没有什么比在应用程序中拥有一个已经崩溃的第三方SDK更糟糕的事情了。无论是一个分析包还是API，有了SwitchBoard，KeepSafe都可以轻便地把它关掉。当然，KeepSafe还可以使用SwitchBoard系统对那些用户没有更新的旧程序进行远程配置来改变API结束点。

　　SwitchBoard系统应用实战经验

　　● 客户端（实例——Android）

　　SwitchBoard拥有Android和iOS两个移动客户端库，客户端支持生产和暂存环境，并且还可以创建用户自己独特的ID（UUID）。

　　SwitchBoard项目会自动将你的Android项目链接到它的函数库中，你只需要将SwitchBoard核心在您的应用程序中进行初始化，之后，你便可以切换到应用程序并且会收到SwitchBoard发给你的应用程序状态报告。

　　在应用程序开始时，SwitchBoard会自动生成一个包含有你的地理位置、操作系统版本、设备类型和语言等信息的配置文件。根据这个配置文件，SwitchBoard决定是否对配置进行更新。

图：在Android上ON/OFF代码

图：在Android上的工作原理价值