数据如何指导决策:优酷主客APP播转率的C端优化

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 数据如何指导决策:优酷主客APP播转率的C端优化

一、背景介绍


1. 了解「播转率」及相关业务

优酷是一个综合视频平台,用户到访优酷是为了观看视频。对于平台来说,希望到访的用户都能找到自己想看的内容,收获满意的用户体验,达成后续的留存与持续活跃。

“播转率”这个指标,作为“播放转化率”的缩写,描述的是平台DAU里有多大比例产生了播放行为。这个指标之所以重要,在于只有先吸引用户产生播放(起播),才有机会让用户观看更多的时长,以及因为内容产生付费等。从用户型产品的视角来看,“产生播放”是一个核心转化环节(类比于淘宝的“下订单”)。

播转率的影响因素众多,从C端可优化的范围来看,主要在流量分发用户体验等环节,涉及包括优酷总编室、各频道运营等业务方,和搜索推荐算法、播放技术等产研团队。其中总编室作为平台运营方,统筹站内核心流量资源,协同产研各方重点从内容分发等方向做播转率的优化。


2. 数据驱动在其中的价值


利用数据驱动的思想解决业务问题,其主要价值体现在两个层次:

第一,是在战略上给与方向性指导。包括帮助看清业务现状、诊断业务存在的问题、找到业务的机会重点、论证方向的可行性等。针对“播转率在C端如何做提升优化”这个大的业务目标课题,核心就是要回答:影响播转率的C端重要因素是什么?当前播转率的关键卡点在哪里?能落地的重点优化方向是哪些?

第二,是参与战术上的落地优化。在这个层面需要深入细节,针对具体问题和场景,发挥数据敏感度和专业性,量化地建立策略模型、敏锐地发现优化机会、科学地评估优化效果等。

本文主要讲述数据侧在第一个层次(数据指导决策)上的工作。对于在第二个层次上的工作,后面也会单独写文章分享针对播转率优化的具体策略细节。


二、案例详解


1. 从头开始:播转率的严格定义


上面已经说过,播转率的定义是DAU里有多大比例用户产生了播放行为。形式化定义如下:

其中,PUV指的是“产生有效播放的独立用户数”(played unique visitor)。特别的,我们把研究范围限定在优酷主客户端APP(含Phone和Pad端安装的Youku APP)。在下面的论述中,我们把主客APP的整体播转率称为“全站播转率”。

关于播转率的几个关键口径

第一,“用户”实际上是用“设备ID”来区分的(和DAU的逻辑一致),而不是账号或其他口径;

      第二,“有效播放”指的是用户看到了视频本身内容的第一帧(由播放日志的play_code编码确定;自动播放作为一种特殊情况,需要观看5秒才算有效播放);

      第三,这里的播放不包含直播这种特殊形式(只包含点播播放)。


2. 首要步骤:指标的多维度拆解


要深入理解任何一个业务指标,无论是要洞察机会点,还是要解释异常波动,从数据角度来说首先要做的都是对指标进行多维度拆解。其思想非常直接而朴素,本质就是“看得更细”。从数据立方体的角度来讲,就是把指标(或称度量)按不同维度进行下钻分析。

要对全站播转率这个指标进行拆解,需要先了解它的特点。第一,宏观上,它是一个比例型复合指标(由PUV和DAU两个简单指标相除得到,且分别在UV粒度上做去重);第二,微观上,从单用户粒度来说它是一个0-1型指标(要么播放,要么不播放,播放多次与播放一次没有差别)。

基于这些特点和业务经验,我们从“人-货-场”三大方向,选择如下维度对全站播转率进行拆解。

1)人的维度 - 按用户拆

前面已经讲过,播转率是一个UV粒度的指标,其口径是用“设备ID”来标识的;所谓用户维度的划分,本质上是针对设备的(包含基于设备的用户画像)。

用户的划分可以有多种维度,按活跃度可以分为高活、中活、低活等,按设备类型可以分为安卓和iOS等,当然也可以按年龄、性别等画像维度来划分。

这里以最简单的性别维度进行说明。首先,用户群体播转率的定义是明确的:

其次,一个用户在性别维度上要么属于男性、要么属于女性(实际中会有“未分类”取值,这里忽略),但不能既属于男性又属于女性。在这个前提下,即使是UV去重类的指标,也可以直接相加(全站DAU = 男性用户DAU + 女性用户DAU,全站PUV = 男性用户PUV + 女性用户PUV)。

基于此,以下公式成立:

可以看到,全站播转率的高低,既取决于每个用户群体播转率的高低,也取决于各群体在DAU中的占比。通过泛化这个模型,我们可以在任意用户维度上精确量化出不同人群及其占比关系,对全站播转率的重要程度。

从上面的分析也能感受到,由于播转率是一个用户粒度的去重指标,所以按用户维度进行拆解,在逻辑上是自洽的,体现在拆解模型上是完备的。

有趣的辛普森悖论

假设全站播转率环比上个周期出现了下跌,但按性别拆开来看,男性用户播转率和女性用户播转率却分别都环比上涨了。这种情况有可能发生吗?答案是肯定的。

根据上面的模型公式可以很好的解释:如果男女用户在DAU中的占比结构发生了变化,即使两个群体各自的播转率都上涨,仍有可能出现整体播转率的下降。说的更直白一点,假设播转率较低的那个人群在DAU中的占比大幅增长,那么这种情况就可以发生。这大概是统计学中的辛普森悖论在现实中最接地气的实例了。


完成了播转率在用户维度的拆解后,可以发现一些基本的数据洞察。比如按DAU的到访方式来看,虽然DSP外投用户和PUSH首唤用户理论上应该进站就产生播放,但其实际播转率却比主动打开APP的用户更低。这与第二部分第4节要讲的用户未播转归因分析也是相互验证的,属于播放链路环节的优化点。


2)货的维度 - 按内容拆

在优酷,承载内容的主要形式是视频,把内容进行划分也有很多维度,以下用业务类型维度进行说明。在该维度下,内容可分为长视频和短视频两大类型(不考虑未分类的情况)。

把播转率在内容维度上进行拆解,和上述按用户维度拆解有本质的区别:一个用户可以既在长视频内容上播转,又在短视频内容上播转,但对于全站来说只算一个播转UV。此时,全站总PUV < 长视频PUV + 短视频PUV。当然如果要实现可加和的精确建模,可做如下拆解:总PUV = 只看长视频的PUV + 只看短视频的PUV + 既看长视频又看短视频的PUV。显然,如果一个维度下的取值太多,这种方式是不可扩展的。

除此之外,内容维度的播转率如何精确定义也有不同。比如“长视频的播转率”,如果严格按照播转率口径,应该表达为“长视频PUV / 长视频DAU”,长视频PUV没有歧义,但“长视频DAU”则缺乏明确的定义(无论是按长视频的曝光UV来定义,还是按DAU里有长视频偏好的用户数来定义,都是不标准且没有太大实际价值的)。在实际分析中,可用全站总DAU作为分母,此时长视频播转率就变成了“DAU里有多大比例产生了长视频的播放”,本质上是将焦点放在了分子(PUV)的部分,即只将PUV按各个内容维度进行拆解和分析。

按内容维度拆解播转率后,很容易发现,全站播转率受长视频影响较大。更准确的说,是和长视频里面新热节目的PUV有很强的相关关系。


3)场的维度 - 按分发场拆

把内容分发给用户,需要以APP内的“分发场”作为媒介。从C端产品形态来看,场的概念可以是一个引导页面(首页、搜索结果页、个人中心页等),也可以是页面里的某一个模块/抽屉(比如首页的轮播图、热播抽屉、猜追抽屉、FEED区域等)。

某个具体分发场的播转率该如何定义呢?以首页为例,首页播转率 = 首页PUV / 首页DAU。其中首页PUV指的是由首页引导点击而产生播放的用户数,首页DAU可以用首页访问用户数来定义(用页面访问日志做统计)。

基于此,可以得到每个分发场(引导页)自身的播转率。哪个场的引导播转效率高,哪个场还有提升空间,似乎都一目了然。但到目前为止,仅做这个拆解,还无法准确量化各场播转率与全站播转率之间的折算关系。为什么呢?前面已经说过,在用户维度上进行播转率的拆解在逻辑上是自洽的,而在内容维度不成立。同样的,场的维度也有这个问题。一个用户可以既访问首页,又访问搜索页,此时TA同时是两个页面的DAU;TA也可以在多个场景产生播转(分别贡献多个场景的播转率),但对于全站播转率来说,TA只能算一个播转UV。在下面的第二部分第3节,我们会讲述如何分析这个问题。

总结来看:以上从“人-货-场”三个大方向说明了如何选取有意义的维度,对全站播转率进行拆解。实际分析中我们可以对多个维度进行交叉,进行二维甚至更高维度的拆解,以便看到更细节的信息,这里不再赘述。


3. 逐步深入:各场播转率提升对全站的贡献测算

从平台运营的视角来看,每个场景会单独做分发策略的优化,各场的产品运营同学会天然地关注自己场的播转率。实际在OKR制定过程中,也是按不同分发场自身播转率的提升作为KR,来承接全站播转率在分发侧整体提升这个O的。

这里的核心问题是,需要知道对这个目标影响最大的场景是哪些,以便为OKR的制定提供方向性的科学指导。进一步说,某个分发场通过自身播转率的提升,带来全站播转率提升的幅度能否量化、如何量化?更直白一点:某个分发场提升1%的自身播转率,理论上对应全站播转率的提升幅度是多少?

前面已经说过,如果只是按第二部分第2节里讲述的通过场景维度来拆分全站播转率,已经不能有效解决这个问题了。

常见分析误区

误区1:场景A的PUV占全站PUV的10%,则场景A的PUV提升10%对应全站PUV能提升1%

误区2:场景A的DAU是全站DAU的10%,则场景A自身播转率提升10%对应全站播转率能提升1%

以上都是常见的错误结论,本质是因为全站播转率(PUV/DAU)是一个在用户粒度去重的0-1型指标,用户在多个场景的播放会分别记到各场的播转;但对全站指标来说,用户在一个场还是多个场产生播放是没有区别的。

举个例子。对于站内某个分发场景A,极端情况下,我们假设其所有到访用户都已经在其他场景产生过播转了,那么场景A本身的播转率无论怎么提升,对全站播转率也没有任何帮助。一个不太严谨的实例,是播放页的二次分发引导场景(到访播放页的用户,理论上在播放页二次引导之前已经有过播放请求了)。之所以说不太严谨,是因为到访播放页的用户虽然有播放请求,但不一定都严格从口径上被记入全站播转UV了(比如在前贴广告中途退出,或者请求播放返回失败等,在第4节用户漏斗分析会详细说明)。

     

具体应该如何分析和量化呢?这里需要跳出各场自身的思维局限,结合全站的行为,将用户进行不同的未播转分类。

假设某个场景的访问用户(DAU)为100w,场景自身的播转率为60%。显然,这里将用户分成了两类,一类在该场景产生了播转(60w),剩下的未播转40w用户,还可以继续分为两类:1)虽然在该场景未产生播转,但在全站其他场景有播转;2)不仅在该场景未产生播转,在全站其他场景也未产生播转。从统计上来看,优化该场景的播转率对全站的影响,不仅跟该场景的DAU规模相关,也跟该场景未播转用户中上述两类的占比相关。

这里的核心逻辑是:一个场景的到访用户中,在全站其他场均未产生播转的人群规模越大,则这个场景能通过分发优化而带来全站整体播转提升的机会就越大。当然,这里的机会越大指的是理论上的空间越大,不包含实际提升难易程度的因素。

我们假设一个前提:某场景通过分发优化促成的新增PUV中,上述两类用户的比例,跟当前该场景未播转人群里这两类用户的比例一致。在这个前提成立的条件下,用下面的公式可以折算出:场景自身播转率绝对值提升1%,全站播转率能提升多少绝对值。

当然,这个假设前提是比较理想化的。由于两类用户的行为特征不同,其实际的转化难度不一定相同。

根据上述方法对主客各分发场进行量化,可以得到如下分析结果。

可以看到,对全站播转率影响相对较大的分发引导场,量化来看依次是:主客首页、搜索、个人中心、NRU首页和剧集频道页等。以搜索场为例,其自身播转率提升1%绝对值,模型测算能带来全站播转率提升约0.XX%绝对值。

现实的尴尬:左手倒右手

现实中,各场播转率提升对全站播转率的影响,比上面分析的更加复杂。我们经常看到一个有意思的现象:某个场景通过分发策略优化显著提升了自身的播转率,但整体来看对全站播转却没有产生任何帮助。仔细分析原因,往往是由于该场景的优化对其他场景产生了负向影响,俗称流量上的“左手倒右手”。本质上,这是用户需求在各场之间发生了转移,并没有产生需求的增量。举个典型的例子,比如首页首屏对搜索新热内容需求的拦截,用户只是选择了最短的路径而已。

每个场景关注自身播转的优化无可厚非,但在平台视角,决策者更希望看到全局上良性的增长。我们也在极力推动所有分发侧实验,除了要看自身场景的实验数据外,还要观测该实验人群在全站整体数据的对比。


4. 剑指核心:回归用户视角、挖掘用户行为


第二部分第3节主要从对播转率做了场景维度的重要性量化分析,这个视角对各场认清自己在全站播转中的定位是很有用的。但播转率终归是一个用户型指标,一个DAU用户或在站内产生了播转,抑或没有产生,都是有其原因的。通过对用户行为的拆解、挖掘、归纳,从用户视角来洞察播转率的提升空间,不失为一种更加直接的方式,将会使得整个播转率提升之路更加清晰。

1)用户播转漏斗分析

根据产生播转的过程,用户从进站成为DAU到产生播放,有两个重要的漏斗环节,如下图所示:

第一个漏斗是从进站到产生播放请求,这个漏斗代表的是用户有多大比例产生播放意愿。第二个漏斗是从播放请求到真正的播放转化,这个漏斗的大小,代表有多大比例的用户由于前贴片广告和播放加载失败等原因而最终未被归到PUV里,这些原因可以统称为播放链路原因。

通过这个漏斗分析,可以很直观地将用户的未播转原因拆分为两类问题:用户意愿问题和播放链路问题。当然这是比较粗粒度的分析,要能指导业务针对性的找到落地抓手和优化方向,需要进一步探查用户不产生播转更明确的原因。下面介绍的“未播转用户行为特征归因”则能帮助解决这个问题。

2)基于用户行为特征的未播转归因

当前优酷主客的播转率已经显著高于50%,代表大部分DAU用户都会产生播放转化,因此从统计上,“未产生播转”相对于“产生播转”来说,是一个更为稀有的事件。基于用户行为特征的未播转归因,核心逻辑是圈出全站的未播转人群,挖掘和抽象出TA们的站内行为特征,结合业务知识归纳出未产生播转的各种原因。根据各种原因对应的人群规模,以及可落地干预的抓手,便可确定全站播转率在用户视角的重点优化方向。

具体从数据侧如何做未播转用户的归因,讲两点经验。

第一,对行为日志数据的处理。优酷主客APP采用集团UT规范上报用户行为,包含点击事件、曝光事件、页面访问事件、播放事件等。做用户行为分析,需要基于这些日志抽象和定义出一个个用户层面的事件状态,并按发生的时间先后进行排序,最终形成用户粒度的状态转移序列数据。有了这个数据,所有未播转用户的行为动线就可以刻画出来。

第二,对用户行为的抽象与归因。既然是用户的未播转归因,就需要在具备用户同理心的前提下,将不同的行为特征归到不同的原因。这个原因一定是用户视角的,而不是平台视角的。一个细节是归因优先级的问题。一个用户可能产生多个对应不同未播转原因的行为特征,但为了直观地看到不同原因所占的百分比,有必要将每个用户只归给一个未播转原因,此时所有未播转原因加总一起是100%。举个例子,一个用户可能会因为PUSH唤端进站,默认进到播放页起播失败之后,又去首页逛FEED区,最终未产生有效播放。如果按行为特征来归因,会命中“因播放链路失败退出播放”和“在首页未找到喜欢的内容”两个原因。按照我们设计的规则,最终会将其归到第一个原因(在归因时,意图相对更明确的行为排在更靠前)。

【对产品和业务的理解是做分析的关键】

如果没有对C端产品形态足够的了解和对全局业务规则的熟悉,从一大堆的用户行为数据里面找出规律和洞察则无从谈起。举个例子,不同用户进站访问的默认页面和产生播转的路径是不同的。DSP外投用户会进到特定的播放承接页,PUSH唤端用户会根据内容类型的不同进到节目播放页或者底导2TAB页,这两类用户都会默认发起播放请求。而主动打开APP的用户则依据用户状态默认进到主客大首页或者NRU首页。如果缺乏这些知识,是无法基于合理的逻辑做出正确分析的。

 

基于用户行为特征,最终我们得出的未播转归因分类如下:

通过以上分析结果,可以很明确地看到全站播转率在用户侧视角的主要卡点和提升空间。当然这里列出的未播转原因是做过汇总的,具体在分析时我们都做了更细的拆分。

几个比较重要的未播转原因包括:

1)播放链路返回失败。这部分从渠道类型看包括了DSP外投播放链路、PUSH唤端播放链路,以及正常跳转站内播放承接页的链路;另一方面,也可以按播放器返回的playcode码做返回错误的类型区分。

2)用户搜了优酷无版权的内容而跳出。针对这部分用户,分析时也区分了有点击节目资料卡或外链,和完全无任何点击的行为。

3)用户误启动APP或无耐心。TA们最显著的特征是从开机页就离开了,或者在站内总停留时长不超过6秒。不管背后的真正动机是什么,这部分用户要做干预是比较困难的。

4)未找到喜欢的内容。这个原因的归类比较泛:只要用户有浏览和逛的行为,在排除前序未播转原因后,都可以归于此。在分析时,我们也按访问路径和探索深度进行了区分。要促进这部分用户播转也是比较有难度的(属于内容分发优化的范畴)。

此外,针对播转率较低的低活人群和NURU人群,我们还单独针对其未播转原因(并结合其路径和内容偏好)做了更细致的子专题分析。


5. 过程沉淀:数据分析产品化


利用集团可视化BI分析平台,我们将上述各个分析过程进行了可视化,沉淀为了数据产品。

大盘播转率全景分析工具


产品化的好处有很多。利用指标的多维度下钻功能,使用者可以方便地探索发现业务存在的问题和潜在的机会点。多维分析同时结合漏斗,在指标异常波动时能帮助发现问题原因。同时,各种针对性的优化措施落地后,也能通过相应未播转原因规模变化观察到对应的效果。


三、对决策产生的实际影响


第二部分中做的数据侧分析洞察工作,对决策产生了方向性的指导,为业务方OKR的制定提供了数据上的依据。不仅直接影响了相关团队的工作投入重点,也促成了多个优化专项的立项。

第二部分第4节关于用户未播转归因的分析,直接指明了在内容分发侧的工作重点。针对播放链路原因导致的未播转,研发团队启动“DSP唤端链路优化”专项,以DSP极简播放页为基础优化起播链路并取消了前贴广告(经过优化,DSP外投人群的播转率大幅提升,和主动打开APP人群的差距绝对值已经从优化前的XXpct缩小到现在的XXpct);从全站整体播转漏斗来看,无效播转用户规模同比实现大幅度下降(如下图)。针对搜索无版权内容跳出,搜索运营和产品启动“无版权意图承接”专项(启动优化后,干预的无版权意图命中率提升XXpct)。针对首页分发的优化,总编室协同推荐算法启动“NRU承接优化”专项和“低活承接优化”专项(经过优化,RU承接页用户全站播转财年同比提升XXpct)。


经过技术优化,因播放链路问题产生无效播转的用户规模大幅下降


第二部分第3节关于各场景对全站播转的重要性分析,首次实现了场景自身播转的提升对全站贡献的量化,分析结果被平台运营侧直接引用,作为新财年各场播转OKR的设置依据,并依此战略性的对各场投入做了取舍(优化ROI配置)。


四、后续展望与规划


1. 机会深挖:持续理解用户行为


优酷有着海量的用户行为数据,这是一个巨大的宝藏。如何从这些数据中挖掘隐藏的规律,发现有价值的信息,是每一个数据使用者面临的挑战。对于前面的洞察分析来讲,我们所触达到的也只是一小部分数据。只有不断尝试细致的深入分析,才能加深对用户行为的理解,从而更有效的找到实现增长的机会点。具体对于播转率提升而言,还需要进一步细化研究用户在站内的行为动线,并结合更长的时间窗口去理解用户行为的前因后果。


2. 格局突破:尝试洞察影响指标的非C端因素


影响全站播转率的因素很多,本文主要陈述的是在C端策略框架下的数据驱动案例。播转率在C端主要依靠流量分发和用户体验两个方向进行优化,前者的本质是实现更精准的“用户-内容”匹配、更好地命中和发掘用户需求,后者则主要包含起播链路优化、产品形态优化、用户权益优化等环节。

事实上,我们也不得不承认,在如今C端分发和体验已经做到一定水平之上的背景下,相较于C端环节,非C端因素对播转率的影响其实更为显著。比如头部内容的供给与排播节奏,就会对播转率产生非常明显的影响。一部S+大剧的开播,会吸引大量目标用户进站产生播放和追剧,从而助推全站播转率在其热播期维持在一个相对高的水位。通过研究站内用户行为,挖掘C端行为侧反馈出来的有价值信息,其实同样也能指导和影响非C端的决策。这也是我们后续在播转率提升和其他目标上想要尝试的突破点。


3. 价值放大:分析方案的应用扩展


前面提到过,产生播放转化本质上是达成用户满意体验的一个偏前置的核心环节。除了提升播转率之外,对于平台价值和用户价值而言,还有其他一些重要的业务目标的决策也需要数据洞察来指明方向。包括如何提升用户观看时长,如何促进用户活跃,如何增长会员收入等等。将已经相对成熟的分析方法论复用到其他业务目标,是下一步的重点挑战,也是数据价值放大的必然选择。

相关文章
|
8天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
37 3
|
29天前
|
传感器 iOS开发 UED
探索iOS生态系统:从App Store优化到用户体验提升
本文旨在深入探讨iOS生态系统的多个方面,特别是如何通过App Store优化(ASO)和改进用户体验来提升应用的市场表现。不同于常规摘要仅概述文章内容的方式,我们将直接进入主题,首先介绍ASO的重要性及其对开发者的意义;接着分析当前iOS平台上用户行为的变化趋势以及这些变化如何影响应用程序的设计思路;最后提出几点实用建议帮助开发者更好地适应市场环境,增强自身竞争力。
|
1月前
|
数据采集 网络协议 算法
移动端弱网优化专题(十四):携程APP移动网络优化实践(弱网识别篇)
本文从方案设计、代码开发到技术落地,详尽的分享了携程在移动端弱网识别方面的实践经验,如果你也有类似需求,这篇文章会是一个不错的实操指南。
65 1
|
2月前
|
JSON API 网络安全
App数据的爬取
App数据的爬取
46 3
|
4月前
|
存储 SQL JSON
【Azure Logic App】微软云逻辑应用连接到数据库,执行存储过程并转换执行结果为JSON数据
【Azure Logic App】微软云逻辑应用连接到数据库,执行存储过程并转换执行结果为JSON数据
【Azure Logic App】微软云逻辑应用连接到数据库,执行存储过程并转换执行结果为JSON数据
|
4月前
|
缓存
【Azure Function】Function App代码中使用Managed Identity认证获取Blob数据时遇见400报错
【Azure Function】Function App代码中使用Managed Identity认证获取Blob数据时遇见400报错
【Azure Function】Function App代码中使用Managed Identity认证获取Blob数据时遇见400报错
|
4月前
|
Web App开发 移动开发 前端开发
如何优化运行在webkit上的web app
如何优化运行在webkit上的web app
|
4月前
【Azure 事件中心】在Azure Function App中消费Event Hub数据,时常出现EventReceiveError
【Azure 事件中心】在Azure Function App中消费Event Hub数据,时常出现EventReceiveError
|
6月前
|
ARouter IDE 开发工具
Android面试题之App的启动流程和启动速度优化
App启动流程概括: 当用户点击App图标,Launcher通过Binder IPC请求system_server启动Activity。system_server指示Zygote fork新进程,接着App进程向system_server申请启动Activity。经过Binder通信,Activity创建并回调生命周期方法。启动状态分为冷启动、温启动和热启动,其中冷启动耗时最长。优化技巧包括异步初始化、避免主线程I/O、类加载优化和简化布局。
89 3
Android面试题之App的启动流程和启动速度优化
|
6月前
|
缓存 JSON 网络协议
Android面试题:App性能优化之电量优化和网络优化
这篇文章讨论了Android应用的电量和网络优化。电量优化涉及Doze和Standby模式,其中应用可能需要通过用户白名单或电池广播来适应限制。Battery Historian和Android Studio的Energy Profile是电量分析工具。建议减少不必要的操作,延迟非关键任务,合并网络请求。网络优化包括HTTPDNS减少DNS解析延迟,Keep-Alive复用连接,HTTP/2实现多路复用,以及使用protobuf和gzip压缩数据。其他策略如使用WebP图像格式,按网络质量提供不同分辨率的图片,以及启用HTTP缓存也是有效手段。
98 9

热门文章

最新文章