从基于Web的应用到原生应用的迁移看Facebook的发布流程

来自Facebook的Chaitanya Mishra在上月的Velocity Conf London上发表了演讲，描述了Facebook将其Android应用从Web View视图转换为全面原生应用的方法。为了达成该目标，各个产品团队只负责自己特性。为了使分布开发模型能够正常工作，由一个核心团队负责回归测试并专注于整体应用的优化而不是某个特性的优化。

因为对于用户来说，升级到应用的新版本（包括修复）决定于第三方的审核以及用户想升级的想法，所以需要对适用于Web开发持续交付模型做一些调整，使其适用于快速迭代的Android开发。当构建失败时快速反映给开发人员，内部试用新发布版本（在发布到应用商店的4周之前先内部发布给员工试用）并监测其使用情况（碰到功能错误或性能问题时及时反馈给开发人员），该措施提升了对外发布的信心。在这4周时间里，在一个发布分支中修复问题，该分支与主分支（在主分支中不断加入并测试新功能，作为将来的发布功能）是并行的。

除了功能和性能测试（使用Selendroid通过界面进行）外，其他在构建过程中针对Android应用的检查还包括：应用的大小（是否有变更会意外增加应用的大小），内存使用率以及电源消耗（实际的电池使用）。Chaitanya举了一个例子，团队发现一个很明显的电源消耗增大却又无法解释的问题，最终证明是一个微不足道的变更导致的，该变更是为了阻止应用进入休眠模式而采用的轮询机制。

应用发布出去之后，Facebook使用Analytics Logger监控应用的性能和问题。反馈的数据使用一种叫做Scuba的工具进行分析。Chaitanya又举了个例子，他们发现数据库崩溃的次数越来越多。他们怀疑是用户设备的可用空间过低导致的，所以他们就增加了剩余空间检测功能，结果发现确实是应用占用了过多的空间，这都是应用分配甚至复制整个数据库，超大缓存，还有一些不必要的文件导致的。问题经过修复后，数据库崩溃的频率明显降低。

尽管应用已经成功转换为完全本地化应用，但是让Chaitanya担心的是，向本地化转化后不稳定现象会偶尔出现，尤其是一些不常用的功能还是基于Web实现的。根据Chaitanya的说法，依赖Web的缺点是需要尽可能保持与网站API的向后兼容。

查看英文原文：Facebook’s Release Process Behind the Move from Web-based to Native App

感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。