android应用启动优化

❶ 安卓手机有时开机就提示“android正在启动 正在优化第N个应用（共N个）。”

安卓手机显示正在优化的处理方法：显示正在优化通常是在手机更新完系统后第一次开机进入桌面时，此为正常现象，等待优化完成后会自动进入桌面，如遇特殊情况优化一直无法完成，多为更新故障，可以进入rec重新安装更新包，双清重启手机后再试。

❷ Android 性能优化之启动加速

当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的

windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，

应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。所以，总结一下，应用的启动流程如下：

Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。

1、冷启动：当启动应用时，后台没有该应用的进程，这腔滑晌时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。
2、热启动：当启动应用时，后台已有该应用伍锋的进程（例：按back键、在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动

1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。
2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application

黑白屏产生原因：当我们在启让清动一个应用时，系统会去检查是否已经存在这样一个进程，如果不存在，系统的服务会先检查startActivity 中的intent 的信息，然后在去创建进程，最后启动Acitivy，即冷启动。

而启动出现白黑屏的问题，就是在这段时间内产生的。系统在绘制页面加载布局之前，首先会初始化窗口（Window），而在进行这一步操作时，系统会根据我们设

置的Theme 来指定它的Theme 主题颜色，我们在Style 中的设置就决定了显示的是白屏还是黑屏。

1.Application 优化(懒加载,延时加载)

2.UI效果，背景图

3.fragment的懒加载

4.延时加载

❸ Android性能优化第（八）篇---App启动速度优化之耗时检测处理

应用的启动速度缓慢这是很多开发者都遇到的一个问题，比如启动缓慢导致的黑屏，白屏问题，大部分的答案都是做一个透明的主题，或者是做一个Splash界面，但是这并没有从根本上解决这个问题。那么如何从根本上解决这个问题或者做到一定程度的缓解？

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。

2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。

3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

执行成功后将返回三个测量到的时间：

这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。

总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。

从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。

Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量、布局、绘制显示在界面上。

因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些 不得以的任务 又必须在UI显示之前执行。所以我们要将 任务 划分优先级。

对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。

极力推荐用第二种，在窗口完成以后进行加载，这里面的run方法是在onResume之后运行的。关于这种懒加载机制，参考 Android应用启动优化:一种DelayLoad的实现和原理(上篇) ，给出了详细的解释。

通过上面我们知道一种懒加载机制，所以我们可以将Application中和首页的onCreate中的有些耗时任务，放到首页渲染完毕后加载。如何找出这些耗时任务，TraceView就派上用场了，TraceView的用法，移步我的前面的博客 Android性能优化第（六）篇---TraceView 分析图怎么看？

比如在首页的onCreate中我们进行了用户启动上报，这个进行懒加载是不是分分钟减少139毫秒呢？

在比如在Application里面用到了GSON，将String转化成json,我将这个移动到懒加载里面，是不是又减少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用户又不会一打开App就要支付，放在Application中加载干嘛？

此处我们这里举得例子是优化了139毫秒和100毫秒的，其实真正耗时的任务有的有1秒多，都被我优化完了，所以trace图中看不到了，就举个了这两个例子，还有SharedPreferences也是耗时大户，经过检测保存一个boolean变量耗时120+毫秒以上。

利用TraceView可以清楚我们每一个方法的耗时时间，极大的帮助了我们做优化工作。

五、优化思路总结
1、UI渲染优化，去除重复绘制，减少UI重复绘制时间，打开设置中的GPU过度绘制开关，各界面过度绘制不应超过2.5x；也就是打开此调试开关后，界面整体呈现浅色，特别复杂的界面，红色区域也不应该超过全屏幕的四分之一；
2、根据优先级的划分，KoMobileApplication的一些初始化工作能否将任务优先级划分成3,在首页渲染完成后进行加载，比如：PaySDKManager。
3、主线程中的所有SharedPreference能否在非UI线程中进行，SharedPreferences的apply函数需要注意，因为Commit函数会阻塞IO，这个函数虽然执行很快，但是系统会有另外一个线程来负责写操作，当apply频率高的时候，该线程就会比较占用CPU资源。类似的还有统计埋点等，在主线程埋点但异步线程提交，频率高的情况也会出现这样的问题。
4、检查BaseActivity,不恰当的操作会影响所有子Activity的启动。
5、对于首次启动的黑屏问题，对于“黑屏”是否可以设计一个.9图片替换掉，间接减少用户等待时间。
6、对于网络错误界面，友好提示界面，使用ViewStub的方式，减少UI一次性绘制的压力。
7、任务优先级为2，3的，通过下面这种方式进行懒加载的方式

8、Multidex的使用，也是拖慢启动速度的元兇，必须要做优化。后面有空专门写一篇Multidex。

相关链接：

Android应用启动优化:一种DelayLoad的实现和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

Android性能优化之加快应用启动速度http://www.open-open.com/lib/view/open1452821612355.html

手机淘宝性能优化全记录http://www.open-open.com/lib/view/open1452488209370.html

Android客户端性能优化（魅族资深工程师毫无保留奉献）http://blog.tingyun.com/web/article/detail/155#rd

Please accept mybest wishes for your happiness and success !

❹ 华为手机开机重启后显示安卓正在启动优化应用的原因是什么

华为手机出现这握亏穗种现象一般是由于andriod系统的匹配功能。目前4.4以上的系统都是这段卜样的。如果每次都是如此你可以尝试拔掉SD卡试试，看看还会不会出现这种情况，这种情况也很可能是SD卡质量不佳导致的。空拿

或者您可以去咨询华为官方售后中心：网页链接

❺ 华为手机开机重启后老是显示安卓正在启动优化应用是怎么回事

建议进入Recovery模式执行双清wipe操作。Recovery模式指的是一种可以对安卓机内部的数据或系统进行修改的模式（类吵罩搏似于windowsPE或DOS）。闷运在这个模式下可以刷入新的安卓系统，或者对已有的系统进行备份或升级，也可以在此恢复出厂设置。进入recovery的方法：1、将手机完全关机后，按住音量键下+电源键，进入bootloader界面（部分手机可能不同，多数是音量上或下+电源键）；2、按音量键将光标移动到recovery那一行；3、按电源键，之后手机会自动重启进入recovery模式。其中音量键为光标选择键，可以用来移动光标，电源键则是确认键。双wipe步骤如下：1.在recovery模式下,用音量下键选择wipedata/factoryreset这项。2.按HOME键执行wipedata/factoryreset命令后再用音量下键选择Yes--deletealluserdata并按HOME键执行命令。3.执行Yes--deletealluserdata命令后，表示开始执行。4.按音量下键选择wipecachepartition命令并按HOME键执行。5.执行wipecachepartition命令后，音量下键选择Yes--WipeCache并按HOME键执行命令。6.执行Yes--WipeCache命令后升祥，表示wipecachepartition也执行成功了。7.wipedata/factoryreset和wipecachepartition执行成功后选择rebootsystemnow重启系统即可。

❻ 如何优化 android 系统应用的启动速度

一、应用的启动

启动方式

通常来说，在安卓中应用的启动方式分为两种：冷启动和热启动。

• 1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。

• 2、热启动：当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

特点

1、冷启动：冷启动因为系统会重新创建一个新的进程分配给它，所以会先创建和初始化Application类，再创建和初始化MainActivity类（包括一系列的测量、布局、绘制），最后显示在界面上。

2、热启动：热启动因为会从已有的进程中来启动，所以热启动就不会走Application这步了，而是直接走MainActivity（包括一系列的测量、布局、绘制），所以热启动的过程只需要创建和初始化一个MainActivity就行了，而不必创建和初始化Application，因为一个应用从新进程的创建到进程的销毁，Application只会初始化一次。

上面说的启动是点击app的启动图标来启动的，而另外一种方式是进入最近使用的列表界面来启动应用，这种不应该叫启动，应该叫恢复。

二、应用启动的流程

在安卓系统上，应用在没有进程的情况下，应用的启动都是这样一个流程：当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类、创建MainActivity类、加载主题样式Theme中的windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了后最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，应用的第一次启动才算完成，这时候我们看到的界面也就是所说的第一帧。

所以，总结一下，应用的启动流程如下：

Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量布局绘制显示在界面上。

三、测量应用启动的时间

在上面这个启动流程中，任何一个地方有耗时操作都会拖慢我们应用的启动速度，而应用启动时间是用毫秒度量的，对于毫秒级别的快慢度量我们还是需要去精确的测量到到底应用启动花了多少时间，而根据这个时间来做衡量。

什么才是应用的启动时间

从点击应用的启动图标开始创建出一个新的进程直到我们看到了界面的第一帧，这段时间就是应用的启动时间。

我们要测量的也就是这段时间，测量这段时间可以通过adb shell命令的方式进行测量，这种方法测量的最为精确，命令为：

• adb shell am start -W [packageName]/[packageName.MainActivity]



执行成功后将返回三个测量到的时间：
1、ThisTime:一般和TotalTime时间一样，除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity，这样将比TotalTime小。
2、TotalTime:应用的启动时间，包括创建进程+Application初始化+Activity初始化到界面显示。
3、WaitTime:一般比TotalTime大点，包括系统影响的耗时。

下面是测量一个应用冷启动和热启动的时间：
冷启动：


热启动：




以上就是本文的全部内容，希望对大家学习Android软件编程有所帮助。

❼ Android开机速度优化初探

Android的开机速度，基本上没人说快的，通常移植完系统后，马上要看的事情就是优化开机时间，以下是简单回忆以下以前做优化的那些事。

优化开机时间，通常做的首先是那有有没有BUG，明显不合理的先解决，由于开发阶段稳定性腊扰带问题，一些地方可能延时加的大，或者频率设的低，先记下来，后面定期还会再看。这些先不看的话，一般拿到机器，我们统计开机时间，主要看如下几个时间段分布：

开机按键时间、亮屏时间(基本固定，除非弄错了，基本检查一遍确定)

uboot启动时间

内核启动后到bootanim退出时间

可以通过添加打印mole init的李汪log，来check每个mole初始化时的时间。从而找到花费时间比较多的mole:

--- a/init/main.c

+++ b/init/main.c

@@-785,7+785,7@@int__init_or_mole

do_one_initcall(initcall_tfn)

if(initcall_blacklisted(fn))

return

-EPERM;

-if(initcall_debug)

+if(1)

                ret =

do_one_initcall_debug(fn);

-3 优化建议：

preloadClasses()与preloadResources()可以放到两个线程里面跑。

修改zygote的nice值，及thread priority。

http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java#590

中增加如下的修改：

在  EventLog . writeEvent ( LOG_BOOT_PROGRESS_PRELOAD_START , 592 SystemClock . uptimeMillis ()); 593 preload (); 594 EventLog . writeEvent ( LOG_BOOT_PROGRESS_PRELOAD_END , 595 SystemClock . uptimeMillis ()); 前增加修改

/* 20151013 optimize android boot begin */

//get the default priority.

int defaultPriority = Process.getThreadPriority(Process.myPid()) ;

//increase the priority .

Process.setThreadPriority(Process.THREAD_PRIORITY_AUDIO) ;

在 gcAndFinalize (); 增加

Process.setThreadPriority(defaultPriority) ;

/*  20151013 optimize android boot end */

-2 系统剪裁也有助于提高系统轮芦的开机速度

提升CPU频率 - 将所有CPU切换至性能模式

adb shell stop perf-hal-1-0

adb shell "echo 1 > /sys/devices/system/cpu/cpu0/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu1/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu2/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu3/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu4/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu5/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu6/online"

adb shell "echo 1 > /sys/devices/system/cpu/cpu7/online"

adb shell "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor"

adb shell "echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,cpubw/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,mincpubw/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom,memlat-cpu0/governor"

adb shell "echo performance > /sys/class/devfreq/soc:qcom, memlat-cpu6/governor"

提升GPU频率

adb shell "echo 0 > /sys/class/kgsl/kgsl-3d0/min_pwrlevel"

adb shell "echo 1 > /sys/class/kgsl/kgsl-3d0/force_clk_on"

adb shell "echo performance > /sys/class/kgsl/kgsl-3d0/devfreq/governor"

-1 电源优化

on init

    # Disable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 0

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 0

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 0

    write /sys/mole/lpm_levels/parameters/sleep_disabled Y

on property:sys.boot_completed=1

    # Enable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1

    write /sys/mole/lpm_levels/parameters/sleep_disabled N

on charger

    # Enable UFS powersaving

    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1

    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1

    write /sys/class/typec/port0/port_type sink

    write /sys/mole/lpm_levels/parameters/sleep_disabled N

0 bootgraph 用来分析内核功能， 在kernel cmdline 增加 initcall_debug ,然后dmesg > boot.log  bootgraph.pl boot.log >  boot.svg

1通过一个比gzip更快的方式去解压内核镜像；

2 去掉系统中一些不必要的log打印；

3 去掉一些系统中不需要的驱动模块；

4 启动时即以最大频率（cpu/DDR）且多核一起跑；

5 将一些耗时大，对启动顺序没有要求的驱动通过异步方式进行加载（如下所示）

这里我们主要关注的是第三个，也是优化的重点。这部分时间，具体都在干啥，瓶颈是哪，可以通过bootchart很清楚的看到。以下结合以前抓的图，简要说一下（图是很久之前抓的，比较懒，没有再跑一遍过程）

上图中bootanim的退出时间没有截出来，实际图是有的，大约是33s的时候结束。

这里分析时，我们是分了几个时间段：

1 内核开始启动，到init进程开始执行。这个可以通过log看到。

2 init进程执行，主要是处理init.rc中的命令，到core和mainl类服务开始启动的时间，上图中可以看到，服务大体都在一个时间点起来的，约7.5S时，这之前的一大段空窗期，也是要重点看的

3 zygote启动时间

4 systemserver中各个服务启动时间

5 应用启动(systemui/launcher/keyguard..)

以上，具体分析看每段时间：

第一点另外处理，具体分析打印看是否有异常，这个值一般是很小的，不合理要和BSP同事一起查一下原因。

第二个主要是init.rc执行各种命令，这个可以通过在execute_one_command函数中统计测量 ，比如大于100ms的命令打印出来，再分析定位原因，这里命令执行时间长基本算BUG，要和BSP工程师一起解决。

第三点主要zygote启动问题，主要慢的原因，是加载资源和类库，这个要读nand，一般卡的时间比较长，图中可以看到，zygote进程一溜的小粉红，说明IO较多。这个preload过程消耗的时间，在logcat的log中，也会打印的，一般来说，都是在近10S左右。

第四个，zygote初始化完后，会fork system_server。 system_server进程启动，耗时也是较长的。根据以前统计分析的结果，这里的服务启动，基本上都是花在packageManagerService的PackageScan中，这又是一个读文件，卡在文件读取中，时间长短，和预制app及安装的app数量有关

第五个时间，是基本都准备ready后，启动launcher等应用了，启动完成后，systemServer请求SurfaceFlinger杀了bootanimation，就启动完成了。

以上时间中，主要要优化的，还是第三步和第四步的IO慢问题，其他可优化的不多。比如CPU，常开四核performance模式启动，也并没提升多少，一般我们就不管了这个了。

咋优化？

确定优化方向后主要看怎么优化这两段耗时的地方：

1. Zygote的preload 资源和class

2. PackageManagerService的包扫描

这里的第一个，最早之前有人直接是去掉preload或删减，虽然可以加快一点开机速度，但是捡了芝麻丢了西瓜，根本不能这样干~

我们最早做的实现方式，

2.1 是将preload做并行处理，毕竟现在都是多核处理器了，而且是preload是加载后还要解析处理的，并行会有一定幅度提升。

对于包扫描，这个不好拆成并行任务，不像preload那么简单干净。考虑过将PackageManager的信息序列化后存起来，下次开机就不扫了，不过看起来改动有点大，不太好搞，也放弃了。

PackageManagerService扫描、检查APK安装包信息

2.2 PMS对/system/framework，/system/app，/data/app，/data/app-private目录中的APK扫描耗费了大量的时间，如果预置的三方应用很多，这样启动的时间就会越长。

优化建议：

2.3 /system/app下的应用，如果是预置应用，在Android.mk建议加上LOCAL_DEX_PREOPT := true控制，在/system/vendor下的预置应用，如果此应用编译时间比较长的，也使用上LOCAL_DEX_PREOPT := true

2.4 尽量减少data区内置app的数量，这个会严重影响开机速度，特别是第一次的开机速度。放在system的app 尽量生成odex 这样会加快开机速度。

最后我们的实现的方式，就是linux上用的较多的readahead机制。具体实现细节就不展开说了，原理就是：

1. 统计开机过程中，读取的块数据信息，记录下来保存

2.再次开机，通过记录下来的块数据读取信息，直接起一个服务，预先开始读，zygote或packagemanagerservice要读文件的时候，文件数据已经在cache中了。

实际用下来，这一招特别好，优化非常明显。以下是实现了一个readahead后的bootchart图：

可以看到：

1. zygote和system_server都提速了

2. zygote和system_server的IO时间，都降低非常大

3. 主要IO时间，跑到readahead进程中去了。

不过，以上实现，还是有可优化的地方：

1. readahead进程可以再提前，在system分区挂载后立刻启动，这样zygote中的IO应该可以再减小

2. 对system_server的IO，此时readahead已经结束了，按理不应该有了，这里还是有IO，这一般是后装apk导致，这个可以把readahead做的更健壮一些，不要只学习开始的一两次。

其他NB的优化

另外还有一个很NB的技术，就是STD。这个我们也搞过，花费了大量的人力物力。STD开机时间，不算上uboot时间的话，基本都是在10S内，5~8S之间。不过这么NB的技术，目前基本上也是废弃了，用起来问题也挺多的：

1. 开机时间少了，关机时间拉长。

由于是STD(Suspend to Disk)，关机时需要将内存数据写入nand，这块也是挺麻烦的事情

2. 稳定性

本身STD弄起来就比较复杂，BUG挺多的，另外使用STD，就相当于永不关机了，这也太考验系统软件的稳定性了...

3. 没毛用

   一开始还能忽悠客户，不过后来也没人怎么关心这个feature了，平白给自己找活干，大家都不乐意使能它了。

❽ 华为手机开机重启后显示安卓正在启动优化应用的原因是什么

造成 Android开机就显示升级应用的错误，是自己刷机后没有wipe，双清。

2、手机在线ota升级后没有自动双清，导致系统缓存混乱。

3、你的手机的安装包里面有自动安装的程序。

解决方法：

尝试在关机状态下，按住“音量+”键再按住“开机键”直到显示语言，选择进入系统，然后按重启手机，它会显示重启进入系统一和重启进入系统二，选择进入系统二，之后重启。

其他原因及方法：

1、可能是软件兼容性导致的，若多次出现自动关机状况，建议将近期安装的第三方软件删除，排除是否和下载的软件有关。

2、请备份手机重要数据，恢复出厂设置。

3、建议执行wipe（双清）操作。

4、若问题既然存在，请送检。

1、造成 Android开机就显示升级应用的错误，是自己刷机后没有wipe，双清。

2、手机在线ota升级后没有自动双清，导致系统缓存混乱。

3、手机的安装包里面有自动安装的程序。

4、手机的自身优化系统和机子不兼容。

解决方法： 尝试在关机状态下，按住“音量+”键再按住“开机键”直到显示语言，选择进入系统，然后按重启手机，它会显示重启进入系统一和重启进入系统二，选择进入系统二，之后重启。

拓展：

Android是由Google公司和开放手机联盟领导并开发的一种基于Linux的自由且开放源代码的操作系统，主要使用于移动设备。

❾ Android启动优化概述

Android启动应用, 按 官方说法 分为冷启动, 温启动和热启动.
具体的定义可以看官方文档, 简单地说

一般我们只需要关注冷启动即可.

要想启动快, 硬件性能必然有影响, 在硬件一定的前提下, 我们要尽量 降低启动应用时CPU的负载 , 让CPU有更多的算力投入到启动流程中:

在做好一些基本原则后, 接着看具体的流程优化点

在应用进程创建后, 首先必然是加载类, 此时一些静态变量就会初始化了, 因此我们应该

类加载完毕后就是创建 Application 实例了, 因此我们应该

之后会先创建 ContentProvider 和执行 ContentProvider.onCreate() , 因此我们应该

跟接着就会执行 Application.onCreate() 等方法, 因此我们应该

接着就进入 Activity 环节.
同样第一步会是创建实例, 因此我们应该

在 Activity 进程生命周期后, 第一步就是渲染(inflate)布局, 我们应该

在应用启动的瞬间, 系统服纳亏务会先展示一个空白窗口哪茄歼, 等待应用第一帧绘制完毕后, 再从该窗口切换到应用, 如果启动耗时较长, 就会明显看到白屏, 对于这一点, 常见的操作有

可以使用IdleHandler, 在主线程空闲时再执行某些不重要的操作

实际上异步初始化只是不阻塞主线程, 但是子线程一样会占用CPU资源, 让主线程的执行时间变少, 所以不应该盲目地将所有工作放到子线程.

优化做到最后, 就是在系统流程上做文章了

原理是将启动时加载的类放到主dex，提升了这些类的内聚，让更多的类满足pre-verify的条件，在安装时就做了校验和优化，以减少首次加载的耗时，从而优化冷启动耗时。
Redex 初探与 Interdex：Andorid 冷启动优化

应用启动过程中会从apk压缩包中读取文件, 该优化的原理是利用Linux中的Pagecache机制, 让启动过程会用到的文件尽可能进入缓存中, 减少磁盘IO次数
支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能

在Dalvik VM(Android5.0以前)加载类的时候会有一个类校验过程, 它需要校验方李冲法的每一个指令, 是一个比较耗时的过程, 可以通过Hook去掉类加载过程中的类验证过程. 不过对于ART(Android5.0之后)来说, 这个过程在安装时已经做了, 所以用处不大.

不进入冷启动, 就不用优化了~

这个Android Studio自带的工具, 可以看到启动过程中详细的方法执行流程, 但是采集数据本身会影响方法执行, 所以不能准确判断每个方法的耗时, 但是仍可以判断哪个方法相对来说耗时.

这个工具的好处是可以自定义事件, 可以指定需要采集的数据集, 可以看到线程间的状态等.

启动优化的一个关键点在于定义启动结束的点, 以及如何测量启动时间.

在Android4.4以上, 系统进程会提供一个类似 ActivityManager: Displayed ***: +3s534ms 的日志, 表示从启动进程到首次绘制完毕所用的时间.

应用可以在任何时候调用该方法, 触发系统打印类似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日志

应用可以通过 ViewTreeObserver 来监听绘制前回调来判断第一帧的绘制时机, 或者直接在控件树的末尾加一个简单的View, 它 onDraw 调用时即表示页面(差不多)绘制完毕.

应用启动过程可以参考 Android Vitals Series' Articles 系列文章

❿ Android 性能优化 05---App启动优化

其实启动框架就是一个任务调度系统，是手淘启动的“大管家”。
管家要做的事情就是把它们的关系梳理得明明白白，有条不紊，合理安排位置、调度时间，袭哗同时提升硬件资源的利用率。

总结下来无非就是两点：

有向无环图[拓扑排序]

可用方案
APT，字节码插桩，利用ContentProvider
面试题LeakCanary 为什么不需要在Application中手动初始化？

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

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

adb命令启动应用，一般会输入三个值：ThisTime、TotalTime与WaitTime。
1.WaitTime：包括前一个应用Activitypause的时间和新应用启动的时间；
2.ThisTime：表示一连串启动Activity的最后一个Activity的启动耗时；
3.TotalTime：表示新应用启动的耗时，包括新进程的启动和Activity的启动，但不包括前一个应用Activitypause
的耗时。

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

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

消除启动时的黑/白屏问题，大部分App都采用自己在Theme中设置背景图的方式来解决。

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

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