(抖库破解版30)安卓抖音无人直播软件下载地址

启动性能是 APP 利用体验的门面，启动过程耗时较长很可能招致用户利用 APP 的兴趣骤减，抖音通过对启动性能做劣化的 AB 尝试也验证安卓抖音无人曲播软件下载地址了其关于营业目标有影响显著。抖音拥有数亿的用户，启动耗时几百毫秒的增长就可能带来成千上万用户的留存缩减，因而，启动性能的优化成为了抖音 Android 根底手艺团队在体验优化标的目的上的重中之重。

本文基于过往对抖音 Android 客户端做启动性能优化的实战经历总结提炼出普适性的办法论，并将该过程中沉淀的东西加以分享，希望能给各人带来一些新的思虑。

抖音 Android 性能优化系列往期文章回忆：抖音Android性能优化：新一代万能型性能阐发东西Rhea

带着问题动身

假设你要负责优化抖音的启动性能，你会如何去规划整体的优化计划安卓抖音无人曲播软件下载地址？你可能会一会儿想到良多方面的细节点，好比：要优化主线程耗时、要削减规划层级、要对某些启动使命做按需加载或预加载、要制止主线程 IO、要对线程利用停止优化、还要有阐发东西帮忙定位性能问题等……

然而，该若何系统性地把那些细碎点组织起来并根据必然的章法来落地启动优化呢安卓抖音无人曲播软件下载地址？此时，需要我们在详细细节点之上有进一步的问题合成与深切思虑，最末构成一套完好的办法论，不只能笼盖所有细节点，还能实在指点在实战中达成启动优化的效果。实在有效的办法论一定是从实战中颠末千锤百炼才气构成的，而抖音庞大的用户基数又进一步保障了办法论的可行性与普适性。那么接下来让我们带着前述问题来看抖音的启动优化办法论是如何的又是若何应用于实战之中的。

启动优化办法论

抖音的启动性能优化办法论分为五部门，别离是：理论阐发、现状阐发、启动性能优化、线上验证与防劣化。

那五部门间存在明显的先后挨次，又能闭环达成可持续的启动性能优化，下面将对那五部门做详细论述：

理论阐发

理论阐发放在更先是为了从一起头就制止让视野遭到限造，良多同窗往往一起头接手启动优化就容易陷入对各类现状细节的阐发，拘泥于全面的潜在可优化点，如许就难以做到对全局和优先级的把控，所以，我们应该起首跳呈现状，从愈加全局的视角来思虑整体优化的目的和战略。那里能够操纵特斯拉开创人——埃隆·马斯克所推崇的“第一性原理”思虑法：

“通过第一性原理，把工作升华到最底子的实理，然后从最核心处起头推理。”

基于此，我们在做启动优化的理论阐发时能够从更本源的角度动身做到全局思虑，好比抖音会做从历程创建到页面展现的全启动途径分阶段耗时阐发、还会根据消耗的系统资本类型做耗时成因阐发，通过那种极致的耗时阐发能够带来极致的优化战略，此外，从全途径动身还可以发现容易轻忽的问题、摸索优化的极限。

现状阐发

在完成理论阐发后，我们根本具备了全局的视角，而且也大致清晰了整体的优化目的和战略，接下来就要基于此来做现状阐发从而了了实现目的的详细途径：

起首利用 profile 东西对可优化点停止摸底：其实不合理的高耗时点就是潜在的优化点，并能根据前述的理论阐发归入一个或多个耗时成因中；然后连系线上的目标数据确定最末优化标的目的：线下摸底的潜在优化点要连系其线上打点确认能否为遍及耗时，再按照耗时成因明白大致的优化思绪、施行成本和预估收益。

在那部门需要尤其留意三点：优良的 profile 东西（那里保举利用同样来自根底手艺团队的“btrace 开源！基于 Systrace 高性能 Trace 东西”）、线下 trace 连系线上监控综合阐发、按照投入产出比评估施行优先级，那三点是保障实在有效获得启动优化收益的关键。

启动优化

在完成了理论和现状阐发后，就能够按照规划的途径来施行详细的启动优化项了。在施行过程中，次要考虑主线程优化、后台线程优化和全局优化三个维度：

主线程耗时优化需要在启动全途径各阶段中细化详细的耗时成因，如：CPU Time、CPU Schedule、IO wait、Lock wait 等，完成耗时归因后能够利用逐渐晋级的优化战略来逐个击破：关于首屏所必需的耗时逻辑做正面优化（可利用缩减耗时逻辑、异步并发、延迟加载等手段）、关于非首屏必需的耗时逻辑做按需加载（需要架构优化的根底）、关于优化后仍存在耗时的逻辑测验考试做营业降级（大都有损需评估全局收益）；后台线程优化战略与主线程类似，在此根底上还能够施行后台使命缩减、线程收敛、开启多历程等优化办法；此外，主线程和后台线程均存在较多启动使命且相互间可能存在联系关系，因而，能够对全局的启动使命做依赖关系梳理并施行精细化的使命重排，旨在削减依赖使命间的期待耗时；全局优化次要是指营业无关的通用的全局优化战略，如虚拟机层面或 IO 层面的优化等。线上验证

在完成了详细的优化项施工后，就来到了线上验证大盘收益的阶段。那个阶段有三点需要留意：

线下的优化必然要有线上的目标反应，线下的优化项因为设备或操做习惯差别往往难以评估能否具备遍及影响，只要当响应的线上目标获得正面反应后才气验证拿到了有效的优化收益；线上目标需要连系均值与分位值综合来评估，只存眷启动耗时的均值往往会掩盖低分位设备的现状，那部门设备可能占比不高，对均值影响有限，但抖音庞大的用户基数乘以该比例仍旧是不小的数量，为了保障该部门用户的启动性能体验，抖音一般会分 50%、70%、90%三个分位值来评估目标；在验证收益时通过 AB 尝试达成，如许做不只能控造变量确保优化项的严酷有效，还能借此来察看性能优化所带来的营业目标收益，那些都能够做为规划后续启动优化标的目的的参考指点。防劣化

在线上验证优化办法获得实在收益后，并非万事大吉了，持续连结住优化效果才算完好达成了启动性能优化的目标。其实不只是启动优化，整个性能优化范畴都是围绕着“攻”和“守”来展开的，“攻”即为前述的阐发与优化，而“守”则是避免劣化，在防劣化方面各人往往不会像优化的方面那么重视，但现实上能避免劣化是可持续获得优化效果的前提（不然新的优化效果会用于填补劣化以至入不够出），而且防劣化比拟于优化是更能耐久有益的。

抖音启动性能防劣化的历程分为了三个期间，差别期间有差别的表示与应敌手段，那很可能是大大都 APP 优化启动性能都要履历的，那里提炼出来以供参考：

快速下降期：此时一般位于启动优化的初始阶段，优化空间很大，陪伴有小幅度的劣化但往往都能被更大幅度的优化抵消且还仍有收益，那时应该抓大放小，根据更高投入产出比的战略重点推进优化，同时也抽出少部门精神治理修复成本低的劣化。瓶颈期：到了该期间绝大部门优化收益已经拿到，想进一步做到优化往往需要投入更多成本，且优化幅度有限，整体的投入产出比不高，同期还会陪伴有中小幅的劣化，此时需要成立完美的线上线下监控系统，及时发现并修复劣化，此外还要通过架构革新从泉源上限造劣化的发作，综合保障优化的收益不会被劣化抵消。劣化期：那个期间往往呈现在年关或重要节日期间，那类时间点往往有重要且告急的活动项目上线，浩瀚联系关系方面均要为其开绿灯，启动性能目标也不破例，为了保障活动效果可能要参加若干耗时的主线程启动使命，所带来的的劣化幅度往往比力大，此时需要对齐预期并在活动完毕后及时修复。启动优化办法论的应用理论

前人云“纸上得来末觉浅，绝知此事要躬行”，前述的办法论讲得再详细再透辟也会与现实的落地存在隔膜，为了做到实正的学以致用，下文将详尽讲解若何将启动优化办法论应用于理论之中。

理论阐发的理论

抖音在理论阐发部门会对启动流程别离做全途径阐发和耗时成因阐发，前者用于发现全途径各个阶段的潜在耗时点制止疏漏，后者用于系统性地将各个耗时点归因从而引导我们找寻优化思绪，关于那两部门的详细理论如下：

启动性能全途径阐发：抖音的启动途径和大大都 APP 类似，整体分为两大阶段和两个间隙，它们定时间挨次排布为：Application 阶段、handle message 间隙、Activity 阶段和数据加载间隙，全途径各部门细分涵盖的内容如下图所示：

APP 历程由 zygote 历程 fork 出来后会施行 ActivityThread 的 main 办法，该办法最末触发施行bindApplication，那也是 Application 阶段的起点；然后是我们在应用中能触到达的attachBaseContext阶段，4.x 的机型在该阶段具有较长的 MultiDex 耗时能够做针对性优化（可参考“开源 | BoostMultiDex：挽救Android Dalvik机型APP晋级安拆体验”），本阶段也是最早的预加载时机；接下来是installProvider阶段，良多三方 sdk 借助该时机来做初始化操做，很可能招致启动耗时的不成控情形，需要按详细 case 优化；尔后就到了 Application 的onCreate阶段，那里有良多三方库和营业的初始化操做，是通过异步、按需、预加载等手段做优化的次要时机，它也是 Application 阶段的末尾。

在Application 阶段和 Activity 阶段之间往往会不成制止地被插入良多 post 到主线程的动静及响应待施行使命，那是拉长启动耗时的另一不成控问题点，需要加以监控治理或通过动静调度优化来尽量减小此间隙。

在来到 Activity 阶段后，起首履历的是其onCreate生命周期，那里涵盖了首屏营业优化的次要场景也是开启异步并发的次要时机，在此中有个重要的 setContentView 办法会触发 DecorView 的 install，可测验考试对 DecorView 的构建停止预加载；后续天然来到View 构建的阶段，该阶段在抖音上相当耗时，可接纳异步 Inflate 共同 X2C（编译期将 xml 规划转代码）并提拔响应异步线程优先级的办法综合优化；再来到View 的整体衬着阶段，涵盖 measure、layout、draw 三部门，那里可测验考试从层级、规划、衬着上获得优化收益。

最初是首屏数据加载阶段，那部门涵盖十分大都据相关的操做，也需要综合性优化，可测验考试预加载、缓存或收集优先级调度等手段。

此外，针对全途径所有阶段还能够施行通用性的优化项，如：启动使命调度框架、类重排、IO 预加载、全局通用性框架优化等。

启动耗时成因阐发：所有的耗时均因代码运行时不合理地消耗系统资本产生，而不合理的耗时点恰是需要做归因阐发之处。抖音根据不合理耗时点消耗的次要系统资本类型划分出五大成因，别离是：CPU Time、CPU Schedule、IO Wait、Lock Wait 和 IPC，下面别离对各成因停止分析：

CPU Time 指占用 CPU 停止计算所破费的时间绝对值，中断、挂起、休眠等行为是不会增加 CPU Time 的，所以因 CPU Time 开销占比高招致的不合理耗时点往往是逻辑自己复杂冗长需要消耗较多 cpu 时间片才气处置完。比力常见的高 CPU 占用是轮回，好比抖音启动时碰到过一个 so 加载耗时，最初定位原因是在解压 so 的时候，遍历 ZipEntry 的次数过多招致，一个可行的优化战略就是能够把 so 所在的 ZipEntry 提早，遍历完 so 的 ZipEntry 之后能够提早中行遍历，而不需要遍历剩下的无效 ZipEntry。除轮回之外，反射也是招致 CPU Time 的重要原因，像在序列化/反序列化、View Inflate 时，都有大量的反射操做，反射的耗时次要是字符串去查找 Method 或者 Field，那个优化战略也能够考虑提早查找 Method 和 Field 缓存起来，或者是通过内联来降低 Field 数量等。别的一个常见的 CPU 耗时是类加载，类的加载过程包罗：Load，从 Dex 文件里读取类的信息，可通过类重排优化；Verify，验证指令能否合法等，通过关掉 Class Verify 能够优化该过程，同时高版本的 vdex 也是为了优化 verify 过程而设想，在 dex2oat 的时候做 verify，verify 之后的成果保留成 vdex，后续只需要加载 vdex；Link，给 Field、Method 分配内存，根据名字排序以便利后续反射的时候查找 Field、Method 等，那个过程的优化，art 虚拟机接纳了 ImageSpace 的计划停止了优化，将 Link 后的内存保留为 image 文件，后续能够间接 load 那个 image 文件，省去了 Link 过程；Init，类的初始化。CPU Schedule 在阐发时次要针对主线程，是指主线程处于可施行形态但获取不到 cpu 时间片，那类耗时可能和线程调度等有关，最末招致分配给主线程的 cpu 时间片不敷以及时处置完其内使命。因为主线程的线程优先级比其安卓抖音无人曲播软件下载地址他线程的优先级要高良多，凡是影响其实不大，事实上抖音做了线上用户的启动耗时统计，那部门的耗时占比也是不大的。不外有一个场景需要存眷，就是衬着，衬着是需要 RenderThread 提交 GPU 的衬着号令，而 RenderThread 并没有主线程那么高的优先级，因而比力容易受 CPU 的负载的影响，招致衬着耗时，那个关于启动来说影响其实不算大，启动只要一次首页的衬着，占整体时间的比例不算大，但关于流利度的影响就会比力大。那类耗时的优化次要仍是从降低 CPU 的负载的角度考虑，好比营业降级、营业打散等手段。抖音还通过对 RenderThread 优先级的提拔优化，拿到了不错的收益。IO Wait 指发作了 IO 操做需要期待 IO 返回成果，那类耗时可能发作在读取资本和文件，类加载，以至在内存不敷时的 PageFault 城市招致 IO Wait。Resources 的相关的操做耗时，次要是需要从 apk 里读取资本文件，优化战略能够有预加载、资本重排、资本异步加载等。类加载的 IO Wait 和 Resources 类似，也能够通过类的重排、预加载等优化计划。文件读写招致的 IO Wait 又分为营业文件和系统文件，营业文件指营业逻辑的读写文件，一般都能够通过异步来处理，而系统文件的例子是 dex 的读写，抖音的 IO Wait 很大一块是它奉献的，目前的思绪仍是做 dex 的重排和 IO 的预读来测验考试优化。Lock Wait 也是次要针对主线程，指其处于等锁形态，期待被其他线程唤醒或本身超时唤醒，招致那类耗时的问题品种多样，大致也是能够分为营业锁和系统锁，营业锁次要是被主线程期待的营业逻辑未能及时处置完，优化思绪一般是移除主线程的锁期待逻辑或者加快被期待的营业逻辑的施行速度。系统锁次要有：String InternTable Lock，ClassLinker Lock，GC Wait Lock 等，目前抖音正在测验考试优化那几类的锁耗时。IPC 指历程间通信，操做系统大都含有响应的机造，Android 中所特有的 IPC 机造是 Binder，因为停止 IPC 挪用往往需要期待通信成果素质上那也算是一种 Lock Wait，但 Android 特有 Binder 机造所以零丁列出，那类耗时可接纳削减或替代 Binder 挪用等手段来优化。

综合前述的五大耗时成因，那里举一个阐发启动阶段 UI 耗时成因的例子做为理论参考，按照 UI 界面的生命周期（一般划分）——UI 构建、数据绑定、View 显示三个阶段别离停止阐发：

在UI 构建阶段中起首要对界面规划的 xml 文件停止解析，那会招致 IO Wait 耗时，在接下来要解析 xml 文件中的 TagName 从而获取对应 View 的 class 会用到反射、创建各子 View 实例并生成 View 树又会用到轮回递归，两部门城市增加 CPU Time 的开销。然后是数据绑定阶段，该阶段次要分两部门，一部门是对数据做恳求、解析、适配，另一是部门是将适配好的数据填充进 UI 中，前一部门往往会涉及到 Json 解析成 Data Class 实例，那里就可能涉及反射、轮回遍历嵌套的数据类构造等增加 CPU Time 的操做。最初是View 显示阶段，常见的 measure、layout、draw 三大衬着 View 的步调就在此中，它们同样会产生递归遍历父子 View 的耗时，此外那里还涉及将应用层计算好的衬着 View 的数据传递给系统层做最末的像素点排布，那么一定又会产生 IPC 耗时。

从那个例子可见即便再复杂的场景只要我们停止细粒度的阐发，都能将耗时点归入前述某一成因中。

现状阐发的理论

如前文办法论所述，现状阐发包罗线下 Profile 数据与线上监控数据的对照阐发，综合那两部门能够明白实在影响大盘启动性能的遍及耗时点，从而确保要做的优化项是行之有效的。下面别离讲述那两部门数据的阐发理论：

线下 Profile 数据阐发：Profile 次要是指利用性能探测东西抓取应用启动途径各阶段的耗时和系统资本消耗情况，常见的开源 Profile 东西有 TraceView、Systrace、Android Profiler 等，那些东西各有优势但均不克不及完全满足抖音做线下 Profile 的需求（详见后文“启动性能优化东西”部门的讲解），为此，抖音自研了“新一代万能型性能阐发东西 RheaTrace”满足了需求。通过该东西我们能够在线下抓取整个启动途径的 Trace 文件，其整体款式与 Systrace 一致，但是涵盖了更多的信息点，一个样例 Trace 文件如下图所示：

那里需要留意抓取 Trace 必然要基于 release 包，debug 包中往往涵盖诸多调试逻辑可能影响启动性能，招致 profile 数据与现实利用情形存在误差。在查看 profile 数据时，首要察看主线程，寻找此中不契合预期的耗时办法，抖音将主线程耗时在 5ms 以上的办法均认定为不契合预期；然后在所有不契合预期的办法中寻找 Top n 的耗时点，逐个阐发耗时原因、寻找打破口；耗时原因需要连系办法实现逻辑以及诸多运行时信息综合阐发（那里能够参考 Google 官方文档“阅读 Systrace 陈述”），需要存眷的运行时信息有办法施行时段对应的 CPU 负载、线程形态的颜色标识值、锁信息、IO 耗时、Binder 挪用耗时等，按照那些信息断定引起办法耗时的次要原因，再连系理论阐发中差别阶段、差别系统资本类型探寻优化手段。

线上监控数据阐发：那部门数据的阐发次要是用做参照和弥补，参照是指线下 Profile 数据阐发出的耗时点要对照线上数据确认其在大盘中存在遍及耗时，弥补是指线下 Profile 数据未能复现的耗时点可能存在于线上大盘中，那部门漏掉的耗时点需要在线下测验考试复现、归因后施行优化。那里有个很重要的点是：该若何对线上的启动性能目标做监控，那是保障线上数据能实在反映用户体验而且与 QA（做竞品测试等）和营业方（判断营业需求能否影响启动性能等）达成一致的前提，下面将对那部门做详细论述，分为启动性能目标的定义、统计和校准三部门：

启动性能目标定义：启动目标定义次要在于若何确定启动途径的起点与起点。起点的备选项有下图中的三个点以及 Application 的 attachBaseContext 办法：下图中“点击图标”后的/proc/self/stats starttime 是内核中记录的 App 启动时间点，该数据的 Android 版本兼容性优良也比力贴合实在情况，能够做为备选；接下来的 Process.getStartElapsedRealTime 是 Framework 中记录的 APP 历程创建起点，该 API 是 Android N 起才供给的兼容性较差；再往后是 Application 的构造函数，根据 Android 官方生命周期式的开发形式凡是不会往 Application 的构造函数中加逻辑，所以不建议在那里记录起点；最初是各人熟悉的 attachBaseContext 办法也是 Application 生命周期中十分早的一个点，能够在那里记录启动点，固然可能和实在情况有小幅差距，但可以起到根本的对照效应而且处于 APP 逻辑能够干涉的范畴内，抖音的启动途径起点选定的恰是此处，此外也能够连系前述的内核中启动时刻综合不雅测。

而关于起点的定义同样有几个备选项：Activity-onResume、Activity-onWindowFocusChanged、View-dispatchDraw 和 DecorView-post：少数 APP 在选定冷启阶段起点时可能会选择首页 Activity 的 onResume 时机，但此时整个 Activity 还不是完全可见，与用户感触感染到的冷启阶段完毕时刻有必然的差距；基于上述原因，更多 APP 会选择首页 Activity 的 onWindowFocusChanged 时机，抖音也是选择的此时机做为冷启过程的起点，此时首页 Activity 已经可见但其内部的 view 还不成见，关于用户侧已经能够看见首页布景，即认为冷启阶段到此完毕，后续的首页内 View 绘造归入首刷过程中；dispatchDraw 从 View 可见那个角度讲应该是比力接近用户感触感染的，但其受营业改动影响较大，倒霉于把控冷启时间及维护；最初是通过 DecorView 在 attachToWindow 前 post 一个 runnable 来打点的体例，该体例能够保障在营业 View 完成衬着后做打点，但该体例可能会受营业同窗做懒加载在打点前插入逻辑的影响，因而抖音的冷启起点也未选用该时机。启动性能目标统计：在统计性能目标时有个关键点往往被各人忽略，就是分位值的概念，因为均匀值相对更通俗易懂且对大盘突提问题敏感往往做为首要统计目标被存眷，但其存在颠簸较大倒霉于大盘监控以及难以表现差别分位机型启动性能差别的问题，而分位值更有利于全面监控且各分位颠簸相对较小，此外关于低端机的性能问题可以更好地闪现出来，有助于做专项优化，在优化抖音的启动性能时我们会重点存眷 50 分位和 90 分的性能目标，不外分位值也存在一些缺点，好比：概念理解起来相对复杂、个别 bad case 分离到各分位不容易表现出来等，因而比力好的理论是：日常优化次要统计分位值，均匀值做为辅助完美监控系统。启动性能目标校准：因为启动途径往往比力复杂，因而添加了启动性能埋点后还需要额外的校准，总的原则是需要保障目标数据能实在反映大盘用户情形。在添加客户端埋点时更好是先梳理再分主途径和重点 case 别离打点，此外还要对若干异常 case 的数据停止剔除或分类制止污染打点数据，好比抖音在添加启动时间打点时就会对开屏告白、保活历程、push 拉起、deeplink 拉起、启动期间退后台、新用户启动等场景停止过滤或分隔统计。启动优化的理论

在做完理论阐发与现状阐发后，我们根本对全局待优化点及其大致优化标的目的会产生整体的认知，在起头落地各个优化办法之前还有很重要但往往会被忽略的一步——按优先级排布优化项、造定整体优化计划，那一步在很大水平上造约着后续启动优化的收益预期与停顿把控，那两点关于定时达成启动优化的末极目的都至关重要。前述中提及了对“优先级”的把控，那点是造定整体优化计划的重中之重。

从抖音启动优化理论总结来看比力好的优先级战略是根据“投入产出比”来排布优化项，望文生义：投入人力越少但优化幅度越大的优化项越应该排在前期，因为所有的性能优化过程都势必会履历从高收益到低收益的变革，那么响应的在排布优化项的前后挨次时也需适应此规律，最末呈现的态势即为：前期以小成本快速降低大盘启动耗时，后期逐渐进步投入打破各个瓶颈型耗时点（更后期大规模重构仅能削减几十毫秒启动时间的情形也应在预期之内），全过程同期加强防劣化机造，最末做到可持续优化。

在完成前述的全局优先级排布及计划造定后，才算实正来到了施行优化的阶段，在那个阶段所要用到的各类优化战略及共同办法在前文办法论部门已有详细讲述，在实战部门起首要弥补一下前述几类优化战略根据“性能无损”、“营业无损”的区别划分，整体如上图所示，此外，我们会连系抖音启动优化实战经历列举各优化战略下可施行的优化项，以供参考：

正面优化：删减非需要的启动逻辑、开屏页与首页 Activity 合并、获取历程名从 IPC 转反射体例等；按需优化：ContentProvider 中过早初始化逻辑转为利用时初始化、多历程由启动时加载转为利用时或特定场景触发加载等；延迟优化：4.x 机型延迟施行 Multidex.install 中的 Odex 操做、主线程动静队列中非启动需要动静延迟施行、启动途径非高优营业逻辑延迟初始化等；运行时优化：CPU 提频、语言层面优化（内联、替代反射、制止用 Kotlin 的 Range 轮回）、封闭 Verify Class、4.x 机型按捺 GC、主动触发 AOT 编译、资本重排、类重排、dex 重排等；异步优化：异步预加载（ShardPreference、实例化对象）、异步 inflate view、线程收敛等；降级优化：极速版、组件化降级、非需要耗时逻辑按人群/地域降级等；综合优化：启动使命调度框架、启动途径重构、前后台启动使命精细化重排、后台负载优化等，那些优化项属于前述优化思惟的综合应用，一般不局限于片面的优化。

通过上述列举的各战略优化项你可能会发现，那此中有的优化项其实会对个别营业性能或功用有损，但最末关于启动性能是有显著提拔的，那么此时需要根据“全局收益更大”的战略来综合评估那些优化项的可落地性，并非只看单点的得失，那种全局性的思维在性能优化中十分重要。

线上验证的理论

那部门在前述的办法论中已针对三个关键点论述得比力详尽，那里仅针对三个关键点在落地时的技巧或留意事项加以弥补：

线下的优化必然要有线上的目标反应：因为线上设备的固有硬件性能各别，所以需要有足够量级的用户启动打点数据才气相瞄准确地断定线下的优化能否在线上产生了效果，那个量级从抖音启动优化中试探的经历来看一般到达 100 万即可；此外，不雅测启动性能数据的时间点也需要把控好，那是因为每次发布晋级版 APP 后，大都是性能相对好的手时机先晋级，那个现象会等招致发版初期的启动性能数据整体偏好，不克不及反映实在大盘情形，因而，抖音一般会拔取每个版本发版后 4-5 天（可能随 APP 晋级笼盖安拆的速度差别而差别）的数据断定大盘情形。线上目标需要连系均值与分位值综合来评估：在抖音启动优化理论中，启动耗时均值会更多用于大盘情形评估或线上监控中，而做为性能优化的同窗最次要存眷的是 50 分位机型的数据，那是能代表过对折用户启动性能水准的目标，此外 90 分位以上的机型也需要我们额外存眷，那类机型十分容易放大启动性能问题，从现实来看，90 以上相对 50 的绝对分位数差了不到一倍，但冷启耗时却可能差到 2 倍摆布（如下图所示抖音在某段期间的各分位冷启耗时情形），那申明低端机的用户启动体验是明显可感知的差，基于我们曾经做过的劣化尝试成果来看，那些机型的启动性能若是不克不及有效提拔，将有很大要率削减其留存。

在验证收益时通过 AB 尝试达成：AB 尝试相关于不雅测差别版本的大盘数据来看更具有严谨性，因而在产出尝试结论前同样需要保障数据量和时间跨度，抖音在开启性能的 AB 尝试后，一般会让对照组及尝试组进组用户各到达 100 万并连结至少 5 天后才停止尝试的数据阐发并产出结论，如许能够根本保障所有相关目标的不变及置信。防劣化的理论

防劣化的系统建立是个比力复杂的工程，要做好是有十分大的挑战的。抖音从最早的线下手动的分版本测试起头，颠末了逐渐的试探优化，演变到当前涵盖了代码提交时静态检测、线下主动化劣化测试和归因、灰度劣化发现和归因、线上常态化的劣化监控和归因。防劣化是一个漏斗，从代码提交阶段到线下测试阶段，再到灰度发布阶段，再到线上版本发布阶段，我们希望劣化可以更前置的发现，每个环节都尽可能的发现处理更多的劣化，包管更少的劣化被带到线上。

防劣化的有几个难点：一是劣化检测的准确率和召回率，为了更多更准确的发现劣化；二是劣化的准确归因，发现劣化之后，若是不克不及精准的指出劣化的原因，需要投入比力多的人力资本和时间定位劣化原因，影响劣化处理的效率；三是劣化的修复，若是是比力严峻的劣化，能够接纳阻塞发版期限处理的体例，是比力容易推进处理的。但是从抖音的理论来看，当启动优化到了深水区之后，优化的速度已经比力迟缓，需要存眷几十毫秒级此外劣化了，假设我们处理了一二两个难点，发现了那些轻细的劣化，但是若何推进营业去处理那些小劣化也同样是一个难题。我们需要可以量化出那些劣化对营业的影响，针对差别的劣化量级，和营业对齐优先级，确定尺度的劣化修复流程，才气够包管劣化不会被带到线上影响大盘用户。

防劣化是一个持久的工做，抖音投入已经有一年多了，目前整体效果还不错，在那个过程中也积累了比力多的经历，之后会专门写一个抖音的防劣化系列文章来给各人介绍我们的手艺功效。

启动优化东西

前人云“工欲善其事必先利其器”，在启动性能优化范畴也是一样，我们不只需要趁手的东西来定位优化耗时问题，还需要尽量主动化的东西来持续发现劣化问题，也就是说整个启动优化在“攻”和“守”的两大方面均需要东西的辅助。那么下面将针对那两部门的东西别离停止介绍及分享抖音在启动优化东西方面的摸索：

线下阐发东西

那部门次要针对业界常见的 APP 性能探测东西停止根本原理解析及优缺点比照，详细包罗的东西有：TraceView、CPU Profiler、Systrace，此外还将提及抖音自研的“抖音Android性能优化：新一代万能型性能阐发东西Rhea”：

TraceView：Instrumentation 形式下接纳 AddListener 的体例注册 MethodError、MethodExited、MethodUnwind 的回调来收罗办法起行时间；Sampling 形式下利用一个 SamplingThread 按时主权线程仓库，通过对此的仓库比照近似确定函数的进入和退出时间；固然是官方供给的东西，但两种形式自己都存在比力大的性能损耗，可能带偏优化标的目的；CPU Profiler：整体通过 JVM Agent 实现，具有完成办法挪用栈输出，且撑持 Java、C/C++办法的耗时检测，上手比力简单，但其同样存在性能损耗较大的问题，且一般仅用于 debug 包，release 包需要额外添加 debuggable 的设置装备摆设；Systrace：基于 Android 系统层的 Atrace 实现，Atrace 又基于 Linux kernal 层的 ftrace 实现，ftrace 在内核中通过函数插桩获取耗时；其本身性能损耗比力低、数据源丰硕且具有较好的可视化页面，但其默认监控点较少，在 APP 自有代码中的监控点需要手动参加，比力费事；RheaTrace：那是抖音基于字节码插桩连系 Systrace 及 Atrace 自研的东西，其具有主动参加监控点、各类耗时信息全面、性能损耗低等特点，是抖音日常在线下施行性能优化时首选的东西，其细节详见抖音Android性能优化：新一代万能型性能阐发东西Rhea，那里不再赘述。

RheaTrace 目前是抖音性能优化同窗的次要东西，它不单单是一个东西，也是一个平台。除了 Systrace 自带的性能数据之外，我们增加了营业的函数耗时插桩的数据，能够更全面地对耗时停止阐发。但是那些数据还不敷，我们撑持以插件的形式，增加本身定造的数据，好比为了优化 IO 的耗时，我们通过 hook 增加了更精细化的 IO 的信息，辅助定位 IO 的耗时问题；抖音的类加载耗时也是有些严峻，我们也 hook 了类加载，增加了类加载的性能数据。我们要极致地优化抖音启动时间，以上那些数据是不敷的，还有锁、View 耗时信息等相关数据弥补，给性能优化的同窗供给全方位的性能阐发东西。

除了 RheaTrace 之外，还有一些特定场景的小东西，好比线程阐发东西、内存阐发东西、高频函数阐发等。因为篇幅有限，就不在那里逐个介绍，后面会有专门的系列文章来介绍。

线上监控东西

上面介绍启动优化办法论的时候我们提到了，不克不及只是看线下的性能阐发，线下的阐发成果其实不能完全代表线上大盘用户的情况。我们阐发线上的性能数据，一方面可以验证我们的线上优化效果，另一方面可以从线上多个维度的数据里指点后续的优化标的目的。

线上监控东西和线下的差别点次要在低性能损耗和兼容性，我们将 RheaTrace 做了革新，使其可以满足线上的监控要求。性能损耗上，我们将监控的性能损耗控造在 1%以内，包大小控造在 200KB 以内，根本实现了线上全量用户的启动耗时监控。通过启动途径的全量插桩，能够针对启动途径的各个阶段停止监控，一是能够发现线上用户哪些使命比力耗时，能够针对性的优化，让更多用户受益；二是能够监控线上的启动使命，若是发作了耗时增加，那么申明有劣化，那比监控到启动时间的劣化，要更容易定位到原因。除了线上的全量慢函数监控之外，我们的线上启动监控还会细化IO、锁、GC等多种维度的耗时数据，帮忙定位线上为什么耗时慢，供给新的优化标的目的。

总结一下线上启动监控东西的思绪就是：将线下的性能阐发数据，低损耗的移植到线上，察看线上用户的性能数据，线上线下相连系的阐发启动耗时，为启动优化供给优化标的目的指点。

启动性能优化之路去向何方

看了上文关于启动性能优化如斯多的理论与理论，想必你已经意识到启动优化之路必定是不会普通的，抖音在那条路上摸索了 2 年之久且仍未抵达尽头。在那条路上势必会履历前期的坦途、中期的苍茫与后期的瓶颈，但无论若何都要不断坚决地走下去，因为只要营业还有一天在迭代那么启动性能就有一天存在挑战的可能，所以启动优化之路的将来一定是无尽头的。

既然如斯，那么我们的重点就应该从何时才气走完那条路转移到若何走得更出色之上，以至到最初可以做到把控那条路的走向，那或许也能算做另一种意义上的走完启动优化之路，那么什么才算走得更出色以及把控路的走向呢？

苍茫时慢下步子再阐发全局的耗时点寻找到新的优化战略、碰到瓶颈时先暂时放缓追逐目标测验考试从代码重构上发掘深层的收益、不竭开辟跨范畴（如端上智能降级）连系的优化标的目的……那些或许都能称做是一种出色，而且会因人而异，最末，当那种出色累计得足够多之时我们很可能会发现启动优化之路上已知的所有岔路口全被走了个遍，同期 APP 的启动性能也很可能已经到达了再优化也没什么明显营业收益的地步，而且呈现的任何劣化点都能及时被处理掉，那么那时不出不测的话，启动优化之路走向的把控权已经尽在你手中了。

参加我们

抖音 Android 根底手艺团队是一个深度逃求极致的团队，我们专注于性能、架构、包大小、不变性、根底库、编译构建等标的目的的深耕，保障超大规模团队的研发效率和数亿用户的利用体验。目前北京、上海、杭州、深圳都有大量人才需要，欢送有志之士与我们配合建立亿级用户全球化 APP！

能够点击「链接」，进入字节跳动雇用官网查询「抖音根底手艺 Android」相关职位，也能够邮件联络：fengda.1@bytedance.com 征询相关信息或者间接发送简历内推！