加速之必要
不考虑技术，有一件事是肯定的——人们似乎总是希望可以更快。根据各种各样的研究，现在用户只愿意等待一个web应用程序加载三秒或更短的时间，超过的话，他们就会变得越来越不耐烦或者干脆换一个应用程序。这些高期待不断被压到移动web之上；现在还压到移动App上。就像Web，现今的移动移动app都有它们自己的性能问题并需要做出一些微调。最新研究表明，过去，在手机上获取app时，47%的移动用户主要是抱怨速度慢且反应迟钝。App在苹果的app商店上被谴责“慢得可怕”。对于Facebook的iPhone应用程序，38，000条评论中有超过21，000的用户只给app一星的评价。用户多数表示app慢，死机，“一直在加载”。
“移动app根据它们在app商店的排名而生存或死亡……排名不佳，用户采用率就降低”佛里斯特研究公司的MargoVisitacion这么说道。这或许就是为什么80%的品牌iPhone，Android和Blackberry应用程序无法达到1，000的下载量的原因。拙劣的移动app性能直接影响用户获取和用户维系。那么该做些什么以保证你的移动app性能尽可能的强大呢？
通过捕捉现实中移动app性能“获得真实信息”
移动app性能首先，最重要的是：为了真正理解移动app性能，你必须衡量你的真正用户正在体验的性能。在数据中心的模拟机上进行测试可以有所帮助但是它基本和你的真实终端用户的真正体验无关。你的数据中心和你的终端用户间有许多影响性能的变量因素，包括云，第三方服务/集成，CDNs，移动浏览器和设备。衡量真实用户是在巨大的复杂物上精准评估性能并确定一个性能提升的基准线的唯一方法。衡量你的真实用户体验的性能可以让你就移动app（关键参数方面的，如你客户使用的所有的地域，设备和网络）性能做出报告。
现在，移动app测试和使用SDKs监控以提交本地app可以让你快速轻松地鸟瞰你所有客户的移动app性能。
负载测试从终端用户角度看也很重要，尤其是在开始一个app前，综合测试网络可以让你在不同的条件下评估性能水平。
理解拙劣性能的商业影响
确定移动app性能问题以及它们对转化的影响很重要：比如，你会注意到移动app的响应时间增加与转化的减少息息相关。这样你就可以进行分类，基于一些考虑（如：我的哪些客户，多少客户受到影响了）按轻重缓急解决问题。如果一个地区的流量份额很高但有问题，而另一个地区的份额较少，那你就知道该优先解决哪个性能问题了。
确保第三方集成有效
就像web应用程序，许多移动app为了给终端用户提供更丰富更满意的体验吸收了大量第三方服务的内容。一个实例便是社交媒体集成，如Twitter就被集成到奥林匹克移动app中了。很不幸，如果你依赖第三方服务的话，你就会完全受限于他们的性能特点。在使用一个第三方集成的app前，你需要确保集成无缝顺利且可以提供你期待的性能。此外，你还要确保一直监控着第三方性能且你的app被设计得可以完好地降级以防第三方的问题。
让你的移动APP快起来
在这个飞速运转的移动app世界有一句格言比任何时候都真——快比慢好。你可以使用一些特定工具和技术让你的移动app变得更快，包括以下：
优化缓存–让你的app数据完全脱离网络。对于内容多的app，设备上的缓存内容可以通过避免移动网络和你的内容基础设施上的过多障碍以提升性能。
将往返时间最小化–考虑使用一个可以提供无数能够加快你的app服务的CDN，包括减少网络延迟的边缘缓存，网络路由优化，内容预取，以及更多。
将有效荷载规模最小化–专注压缩，通过使用任意可用的压缩技术减少你的数据的规模。确保图像规模适合你最要的设备段。同样，确保你利用压缩。如果你有要花很长时间加载的内容，那么你可以一点一点儿的加载。你的app可以在加载时使用该内容而不是等整个加载完成后才使用它。零售app经常使用该技术。
优化你的本机代码–写得不好或全是bug的代码也会导致性能问题。在你的代码上运行软件或检查代码以找出潜在问题。
优化你的后端服务性能–如果对你的app进行了性能测试后你发现后端服务是性能削弱的罪魁祸首，那么你就不得不进行评估并决定该如何加快这些服务。
总结
智能手机用户当然也是“快比慢好”，他们期待他们的app可以飞快。几乎每隔一段时间，移动运营商和智能手机制造商都要宣布更快的网和设备，但不幸的是，移动app本身的速度却跟不上。
最主要的原因是一组截然相反的目标使得实现飞速性能变得很困难。移动app开发者总希望提升速度的同时可以提供更丰富的体验。需要更多内容和特点能够快速地覆盖宽带，内存和计算机能力。
本文给出了一个简短的本地移动app的性能最佳实践的例子。性能调整的空间很大，但错误的空间同样也很大。因此，早点测试你的app，绝不要药听天由命。记住——快总比慢好。
最新内容请见作者的GitHub页：http://qaseven.github.io/