在前一篇文章中，我们讨论了监控app性能的重要性。现在，我们要告诉你具体如何去做到这一点。我们已经和世界上几个最受欢迎的app开发团队讨论过了构建流畅App的最佳实践，团队包括WeChat、Yahoo News Digest应用。根据我们的经验和与那些顶尖的开发者讨论，我们总结发现开发一个成功的App中最重要的实践是建立一个性能优化流程：
一直监控app性能对当你的app性能不佳时去监测问题非常。一旦发现某个性能问题，一定要集中所有力量解决根本问题。检测问题可能需要更多的措施和详细的数据。侦测到问题的原因，仅仅对它进行修复是不够的，你还必须得重新评估你的app性能，验证你的修改已经生效了。这就是更多的措施。
措施
有两个性能指标与用户体验(UX)密切相关。首先，我们来讨论响应时间：你的app响应用户操作需要多长时间（比如启动app、打开新的文章、加载联系人列表等）。理想情况下，你的app响应这些操作应该非常快，这有助于提供更具吸引力的用户体验。
响应时间的一个关键之一是启动时间。App的启动是给用户第一体验感，第一印象非常重要。事实上，一份研究数据表明79%的用户在删除app之前会再次重试有问题的app一次或两次。
这里有些来自NimbleDroid的建议，他拥有多年的软件性能优化经验。
建议1：限制app的启动时间小于2秒
我们建议app的启动时间不超过2秒，这是用户期望的中等时间长度。与Web性能类似，47%的用户期望加载一个页面的时间不超过2秒，并且移动用户的耐心更小，他们希望能快速顺畅地使用。
建议2：消除鸿方法
第二个重要指标是平滑性。虽然具有很短的响应时间非常棒，但是响应操作本身应该足够平滑，将“停滞”最小化。用户很善于发现停滞现象，这意味着即使是很小的结巴也很能反应出你的app的用户体验感。
为了理解平滑性，你可以收集你的app每秒钟的帧（FPS）和帧定时数据。然而，需要注意的是这个数据并不能够告诉你的app性能问题的原因，也就是说它不能明确是哪个方法使得你的app出现停滞。
在Android中，UI线程（即主线程）是唯一可以更新UI的线程。为了维持60FPS的刷新频率，UI线程必须在大约16ms内绘制完每个帧。如果在UI线程中，任何方法的调用时间超过这个时间，那么app就必须失去一个帧，从而产生了一个异常的停滞。更糟糕的是在这个时间期间，app不会相应用户操作，因为UI线程卡住在一个方法调用中。
在实际开发中，不能确定每个方法在UI线程中被调用的延时小于16ms。32ms可能会更加现实点，调用方法时间超过这个时间的方法称为鸿方法，因为它们引起app出现“卡顿”。去掉所有鸿方法非常有利于提高app的平滑性，从而为用户提供更好的用户体验。
建议3：尽可能早的检测
Okay！监测与UX相关的指标很重要，但是，监测这些标准的频率是多久才合适呢？每次build的时候？每天build时？每次发布前？发布后？你应该衡量下什么时候来执行检测好些，越早跟踪检测软件的标准，就会越早发现和处理性能问题。Yahoo团队安排每次发布版本之前，WeChat团队把它安排在app每天build的时候。
分析
建议4：了解常见性能问题
优化软件的关键是了解常见的性能问题并把它们从你的代码消灭掉。在我们分析的下载量到达500万的apps当中，发现开发者往往是构建的应用在桌面运行非常快，但是在移动端运行就会明显变慢。比如，ClassLoader.getResourceAsStream()方法加载一个3K的jar资源在MacBook Air上需要大约7ms，而这个操作在Nexus 7 2013上要耗时大约1700ms。 这说明在Android中getResourceAsStream的实现在它的第一次调用时执行了大量额外的工作，如索引APK文件中的所有资源、验证APK文件的权限、解析它的manifest。像这样的操作非常消耗CPU，从而使得app运行明显变慢，etResourceAsStream使得Walgreens app运行变慢1.7秒。NimbleDroid 编译了一系列方法来避免在你的Android app中使用它，可以从这里获取。
建议5：第三方SDK并不总会给你惊喜
有时候性能问题是由你使用的第三方SDK引起的，并不是你自己的代码问题。这样的问题特别难侦测到。像非常流行的一Java时间库org.joda.time，可能你在以前的Java项目中使用过它，结果是它在你的app启动时仅仅创建一个org.joda.time.DateTime()对象就使得你的应用明显变慢。这是因为org.joda.time.DateTime() 使用了getResourceAsStream()去避免从APK文件中加载时间区。
优化
修复运行缓慢的代码可以是一个噩梦般的过程。有数百种可能使得app陷于卡顿，发现app运行缓慢的原因可能要耗时数个星期。然而，有些常见修复准则。你要么使用更高效的数据集、算法、接口实现，或调用的后台线程不会使UI卡住。遵循上面的准则，你可使得你的app更高效，做出的产品会令人更喜欢。
