Android App优化之性能分析工具 - 简书
Android App优化之性能分析工具
今天聊下个人比较惯用的一些App性能测试和分析工具, 先上个图:![性能分析工具]
tools_mind_node
本文暂不对工具的使用做过多的深入.在后续的具体实例中会具体说明怎么用这些工具来达成分析目的和解决问题的.
1, 官方工具
一般来说, 学习一门新的技术, 最应该做的就是阅读其官方文档, 那是最权威的.Android本身给我们提供了很多App性能测试和分析工具, 而且大部分都集成到Android Studio或DDMS中, 非常方便使用.
1.1 StrictMode
顾名思义, "严格模式", 主要用来限制应用做一些不符合性能规范的事情. 一般用来检测主线程中的耗
时操作和阻塞. 开启StrictMode后, 如果线程中做一些诸如读写文件, 网络访问等操作, 将会在Log console输出一些警告, 警告信息包含Stack Trace来显示哪个地方出了问题.
主要用来做主线程优化分析
1.2 Systrace
Systrace是一个收集和检测时间信息的工具, 它能显示CPU和时间被消耗在哪儿了, 每个进程和线程都在其CPU时间片内做了什么事儿. 而且会指示哪个地方出了问题, 以及给出Fix建议.
其以trace文件(html)的方式记录. 可以直接用Chrome浏览器打开查看. 界面如下:
作用很多, 个人主要用来分析UI的绘制时间, 结合Hierarchy Viewer来提升UI性能.
也可以用来发现耗时操作.
1.3 Hierarchy Viewer
Hierarchy Viewer提供了一个可视化的界面来观测布局的层级, 让我们可以优化布局层级, 删除多余的不必要的View层级, 提升布局速度.
Hierarchy Viewer
有必要说明下的是:上图红框标出的三个点是关键分析数据. 左起依次代表View的Measure, Layout和Draw的性能. 另外颜色表示该View的该项时间指数, 分为:
* 绿色, 表示该View的此项性能比该View Tree中超过50%的View都要快.
* 黄色, 表示该View的此项性能比该View Tree中超过50%的View都要慢.
* 红色, 表示该View的此项性能是View Tree中最慢的.
用来做View层级分析, 可以分析出View Tree中的性能阻塞点, 以便对症下药, 提升布局性能.
Hierarchy Viewer需要Root的机器(产品机没有开启ViewServer)才可以执行.可以使用来协助我们在未Root的机器上使用Hierarchy Viewer分析.
1.4 TraceView
一个图形化的工具, 用来展示和分析方法的执行时间.
分析方法调用栈以及其执行时间, 优化方法执行.
1.5 Memory Monitor
内存使用检测器, 可以实时检测当前Application的内存使用和释放等信息, 并以图形化界面展示.
Memory Monitor
用来做内存分析, 内存泄露排查的不二之选. 可以结合heap viewer, allocation tracker来分析.
可以导出hprof文件结合第三方的工具分析泄露点.
1.6 Other Monitor
Android Studio的Monitor还提供了其他三个Motinor --- CPU, GPU, Network.
分别用来跟踪监测CPU,GPU和Network的使用极其变化, 可以作为网络优化, 流量优化和渲染优化等的一个指导. (个人并不常用到~)
Android的开发者模式中也提供了较多的用来监测性能的选项, 可以用下:
Developer options
2, 第三方工具
以下工具全部开源, 开源万岁...
2.1 Google的Battery Historian
Google出品, 通过Android系统的bugreport文件来做电量使用分析的工具.
用来做电量使用分析.
2.2 网易的
针对Android App的CPU, 内存, 网络, 电量等多项综合的测试分析.
比官方工具更适合国人使用来做App的整体性能分析.
2.3 Square
Square出品, 必属精品.
类似与App探针的内存泄露监测工具.
集成到App中, 用来做内存问题预防最好不过了.
2.4 AndroidDevMetrics
一个library, 用来检测Activity生命周期执行性能, Dagger2注入性能以及帧率性能的工具.
如果你的应用使用的Dagger2, 这个就比较必要了.
没有侧重的提, 是因为这个工具在ADT时代比较常用, AS2.0之后, 本身的Memory Monitor越来越强大, 结合日益完善的第三方工具基本上可以完成内存方面的优化了.
欢迎大家分享自己常用的App性能分析工具, 共同学习~^_^一说起，测试员想到肯定是去检查文件，功能，API，性能并确定软件是否安全，以及关于软件特定部分的其他事项。但是对于测试，测试员不得不基于用户移动使用模式考虑移动相关的功能。
　　本文是基于我的经验而写的。作为一名敏捷团队的软件质量保证经理，我一心投入iPhone，，WindowsPhone7的移动apps和移动webapps。在XING移动团队的日常工作以及与其他移动测试专家交流的过程中，我深刻了解了移动测试工作的困难。渐渐地，我明确了什么是帮助改进同事们和我的测试工作并为用户提供更高质量app的移动最佳做法。
　　每项开发的新功能都需要进行测试。移动app测试中功能测试是一个重要方面，移动测试员应该要进行手动测试和。刚开始测试时，测试员必须把移动app当做"黑盒"一样进行手动测试，看看提供的功能是否正确并如设计的一样正常运作。除了经典软件测试，像点击按钮看看会发生什么，测试员还必须执行更多功能的移动设备专门的测试。
　　如今，现代移动设备都有触摸屏，要求多点触控动作来与它们互动。设备可以是纵向或横向显示屏。它们提供动作，倾斜和螺旋传感器。它们有不同的接口可以连接其他设备或服务，比如GPS，NFC，照相机，LED等等。
　　移动软件测试员必须确保app的所有特定设备功能在app里都能用。移动设备的种类这么多，测试时要将所有的覆盖是不可能的，所以功能测试时测试员要专注于他们app的关键之处。什么是真的简单有效的呢？设备旋转。我测试工作期间发现有许多bug仅需将设备从纵向旋转为横向再旋转回来就好了。
　　除了整个手动测试过程，测试自动化对移动app也很重要。每个代码变化或新功能都可能影响现存功能及它们的状态。通常手动回归测试时间不够，所以测试员不得不找一个工具去进行自动化回归测试。现在市面上有很多移动测试自动化工具，有商业的也有开源额，面向各个不同平台，如Android，iPhone，WindowsPhone7，BlackBerry以及移动webapp。根据开发策略和结构，质量保证专家需要找出最适合他们环境的自动化工具。
　　安卓的话，就有Robotium[ROB01]，Robolectric[ROB02]，Roboguice[ROB03]，MonkeyTalk[MON01]，Monkeyrunner[MON02]，NativeDriver[NAT01]andCalabashforAndroid[CAL01]等开源工具。自动化工具Robotium已经变成开源界的实际标准。它用起来很简单且是基于安卓测试设备的。
　　iPhone的测试自动化工具包括KIF(KeepItFunctional)[KIF01]，UIAutomation[UIA01]，MonkeyTalk[MON01]，CalabashforiOS[CAL02]，Frank[FRA01]，Zucchini[Zuc01]等等。所有这些工具也可以在设备或iOS模拟器上模拟真实用户互动。选择一个工具对测试自动化并不容易，但做决定时有一点要牢记，因为很重要:测试自动化应该使用同样的编程语言作为产品代码。如果测试和产品代码用一样的语言去写，那对测试员和开发员都有好处，因为这就使得他们做配对代码时可以轻松些。测试员可以和开发员在同一水平进行交流，他们可以执行测试和产品代码的代码审查。对于测试自动化，开发员可以用他们习惯的语言编写他们自己的脚本。
　　总结：
　　把app作为"黑盒"进行测试并试着中断它。
　　打开移动app的每个屏幕并将设备从纵屏变为横屏再变回纵屏。
　　别忘了去测试设备特定的功能，比如传感器和通信接口。
　　为移动app编写测试自动化脚本。
　　选择一个适应公司策略和结构的测试自动化工具。
　　测试和产品代码应该用同一种语言。
　　非功能测试
　　移动app测试的另一重要方面是移动app的非功能需求。移动app在推出市场或进行进一步开发前，移动测试员有许多需要测试的问题。
　　早期开发阶段要进行的第一个测试应该是实用性测试。通常是由alpha用户或同事进行的。走进一家咖啡馆或餐厅，问问里面的人他们的app使用情况。让他们看看现阶段开发的第一个版本并收集反馈，看看用户是否能很好地使用新功能，以便得出第一印象。
　　检查app的性能。将推出的版本与当前版本做一番比较，看看性能是一样？更好？还是更差？将app安装到旧的设备上，看看该app在旧设备上是否仍能运作，无论硬件设备好或差。最先进的设备也一样要这么做。
　　测试，，彩信，微博或其他通知进来时app的反应。使用app时检查一下电量。确保测试过程测试设备是充满电的并每十分钟检查一下电池使用情况，看看该app有没有太耗电。在低电量时把app安装到设备上看看会发生什么。检查app的内存使用情况。如果app在本地文件系统中存储数据，测测不同内存卡的使用情况。想想看本地存储快满时会发生什么呢--app会崩溃或弹出出错提醒框来通知用户吗？
　　测试app的安装和删除过程。更重要的是，测试从老版本升级为新版本的过程。或许本地已经改变了，这样就会引起一些严重的迁移问题。
　　App被本地化了吗？测试员需要用不同的语言测试app。记得在不同的网络载体上以不同的网速进行测试。确定该app在GPRS，EDGE，UMTS，LTE和WiFi环境下都能运作。
　　别忘了检查网络连接不好或完全掉了时app会怎么反应。飞行模式下使用该app看看如果一个请求失败了会发生什么。将测试设备连接到电脑上并检查开发日志文件有没有例外、警告或其他奇怪的异常之处。这些只是移动测试员和开发员开发和测试一个app时应该考虑的非功能需求中的一部分。每方面都检查到位是绝不可能的，因此整体团队应该支持QA成员尽量覆盖更多方面以防用户得到不好的体验。
　　总结：
　　做实用性测试。
　　比较app已推出版本和新版本的性能。
　　检查电话，短信，彩信或微博或进来时app的反应。
　　检查测试设备的电量。
　　测试app的内存使用情况。
　　安装并删除app。
　　测试从旧版本升级到新版本的过程。
　　检查语言的转换。
　　在不同的载体和网络连接，如GPRS，WiFi，orLTE，环境中使用app。
　　检查日志文件的错误或例外。
　　测试设备--碎片
　　对于一个移动质量保证者来说，关于移动测试设备的关键问题是，"测试该用哪个工具比较好呢？"这个问题必须解决，因为无法在每台设备上都测试一遍！就此来看，移动设备市场上有两大玩家：Android和iOS!但是因为地理位置的原因，一些其他平台也常用到。有，BlackBerry，webOS，SymbianOS，以及功能机。
　　几乎每个平台都有不同的供应商在售卖拥有不同硬件，软件规格和定制用户界面的智能机。比如安卓，就有像Samsung，HTC，ASUS，LG，Motorola，Sony，Huawei等供应商。这是设备碎片的一个重要例子，且要找到恰当的测试设备真的很难。移动网页是另一个相当难搞的问题，因为移动种类太多，如：Safari，OperaMini，Dolphin，AndroidandRIMnative，GoogleChrome，Firefox，InternetExplorer9以及其他功能机浏览器！那么到底该选什么测试设备呢？就用最新的浏览器版本吗？把市场上的每种设备都买来？还是使用模拟器？
　　在此对模拟器小注一下：别用模拟器测试！它们或许对基本测试有所帮助，但其结果与真机上的结果却是不同的。
　　以我之见，解决这个测试设备问题的一个不错的主意就是将设备和浏览器组合起来。比如，移动测试员可以根据他们的硬件和软件规格将设备组合起来。每个组合确定一个优先事项，比如A=最高，B=平均，C=最低。每组都包含根据平台和供应商分配到那一类的设备。
　　可能的组合概述：
　　组1，优先事项C：CPU和RAM小，分辨率低的小设备。旧的软件版本和浏览器
　　组2，优先事项B：一般CPU，RAM&512MB，显示屏大小和分辨率好的中档设备。软件不是最新的。
　　组3，优先事项A：双核/四核CPU，RAM&512MB，分辨率高的高档设备。最新的软件版本。
　　这三组涵盖了一个特定平台上的绝大多数用户，也代表了市场上适合这一组的其他。这可以减少开发和测试过程中要求的工作。
　　总结：
　　组合并选出优先测试设备和浏览器版本。
　　不要用模拟器进行测试。
　　组合工具
　　正如之前所提到的，移动测试员必须对移动app进行测试自动化以保证代码变化不会影响现在的功能。另一个最佳做法就是组合测试工具并将它们集成为一个连续的集成服务器以便从中心开始执行这些工具。开发员需要为他们的代码写以确保每个细小的组件的且如期运作。另外，使用像Robotium或KeepItFunctional一类的工具进行端到端的检查测试，就像用户一样，很有用。
　　总结：
　　组合测试工具并将之集成为一个连续的系统。
内部Beta版本
　　如果一个移动团队想要早点与移动app的beta测试员沟通，他们可以创建他们自己的内部app商店，比如安卓的和iPhone.的。有了hockeykit[HOC01]工具，团队就可以通过公司WIFI把app的新版本传给同事。这是从同事那获得重要反馈的有效方法，尤其是如果团队或测试员没机会向外界展示该app。Hockeykit也提供关于怎样测试该app以及同事们用了哪种OS版本和设备的有用数据。它还包括一个crashreporter以便看到导致现开发版本错误和崩溃的原因。
　　总结：
　　用内部beta版本获得早期反馈。
　　了解顾客
　　如果开发员和测试团队了解以后将会使用app的顾客的话，移动测试就会更加有效。收集顾客信息的好地方是特定供应商的app商店（AppleAppStore，GooglePlayStore，WindowsMarketplace等）。如果一个团队在这些商店中已有了一款app，他们就会获得关于顾客使用的设备，软件版本，语言以及载体的信息。移动网页，却没有app商店提供相关用户数据。所以，收集关于移动网页里所使用的"用户代理"（设备，浏览器）的信息就有意义了。意识到这点，团队就可以优化各种设备和软件版本并减少花在开发和测试它们上的精力了。
　　除了用户数据，app商店里的顾客评论也需要细细整理以便收集重要的反馈以及他们对新功能的期待，并对所报bug做出回应。
　　总结：
　　了解你的顾客所使用的设备和软件版本
　　利用来自供应商市场的数据
　　认真对待app商店里的评论
　　在论坛社区主动出击
　　这是最后一个最佳做法，它与日常移动测试工作不直接相关，但或许可以帮你从不同的角度思考并获得新的想法。
　　在社区里做一个主动积极的软件测试员，就像：在这样的社区里，软件测试员可以和其他（移动）质量保证专家就各种测试话题交流观点意见。他们可以共享知识，帮助其他人解决他们遇到的问题。测试员可以在写测试用例时得到很棒的想法：关于如何写出好的bug报告，并且还可以提高他们自己的测试和测试自动化技能。
阅读(...) 评论()更多公众号：iTestTrain啄木鸟软件测试培训网目前提供的课程包括有： 《软件开发质量管理培训》， 《大数据理论与实践》， 《如何帮助传统企业利用大数据进入互联网+时代》， 《软件测试基础知识培训教程》， 《云计算测试培训》最新文章相关推荐搜狗：感谢您阅读移动App测试中的最佳做法，本文可能来自网络，如果侵犯了您的相关权益，请联系管理员。QQ:你花了很多心血、汗水和眼泪来构建一个App，然后才发现你的产品根本不是你幻想的那样。 这个很耳熟吧？
如果你的App无法留住用户，那你App的可用性和长期吸引性就有问题。但是互联网是个很容易通过跟踪发现App问题的地方。下面我们就介绍一些方法和工具，能让你的App在正式面市前看起来不那么恶心。
做一个职业的评估：可用性测试工具uTest
新手设计师常犯的错误就是违反基本的设计和可用性原则，有经验的设计师在审计可用性的时候就可以把这些问题标记出来。所以在真正面向用户前，使用。
检查用户是否认可你的价值主张：登陆页面测试工具Clue
也许你认为你的登陆页面完全阐述清楚了你的App是多么强悍，但是你的说明语言可能很不清楚或者扯得不相关，使用测试，你可以快速创建一个内存测试来看看用户对你的实际页面有什么反馈。
跟踪正确的分析数据：App数据分析工具
Flurry 和Google都提供免费的App分析报告，比如用户会话长度和用户使用频率。另外一些先进的移动分析平台包括Kontagent, Localytics, 以及Apsalar。它们会提供更复杂的用户分类、使用故障、留存率和转换率分析功能。
远程用户行为记录工具
找到你的目标用户进行测试，建立面对面的可用性研究非常耗时。如果想节省时间，可以使用远程移动可用性测试服务和，它们可以提供目标用户第一次使用你程序的时候的赞赏或者困惑的表情视频。
热点地图工具跟踪用户操作和路径
用户经常会在你意想不到的方式和手势使用App，所以移动平台上你可以使用触摸跟踪工具，来可视化用户来源和手势。该工具也会构建用户路径向你展示用户如何使用App、用户使用时在哪里反弹了。这样你就知道用户是否在关注你认为正确的事情，是否在你认为重要的地方采取了必要步骤。
分割测试工具
分割测试也叫A/B测试，一般通过运行多个设计版本来决定哪一个是最棒的的，可用的工具包括, , 和 ，这对帮助非技术人员设计测试多个代替品是非常有用的，比如测试App内购买的界面和文字教程。
而且这些分割测试的结果很直观，比如Swrve一个著名案例曾发现App内购买价格提高竟然没有导致销量下降。
团队协作工具Notable：与你的设计团队随时讨论和反馈
做完了上面所有的用户测试后，你会在哪里记录你的这些测试反馈？就是专门的一个协作工具，可以让你批量上传和注释你的App截图，方便你和你的团队分享和讨论。