目录启动方式冷启动(启动优化目标)热启动温启动启动流程中可优化的环节检测工具启动时间检测LoGCat Displayedadb 命令统计CPU profileapi level &g
本文主要探讨以下几个问题:
应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动与热启动
冷启动是指应用从头开始启动:系统进程在冷启动后才创建应用进程。发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动。
在热启动中,系统的所有工作就是将 Activity 带到前台。只要应用的所有 Activity 仍驻留在内存中,应用就不必重复执行对象初始化、布局加载和绘制。
温启动包含了在冷启动期间发生的部分操作;同时,它的开销要比热启动高。有许多潜在状态可视为温启动。例如:
启动流程中开发者可优化的环节不多,咱们可以从APP启动流程中寻找下
APP启动过程如下:
所以,我们能优化的阶段只有 Application.onCreate() —> Activity.onWindowFocusChanged()
启动的时间怎样算是合适的?怎样一个时间范围内用户是感觉流畅的?Android Vitals在您的应用出现以下情况时将其启动时间视为过长:
那APP启动用了多长时间?用什么区检测?
在 Android 4.4(API 级别 19)及更高版本中,logcat 包含一个输出行,其中包含名为 Displayed 的值。此值代表从启动进程到在屏幕上完成对应 Activity 的绘制所用的时间。
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活动,需要做以下操作
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低于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最常用于捕获应用程序主线程上的意外磁盘或网络访问。帮助我们让磁盘和网络操作远离主线程,可以使应用程序更加平滑、响应更快
// 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());
}
当系统加载并启动 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 性能优化内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!
--结束END--
本文标题: Android 分析实现性能优化之启动速度优化
本文链接: https://www.lsjlt.com/news/156099.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
下载Word文档到电脑,方便收藏和打印~
2024-01-21
2023-10-28
2023-10-28
2023-10-27
2023-10-27
2023-10-27
2023-10-27
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0