Android App 启动优化全记录

  • 时间:
  • 浏览:1

启动过程中繁忙的 SystemServer

这里涉及到具体的业务,每个 App 有的是一样,许多所要做的事情有的是一样的,下面是邵文在高手课后面 提到的:

应用启动的如果,将会主系统守护进程的工作没人多,也会造成主系统守护进程过于繁忙,下面哪几个系统调度相关的点需要注意:



(https://www.androidperformance.com/images/15740896485396.jpg)

推荐阅读:2019最新收集阿里Android面试失败大全之源码篇

2019最新收集BATJAndroid 高级面试题及答案转自“写给全国移动互联网工作者的一封公开信”

利用 Linux 的 IO 读取策略,PageCache 和 ReadAhead 机制,按照读取顺序重新排列,减少磁盘 IO 次数 。具体操作需要参考支付宝 App 构建优化解析:通过安装包重排布优化 Android 端启动性能 这篇文章

启动过程中繁忙的 cpu

应用的启动,从桌面点击应用图标到主界面用户可操作,大致遵循下面的流程:

Android 系统更新也会对应用启动数率进行优化,比如后面 提到的 Pre-Fork,又比如这里的多样化 doFrame 个数

流程梳理,延后执行;实际上,你这人 步对项目启动加速最有效果。通过流程梳理发现次要流程调用时机偏失等, 相似于

当然对于应用开发者来说,后面 说的都没人多理想化了,许多目前的手机厂商也会很暴力,应用到了后台就会出理 掉,不过这毕竟是另八个方向,Google 也在规范应用后台行为和规范厂商出理 应用这两方面有的是做努力,Android 系统的生态,还是需要应用开发者和 Android 厂商一并取改善。

App 启动的如果,系统会对要启动的应用做绝对的资源倾斜,比如 CPU、IO、GPU 等,你这人 点我们我们我们 抓个 Systrace 看一下即可,不管是频率还是调度算法,正在启动的 App 绝对是当时的系统 VIP 客户

次要场景会针对用户的使用习惯进行学习,比如在那先 时间、那先 场合、那先 交通工具打开手机,系统会预测我需要启动的 App,并在后台进行启动,原本你点击你这人 App 的如果,就将会是热启动了

次要应用启动的如果,需要小量的内存,比如现在的相机启动,这如果将会没人足够的内存,没人系统需要要通过杀掉没人多没人多应用、释放 Cache 等操作来给你这人 App 让路,你这人 过程会使得那先 大内存的 App 在启动的如果频繁进行内存操作,原困 启动数率变慢

Linux 底层文件系统中 VFS 上次 App 系统守护进程之间,所处一层 pagecache,pagecache 由内存中的物理 page 组成,其内容对应磁盘上的 block。Pagecache 的大小是动态变化的,需要扩大,也需要在内存过高 时缩小。Cache 缓存的存储设备被称为后备存储(backing store),另八个 page 通常蕴含多个 block,那先 block 不一定是连续的

IdleHandler:当 Handler 空闲的如果才会被调用,将会返回 true, 则会时不时执行,将会返回 false,执行完一次后就会被移除消息队列。比如,我们我们我们 需要将从服务器获取推送 Token 的任务装下 去延迟 IdleHandler 中执行,将会把许多不重要的 View 的加载装下 去 IdleHandler 中执行

具体的业务会有具体的优化场景,我们我们我们 需要参考这篇文章中的优化流程和优化项(https://www.jianshu.com/p/f5514b1a826c)

系统也会对许多应用进行特殊出理 ,以提升用户体验:包括但不限于 系统守护进程系统守护进程优先级调整、查杀白名单、用户常用应用记录等,进行适当的后台保活,下次启动的如果就是热启动了

需要在 systrace 生成的文件中看过 verifyClass 过程,将会需要校验土办法的每另八个指令,没人多没人多是另八个比较耗时的操作。

应用主界面布局优化是老生常谈了,综合起来无非就是下面两点,你这人 需要结合具体的界面布局去做优化,网上有的是比较多的资料需要查阅

IO 分网络 IO 和磁盘 IO ,启动过程中不建议进行网络 IO ,对于磁盘 IO 则要细扣,邵文在高手课后面 有讲到:

需要把具体的业务分为下面八个维度(此处图文来自https://juejin.im/post/5c21ea325188254eaa5c45b1#heading-5)

次要厂家会对启动过程 App 的主系统守护进程和渲染系统守护进程做特殊对待,比如我们我们我们 直接跑到大核上,将许多不重要的系统守护进程移到小核

启动窗口,也叫启动页、SplashWindow、StartingWindow 等,指的是应用启动如果的预览窗口。iOS App 强制有另八个启动页,用户点击桌面 App 图标如果,系统会立即显示你这人 启动窗口,等 App 主页加载好如果再显示主页面。Android 有的是相似于的机制 (启动窗口你这人 是 Android 系统提供的),许多也提供了另八个接口,让应用开发者设置不是显示你这人 启动窗口(默认是显示),次要开发者会把你这人 系统提供的启动窗口禁掉,启动另一方的窗口。

虽然对用户来说,第某种启动流程是最好的,只涉及到一次窗口的切换;许多次要 App 将会广告页的需求,会使用第二种流程 ;许多尽量没人多使用第某种和第某种启动流程,体验非常不好

当然保活还有第一根路就是走跟厂商的合作,优化后台内存、添加重复拉起、添加流氓逻辑、积极响应低内存警告,做好那先 话后需要跟系统厂商联系,谈装下 去查杀白名单和自启动白名单的可行性

许多按需进行加载优化

Activity 打开如果就预加载数据,在 Activity 的 UI 布局初始化完成后显示预加载的数据,大大缩短启动时间。 需要参考 :https://github.com/luckybilly/PreLoader/blob/master/README-zh-CN.md

类重排的实现通过 ReDex 的 Interdex 调整类在 Dex 中的排列顺序。Interdex 优化需要去分析类引用,它只需要调整 Dex 中类的顺序,把启动需要要加载的类按顺序装下 去主 dex 里,你这人 工作我们我们我们 完整性需要在编译过程中实现,许多你这人 优化需要提升启动数率,优化效果从 facebook 宣告的数据来看也比较可观,性价比高。具体实现需要参考 Redex 初探与 Interdex:Andorid 冷启动优化

保活,是各个应用开发者的噩梦,也是 Android 厂商关注和打击的重点。不过从启动的数率来看,将会应用系统守护进程不被杀,没人启动自然就快了,没人多没人多保活对应用启动数率也是有极大的帮助。

我们我们我们 需要参考淘宝的全链路优化的案例:历时1年,上百万行代码!首次揭秘手淘全链路性能优化(上))

利用文件重布局结合Pagecache 机制需要减少启动过程中的真正 IO 的次数,简单的说,通过文件重布局的目的,就是将启动阶段需要用到的文件在 APK 文件中排布在一并,尽将会的利用 pagecache 机制,用为宜的磁盘 IO 次数,读取尽将会多的启动阶段需要的文件,减少 IO 开销,从而达到提升启动性能的目的

厂商的策略各不相同,这里就是简单的提一下思路

启动优化整个流程的梳理,流程的梳理,我们我们我们 这里引入了另八个有向无环图的概念,我们我们我们 会把整个的概念梳理成有向无环图的社会形态,许多会去挨个加载。右边的次要,需要看过我们我们我们 其虽然启动的如果,首先会去加载许多必要的启动项,必要的启动项是左边流程,会用另八个多系统守护进程的土办法加载,以来有向无环图进行控制,比如说我是在非需要的如果启动加载我需要装下 去后面 再去加载。当然在整个有向无环图的顺序加载,虽然还是会做许多系统守护进程的判断,要判断许多项目是有的是要在主系统守护进程里加载,许多要在初始系统守护进程后面 加载

次要厂商会在监测到你这人 大内存 App 启动的如果,提前做内存的回收操作,原本在启动的如果,有的是了足够的内存给你这人 App 使用

作者:Gracker

原文链接:https://www.androidperformance.com/2019/11/18/Android-App-Lunch-Optimize/

本文参考了目前大次要 Android 应用启动优化的方案,将我们我们我们 的方案做另八个汇总,将会你有这方面的需求,只需要对照这篇文章,看看另一方的方案,查漏补缺。没人多没人多方案是要根据具体的业务去做优化的,没人多没人多这里也没人对每某种方案进行完整性的介绍,要用到哪另八个方案的如果,需要具体去网上查找对应方案的具体实现土办法,这里就是做另八个汇总

当然这里说的保活,并有的是建议我们我们我们 用各种黑科技、相互唤醒、通知轰炸你这人 保活手段,就是提供真正的功能,能让用户虽然你在后台是合理的、需要接收的。比如在后台的如果,资源能释放的都释放掉,没人多时不时在后台做耗电操作,该停的服务停掉,该关的动画关掉。

另外我还添加了次要系统厂商所做的启动相关的优化,不过只写了许多我知道的,还有许多厂商有黑科技,就没哟这里的讨论范围了。知道厂商做的事情,将会也会帮助到你,比如联系厂商做白名单、接入厂商 SDK 等

次要厂商也提供了资源调度的 SDK ,应用需要接入那先 SDK,在需要资源的如果直接调用 SDK 获取

Android Q 加入了 PreFork 机制,会先 fork 哪几个空系统守护进程,当 App 启动的如果,需要直接复用这哪几个空系统守护进程,而不让重新去 fork

各家应该有的是另一方的方案,关键在于何如定义启动如果开使的点,你这人 也是时不时困扰我的另八个地方,有的应用很好定义,有的应用则将会比较多样化,无法直接衡量启动数率。像 adb 你这人 土办法另一方玩玩需要,生产环境没啥用;录屏某种有的是性能损耗..

启动的如果,对启动过程中的 Message 进行重新排列

这里还需要引入冷启动和热启动的概念,这也是我们我们我们 时不时会碰到的另八个概念

StartingWindow 会在用户点击 App 后立即创建并显示(前提是 App 没人禁止 StartingWindow),在 AppWindow 创建好如果,StartingWindow 消失,AppWindow 显示

许多启动另一方的窗口需要的时间要比直接显示系统的启动窗口所花的时间要长,这就会原困 用户在使用的如果,点击图标启动 App 的如果,有一定的延迟,表现在点击图标过了一段时间才进行窗口动画进入 App,我们我们我们 要尽量出理 你这人 情况报告

系统会对许多应用进行特殊出理 ,比如你这人 App 比较重要许多必须杀掉,没人有的厂商会在你这人 应用退到后台如果,进行无感重启:比如说某个应用内存超标将会持续 Crash ,后台重启需要很好地出理 你这人 那先 的大问题,原本重启后的 App 是用户点击启动的如果就是热启动

通过OCR提取图片中的文字信息作为关键社会形态。该算法的优势:1. 在于应用页面上基本有的是有文字的, OCR也需要识别到图片上的文字, 文字出現则图片加载完成, 和用户体感是一致的;2. 文字作为社会形态,过滤掉了没人多没人多图片社会形态将会带来的噪声, 减少了算法调试的工作量;另外阿里集团内有非常性性性性成熟期 图片 是什么和优秀的OCR服务——读光,文档识别率超过99.7%, 使用水滴平台封装的OCR服务,需要快速接入和使用。最终的识别方案就是基于OCR识别来进行的

需要看过应用启动过程中,最重要的另八个系统守护进程就是 SystemServer 和 App Process . 其职责划分如下:

下面图中需要看过高 内存的如果,启动应用主系统守护进程有较多的 IO 在等待(UI Thread 你这人 栏,橘红色代表 IO 在等待 )

启动过程中负载比较高,有许多系统 IO 有的是此时所处,这如果 IO 的性能下降会比较快,此时 App 中的 IO 操作会比平时变慢许多,尤其是在性能比较差的机器上。

需要参考下面这篇文章 支付宝客户端架构解析:Android 客户端启动数率优化之「垃圾回收」)

这里我建议我们我们我们 学习历时1年,上百万行代码!首次揭秘手淘全链路性能优化(上)中提到的测量土办法:自动化、稳定、持续集成

从 Spark 的 DAGScheduler 中领悟到它的核心思想,面向阶段调度(Stage-Oriented Scheduler):把应用划分成另八个个的阶段(Stage),再把任务(Task)安排到各个阶段中去,任务的编排则是通过构建 有向无环图(DAG),把任务依赖通过图的土办法梳理得 井井有条。将会它分阶段执行,先集中资源把阶段一读懂,再齐心协力去执行阶段二,原本即能控制拥塞,又能保证时序,还能并发执行,让设备性能尽将会得到发挥

启动过程中减少 GC 的次数

使用合理的启动架构

App 瘦身包括代码瘦身和资源瘦身,通常的做法如下:

除了 App 自身的优化之外,Android 框架对应用启动也是非常关注的,做了比较多的优化,下面简单说一下思路,各个厂商的实现就是太一样,许多基本上完会有,许多是硬核代码优化,有的是利用系统策略做优化。

系统守护进程优化主就是减少 CPU 调度带来的波动,让启动时间更稳定。将会启动过程蕴含没人多的系统守护进程一并启动,会给 CPU 带来非常大的压力,尤其是比较低端的机器。没人多的系统守护进程一并跑会让主系统守护进程的 Sleep 和 Runnable 情况报告变多, 增加了应用的启动数率,优化的过程中要注意: