Android 分析实现性能优化之启动速度优化

目录
  • 启动方式
  • 冷启动(启动优化目标)
  • 热启动
  • 温启动
  • 启动流程中可优化的环节
  • 检测工具
    • 启动时间检测
    • Logcat Displayed
    • adb 命令统计
  • CPU profile
    • API level >= 26
    • API level < 26
  • StrictMode 严苛模式
  • 优化点
  • 黑白屏问题

本文主要探讨以下几个问题:

  • 启动方式
  • 启动流程中可优化的环节
  • 检测工具
  • 优化点
  • 黑白屏问题

启动方式

应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动与热启动

冷启动(启动优化目标)

冷启动是指应用从头开始启动:系统进程在冷启动后才创建应用进程。发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动。

热启动

在热启动中,系统的所有工作就是将 Activity 带到前台。只要应用的所有 Activity 仍驻留在内存中,应用就不必重复执行对象初始化、布局加载和绘制。

温启动

温启动包含了在冷启动期间发生的部分操作;同时,它的开销要比热启动高。有许多潜在状态可视为温启动。例如:

  • 用户在退出应用后又重新启动应用。进程可能未被销毁,继续运行,但应用需要执行 onCreate() 从头开始重新创建 Activity。
  • 系统将应用从内存中释放,然后用户又重新启动它。进程和 Activity 需要重启,但传递到 onCreate() 的已保存的实例savedInstanceState对于完成此任务有一定助益。

启动流程中可优化的环节

启动流程中开发者可优化的环节不多,咱们可以从APP启动流程中寻找下

APP启动过程如下:

  • 点击桌面App图标,Launcher进程采用Binder IPC向system_server进程发起startActivity请求;
  • system_server进程接收到请求后,向zygote进程发送创建进程的请求;
  • Zygote进程fork出新的子进程,即App进程;
  • App进程,通过Binder IPC向sytem_server进程发起attachApplication请求;
  • system_server进程在收到请求后,进行一系列准备工作后,再通过binder IPC向App进程发送scheduleLaunchActivity请求;
  • App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送LAUNCH_ACTIVITY消息;
  • 主线程在收到Message后,通过反射机制创建目标Activity,并回调Activity.onCreate()等方法。
  • 到此,App便正式启动,开始进入Activity生命周期,执行完onCreate/onStart/onResume方法,UI渲染结束后便可以看到App的主界面。

所以,我们能优化的阶段只有 Application.onCreate() —> Activity.onWindowFocusChanged()

检测工具

启动时间检测

启动的时间怎样算是合适的?怎样一个时间范围内用户是感觉流畅的?Android Vitals在您的应用出现以下情况时将其启动时间视为过长:

  • 冷启动用了 5 秒或更长时间
  • 温启动用了 2 秒或更长时间
  • 热启动用了 1.5 秒或更长时间

那APP启动用了多长时间?用什么区检测?

Logcat Displayed

在 Android 4.4(API 级别 19)及更高版本中,logcat 包含一个输出行,其中包含名为 Displayed 的值。此值代表从启动进程到在屏幕上完成对应 Activity 的绘制所用的时间。

adb 命令统计

adb shell am start -S -W [packageName]/[activityName]

C:\Users\****>adb shell
generic_x86_arm:/ $ am start -S -W com.miss.misslink/.MainActivity
Stopping: com.miss.misslink
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.miss.misslink/.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.miss.misslink/.MainActivity
TotalTime: 941
WaitTime: 961
Complete

WaitTime:包括前一个应用Activity pause的时间和新应用启动的时间;
ThisTime:表示一连串启动Activity的最后一个Activity的启动耗时;
TotalTime:表示新应用启动的耗时,包括新进程的启动和Activity的启动,但不包括前一个应用Activity pause的耗时。

我们一般只用 TotalTime,可以很清楚的知道APP的启动时间。那我们如何判断是哪些方法耗时太多导致APP启动时间过长呢?

CPU profile

API level >= 26

要在应用启动过程记录CPU活动,需要做以下操作

1.依次选择 Run > Edit Configurations

2.勾选 Trace Java Methods(跟踪 Java 方法:在运行时检测应用,以在每个方法调用开始和结束时记录一个时间戳。系统会收集并比较这些时间戳,以生成方法跟踪数据,包括时间信息和 CPU 使用率。)

3. 依次选择 Run > Profile,将您的应用部署到搭载 Android 8.0(API 级别 26)或更高版本的设备上

主要分析的地方有3个: Flame Chart、 Top Down 、bottom up。

API level < 26

对于API低于26的,我们可以调用 Debug API,调用起点 Application构造函数

public class MyApplication extends Application {

    public MyApplication() {
        //  没有指定绝对路径,就是相对路径,相对 sdcard
        Debug.startMethodTracing("miss");
    }

}

调用终点 Activity.onWindowFocusChanged()

    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
        Debug.stopMethodTracing();
    }

如此一来会在 sdcard 路径下生成 miss 文件,双击打开即可

StrictMode 严苛模式

StrictMode是一个开发人员工具,它可以检测出我们可能无意中做的事情,并将它们提请我们注意,以便我们能够修复它们。StrictMode最常用于捕获应用程序主线程上的意外磁盘或网络访问。帮助我们让磁盘和网络操作远离主线程,可以使应用程序更加平滑、响应更快

	//	Application onCreate 中使用
    @Override
    public void onCreate() {
        if (BuildConfig.DEBUG) {
            //线程检测策略
            StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()   //读、写操作
                    .detectDiskWrites()
                    .detectNetwork()   // or .detectAll() for all detectable problems
                    .penaltyLog()
                    .penaltyDeath()
                    .build());
            StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects()   //Sqlite对象泄露
                    .detectLeakedClosableObjects()  //未关闭的Closable对象泄露
                    .penaltyLog()  //违规打印日志
                    .penaltyDeath() //违规崩溃
                    .build());
        }

优化点

  • 合理的使用异步初始化、延迟初始化、懒加载机制。
  • 启动过程避免耗时操作,如数据库 I/O操作不要放在主线程执行。
  • 类加载优化:提前异步执行类加载。
  • 合理使用IdleHandler进行延迟初始化。
  • 简化布局
  • 第三方库有些是有优化插件的,比如ARouter

黑白屏问题

当系统加载并启动 App 时,需要耗费相应的时间,这样会造成用户会感觉到当点击 App 图标时会有 “延迟” 现象,为了解决这一问题,Google 的做法是在 App 创建的过程中,先展示一个空白页面,让用户体会到点击图标之后立马就有响应。
如果你的application或activity启动的过程太慢,导致系统的BackgroundWindow没有及时被替换,就会出现启动时白屏或黑屏的情况(取决于Theme主题是Dark还是Light)。消除启动时的黑/白屏问题,大部分App都采用自己在Theme中设置背景图的方式来解决。

<style name="AppTheme.Launcher">
	<item name="android:windowBackground">@drawable/bg</item>
</style>
<activity
	android:name=".activity.SplashActivity"
	android:screenOrientation="portrait"
	android:theme="@style/AppTheme.Launcher">
	<intent-filter>
		<action android:name="android.intent.action.MAIN" />
		<category android:name="android.intent.category.LAUNCHER" />
	</intent-filter>
</activity>

然后在Activity的onCreate方法,把Activity设置回原来的主题

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        setTheme(R.style.AppTheme);
        super.onCreate(savedInstanceState);
    }

这么做,只是提高启动的用户体验。并不能做到真正的加快启动速度。

总结:启动速度优化也会涉及到布局优化与卡顿优化,包括内存抖动等问题。优化是一条持续的道路,很多时候我们会发现通过各种检测手段花费了大量的精力去对代码进行修改得到的优化效果可能并不理想。因为优化就是一点一滴积累下来的,我们平时在编码的过程中就需要多注意自己的代码性能。

到此这篇关于Android 分析实现性能优化之启动速度优化的文章就介绍到这了,更多相关Android 性能优化内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Android图片性能优化详解

    1. 图片的格式 目前移动端Android平台原生支持的图片格式主要有:JPEG.PNG.GIF.BMP.和WebP(自从Android 4.0开始支持),但是在Android应用开发中能够使用的编解码格式只有三种:JPEG.PNG.WebP,图片格式可以通过查看Bitmap类的CompressFormat枚举值来确定. public static enum CompressFormat { JPEG. PNG. WebP; private CompressFormat() { } } 如果要在

  • 简单了解Android性能优化方向及相关工具

    开发一款性能优良的应用是每一个Android开发者都必须经历的挑战.在移动端资源有限的前提下,提高应用的性能显得尤为重要.常见的提高APP性能的优化方向有三个:布局和渲染优化.内存优化.功耗优化. 一:布局优化 所谓布局优化,就是尽量减少布局的嵌套层级,减少无用的布局.主要的优化方法有: (1)优先使用RelativeLayout来减少布局嵌套层数,否则尽量使用LinearLayout.这是因为RelativeLayout能够在不嵌套的情况下完成复杂的布局,而当布局比较简单时优先使用Linear

  • 浅谈android性能优化之启动过程(冷启动和热启动)

    本文介绍了浅谈android性能优化之启动过程(冷启动和热启动) ,分享给大家,具体如下: 一.应用的启动方式 通常来说,启动方式分为两种:冷启动和热启动. 1.冷启动:当启动应用时,后台没有该应用的进程,这时系统会重新创建一个新的进程分配给该应用,这个启动方式就是冷启动. 2.热启动:当启动应用时,后台已有该应用的进程(例:按back键.home键,应用虽然会退出,但是该应用的进程是依然会保留在后台,可进入任务列表查看),所以在已有进程的情况下,这种启动会从已有的进程中来启动应用,这个方式叫热

  • Android APP性能优化分析

    本文通过Android APP性能优化的四个方面做了详细分析,并对原理和重点做了详细解释,以下是全部内容: 说到 Android 系统手机,大部分人的印象是用了一段时间就变得有点卡顿,有些程序在运行期间莫名其妙的出现崩溃,打开系统文件夹一看,发现多了很多文件,然后用手机管家 APP 不断地进行清理优化 ,才感觉运行速度稍微提高了点,就算手机在各种性能跑分软件面前分数遥遥领先,还是感觉无论有多大的内存空间都远远不够用.相信每个使用 Android 系统的用户都有过以上类似经历,确实,Android

  • 详解Android性能优化之启动优化

    1.为什么要进行启动优化 网上流行一种说法,就是8秒定律,意思是说,如果用户在打开一个页面,在8秒的时间内还没有打开,那么用户大概的会放弃掉,意味着一个用户的流失.从这里就可以看出,启动优化的重要性了. 2.启动的分类 2.1 冷启动 先来看看冷启动的流程图 从图中可以看出,APP启动的过程是:ActivityManagerProxy 通过IPC来调用AMS(ActivityManagerService),AMS通过IPC启动一个APP进程,ApplicationThread通过反射来创建App

  • 浅谈Android性能优化之内存优化

    1.Android内存管理机制 1.1 Java内存分配模型 先上一张JVM将内存划分区域的图 程序计数器:存储当前线程执行目标方法执行到第几行. 栈内存:Java栈中存放的是一个个栈帧,每个栈帧对应一个被调用的方法.栈帧包括局部标量表, 操作数栈. 本地方法栈:本地方法栈主要是为执行本地方法服务的.而Java栈是为执行Java方法服务的. 方法区:该区域被线程共享.主要存储每个类的信息(类名,方法信息,字段信息等).静态变量,常量,以及编译器编译后的代码等. 堆:Java中的堆是被线程共享的,

  • Android 分析实现性能优化之启动速度优化

    目录 启动方式 冷启动(启动优化目标) 热启动 温启动 启动流程中可优化的环节 检测工具 启动时间检测 Logcat Displayed adb 命令统计 CPU profile API level >= 26 API level < 26 StrictMode 严苛模式 优化点 黑白屏问题 本文主要探讨以下几个问题: 启动方式 启动流程中可优化的环节 检测工具 优化点 黑白屏问题 启动方式 应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动.温启动与热启动 冷启动(启动优化

  • Android 进阶实现性能优化之OOM与Leakcanary详解原理

    目录 Android内存泄漏常见场景以及解决方案 资源性对象未关闭 注册对象未注销 类的静态变量持有大数据 单例造成的内存泄漏 非静态内部类的静态实例 Handler临时性内存泄漏 容器中的对象没清理造成的内存泄漏 WebView 使用ListView时造成的内存泄漏 Leakcanary leakcanary 导入 leakcanary 是如何安装的 leakcanary 如何监听Activity.Fragment销毁 RefWatcher 核心原理 流程图 本文主要探讨以下几个问题: And

  • Paddle模型性能分析工具Profiler定位瓶颈点优化程序详解

    目录 Paddle模型性能分析Profiler 1.使用Profiler工具调试程序性能 1.1 使用cifar10数据集卷积神经网络进行图像分类 1.1.1 获取性能调试前模型正常运行的ips 1.1.2. 开启性能分析器,定位性能瓶颈点 1.1.3. 优化程序,检查优化效果 1.1.5 结果展示 2 统计表单展示 Paddle模型性能分析Profiler 定位性能瓶颈点优化程序提升性能 Paddle Profiler是飞桨框架自带的低开销性能分析器,可以对模型运行过程的性能数据进行收集.统计

  • Android中方法数超限问题与启动优化详解

    前言 最近写了篇有关Eclipse工程转Android Studio工程的文章,而导致公司项目需要转 AS 的直接原因,就是今天要写的主题–方法数超限,相信大多数 Android 项目的都会碰到这个问题. 传统的 Eclipse 解决方法数超限的办法,就是在 project.properties 中加上 dex.force.jumbo=true ,然后清理工程重新编译.但是,当方法数越来越多,这个方法也会解决不了问题,这个时候,就要用到 Google 官方给出的方案 MultiDex了. Mul

  • 阿里数据iOS端启动速度优化心得

    背景 7月26号我们阿里数据iOS端发布了4.4.0版本,这次版本主要是优化了性能,其中main()阶段的启动耗时优化成果比较明显,从之前的0.5-0.7秒,降低为目前的0.1-0.2秒(main()第一行代码到didFinishLaunchingWithOptions最后一行代码的耗时),用户体验提升明显.在这里梳理一下优化的一些经验,欢迎大家一起交流. 应用启动流程 iOS应用的启动可分为pre-main阶段和main()阶段,其中系统做的事情依次是: 1. pre-main阶段 1.1.

  • mysql查询时offset过大影响性能的原因和优化详解

    前言 mysql查询使用select命令,配合limit,offset参数可以读取指定范围的记录.本文将介绍mysql查询时,offset过大影响性能的原因及优化方法. 准备测试数据表及数据 1.创建表 CREATE TABLE `member` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL COMMENT '姓名', `gender` tinyint(3) unsigned NOT NU

随机推荐