APP启动方式 App启动方式分三种:冷启动(cold start)、热启动(hot start)、温启动(warm start) ▲ 冷启动 系统不存在App进程(APP首次启动或APP被完全杀死) 时启动APP此时,APP的启动将经历两个阶段: 第一阶段 1.加载并启动app;2.app启动后,第一时间为app显示一个空白的window;3.创建app进程 第二阶段 系统一旦创建了app 进程,app进程就要负责做以下的任务: 1.创建app对象;2.启动主进程ActivityThread;3.创建MainActivity;4.渲染视图;5.执行onLayout;6.执行onDraw7 ▲ 温启动 温启动包含了冷启动的一些操作,由于app进程依然在,温启动只执行冷启动的第二阶段,这代表着它比热启动有更多的开销。 温启动有很多场景,例如: 用户按连续按返回退出了app,然后重新启动app; 由于系统收回了app的内存,然后重新启动app App启动优化 app启动优化的方向是冷启动。
Android 优化目录 ---- App 启动方式 冷启动 App 没有启动过或 App 进程被杀,系统中不存在该 App 进程,此时启动即为冷启动。 需要创建 App 进程,加载相关资源,启动 Main Thread,初始化首屏 Activity 等。 在这个过程中,屏幕会显示一个空白的窗口(颜色基于主题),直至首屏 Activity 完全启动。 热启动 热启动意味着 App 进程只是处于后台,系统只是将其从后台带到前台展示给用户。 温启动 介于冷启动和热启动之间,一般来说在以下两种情况下发生: 用户返回退出了 App,然后又启动。进程可能还在运行,但是 activity 需要重建。 优化 布局优化 逻辑优化 必要且耗时的逻辑,考虑单独开线程执行 必要不耗时,按优先级高低依次执行 非必要的延迟初始化,等用到再初始化 针对冷启动的欺骗效果 使用 placeholder UI
启动优化 启动时间:从用户点击app图标开始到 AppDelegate 的didFinishLaunching 冷启动: 内存中不包含app相关数据的启动,一般我们可以通过重启手机来实现冷启动 热启动 : 是指杀掉app进程后,数据仍然存在时的启动 启动优化 -> T1 + T2 需要启动优化的部分 T1: pre-main阶段, 即main函数之前, 操作系统加载APP可执行文件到内存,执行一系列加载 : 尽量少用外部动态库,苹果官方建议自定义的动态库最好不要超过6个,如果超过6个,需要合并动态库 OC类越多越耗时 将不必须在+load方法中做的事情延迟到+initialize中,尽量不要用C++虚函数 ,能延迟的延迟,能放后台初始化的放后台,尽量不要占用主线程的启动时间 优化代码逻辑,去除非必须的代码逻辑,减少每个流程的消耗时间 启动阶段能使用多线程来初始化的,就使用多线程 尽量使用纯代码来进行UI框架的搭建 因此,我们的优化思路就是:将所有启动时刻需要调用的方法,排列在一起,即放在一个页中,这样就从多个Page Fault变成了一个Page Fault。
之前曾在iOS 优化-瘦身文章中提到过 iOS 优化将会是一个专题,今天就带来 iOS 优化系列的第二篇,主要介绍一下启动优化,即如何减少应用的启动时间。 App 启动过程 在优化之前,我们需要对 App 的完整启动过程有个了解,这样我们才能知道启动耗时分布的阶段、哪一个阶段可以被优化以及优化哪一个阶段 ROI 最高。 XCTest 在 UITest 内 Xcode 自动帮我们生成好了用于测试 App 启动的测试用例: XCTest 此测试会启动你的应用 6 次,并且仅使用最后 5 个度量值。 pre-main 阶段优化 库的优化 动态库转静态库; 减少动态库的个数,可以采用合并手段,将多个动态库合并成一个,官方建议动态库数量小于 6 个; 动态库懒加载; 这里的动态库不是指系统动态库,而是我们自己新建的动态库 参考资料 reducing-your-app-s-launch-time[6] 58 同城 App 性能治理实践-iOS 启动时间优化 iOS 优化篇 - 启动优化之 Clang 插桩实现二进制重排[7
首页显示后无法操作 原因:同上 启动优化 方法和卡顿优化基本相同,只是启动太过重要,需要更加精打细算; 优化工具 Traceview 性能损耗太大,得出的结果并不真实; Nanoscope 非常真实,不过暂时只支持 Nexus 6P 和 x86 模拟器,无法针对中低端机做测试; Simpleperf 的火焰图并不适合做启动流程分析; systrace 可以很方便地追踪关键系统调用的耗时情况,但是不支持应用程序代码的耗时分析 IO优化 负载过高时,IO性能下降的会比较快,特别是对低端机; 启动过程不建议出现网络IO 磁盘IO要清楚启动过程读取了什么文件,多少字节,buffer大小,耗时多少,在什么线程等 重度用户是启动优化一定要覆盖的群体 具体实现参考项目MultiDexTest 6. 预加载优化 1. 类预加载: 在Application中提前异步加载初始化耗时较长的类 2. 对于启动优化要警惕 KPI 化,要解决的不是一个数字,而是用户真正的体验问题。
文章目录 一、 界面启动时间 二、 启动优化项目 三、 方法追踪 一、 界面启动时间 ---- 在 【Android 性能优化】应用启动优化 ( 启动白屏问题 | 应用启动时间测量 | 冷启动 | 热启动 相加等于 TotalTime 的时长 ; 二、 启动优化项目 ---- 在 Launcher 应用点击图标后 , 启动应用 , 系统为应用开启进程 , 分配内存的步骤是无法干预的 , 开发者能做启动优化的地方只有两个位置 , 一个是 Application 的 onCreate 方法 , 另一个是 Activity 的 onCreate 方法 ; 针对上述的启动时间 , 可优化的时间是 TotalTime , 和 ThisTime 首界面布局优化 : 一般在 Activity 界面中 , 需要加载 xml 布局文件 , 显示布局文件中的画面 , 布局文件层级不能太多 ; 三、 方法追踪 如果要优化性能 , 首先要知道当前性能是多少 , 使用什么手段 , 优化到什么程度 ; 这里就需要统计当前的应用性能 , 如应用启动每个阶段的耗时 ; 使用 Debug.startMethodTracing() 追踪分析方法执行情况 ; // 将追踪信息存放到该文件中
前言 之前有读者说到关于Android性能优化,性能优化包括很多方面,比如: 启动优化、布局优化、内存优化、卡顿优化、网络优化、数据库优化、内存泄漏优化、包体积优化等等。 后面我们会依次聊聊,今天就从启动优化聊起 冷启动、温启动、热启动 首先了解下启动的这三个概念,也是面试常被问到的: 冷启动。 优化点 三种启动方式中,冷启动经历的时间最长,也是走完了最完整的启动流程,所以我们再次分析下冷启动的启动流程,看看有哪些可以优化的点: Launcher startActivity AMS startActivity 6)Webview启动优化 如果我们的主页涉及到Webview,那我们还要处理WebView的优化。 Multidex预加载优化。5.0以下多dex情况。 Webview启动优化。预创建,缓存池,静态资源。 避免布局嵌套。多层嵌套。
前言 taptap-developer是一个spring boot框架驱动的纯Grpc服务,所以,只用了四步,移除了web和spring cloud相关的模块后,启动速度就稳稳的保持在了6s内。 除了启动速度提升外,在服务待机状态下,内存锐减了50%左右,从500M左右的内存占用,缩减到了250M不到。 spring容器启动时,会扫描加载factories的信息。 ,默认是随容器启动就开始初始化的, 优化:这里可以根据业务特点,选择延迟加载,参考配置spring.data.jpa.repositories.bootstrap-mode=lazy Spring Data : 系统资源的变化 优化前的 优化后的 最后,基于资源监控图,从三个维度总结下,优化后的资源占用情况: 资源名称 优化前 优化后 内存 500M左右 250M左右 总线程数 107 78 装载类 12922
bootchart 2.2.5 gpio +示波器. 2.2.6 grabserial. 2.3 优化方法 2.3.1 boot0启动优化 2.3.1.1 非安全启动. 2.3.1.2 安全启动 2.3.2 . 3 Tina启动速度优化 3.1 开启Tina启动速度优化. 3.2 实验结果 4 参考资料 1 概述 编写目的: 介绍TinaLinux下启动速度优化使用方法。 2 启动速度优化简介 启动速度是嵌入式产品一个重要的性能指标,更快的启动速度会让客户有更好的使用体验,在某 些方面还会节省能耗,因为可以直接关机而不需要休眠。 启动速度优化可提升产品的竞争力。 2.3.4 rootfs启动优化 rootfs启动优化主要是优化rootfs的挂载到init进程执行。 2.3.4.1 initramfs initramfs是一个内存文件系统,会占用较多DRAM。 注:通过该宏预计可达到70%左右的优化效果,如还需优化,可参考第二章的内容。 3.1 开启Tina启动速度优化.
一.Sharding-JDBC 启动优化 问题分析 最近在本地调试的时候发现,项目本地启动比较慢,对启动日志进行分析,Sharding-JDBC 在加载元数据的过程中中耗时 116 秒 ,占用了项目启动时间的一半 MAX_CONNECTIONS_SIZE_PER_QUERY("max.connections.size.per.query", String.valueOf(1), int.class) //...... } 那是不是把这个配置扩展一下就可以提高启动速度了 从这里来看启动问题解决了,同时也产生了疑问,为什么 max.connections.size.per.query 默认值设置为 1。 updateByID(1); updateByKey(1); } 所以最终得出结论目前状态下,测试环境、预发环境可对max.connections.size.per.query 进行配置,提高启动速度 总结 在分析启动问题的过程中对 Sharding-JDBC 查询过程进行了简单的了解,规避了线上可能引发的问题,同时也提醒了自己在改动一些配置时需要对配置所涉及的影响面进行充分评估后再进行改动。
,进行获取启动完成时间 Systrace 轻量级,开销小 直观反映CPU利用率 cpu time与 wall time - cpu time:代码消耗CPU时间(重点指标,也是优化方向) - wall 可见冷启动的必要条件是该APP进程不存在,这就意味着系统需要创建进程,APP需要初始化。在这三种启动方式中,冷启动耗时最长,对于冷启动的优化也是最具挑战的。因此本文重点谈论的是对冷启动相关的优化。 在冷启动时,应用程序从头开始。在其他状态下,系统需要将正在运行的应用程序从后台运行到前台。我们建议您始终根据冷启动的假设进行优化。这样做也可以改善热启动和温启动的性能。 启动优化 透明主题优化 为了解决启动窗口白屏问题,许多开发者使用透明主题来解决这个问题,但是治标不治本。 虽然解决了上面这个问题,但是仍然有些不足。 <! ,优化用户体验。
我们可以添加一个启动页面,这个启动页在显示后先处理之前App中的逻辑,处理完后再加载原来的第一个页面,比如是登录页。 "Center" FontSize="26" Foreground="#666666" Text="课堂启动中 设置欢迎页为启动页 <Application x:Class="SchoolClient.MyApp" xmlns="http://schemas.microsoft.com/winfx
什么是启动? 启动类型 启动三种类型:冷启动 热启动 重启 启动阶段 1.1 System Inteface Dyld3 1.2 System Inteface libSystem Init 2. Initial Frame Render 6. Extend 2. 如何正确测量? 1. XCTest 2. Use Instruments 1. Minimize 2. Optimize 二进制重排 将启动时需要调用的函数放到一起 ( 比如 前10页中 ) 以尽可能减少 page fault , 达到优化目的 . 而这个做法就叫做 : 二进制重排 . 具体操作: 如何检测 page fault : 首先我们要想看到优化效果 , 就应该知道如何查看 page fault , 以此来帮助我们查看优化前以及优化后的效果 .
今天来聊聊启动优化。 启动分为两种类型,一个是冷启动,一个是热启动: 冷启动:指App被后台杀死后,在killed状态打开App。 热启动:指App没有被后台杀死,仍然在后台运行,此时再次去打开App。 一般而言,我们讲启动优化指的都是冷启动的优化。 启动优化,优化的是启动的时间,所以说,首先要知道如何去获取启动的时间。 然后,对于开发者自己导入的动态库(framework格式的),它需要的耗时是比较多的,苹果给出的建议是不要超过6个。 我讨论了main函数之前的启动时间的测量以及优化方案,接下来就来讨论下main函数以及main函数之后的启动时间的测量以及优化方案。 好,到这里为止,我就将启动优化常规的一些内容都给说完了。接下来咱就来聊聊一个非常规的黑科技——二进制重排,看一看如何在项目中去使用二进制重排来进行pre-main阶段的启动优化。
骨架屏优化,适用于当前页面加载内容多,加载耗时的情况,为了优化体验,先显示页面骨架的方式 vue优化之骨架屏 3.端窗体启动优化 在主窗体构造函数里加载网页和注册js对象 窗体show之后,再hide
设定虚拟机堆使用率为0.8,当实际的使用率偏离设定的比率时,虚拟机在垃圾回收的时候将调整堆的大小,使实际使用率接近设定的百分比 6、装载库libandroid_servers.so。 mSystemServiceManager.startService(UiModeManagerService.class); 591 592 try { // 进行dex优化 JobSchedule 后台延Dex优化 981 BackgroundDexOptService.schedule(context, 0); 982 TelephonyRegistry.systemRunning() MediaRouterService.systemRunning() MmsServiceBroker .systemRunning() 6 6、服务类别 system_server进程,从源码角度划分为引导服务、核心服务、普通服务3类(也就其他服务,因为源码上为other)。
所以咱们这篇文章有两个目的: 启动速度提升(用户眼中的大神就是你) 优化代码逻辑和规范(别让自己成为继任者中的XX) 今天咱们就来了解一下应用启动内部机制和启动速度优化。 看到这里我觉得好多人已经知道怎么去优化启动速度了。 性能迟缓分析 看到上面的实验其实三种启动情况,受我们影响的方面在于 application 和 activity 。 通常,有机会优化这项工作以实现性能改进。 产生的原因包括: 加载大型或复杂的布局。 加载大量数据后绘制屏幕。 加载和解码Bitmap。 VectorDrawable 对象。 布局优化 通过减少冗余或嵌套布局来扁平化视图层次结构。 布局复用(<include/>和 <merge/>) 使用ViewStub,不加载在启动期间不需要可见的 UI 部分。 代码优化 不必要的初始化还是磁盘I/O,延迟初始化 资源初始化分类,以便应用程序可以在不同的线程上延迟执行。 动态加载资源和Bitmap 关于这两块的优化后续会有单独的文章去写。
系统动态库存在于共享缓存,但自定义动态库没有这个待遇,所以苹果官方建议不要超过6个自定义动态库,超过可进行多个动态库合并,以此来优化动态库加载的耗时 动态库的合并,需要源码才能进行。 应用启动时,系统会生成类和分类的两张表,OC类和分类的注册,会插入到这两张表中,所以会造成一定的时间消耗 这部分时间很难优化,除非减少项目中类和分类的定义 减少类和所属分类load方法的使用,让类以懒加载的方式加载 页表存储在内存中,有了页表,就可以将程序和物理内存完全阻隔开 一个进程中,只有部分功能是活跃的,所以只需要将进程中活跃的部分放入物理内存,避免物理内存的浪费 现代的操作系统进行了更合理的优化,例如iOS ,这个启动方式就是冷启动 热启动:当启动应用时,后台已有该应用的进程(例:按home键回到桌面,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用 如果是微信、抖音等大型项目,不进行优化可达到6000次以上,造成不小的时间消耗 4.2 二进制重排的原理 搭建测试项目,查看代码顺序 打开项目,在Build Settings→Write Link Map
首页显示后无法操作 原因:同上 启动优化 方法和卡顿优化基本相同,只是启动太过重要,需要更加精打细算; 优化工具 Traceview 性能损耗太大,得出的结果并不真实; Nanoscope 非常真实,不过暂时只支持 Nexus 6P 和 x86 模拟器,无法针对中低端机做测试; Simpleperf 的火焰图并不适合做启动流程分析; systrace 可以很方便地追踪关键系统调用的耗时情况,但是不支持应用程序代码的耗时分析 IO优化 负载过高时,IO性能下降的会比较快,特别是对低端机; 启动过程不建议出现网络IO 磁盘IO要清楚启动过程读取了什么文件,多少字节,buffer大小,耗时多少,在什么线程等 重度用户是启动优化一定要覆盖的群体 具体实现参考项目MultiDexTest 6. 预加载优化 1. 类预加载: 在Application中提前异步加载初始化耗时较长的类 2. 对于启动优化要警惕 KPI 化,要解决的不是一个数字,而是用户真正的体验问题。
APP启动速度非常重要,APP启动速度慢,可能会造成用户体验不良好,尤其是在最近用Android studio之后,如果长时间不打开app,启动速度就会特别的慢,下面我们一起探讨一下影响app启动速度的原因 WaitTime为我们所关注的启动时间 那么7551算不算启动时间长呢? 这是一个很长时间没有启动的app,当它第一次启动的时候就有很长的启动时间,下面来说怎么来减少吧。 减少应用启动耗时 app的启动流程,简单的说,主要包括两部分: Application 启动界面的onCreate方法 因此最简单的方法就是尽量减少这两个方法中的耗时操作。 上面的方法从代码上解决了启动速度,但是用户启动的时候还是感觉慢,怎么办呢?直接上代码: <!