共计 12139 个字符，预计需要花费 31 分钟才能阅读完成。
图片来自：https://unsplash.com/photos/_…
本文作者：ZZG
前言
作为 APP 体验的重要环节，启动速度是各个技术团队关注的重点。几百毫秒启动耗时的增减都会影响用户的体验，并间接反馈在留存上。心遇 APP 作为一款用于满足中青年市场用户社交诉求的利用，对各个性能档次的手机型号，都要求有良好的启动体验。因而，随着用户量快速增长，启动优化作为一个性能专项被提上了日程。
启动优化，顾名思义，就是优化用户从点击 icon 到首页齐全可见这一过程的时长。为了能更好地对启动时长进行度量，咱们将它分为启动阶段和首页首刷这两局部。启动阶段即是从点击 icon 到首页首帧展现为止。首页首刷阶段则是记录从首页首帧可见到首页齐全可见的时长。
通过 5 个月的优化实际，心遇线上均匀启动时长 从 8 秒多升高到 4 秒左右，启动时长减幅超过 50%，其中启动阶段升高 3.7 秒，首帧首刷时长升高了 0.4 秒。启动优化作为性能优化我的项目的重要组成部分，曾经胜利达到了预期的基线指标。
优化实际
本文将介绍心遇团队在启动优化上所做的工作，以及在优化实际中所取得一些感悟。
利用有三种启动状态：冷启动，温启动和热启动。本文次要关注冷启动的耗时。首先咱们要明确，启动优化优化的是哪几个步骤:
在冷启动开始时，零碎过程首先会执行一系列操作，并最终创立出利用过程，而后由利用过程执行主线程启动，页面创立等工作。这个流程其实波及到的点有很多，但基于缩小从启动到首页展现这段主链路的时长这个指标来讲，咱们能够将工作聚焦于三个阶段：Application 创立，主线程工作，Activity 页面渲染。在后续的优化中，咱们也是着重优化这三个阶段的耗时点。
为了可能更好地论述各个优化措施的实现和带来的收益，咱们以 oppo A5 手机为例进行阐明。
这是优化前的 App 在 oppo A5 上 的各个阶段的耗时。
从点击 icon 到首页齐全可交互，这个阶段的耗时达到了 19 秒。oppo A5 作为一款性能较差的手机，固然会对启动时长有肯定影响，然而 App 启动过程中各种不合理的逻辑和代码实现才是整个简短启动流程的次要起因。通过一系列的优化工作，App 各个启动流程的耗时如下所示：
整个启动耗时缩短至 9 秒，优化工作收益在 10 秒左右。接下来，咱们会分阶段阐明这 10 秒的收益是如何实现的。
Application 优化
Application 阶段通常用于初始化比拟外围的业务库。在利用开发晚期，咱们并没有对这个阶段的启动工作进行管控，导致这里往往会沉积有大量的强业务相干的代码。在接手这个优化我的项目前，整个 Application 中执行的工作有 90 多个。在后续的优化中，咱们对整个工作流程进行了精简，基于的准则是：
- Application 中的工作该当是全局根底工作
- Application 创立时该当尽量减少网络申请操作
- Application 创立时不容许有强业务相干的工作
- Application 创立时尽量减少有 Json 解析解决和 IO 操作的工作
优化后，Application 中的启动工作被缩小到了 60 多个，次要分为根底库初始化，性能配置和全局配置这三大类。根底类库次要是对网络库，日志库等根底库进行初始化配置，除了主过程外，其余的过程也依赖这些工作，移除它们会对全局的稳定性造成影响。它们也是启动工作中占比最大的，耗时最多的一类工作，因而升高它们的耗时也是前面继续优化的重点。性能配置次要是对一些全局相干的业务性能的前置配置，例如对业务缓存的预加载，特定业务前置等，移除它们会造成业务有损，在这种状况下，咱们须要找到业务诉求和性能配置之间的平衡点。全局配置次要是对于全局 UI 配置，文件门路的解决操作，它们占比少，耗时少，是首页创立的前置工作，因而暂不解决。
工作排布的外围是解决好工作的前后依赖问题，这个须要开发者对业务逻辑有着比拟深的了解，因为每个利用都不雷同，因而这里不做开展。咱们次要对心遇在工作排布和优化中一些细节进行介绍：
- 基于过程进行工作排布。心遇在运行中会启动多个过程，它们用于实现特定的工作，不便模块隔离。很多过程，例如 IM 过程，通常只须要启动 Crash SDK 和网络 SDK 等极少数外围 SDK 初始化工作。对于这类过程，如果依照主过程的流程执行所有的主链路代码，会造成不必要的资源节约。为此，咱们会对 Application 的工作进行粗疏划分，将工作的运行精密到过程级，防止在非主过程中执行了不必要的工作。
- 懒加载。这里次要是对一些根底工作进行革新，将工作初始化和工作启动拆分开来，将启动工作移出 Application 创立流程，同时对其进行精简，去除冗余逻辑。在创建对象时，能够提早其成员对象的创立，灵便应用 by lazy 等关键字，使对象轻量化。
- 过程收敛。多过程能够实现模块隔离，同时防止单个过程内存占比过高导致的内存下限限度，其劣势在于多过程会导致利用整体内存占用过多，触发低内存的概率更高。此外，如果利用启动时内存占比过高，可能会导致手机进行内存回收，占用大量的 CPU 资源，这反馈在用户的体验上就是启动慢，利用卡。比照多过程的优劣，咱们目前采纳的策略是尽量延后主过程以外的过程启动，同时通过过程合并来缩小过程的数量。通过这些策略，咱们最终无效地将启动时的过程数升高至两个。联合工作排布工作，咱们为每一个过程都筛选了最简的工作集，防止它们执行不必要的工作，造成资源节约，这些工作最终使得过程启动占用的内存大大减少。
- 线程收敛。对于多核 CPU 来说，适当的线程数量可能晋升效率，然而如果线程泛滥则会导致 CPU 负载过重。多线程并发，实质上就是多个线程轮流获取 CPU 使用权的过程。在负载超重的状况下，过多的线程争抢工夫片，除了升高启动速度外，也会导致主线程卡顿，影响用户体验。在做这方面优化时，须要确保全局应用对立的线程池。同时很多二方和三方 SDK 也是创立子线程的小户，这时候须要和相干的技术部门进行沟通，去除不合理的线程创立。另一方面，防止在启动阶段进行网络申请，也是缩小线程数的关键所在。
Application 优化是整个启动流程的要害，正当的工作编排不仅可能升高 Application 的创立时长，对后续的首页创立也有十分大的优化成果。目前，在 oppo A5 手机上，心遇 Application 的创立工夫从 5 秒升高到了 2.5 秒左右，并且还有很大的优化空间。
启动链路
执行完 Application 创立之后，利用过程的次要工作就是创立 Activity。这里须要留神的是，从 Application 到 Activity 里还藏有很多 post 到主线程中的工作，以及注册的 ActivityLifecycleCallbacks 的回调监听，它们会偷偷减少从 Application 到 Activity 的工夫间隙。ActivityLifecycleCallbacks 注册通常和业务相干，它的注册比拟荫蔽。在之前业务开发中，咱们的确存在着肯定的 ActivityLifecycleCallbacks 滥用的状况，这须要咱们器重起来。
对于主线程音讯耗时，咱们在应用 Profiler 和 Systrace 对启动流程进行耗时定位时，就发现了很多这样的问题。因为各种起因，Application 中工作会将耗时的工作 post 到主线程中来，外表上看 Application 的创立工夫缩短了，然而总体上启动工夫却被扩充了。对于耗时点应该定位到根本原因进行解决，而不是一味地 post 进来，这样治标不治本。
其次，缩短启动到首页的链路，是咱们优化的重点。
在原有的启动流程中，loading 页面作为心遇的启动页面，承当有路由和权限申请两个工作。
- 在通常状况下，用户启动 App，在 loading 页面判断是否登录，如果未登录，则进入登录页面
- 如果用户曾经登录，则判断是否须要展现开屏页，如果须要则进入开屏页，等到开屏完结，就跳回 loading 界面，再进入首页。
从上可知，即便没有开屏页，用户启动 APP 到展现首页，最起码要通过两个 Activity 的启动。启动链路缩短的外围在于将 loading，main 和开屏页合并为一个页面。这样做不仅能够最起码缩小一次 Activity 的启动，同时也能够在展现开屏页时并行处理其余的工作。
这里的首页更像是一块画布，首页界面的创立和渲染是其中的一笔。
实现这个性能的代码逻辑比较简单，就是将 main 页面设置为启动页，首页和开屏页封装为两个 fragment，依据业务逻辑进行展现。用户点击 icon 进入到首页，如果判断已登录，则执行首页前置工作和首页 UI 渲染，同时判断是否加载开屏页 fragment。值得注意的是，咱们并没有去除 loading 页，当判断用户未登录的状况下，就会进入 loading 页面，进行原有的打点和登录路由的工作。因为在绝大多数状况下，用户都是在已登录的状况下应用利用，所以这么做的收益最大并且批改老本最小。
为了实现这个流程，咱们须要解决好首页实例和首页工作编排的问题：
首页实例
首页原有的 launchMode 是 singleTask，这么做的目标是为了确保全局只有一个首页实例。然而咱们在革新后将首页设置为启动页，如果持续将首页设置为 singleTask，会造成业务 bug：当咱们从二级页面退到后盾，在点击图标时回到前台时，会跳到首页，而不是原先的二级页面。这里的起因能够简略了解为，点击图标时，零碎会调用 launcher 属性的首页。因为栈中存在首页实例以及它的 singleTask 属性，导致系统会应用这个已有实例，并将它下面的 activity 都 pop 出栈，最初造成这个异常情况呈现。解决的计划是抉择 singleTop 作为首页的 launchMode。singleTop 并不能确保首页实例的全局唯一性。好在心遇 APP 实现了 router 跳转的性能，能够通过对立的 url 关上首页。咱们在启动首页 Activity 的最初一步，在 intent 中减少 FLAG_ACTIVITY_NEW_TASK 和 FLAG_ACTIVITY_CLEAR_TOP 的 flag，以实现了 singleTask 的成果。这个计划根本能够满足咱们的需要，然而也不排除在特定状况下，呈现间接启动首页的操作。为此咱们注册了 Application.ActivityLifecycleCallbacks，对栈里的 activity 实例进行监控，当栈中呈现多个首页实例时，对新的首页实例进行革除，并进行提醒。
工作编排
通过革新后的首页并不是一个传统意义上的页面 Activity，而是承载了一连串工作执行的容器。包含在后续的革新中，咱们会将首页的数据申请和 UI 渲染抽来到来，此外一部分高优的业务工作也被从 Application 中抽出放到了首页中，为了无效治理这些工作的前后依赖关系，咱们须要一个有向无环图对这些工作进行治理。
工作编排的核心思想就是工作打散，错峰加载，将一个低优先级并且高耗时的工作延后，或者放在更往后的闲时工作流中去进行执行，同时也要保障工作之间的前后依赖关系，确保不要出错。正当地划分业务工作的颗粒度并且对它们进行排序是决定图运行速度的要害，也比拟考验开发对业务的相熟水平。目前业内曾经开源的对于有向无环图的计划有很多，比方 alpha 等，为了适配心遇特定的业务需要，团队外部也开发一套启动框架用于实现对首页工作的编排。
对于首页工作的加载，咱们初步提出了工作流的概念。咱们将启动工作划分为了三个工作流阶段，包含根底工作流，外围工作流和闲时工作流。整个启动流程中的业务逻辑都被咱们拆成了绝对独立的工作，并依照优先级和依赖关系调配到了这三个工作流中。
- 根底工作流：这个阶段次要是执行 Application 的创立，用于搁置网络库，监控等根底 SDK。这个工作流的工作要求尽量得少，并且都是后续工作流的前置工作。
- 外围工作流：在这个阶段中，会搁置外围的业务工作，除了一些外围业务的初始化工作之外，还包含首页 UI 的渲染，业务数据的申请以及开屏页的展现。这些工作依据有向无环图进行排列和治理，从首页创立时开始执行。因为这个阶段曾经进入到了首页，因而为了让用户能尽早看到第一帧，咱们须要尽可能地将业务数据获取和首页渲染的工作提前。
- 闲时工作流：这个阶段次要实用于搁置一些优先低，耗时长并且对实现工夫不做要求的工作。对于对闲时机会的判断有好几种办法，心遇这边做了简略解决，即在外围工作流完结 10 秒后，在 IdleHandler 中进行执行的。如果心愿比拟准确地断定闲时机会，能够通过往主线程中 post 音讯，统计主线程中音讯距离时长和利用内存水位监控相结合的计划进行断定。
应用启动框架来治理启动工作的益处在于能够使得外围业务提前加载实现，同时也能够将工作细粒度化。例如为了使得首页更快地展现，咱们将首页的数据申请和 UI 渲染相剥离。将首页的数据申请提前到了 Application 中。这个低端机上优化效果显著，数据申请的 call 对象创立和 Json 解析在低端机上耗时重大，通过利用 Application 和 Activity 创立的工夫同时进行接口申请操作，使得在低端机上，首页的 loading 工夫从原有的 3 秒缩短到了 1 秒以内。
在后续的工作中，工作编排始终是咱们启动优化的重点方向。尤其是通过对每个工作的耗时点定位和对整个工作流程的梳理，从而将启动时长升高到极致，是咱们启动优化的长期指标之一。
启动优化做到了当初这个境地，整个启动流程的代码也是大翻新，然而线下评测数据显示，整个启动耗时仅仅缩短了 3 秒左右，甚至于首刷时长还有肯定水平的劣化。这是因为启动流程是一个整体，启动和首页不能割裂开来。后面对于启动的工作编排也势必会影响到首页的创立。此外，咱们的优化工作还不够细腻，对一些细节把握还有余，尤其是锁的解决方面，前面会对这个进行介绍。
首页优化
解决完启动链路的梳理，接下来，咱们须要将眼光转向首页。首页是整个 APP 中最外围的页面。它的业务逻辑简约并且 UI 层级简单。
懒加载
通过后面的革新，咱们的首页大抵如图所示：
在关上首页后，APP 会加载首页的五个 TabFragment，这个是极为耗时的。
咱们测算了 App 在 oppo A5 上各个 fragment 的创立时长，大抵数据如下：
如果可能提早动静等另外四个 fragment 的创立和加载，实践上能够缩小 2 秒左右的启动耗时。
思考到首页展现时只有第一个 fragment 是可见的。为此咱们对首页实现了懒加载。首页应用的是通用的 ViewPager2+tabLayout 的架构模式。ViewPager2 人造反对懒加载的操作，为了防止在页面切换时，已有的 fragment 被回收，咱们增大了 viewPager2 外部的 recyclerView 的缓存池大小。
((RecyclerView)mViewPager.getChildAt(0)).setItemViewCacheSize(mFragments.size());尽管这个计划能极大地放慢首页的渲染速度，然而实质上它是将其余页面的创立和渲染推延到了切换时，如果页面比拟重并且手机性能比拟差的话，在切换时会有显著的卡顿和白屏状况，这也是无奈承受的。
为此咱们对首页和各个 fragment 进行了革新。
页面插件化
View 的创立是首页渲染耗时的小户。通常状况下，咱们应用 LayoutInflater 去加载 xml 文件，这外面波及到了 xml 解析，而后进行反射生成实例的过程，总体上是比拟耗时的。咱们对其中比较简单的 xml，应用了代码进行构建，然而对于简单的布局文件，应用代码构建耗时微小，并且不可保护。
为了让首页 ” 轻 ” 起来，咱们基于业务角度对 view 进行组件化切割。这里外围的一个思路就是让用户看到最根底的界面，应用到最外围的性能。举个例子，比方一款视频播放利用，用户第一眼想看到的是它的播放界面，想应用的是视频播放性能。至于其余的顶部图标等等，却是不会在乎的。基于这个思维，咱们该当首先将播放组件和播放性能优先创立，并展现进去，而其余的业务模块能够通过 ViewStub 的模式延后加载。
那么心遇的外围页面是什么？是首页的缘分列表, 而外围性能则是对缘分列表的操作。明确了这一点，首页简单的逻辑整个就清晰了起来，咱们明确了用户最外围的需要是什么。
这里介绍一下 Plugin，Plugin 是团队外部积淀出的一套 UI 组件化计划，实质上是一套升级版的 ViewStub，然而又具备 fragment 的能力，人造适配 mvvm。Plugin 是一个功能强大的组件库，对于 Plugin 的具体实现，咱们在通过细细打磨之后，有机会会在后续文章里进行介绍，这里暂且不做开展。通过 Plugin, 咱们将简单的 view 基于业务档次切割成一块块独立的业务性能组件，依照优先级进行加载。这样能够确保用户能够更快地看到首页，并应用到最外围的性能。
缘分的 plugin 在首页创立时就优先展现，而其余的 plugin 能够等到缘分 plugin 齐全展现，并且相干的数据返回时再进行渲染和加载，这样大大加重了首页的负载。
Json 解析解决
Json 解析操作也是须要进行优化的点。优化前，依据测试同学的测试数据，在低端手机上，主接口的 Json 解析工夫高达 3 秒，这个时长是无奈被承受的。
Json 解析耗时的起因实质上是在解析时，从 Json 数据到对象的创立是通过反射操作进行对象生成和赋值的，对象越简单，那么耗时就越长。对于首页的主接口来说，返回对象的解析在低端机上的耗时曾经超过 UI 的渲染的耗时，是咱们必须要克服的点。
咱们目前采取的计划是将首页的数据对象应用 Kotlin 进行重构，并对相干对象应用 @JsonClass(generateAdapter = true) 进行标注，它会在编译期间对标注的对象生成对应的解析适配器，从而缩短解析工夫。
XML 解析优化
测试数据显示，在性能较差的手机上，xml inflate 的工夫在 200 到 500 毫秒之间。自定义控件和较深的 UI 层级会减轻这个解析耗时。
为了升高 xml 解析的工夫。咱们对首页的各个 UI 模块的 xml 进行了优化，尽量减小 xml 层级，并且防止不必要的自定义控件的应用。在心遇 App 上，对强业务相干的自定义控件肯定水平的滥用也是导致 xml 加载耗时的重要起因。
除此之外，咱们也思考过其余计划来升高解析的工夫，比方将 xml 解析的操作放在子线程中，并提前到 Application 中进行执行。这个计划简略且无效，并获得了肯定的收益。
一个具体的例子是，首页缘分页面的 item 的 xml 解析耗时在 200ms 左右，咱们将它搁置于子线程中并提前预处理，解析胜利后的 view 存入缓存中，在进入到首页创立 item 时，从缓存中获取 view 进行渲染。后果是胜利将 item 创立的时长升高到了 50ms 以内。
异步解析的计划看起来很有成果，然而如果指望将所有 xml 都通过异步解析的计划进行预处理，那么注定是要悲观的。因为它其实有很大的局限性。
首先要留神的 view 的锁的问题，它会使 xml 的解析从异步变成同步，导致解析反而变慢。对于锁的解说和解决，咱们会在下一章进行具体阐明。在上述优化例子中，咱们通过复制 LayoutInflater 实例的计划来局部绕过了锁的限度。
LayoutInflater inflater = LayoutInflater.from(context).cloneInContext(context);
View view = inflater.inflate(R.layout.item_view, null, false);view 的锁事实上并不只 LayoutInflater 一处，在 resource,assets 外部也存在有锁，因而上述的计划并不能齐全达到同步的成果。
第二点，子线程优先级低，尤其在负载重的状况下，子线程解析 xml 会导致整个解析流程拉长。这很容易呈现在理论须要用到 view 时，xml 解析还没执行结束，导致走降级计划，从新主线程解析 xml，这反而导致了资源节约，最终使得渲染时长变长。因而异步解析 xml 只能用于极少的外围 xml 的预处理，并且 xml 的层级不能太简单。
对于 xml 的解析优化始终是咱们摸索的重点。目前，咱们尝试应用 compose 的计划来作为解决 xml 解析耗时问题的次要方向，当初还在试验和积淀阶段，置信不久就会有合乎预期的成绩。
首页优化的工作带来了很大的收益，线下评测显示，在 oppo A5 手机上，不仅首帧展现的时长相比于优化前升高了 3 秒左右，整个首页渲染的工夫也达到了 1 秒以内。首页的数据可能更快地展现，用户的应用体验也会大大晋升。
锁
锁对启动优化时带来的麻烦是如此让人印象粗浅，以至于咱们须要独自开一节来讲。
在进行启动优化时，如果遇到耗时的工作，咱们通常会将它置于子线程中解决，实践上讲如果资源足够，这个耗时工作的工夫会被齐全优化掉。然而事实往往并不是如此，这种操作可能成果不佳，甚至反而会好转。这外面的起因就是锁。这里咱们挑几个有代表性的锁来讲一讲。
Retrofit
咱们都晓得 Retrofit 是通过动静代理的形式生成申请时的 Call 实例, 然而咱们往往漠视了其中锁的存在。
如果在首页呈现这种大量接口同时发动申请的状况，多个接口创立竞争这把锁，这会无形中把接口申请，从并行变成了串行，这在性能较差的手机上尤为显著。
所以在理论启动过程中，咱们能够看到，一个 api 申请的耗时，往往是申请自身只须要 300ms，但等 Retrofit 的这把锁就要 200ms。
此外剖析 Retrofit 通用的写法，咱们能够看到这部分耗时是在执行 create 时产生的。蹩脚的是，这种写法经常会让咱们误以为，这只是创立了一个对象，并不是一个耗时的操作，从而将它轻易地裸露在主线程中。
GitHubService service = retrofit.create(GitHubService.class);咱们通过对首页的代码进行整改，通过切换线程的模式，将这部分代码切到子线程中。对于锁的问题，通过排查，基本上是因为解析接口返回数据时耗时过长所导致的。这部分波及到 Json 解析优化的问题，能够看上文解决方案。
反射
咱们晓得反射是耗时操作，尤其对于 Kotlin 的反射而言。因为 Kotlin 各种语法糖的缘故，反射操作须要从 Metadata 中读取类信息，所以 Kotlin 的反射效率自身就比 Java 低不少。
同时，因为 kotlin_builtins 的存在，Kotlin 中的很多内建信息（比方根底类型 Int, String, Enum, Annotation, Collection 都是以文件的模式保留在 apk 中的，同时也包含协程、多平台等 Kotlin 会用到的信息），在反射过程中会隐式触发类加载和对这些文件的 IO 操作。
static {Iterator<ModuleVisibilityHelper> iterator = ServiceLoader.load(ModuleVisibilityHelper.class, ModuleVisibilityHelper.class.getClassLoader()).iterator();
MODULE_VISIBILITY_HELPER = iterator.hasNext() ? iterator.next() : ModuleVisibilityHelper.EMPTY.INSTANCE;
}对于类加载而言，自身就是有锁 + IO 操作，所以线上常常会有 ANR 呈现。
而 IO 操作更不用说，受限于零碎整体文件系统的负载，IO 操作自身的耗时就是不可控的，同时在锁内 IO 又无形中加剧了这种耗时。
所以，反射操作尤其是 Kotlin 的反射能够简略了解成一个潜在的带锁 IO 操作（尤其是在 APP 启动过程中）。
这个可能会导致各种奇怪的问题。在优化中咱们就曾碰到过这么一个例子，咱们自身心愿通过本地缓存的形式让用户更早得看到 UI，然而因为各种锁的加持，最终不仅拖慢了各个 api 申请的速度，还蝴蝶效应般的把这部分预加载的耗时又转换回了 UI 线程，导致线程卡死。咱们在通过一系列的排查工作之后，最终定位到起因是在启动过程中，Kotlin 首次加载 buildins 带来的耗时。咱们能够在必要时手动触发第一次反射，来躲避掉这个问题。
View 的锁
后面说到了 view 的创立是耗时小户，正向优化会比拟艰难，咱们也会想到，是不是能够把一部分 UI 扔到 IO 线程中去 inflate。上文中也有异步解析 xml 的计划。同时咱们也提到了 view 的 inflate 局部步骤也是带锁的。
这把锁是跟着 LayoutInflater 实例走的，换言之个别状况下是跟 Context 走的。在咱们遇到的例子中，view 的加载放在子线程中，因为锁的存在，导致其余的 view 的加载工夫被拖长了，并且因为 CPU 负载高，IO 线程优先级低，这一系列起因反而导致启动流程好转。
Moshi
Moshi 深度遍历一个 Class 并生成 JsonAdapter 波及大量反射，耗时工夫不可控。不过比拟迷信的是，Moshi 外部缓存尽管也有用到锁，但借助 ThreadLocal 能够把耗时操作放在了锁外，后续相似场景也能够参考这种写法。
最佳实际
通过对上述一系列问题的剖析，咱们能够总结出以下最佳实际：
- 不要在主线程进行任何 Moshi 解析；
- 通过 Moshi 解析 Kotlin 类时，要应用 JsonClass 注解；
- 不要在主线程进行任何 Retrofit 相干的操作；
- 异步 inflate xml 须要留神多线程竞争的问题。
理论状况上，问题变幻无穷，硬套公式是不行的，最佳实际更不是银弹。在遇到耗时的工作时，不想着去查找起因，而是粗犷地将它放在子线程中，不论是因为同步锁还是其余机制，被耗费的 CPU 工夫总会以另一种模式影响 UI 线程的工作效率。
防劣化
启动优化是一个长期的优化我的项目，其时效之长能够说是贯通一款产品的生命周期。所以并不是说在一段时间重点攻坚之后，启动时长降下来了就高枕无忧了。如果没有防劣化措施，在通过几个迭代之后，启动时长又将回升，尤其是当启动优化来到了深水区之后，各方面的改变都会对启动速度有着千头万绪的影响。所以启动优化不仅是一个攻坚战，更是一个长时间的拉锯战。
因而，咱们须要线上和线下的监控数据作为咱们启动优化工作的领导。
线上数据
外围的节点如下：
在线上数据中，咱们次要采集了 Application 的 attachBaseContext 办法作为启动的起始点，首页的 onWindowFocusChanged 作为首页可见的节点，onViewAttachedToWindow 作为首页数据上屏的节点。
心遇目前应用的监控节点更偏差于作为横向比拟，如果冀望更加准确的测量数据，启动的起始点能够应用过程的创立工夫，首帧数据采集能够定位到 dispatchDraw 时调用。然而思考到易用性，并且冀望不受业务影响，心遇应用了目前的监控计划，次要是用于比照历史版本的优化和劣化。
值得一提的是，线上数据采集须要关注乐音的影响。局部机型会在后盾杀死过程并重启，然而在重启过程中因为省电策略又会强制进行重启过程，导致这次计时异样，呈现乐音。
心遇这边采纳的计划是比照启动时长和线程的启动时长的比照，如果相差超过阈值，则舍弃这次记录。
val intervalTime =
abs(System.currentTimeMillis() - attachStartTime - SystemClock.currentThreadTimeMillis())依据实际，20 秒是比拟适合的阈值数字。
线下数据
通过打点进行数据统计，尽管可能在肯定意义上反映出以后的启动状态，然而总归和用户理论的体验会有区别。因而在线下数据采集时，咱们比拟举荐应用各个性能层级的手机对利用进行启动录屏，最初测量出启动耗时。
措施
对于防劣化的工作，咱们目前还在摸索阶段。目前在每个版本公布之后，测试同学会给出一份以后版本的性能测评报告，咱们会联合线上的启动数据进行综合剖析，判断以后版本的启动时长是否劣化。如果数据劣化，咱们会对整个启动流程进行剖析，找出异样点并修改。
这种计划比拟低效，因为很多状况下劣化水平低，不易在数据上展现进去。在等到能从数据上反馈进去时，可能曾经累计有很多的异样点了。
为此，咱们对 Application 和首页的代码改变会进行特地的 Code Review。咱们不激励在 Application 中增加代码，如果须要增加代码，那么会对其必要性进行评估。此外，咱们对启动框架设置了启动耗时报警，如果启动耗时超过阈值，则会在开发阶段就揭示开发者代码可能有异样。咱们认为所有的优化工作归根到底都要靠开发者自身，因而每个团队成员都要有这方面的优化意识才是最重要的。咱们目前也在打算制订相干的标准措施来标准团队成员在这方面的开发工作。
总结
启动优化做到当初，心遇的启动速度和首屏渲染时长都已进入到基线。然而正如上文中说的，启动优化是一个须要长期关注的专项，咱们对于心遇的启动时长的优化也不会仅仅限于此。在这次优化我的项目中，咱们遇到过很多问题，也总结出了很多的最佳实际计划，其中最大的播种就是粗浅明确了一点：没有平白无故的耗时，如果有，那么就必定是哪里出问题了。面对耗时，不想着去解决，只是将它放在子线程中，而后不予理睬，这个问题必然会在下个路口等你。咱们有时也思考过应用一些黑科技去优化启动速度，然而往往成果不尽人意，起初想想，其实大道至简，往往最简略的计划才是最好的，隔靴搔痒，能力拿到最佳成果。一味谋求高大上的技术去优化，往往陷入了大炮打蚊子的困境。
在后续的工作中，咱们仍然会对启动进行继续的迭代和打磨。相比于之前的工作，咱们会更加精细化，由浅入深，联合具体业务进行技术计划定制，实现速度晋升，在摸索出一套比拟适合的计划后，再对计划进行泛化，利用到其余业务中。而后回过头来看看，这样由外入内，再由内入外，咱们可能会对整个启动流程有簇新的意识。
参考资料
- 利用启动工夫
- 抖音 Android 性能优化系列：启动优化实际
本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！
