作者 / Google 和 Facebook 团队
撰稿 / Google Android 团队的 Kateryna Semenova 和 Facebook 团队的 Tim Trueman、Steven Harris、Subramanian Ramaswamy
简介
缩短利用的启动工夫并非小事，咱们必须深刻理解其影响因素。往年，Google Android 团队和 Facebook 利用团队始终在单干钻研这方面的量化指标，并共享优化办法，以改善利用启动状况。Google Android 的公开文档中蕴含了很多对于 利用启动优化 的信息。这里咱们想进一步分享其在 Facebook 利用中的实际状况，以及哪些因素有助于改善利用启动性能。
当初，每个月有超过 29 亿人应用 Facebook。Facebook 帮忙人们构建社区，并让世界更严密地分割在一起。用户会在这里分享生存的霎时，理解和探讨正在产生的事件，建设和造就人际关系，独特单干以发明支出机会。
Facebook 利用开发者则致力于确保用户享受最佳体验，并让利用在任意设施、任何国家 / 地区和不同网络条件下都能流畅运行。Google Android 团队和 Facebook 团队精诚合作，在利用启动工夫的指标定义和最佳实际上达成共识，并在这里分享给大家。
从哪里开始
首先天然是测量利用的启动工夫。您可借此获悉用户启动体验的衰弱水平，追踪启动工夫好转的状况，并计算进行改良须要投入的资源量。归根结底，您的启动工夫须要与用户满意度、参与度或用户增长相关联，以确定投入的优先秩序。
Android 定义了两个掂量利用启动工夫的指标: 齐全显示所用工夫 (TTFD) 和 初步显示所用工夫(TTID)。尽管您能够进一步将其划分为冷 / 暖启动工夫，但本文不会解释它们之间的区别，而 Facebook 的办法是，掂量和优化与利用交互的所有用户所经验的启动工夫 (有些是冷启动，有些是暖启动)。
齐全显示所用工夫 (Time-To-Full-Display, TTFD)
TTFD 会记录您的利用实现渲染并可供用户交互和应用时所需的工夫，可能包含显示本地存储或来自网络上的内容所需的工夫。如果网络较慢，这可能会破费一段时间，并会视用户的应用设施而有所差别。因而，咱们有必要立刻展现一些内容，让用户看到利用启动的过程，而这就要提到 TTID 了……
初步显示所用工夫 (Time-To-Initial-Display, TTID)
TTID 会记录您的利用显示背景、导航、可疾速加载的本地内容、加载较慢的本地或网络内容的占位块所须要的工夫。TTID 应该是用户能够到处导航并返回其指标的所需工夫。
不要扭转太多: 有一件事须要留神，就是在 TTID 和 TTFD 之间利用内容的视觉变动问题，例如在页面里先展现的是已缓存的内容，而后在网络内容加载实现后忽然切换页面内容。这种忽然的变动可能会让用户感到不快和丧气，所以请确保您的利用可在 TTID 期间显示足够有意义的内容，尽可能地向用户展现其将在 TTFD 期间看到的内容。
达成用户指标
用户拜访您的利用是为了获取内容，这可能须要一段时间实现加载，而您心愿利用能够尽快把这些内容出现给他们。
Facebook 利用开发者专一于基于 齐全显示所用工夫 (TTFD) 的指标，蕴含显示所有内容和图像，因为这代表了用户拜访利用的残缺体验。开发者想要晓得，网络加载内容和图像是否破费了较长时间，或者加载失败，以便让团队能够从头到尾改善整个启动体验。
良好的 TTID 和 TTFD 指标该当是多少？
Facebook 将启动工夫指标设定为他们认为利用启动耗时 “ 不佳 ” 的百分比，即任何 TTFD 超过 2.5 秒的启动或启动失败的局部 (例如，图像无奈加载或利用解体)。Facebook 致力于通过改良工夫超过 2.5 秒的启动，使其解脱 “ 不佳 ” 状态，以及修复导致启动失败的问题，从而升高启动工夫 “ 不佳 ” 的比例。抉择 2.5 秒是因为，钻研表明，这对于 Facebook 用户来说很重要。这也与 Web Vitals 为网站倡议的 最大内容绘制 (LCP) 指标相符。
与 TTID 相比，提供残缺体验，尤其是用网络获取最近的内容，会让您的 TTFD 启动指标看起来相当迟缓。而这其实是一件坏事！它反映了用户对您利用的实在体验。您对此所做的改良，可能会像 Facebook 那样，进步用户的利用使用率以及对其性能的认可。
测量 TTFD 的辣手水平可能会视您的利用而异。如果太难，无妨从 初步显示所用工夫 (TTID) 着手。尽管因为占位块或图像的存在可能会导致无奈量化局部内容的加载性能，但这仍然是一个着手点，毕竟这部分也是用户日常与利用交互的内容 (尽管不是全副)。
检测 TTID
在 Android 4.4 (API 级别 19) 及更高版本中，logcat 提供了 “Displayed” 值，用于记录从启动过程到实现在屏幕上绘制相应 Activity 第一帧所通过的工夫。
报告的日志行相似于以下示例:
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms检测 TTFD
要检测 TTFD，只需在您的所有内容都在屏幕上显示后，在 Activity 中调用 reportFullyDrawn())。请确保蕴含替换占位符的任何内容，以及您渲染的任何图像 (务必计算图像自身显示的工夫，而不仅是其占位符显示的工夫)。在您调用 reportFullyDrawn() 后，就能够在 logcat 里看到它:
ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms来自 Facebook 利用开发者的倡议
多年来，Facebook 利用开发者始终在为泛滥设施、平台以及国家 / 地区的数十亿用户优化利用。本节分享了 Facebook 利用开发者在优化利用启动时使用的一些要害教训。
- 先了解，再优化 – 在定义了好的启动指标后，您就应该用其检测利用的具体表现，这有助于了解利用的启动性能并设置改良优先级，为您的用户带来更好的体验。从量化检测动手，一来能够证实存在晋升空间，二来能够确定重点致力的方向，并且在开始优化后能看到具体的改良成果。
- 首先修复解体 – 在您检测启动情况之后，请确保利用的确能够启动。启动时的解体是最让人丧气的事件，也是让用户放弃您利用的最快形式，请优先断定和解决这些问题。
- 切莫遗记性能可靠性 – 另外，不要遗记性能可靠性。您的利用是否能迅速展现一些内容，但却未能加载所有内容，或者加载图像的耗时过长？您的利用可能启动得很快，但未能按用户要求运行 (比方，点击按钮不起作用)，这些因素都会好转用户体验。
- 以一致性为指标 – 与具备一致性但启动工夫长于平均水平的性能体现相比，不统一的性能体现更令人丧气。察看启动工夫的长尾，查看是否存在缓解这些启动迟缓状况的修复措施或办法。请务必查看您的离线和有损网络启动性能的启动行为。
- 并行工作 – 大多数当代手机都有至多 4 个 CPU，所以有空间解决多任务！除非万不得已，否则不要阻塞主线程。将 I/O 和非关键门路挪动到主线程之外运行。
- 提早执行 – 在实现了牢靠且统一的启动后，请查看您为显示首个可见画面的内容所做的所有，是否有一些工作是不必要的？在利用启动之后，请把与启动体验不间接相干的任何工作移除、延后、或者移到后盾 (然而留神察看利用的响应能力，并将其作为一个管制指标)。试着让您利用的 onCreate() 尽量放弃轻量。您还可应用 Jetpack App Startup 开发库，以便在利用启动时初始化组件。这样做时，请确保依然加载所有启动流动所需的模块，并且留神在提早加载的模块可用时不要造成闪动。
- 显示进度，然而不要过多地扭转界面 – 请不要在启动期间适度扭转要展现给用户的内容。如果用户尝试点击内容，后果它却发生变化，并失去了谬误的后果，这是非常令人丧气的。这相似于 Web Vitals 中的 累积布局偏移 (CLS) 概念。对于时长不定的网络端加载，请略过启动画面，并显示异步加载的占位符。您能够思考在这个内容区域应用不太显眼的 动画 来反映加载状态。确保具体加载的内容构造和占位构造尽可能地匹配，以便在内容加载实现后实现平滑过渡。
- 缓存 – 当用户第一次关上利用时，您能够为一些界面元素展现加载指示器。在用户下次访问您的利用时，您可在加载更多最新内容的同时，显示这些已缓存的内容。您是否曾在利用加载实现后，看到咱们在 Facebook 的动静更新中展现从网络获取到的最新内容？如果能够，请将网络加载过程从启动中排除进来，这样能够加快速度，并实现更统一的启动性能体验。然而，正如下一点所倡议的那样，显示已缓存的内容并不总是最佳做法，因而，咱们要掂量并找到对用户更敌对的因素。
- 快慢联合 – 新鲜，相干，但显示速度稍慢的内容，比疾速显示的过期内容更好。间接向您的用户展现最新的内容，比启动超级迅速，但在启动不久之后就得刷新内容要更有价值。您能够评估以下做法是否成果更好: 做出优化，以尽量疾速地显示最新内容，并设置超时工夫，以在网络较慢时显示较旧的内容；在网络离线时，间接显示既有的内容。
- 统一的会话开始界面 – 在您的利用长时间处于后盾后，您可能会发现，将用户重置到您的主内容界面是很好的做法。利用能够在设施的内存中保留很长时间。
- 查看外部工作原理 – 如果您 跟踪 并切实查看了启动期间执行的内容，或者罗唆应用调试器，您可能会有让人惊喜的新发现！在充沛理解了启动的要害门路后，您就能够高效地优化利用性能。在发现了具备最大晋升空间的因素后，就在该方面做出投入。
- 确保能轻松实现正确的后果 – 开发者有时会应用并非最优的模式和架构，因为做事件的办法太多了。请放心大胆地整合您利用中应用的模式，而后加以优化，以便轻松抉择适合办法，从而实现工作并让其高效运行。即时代码执行 (eager code execution) 模式就是一个很好的例子: 如果您正在执行第一次全屏绘制后才须要呈现的内容代码，那么性能体现必定会蒙受侵害。您无妨采纳提早执行的模式，仅在启动的要害门路受到阻塞时，再以即时执行形式运行代码。
Google Android 团队给出的倡议
Google Android 团队对于掂量和优化利用启动的倡议请查阅官网文档 “ 利用启动工夫 ”。
本节总结了一些实用于所有 Android 利用开发者且与上述 Facebook 倡议相干的要点。
- TTID 和 TTFD 是利用启动的重要指标。Google Android 会在 Play 管理中心 依照 TTID 对利用进行排名。TTFD 是 TTID 的母集，因而 TTID 的任何改良措施都同时实用于这两个指标。
- 调用 reportFullyDrawn() 来报告 TTFD，让零碎晓得 Activity 已实现渲染。为改善利用启动速度，Android 零碎会进行调整，以优先解决在调用 reportFullyDrawn()) 之前产生的工作。在您的利用处于齐全可用状态时调用这个办法能够改善利用的启动工夫。每个利用都应该应用这个 API！切莫遗记用其掂量利用体现状况。
- 用 Android Vitals 监控您利用的技术性能，有助于改善利用启动体验。通过 Play 管理中心，您能够查看各种数据以帮忙您理解和改良利用的启动工夫等性能体现。
- 咱们晓得，与在开发阶段修复谬误相比，生产环境中的修复老本要高得多。这点也同样实用于性能方面。您能够借助 Jetpack Macrobenchmark: Startup 设置您的利用，以在晚期应用本地性能测试掂量利用启动状况。
- 正如咱们下面探讨的那样，量化检测是理解和优化启动的要害。Android 提供 零碎跟踪 服务，能够帮忙深刻开掘和诊断利用启动问题。
- 通过 Jetpack App Startup 开发库，咱们能够间接高效地在利用启动时初始化组件。开发库和利用的开发者都能够应用此库来简化启动流程，并明确地设置初始化程序。您能够应用此库设置在启动期间的什么时刻加载哪些组件。
- 影响利用启动的一个 典型问题 是在初始化时做了太多工作。比方，填充过大或简单的布局、阻止屏幕绘制、加载和解码位图、垃圾回收等。
总结
本文介绍了一些要害的启动工夫指标和优化最佳实际，以改善启动体验，帮忙晋升 Facebook Android 利用的用户参与度和使用率。本文还分享了 Google Android 团队倡议的指标、开发库和工具。任何 Android 利用都可从本文分享的策略中受害。请大家动起手来，认真量化利用的启动状况，并为用户打造疾速且令人愉悦的利用启动体验！
欢迎您 点击这里 向咱们提交反馈，或分享您喜爱的内容、发现的问题。您的反馈对咱们十分重要，感谢您的反对！