Android App 启动优化全记录

  • 时间:
  • 浏览:2
  • 来源:5分排列5官方_极速5分排列3

下面图中都还可以 都看低内存的时候,启动应用主守护线程池池有较多的 IO 等待图片(UI Thread 你这些 栏,橘红色代表 IO 等待图片 )

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

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

具体的业务会有具体的优化场景,亲戚亲戚朋友都还可以 参考这篇文章中的优化流程和优化项(https://www.jianshu.com/p/f5514b1a826c)

要是按需进行加载优化

StartingWindow 会在用户点击 App 后立即创建并显示(前提是 App 这么禁止 StartingWindow),在 AppWindow 创建好时候,StartingWindow 消失,AppWindow 显示

启动优化整个流程的梳理,流程的梳理,亲戚亲戚朋友这里引入了三个小 有向无环图的概念,亲戚亲戚朋友会把整个的概念梳理成有向无环图的底部形态,然都是去挨个加载。右边的累积,都还可以 都看亲戚亲戚朋友其之太久有启动的时候,首先会去加载许多必要的启动项,必要的启动项是左边流程,会用三个小 守护线程池池的最好的法子 加载,以来有向无环图进行控制,比如说我是在非须要的时候启动加载帮我放上里面再去加载。当然在整个有向无环图的顺序加载,之太久有还是会做许多守护线程池池的判断,要判断许多项目是完整性都是须在主守护线程池池里加载,许多要在初始守护线程池池里面加载

都还可以 都看应用启动过程中,最重要的三个小 守护线程池池要是 SystemServer 和 App Process . 其职责划分如下:

启动的时候,对启动过程中的 Message 进行重新排列

启动过程中繁忙的 SystemServer

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

当然对于应用开发者来说,里面说的都太久理想化了,要是目前的手机厂商也会很暴力,应用到了后台就会出理 掉,不过这毕竟是三个小 方向,Google 也在规范应用后台行为和规范厂商出理 应用这两方面完整性都是做努力,Android 系统的生态,还是须要应用开发者和 Android 厂商一起取改善。

累积厂商会在监测到你这些 大内存 App 启动的时候,提前做内存的回收操作,三个小 在启动的时候,完整性都是了足够的内存给你这些 App 使用

当然这里说的保活,并完整性都是建议亲戚亲戚朋友用各种黑科技、相互唤醒、通知轰炸你这些 保活手段,要是提供真正的功能,能让用户之太久有你在后台是合理的、都还可以 接收的。比如在后台的时候,资源能释放的都释放掉,不须总是在后台做耗电操作,该停的服务停掉,该关的动画关掉。

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

要是启动当时人的窗口须要的时间要比直接显示系统的启动窗口所花的时间要长,这就会是是是因为用户在使用的时候,点击图标启动 App 的时候,有一定的延迟,表现在点击图标过了一段时间才进行窗口动画进入 App,亲戚亲戚朋友要尽量出理 你这些 状态

启动窗口,也叫启动页、SplashWindow、StartingWindow 等,指的是应用启动时候的预览窗口。iOS App 强制三个小 启动页,用户点击桌面 App 图标时候,系统会立即显示你这些 启动窗口,等 App 主页加载好时候再显示主页面。Android 完整性都是同类的机制 (启动窗口你这些 是 Android 系统提供的),要是也提供了三个小 接口,让应用开发者设置是是不是显示你这些 启动窗口(默认是显示),累积开发者会把你这些 系统提供的启动窗口禁掉,启动当时人的窗口。

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

Linux 底层文件系统中 VFS 上次 App 守护线程池池之间,发生一层 pagecache,pagecache 由内存中的物理 page 组成,其内容对应磁盘上的 block。Pagecache 的大小是动态变化的,都还可以 扩大,都还可以 不能在内存不足英文时缩小。Cache 缓存的存储设备被称为后备存储(backing store),三个小 page 通常富含 多个 block,那先 block 不一定是连续的

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

类重排的实现通过 ReDex 的 Interdex 调整类在 Dex 中的排列顺序。Interdex 优化不须要去分析类引用,它只须要调整 Dex 中类的顺序,把启动时须要加载的类按顺序放上主 dex 里,你这些 工作亲戚亲戚朋友完整性都还可以 在编译过程中实现,要是你这些 优化都还可以 提升启动下行速率 ,优化效果从 facebook 表态的数据来看也比较可观,性价比高。具体实现都还可以 参考 Redex 初探与 Interdex:Andorid 冷启动优化

都还可以 把具体的业务分为下面三个小维度(此处图文来自https://juejin.im/post/5c21ea325188254eaa5c45b1#heading-5)

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

之太久有对用户来说,第你这些 启动流程是最好的,只涉及到一次窗口的切换;要是累积 App 是是是是因为广告页的需求,会使用第二种流程 ;要是尽量不须使用第你这些 和第你这些 启动流程,体验非常不好

应用启动的时候,是是是是因为主守护线程池池的工作太久,也会造成主守护线程池池过于繁忙,下面十哪几个 系统调度相关的点须要注意:

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

作者:Gracker

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

本文参考了目前大累积 Android 应用启动优化的方案,将亲戚亲戚朋友的方案做三个小 汇总,是是是是因为你有这方面的需求,只须要对照这篇文章,看看当时人的方案,查漏补缺。太久有方案是要根据具体的业务去做优化的,太久有这里也这么对每你这些 方案进行完整性的介绍,要用到哪三个小 方案的时候,都还可以 具体去网上查找对应方案的具体实现最好的法子 ,这里要是做三个小 汇总

启动过程中繁忙的 cpu

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

保活,是各个应用开发者的噩梦,也是 Android 厂商关注和打击的重点。不过从启动的深度图来看,是是是是因为应用守护线程池池不被杀,这么启动自然就快了,太久有保活对应用启动下行速率 也是有极大的帮助。

累积应用启动的时候,须要大量的内存,比如现在的相机启动,这时候是是是是因为这么足够的内存,这么系统须要要通过杀掉太久有应用、释放 Cache 等操作来给你这些 App 让路,你这些 过程会使得那先 大内存的 App 在启动的时候频繁进行内存操作,是是是因为启动下行速率 减慢

使用合理的启动架构

累积场景会针对用户的使用习惯进行学习,比如在那先 时间、那先 场合、那先 交通工具打开手机,系统会预测帮我启动的 App,并在后台进行启动,三个小 你点击你这些 App 的时候,要是是是是因为是热启动了

启动过程中负载比较高,有许多系统 IO 完整性都是此时发生,这时候 IO 的性能下降会比较快,此时 App 中的 IO 操作会比平时减慢许多,尤其是在性能比较差的机器上。

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

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

累积厂家会对启动过程 App 的主守护线程池池和渲染守护线程池池做特殊对待,比如让亲戚朋友直接跑到大核上,将许多不重要的守护线程池池移到小核

启动过程中减少 GC 的次数

Android Q 加入了 PreFork 机制,会先 fork 十哪几个 空守护线程池池,当 App 启动的时候,都还可以 直接复用这十哪几个 空守护线程池池,而太久重新去 fork

各家应该完整性都是当时人的方案,关键在于怎么还可以定义启动始于的点,你这些 也是总是困扰我的三个小 地方,有的应用很好定义,有的应用则是是是是因为比较僵化 ,无法直接衡量启动下行速率 。像 adb 你这些 最好的法子 当时人玩玩都还可以 ,生产环境没啥用;录屏你这些 完整性都是性能损耗..

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

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

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

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



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

亲戚亲戚朋友都还可以 参考淘宝的全链路优化的案例:历时1年,上百万行代码!首次揭秘手淘全链路性能优化(上))

流程梳理,延后执行;实际上,你这些 步对项目启动加速最有效果。通过流程梳理发现累积流程调用时机偏失等, 同类

累积厂商也提供了资源调度的 SDK ,应用都还可以 接入那先 SDK,在须要资源的时候直接调用 SDK 获取

这里还须要引入冷启动和热启动的概念,这也是亲戚亲戚朋友总是会碰到的三个小 概念

守护线程池池优化主要是减少 CPU 调度带来的波动,让启动时间更稳定。是是是是因为启动过程富含 太久的守护线程池池一起启动,会给 CPU 带来非常大的压力,尤其是比较低端的机器。太久的守护线程池池一起跑会让主守护线程池池的 Sleep 和 Runnable 状态变多, 增加了应用的启动下行速率 ,优化的过程中要注意:

应用主界面布局优化是老生常谈了,综合起来无非要是下面两点,你这些 须要结合具体的界面布局去做优化,网上完整性都是比较多的资料都还可以 查阅

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

IdleHandler:当 Handler 空闲的时候才会被调用,是是是是因为返回 true, 则会总是执行,是是是是因为返回 false,执行完一次后就会被移除消息队列。比如,亲戚亲戚朋友都还可以 将从服务器获取推送 Token 的任务放上延迟 IdleHandler 中执行,是是是是因为把许多不重要的 View 的加载放上 IdleHandler 中执行

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

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

系统会对许多应用进行特殊出理 ,比如你这些 App 比较重要要是这么杀掉,这么有的厂商会在你这些 应用退到后台时候,进行无感重启:比如说某个应用内存超标是是是是因为持续 Crash ,后台重启都还可以 很好地出理 你这些 那先 的大问题,三个小 重启后的 App 是用户点击启动的时候要是热启动

都还可以 在 systrace 生成的文件中都看 verifyClass 过程,是是是是因为须要校验最好的法子 的每三个小 指令,太久有是三个小 比较耗时的操作。

都还可以 参考下面这篇文章 支付宝客户端架构解析:Android 客户端启动下行速率 优化之「垃圾回收」)

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