原文 BY Tommy MacWilliam
无论是为了让用户的体验更好，还是为了跑A/B测试，我们一直都在努力提升Quora的移动端和网页端的用户体验。Quora的iPhone和Android版App都能够通过内置浏览器Webviews来执行Javascript代码，这样我们就能够跳过App/Play Store来进行较大规模的更新（进一步阅读：从头开始重新构建iPhone版Quora）。
让我们来看一些例子，首先从第一打开App的时候开始：
这个页面上的所有内容都能够进行A/B测试而不用发布新版本。事实上，整个页面是个全屏的WebView，里面呈现了我们服务器上的Html5页面。我们使用了一些原生代码来处理登录注册相关的交互，却能够在不更新客户端的前提下替换页面上的任意内容。通过这种方式我们能够轻松进行A/B测试。
当你登录之后首先看到的是Feed流，下面这张图说明了这个页面哪些用了原生代码，而哪些是使用了Web代码：
绿色框中的内容我们都可以任意A/B测试而不用更新客户端，而蓝色框中的内容想要更改就只能去App Store发布新版本了。例如，当你按下导航栏坐上角的Feed按钮时会触发一个原生事件，因此这种情况下我们没有办法不通过App Store就改变这中交互。但是，这个原生事件触发后的效果是下划一个新的包含了WebView的UIView，因此里面包含的内容我们是能够进行A/B测试的。
不过上面说的并不意味着在不更新App/Play Store的客户端的前提下，所有的使用原生代码实现的功能都无法修改。当我们添加一些新内容时，我们都会在其中隐藏一些“钩子”（hooks），进而这些内容都能够通过Javascript来修改了。例如，下部导航栏的标签都是原生的组件，但在我们写它们的时候加入了即使不修改原生代码，也能够允许上面的文字改变的功能。可能一些聪明的用户已经注意到之前我们上线测试写文章模块时（Write Page）并没有发布新版本，尽管原生部分的改变相当明显。这都归功于之前加入的功能，把底部标签栏标签上的文字从"Open Questions"改为了"Write"。
另外像新添加文字这种小的修改我们也能够不发布新版本就进行A/B测试。比如说想要在"Your Content"部分进行A/B测试，我们应该怎么做？
再回到上面Feed的例子，顶部导航和底部标签栏中间的所有部分都是在服务器上生成的Web网页，因此我们可以很方便地对语言、布局、颜色或字体大小等进行修改。顶部导航上的标题是原生的部分，但也能够通过Javascript修改，也不需要发布新版本。右上角的按钮也一样，Javascript决定上面显示的内容，因此这里也可以很方便地对语言做A/B测试。当你按下这个按钮，你会看到这样的一个浮层：
显然这里能看到的所有东西都能够很方便地修改，无论是内容、按钮文字、标题或是按钮的行为等。事实上，我们能够在不提交App/Play Store新版本的情况下改变任何一个原生按钮的行为。所以说，如果我们想要对某个页面的切换行为做A/B测试：切换导航与弹出浮层 —— 依然不需要提交新版本。更夸张一点，甚至将一个按钮改为做另一件完全不同的事（比如，在当前页弹出一个搜索栏），依然不需要新版本。
最后总结一下，我们能够不通过App/Play Store而改变App上绝大多数UI元素（无论是原生的还是Web的）的行为。这种架构以及我们的持续开发模型（continuous deployment model）使得我们能够快速迭代，从而做出更好的产品。
