第 1 章 Android 的性能指标

第 1 章 Android 的性能指标

说到性能,不同的领域有不同的标准。对于移动 App 领域,性能的评判标准主要体现在 App 的运行方式、工作效率以及使用的流畅性上。在本书中,我们将从提升 App 的效率和速度的角度来探讨性能问题。

众所周知,Android 性能问题非常复杂,因为有成千上万种计算能力参差不齐的设备。但是大多数时候,我们只是保证了开发的 App 能够在自己的目标设备上完美运行。希望本书可以帮助你进一步完善 App,使其能够在 19 000 种不同的 Android 设备上运行并且获得极致的体验。

本书将重点介绍电池管理、工作效率和速度这几个方面的性能优化问题,同时也会探讨开发人员面临的一些主要问题,还会介绍一些能帮助我们确定和定位性能问题所属类型的工具。一旦确定问题,我们将围绕其讨论一些可行的补救措施。

 本书适合所有的 Android App 开发者。不论是性能方面的技术带头人、独立开发者、开发团队还是测试人员,都将会从后面章节中讨论的各类性能监测工具和技术中获得帮助。

关于代码优化的建议,每个人所遇到的情况是不同的。有些优化修改简单快速而且效果明显,而有些优化则需要很多额外的工作,比如代码重构、改良 App 的主要架构等。这些优化的建议也许不总是可行的,但是知道 App 到底哪里存在缺陷将能够帮助你持续地提升 App 的性能。

通过研究 App 的基本性能问题,你就可以在感觉到 App 出现问题的时候有个大致的解决方向,并且知道该如何一步步地提升 App 的效率、性能和速度,从而避免 App 的卡顿和用户的投诉。

1.1 性能对用户很重要

你的 App 运行得有多快?早在 20 世纪 60 年代关于人类注意力的相关研究就指出,在 100 毫秒内的行为都被认为是即时的,延迟 1 秒及以上就会让人意识到卡顿 1。而延迟和卡顿(即便这种缓慢是感觉上的)对于一个 App 来说是致命的,甚至有时候还会给用户的手机带来灾难(2012 年的一项研究表明,App 出现的卡顿导致 4% 的用户气得摔坏了手机! 2)。

1Jakob Nielsen,“Response Times: The 3 Important Limits,”excerpt from Usability Engineering (1993), http://www.nngroup.com/articles/response-times-3-important-limits.

2Mobile Joomla!,“Responsive Design vs Server-Side Solutions,”December 3, 2012, http://www.mobilejoomla.com/blog/172-responsive-design-vs-server-side-solutions-infographic.html.

1.1.1 电子商务和性能

假设一个电子商务类 App 的一个购物流程需要的平均时间长达 5 分钟,并且每个页面的加载平均需要 10 秒钟,那么完成一次购买你最多只能加载 30 个界面到屏幕上。如果能将每个页面的加载时间都减少 1 秒钟,你就可以在每次购物流程中增加 3 个页面。这样可以让用户将更多的商品加入自己的购物车,或者是单纯地将整个交易流程缩短 30 秒钟。

以上的假设其实都是有据可依的。2008 年的一项研究表明,相比那些反应迅速的网站,反应迟缓的网站的交易率和用户满意度更低 3

3Roger Dooley,“Don't Let a Slow Website Kill Your Bottom Line,”Forbes, December 4, 2012, http://www.forbes.com/sites/rogerdooley/2012/12/04/fast-sites/.

事实上,前文中虚构的电子商务网站的优化例子和图 1-1 里的数据是基本匹配的。给交易流程平均增加 3.3 个界面,也就等于在整个交易过程中增加了 11% 的页面视图。

{%}

图 1-1:网站速度慢所造成的影响(当网页存在 1 秒延迟时)

对网页性能的研究为移动 App 的性能研究提供了很大的启发。很多研究表明网站反应速度的提升有利于提高订单量和销售量。我认为这同样适用于移动 App(而且考虑到移动端的及时性,这种影响的估计甚至可能还是保守的)。

亚马逊 4 和沃尔玛 5 都曾分别报告过类似的数据。这两大零售商都已经意识到,仅仅 100 毫秒的延迟就可能导致他们的收益下降 1%。Shopzilla 为了优化性能重构了他们的网站,结果他们的页面浏览量增加了 25%,转化率也提升了 7%~12%,且重构之后只用了原来一半的节点! 6

4Todd Hoff,“Latency Is Everywhere And It Costs You Sales - How To Crush It,”High Scalability, July 25, 2009, http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it.

5Joshua Bixby,“4 Awesome Slides Showing How Page Speed Correlates to Business Metrics at Walmart.com,”Radware, February 28, 2012, http://www.webperformancetoday.com/2012/02/28/4-awesome-slides-showinghow-page-speed-correlates-to-business-metrics-at-walmart-com/.

6Todd Hoff,“Latency Is Everywhere.”

1.1.2 电子商务之外的影响

性能差的 App 不仅会导致销售量和收益降低,还会导致其在 Google Play 市场的排名下滑。更糟糕的是,这些 App 的表现通常会使用户把它们从设备中移除。比如在 2011 年,T-Mobile 就要求 Google 从应用市场(当时还叫 Android Market)移除一款第三方语音邮件 App——YouMail,因为 YouMail 检查新语音邮件的方式竟然是每隔 1 秒从服务器拉取一次数据(是的,你没听错,一小时就要向服务器请求 3600 次)!如此频繁的连接请求只需要大约 8000 个用户就能产生比 Facebook 还要多的连接数。事实上,在 Google 云推送被广泛地应用之前,这样的做法一直存在。即便是现在,Google Play 上依然存在有类似行为的 App。正如我们所知道的,这些 App 会让服务器、网络的性能变差。最重要的是,它们还会影响用户的 Android 手机设备。

有时候你会发现,刚发布的时候 App 的架构很好,但是后来它变得更大的时候还会如此吗?假设你可以在下届 Super Bowl 比赛中为你的 App 做个广告,App 和服务器架构准备好迎接用户数量呈指数型增长了吗?

1.1.3 性能可以节省基础设备

大多数的 Android App 和远程服务器有高频率的交互,需要从服务器获取很多的内容。减少向服务器发出的请求次数(或是减少每次请求数据的大小)可以让 App 速度得到巨大的提升,而且可以减少服务器端的请求堵塞,节省基础设施上的投入。我曾经所在的公司通过减少 35%~50% 的网络请求和 15%~25% 的数据交互,每年能够在远程服务器设备购置上节约数百万美元。

1.2 最恶劣的性能影响因素:宕机

在 2015 年,一项关于财富 500 强公司的研究表明,网站宕机所造成的损失大约是每小时 50 万 ~100 万美元。为避免收入损失,他们斥资引进了数据中心、云服务器、数据库等作为数据备份。回顾过去的十年,各种各样的研究 7 对宕机所造成的损失持续地做出了评估(而且损失是逐年增加的)。其中有两个研究指出收入损失仅占宕机损失的 35%~38%。如果我们用这些研究所得的数据来做图表,会发现在 2015 年宕机一小时会造成每小时 17.5 万美元的收入损失,而且这项损失是持续升高的(见图 1-2)。

7Yevgeniy Sverdlik,“One Minute of Data Center Downtime Costs US$7,900 on Average,”Datacenter-Dynamics, December 4, 2013, http://www.datacenterdynamics.com/critical-environment/one-minute-of-data-centerdowntime-costs-us7900-on-average/83956.fullarticle;
Martin Perlin,“Downtime, Outages and Failures - Understanding Their True Costs,”Evolven, September 18, 2012, http://www.evolven.com/blog/downtime-outages-and-failures-understanding-their-true-costs.html; AppDynamics,“DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified,”http://info.appdynamics.com/DC-Report-DevOps-and-the-Cost-of-Downtime.html.

{%}

图 1-2:每小时宕机的损失

宕机是最严重的性能问题。一切都将无法运转!也正是由于这样的原因,各家公司每年都会花费数百万美元来保证他们的内容不会被中断。宕机问题除了会损失收入、降低用户满意度外,也会让用户不知所措(见图 1-3)。

{%}

图 1-3:洛杉矶郡警察局的 Brink 警佐发的一条推文,回应民众询问警察局 Facebook 宕机的问题

在所有需要改进的性能问题中,保证正常运行对一个公司至关重要。移动端的宕机其实就是 App 崩溃。显然,首要的性能问题就是必须不能崩溃。如果一个 App 都不能正常工作,那它运行得再快又有什么用呢?然而,如果 App 运行得非常缓慢,或者让人感觉缓慢,用户也会有一种遇到宕机的感觉。

1.2.1 低性能就像持续的宕机

电力负载过大时,通常电力公司提供的电压就会比较低,灯光就会显得昏暗(冰箱很可能无法正常工作)。反应缓慢的 Android App 与此同理。用户仍然可以使用 App,但是滚动可能很卡,图像加载迟缓,整体上的感觉就是慢。就像电压管制对电力公司用户的不利影响一样,一个反应缓慢、性能低下的 Android App 使用起来就像不断反复着宕机状态一样。2015 年 3 月,惠普发布了一份“移动 App 还没能满足用户的预期”报告(http://bit.ly/1OOw5TB)。报告指出,用户对 App 反应迟钝和 App 崩溃一样反感(见图 1-4)。

{%}

图 1-4:低性能与崩溃:对用户来说是一样的

结合 1.1 节和 1.2 节中的数据,我们可以大致评估出 App 反应迟钝所造成的损失(见图 1-5)。一旦发生宕机,App 就会损失收益 8。如果知道当加载时间超过 4.4 秒时,转化率就会下降 3.5%~7%,我们就可以大致估算出反应迟钝的低性能 App 至少会每小时减少 6000~12 000 美元的收入。

8当然,有一些用户会在以后再购买,所以实际损失并没有估计的这么多。

{%}

图 1-5:低性能的 App 每小时造成的损失(基于 1 秒的网页延迟)

如图 1-5 所示,反应迟缓、低性能的 App 造成的损失每年都在增长,App 会逐渐失去收入和用户,最终一无所获——我希望这种悲剧永远都不会发生在你的 App 身上。

1.2.2 消费者对性能bug的态度

由于复杂的开发环境,总会有一些测试过程中遗漏的 bug 影响用户。最近的一项研究表明,44% 的 Android App 的问题和 bug 都是用户发现的,并且这其中的 20% 是用户通过 Google Play 的评价反馈给开发者的 9。开发者肯定不想通过差评来了解 App 存在的问题。差评不仅反应了某个用户对 App 的低性能的反感,还可能会使看到差评的用户拒绝下载,从而造成用户流失,进而影响 App 的收益。

9Perfecto Mobile,“Why Mobile Apps Fail: Failure to Launch,”Fall 2014, http://info.perfectomobile.com/rs/perfectomobile/images/why-mobile-apps-fail-report.pdf.

即使 App 被用户下载了,也不意味着 App 就已经被用户认可了。2014 年,被下载过的 Android App 中有 16% 只被启动了一次 10。面对选择繁多的 App 市场,用户都是很容易动摇的。如果 App 不能让用户满意,他们很快就会选择另一款同类型的 App。虽然用户卸载 App 的原因很多,但是应该说失望是卸载的首要原因。根据 Perfecto Mobile 的一项研究 11,让用户感到最失望的问题有以下几个:

10Dave Hoch,“App Retention Improves - Apps Used Only Once Declines to 20%,”Localytics, June 11, 2014, http://info.localytics.com/blog/app-retention-improves.

11查看“Why Are Your Mobile Apps Failing?(http://info.perfectomobile.com/rs/perfectomobile/images/why-apps-fail-infographic.pdf)”图表。

  • 用户界面问题(58%)

  • 性能问题(52%)

  • 功能性问题(50%)

  • 设备兼容问题(45%)

尽管性能问题在用户卸载 App 的原因榜上排在了第二位,但是可以清楚地看到其他几类问题也和性能息息相关。这足以表明,用户卸载 App 的主要原因仍是 App 的性能差。

如果 App 采用了最小可行产品(MVP)的方法——初始发布时存在 bug 和性能问题——那么当这些问题得到修复后:

  • App 依然拥有用户

  • 用户会更新 App

  • 用户会启动更新后的 App,看看有哪些改进

Twitter 的报告表明,50% 的用户在 3 天之内升级了他们的 App,并且 75% 的用户在 14 天之内升级到了最新的版本。12Twitter 发现以上情况是反复发生的。所以,只要 App 没有被用户卸载,你的更新版本(bug 修复和性能提升的版本)就有希望:

12查看“Scaling Android Development at Twitter”(https://youtu.be/T5qEnillTHc?t=6m43s),Twitter 的 Jan Chong 在 2014 年巴黎 Droidcon 上的演讲。

  • 被用户下载

  • 被用户打开看到性能的提升

1.2.3 智能手机电池寿命:矿井中的金丝雀

上一小节中的研究表明,用户更喜欢反应迅速、性能优良的 App。智能手机用户最关心的一个问题就是电池的寿命问题。尽管用户还没有普遍意识到,但是 App(特别是没有经过优化的)是耗电的主要原因。我把设置成百分数的剩余电量作为 App 性能的指示器。如果发现电量急剧降低,我就开始审查最近下载的 App 是否存在潜在的问题。

针对新 Android 设备的常见评论是,电池的寿命并没有得到改善。我们认为,如果这些评论者在新旧设备上安装了完全一样的 App,新旧设备的电池寿命就不会有什么明显的差别。迁移到新手机上的 App 依旧在消耗电量。在第 3 章中,我们将展示如何用设备的耗电量来衡量 App 的性能,以及如何提高 App 的性能来为用户节省电量。

移动设备上最耗电的就是屏幕、蜂窝式网络和 Wi-Fi,以及其他的信号发射器(如蓝牙或 GPS)。众所周知,App 必须在屏幕上使用,所以 App 使用移动设备中其他耗电部件的方式才是影响电池寿命的关键。

以往遇到设备的电池寿命问题,消费者通常会指责设备、设备制造商或者运营商。不过现在已经不再这样了。事实上,35% 的消费者曾因为过度耗电而卸载了一款 App。13 虽然能够展示 App 耗电量的消费者工具才刚刚进入市场,但是它们的质量在快速地提升。值得庆幸的是,节省电量的开发者工具也已经开始出现了。我们将在第 3 章中讨论这些工具。在设计和开发 App 的过程中,开发者最好认真地对待电量和电源问题。

13Hewlett-Packard,“Failing to Meet Mobile App User Expectations: A Mobile User Survey - Dimensional Research,”http://bit.ly/1LXYPec.

1.3 App性能问题的检测

在发布 App 之前,发现性能问题的最好方法就是不断地测试。在第 2 章中,为了使 Android 系统有更好的兼容性,我们将介绍应该测试的所有机型。后续的章节将介绍很多可帮你诊断性能问题的工具,以及解决这些问题的技巧。一旦 App 发布到了市场上,就要确保 App 能将用户问题和使用情况反馈给开发者。阅读这些反馈报告并分析其中的信息更有利于开发者解决已发现的问题。

模拟和真实用户监测(real user monitoring,RUM)是两种常见的性能测试方法。

1.3.1 模拟测试

实验室的模拟测试需要创建特定的测试用例,或者是在 App 上模拟用户行为。后面将要讨论的很多和 App 一起运行的工具在寻找异常的时候都需要测试用例来模拟运行。这是一种发现、解决 bug 和性能问题的好方法。然而,Akamai 给出的每天 19 000 份独特的 Android 用户代理报告指出,14 并不是所有的场景都可以用测试用例来模拟。

14Alec Heller,“UA Strings Are Terrible: Adventures in Server-side Device Characterization for Site Performance,”Velocity 2014: Building a Fast and Resilient Business, June 25, 2014, http://velocityconf.com/velocity2014/public/schedule/detail/35211.

1.3.2 真实用户监测

并不是所有场景下的测试都可以在实验室进行,所以收集真实的用户性能数据是十分必要的。在 App 中插入分析代码库来收集用户的真实数据,能够让你快速地了解用户可能面对的问题的类型。这样你就可以解决所发现的用户问题和 bug。解决问题之后,想办法将用户问题复制到实验室,这是避免以后的发行版 App 出现此类问题的聪明做法。第 8 章将探讨一些从 RUM 工具中获取到的结果。

1.4 总结

本章中给出的证据强有力地表明,性能好的 App 的加载、滚动和其他用户事件都足够快速平滑。性能差的 App 导致的用户流失率和 App 崩溃差不多。因此性能差和持续宕机都会失去订单量、销售额和用户(不管是现在还是未来)。相信这些证据足以说服你(也足以说服你的经理和领导)。让我们来解决所有的性能问题并让 App 更快地运行吧!

目录