Android性能优化--启动优化

最新推荐文章于 2024-08-11 14:36:28 发布

像程序那样思考

最新推荐文章于 2024-08-11 14:36:28 发布

阅读量249

点赞数

分类专栏：安卓程序员性能优化文章标签： Android开发 Android工程师程序员性能优化

本文链接：https://blog.csdn.net/weixin_45258969/article/details/103477505

版权

程序员同时被 3 个专栏收录

128 篇文章 0 订阅

订阅专栏

安卓

126 篇文章 4 订阅

订阅专栏

性能优化

29 篇文章 0 订阅

订阅专栏

1. 前言

一个应用App的启动速度能够影响用户的首次体验，启动速度较慢(感官上)的应用可能导致用户再次开启App的意图下降，或者卸载放弃该应用程序。本文会通过以下几个方面来介绍应用启动的相关指标和优化，提供应用的启动速度。

整体文章思路如下：

启动优化

2. 冷启动&热启动

通常来说，启动方式分为两种：冷启动和热启动。

**冷启动：**当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动。
**热启动：**当启动应用时，后台已有该应用的进程（例：按back键、home键，应用虽然会退出，但是该应用的进程是依然会保留在后台，可进入任务列表查看），所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动。

两者之间的特点如下：

冷启动:系统会重新创建一个新的进程分配给该应用，从Application创建到UI绘制等相关流程都会执行一次。
热启动：应用还在后台，因此该启动方式不会重建Application，只会重新绘制UI等相关流程。

冷热启动时间的计算命令：

adb shell am start -W [packageName]/[packageName.XxxActivity]

参数说明：
1、ThisTime:一般和TotalTime时间一样。除非在应用启动时开了一个透明的Activity预先处理一些事再显示出主Activity，这样将比TotalTime小。
2、TotalTime:应用的启动时间。包含创建进程+Application初始化+Activity初始化到界面显示。
3、WaitTime:一般比TotalTime大点，包含系统影响的耗时。
对于我们的应用来说结果如下：
冷启动

冷启动

热启动

热启动

可以看到两者时间相差比较大。
根据该命令基本可以看出一个应用的启动速度了，从冷启动热启动的相关关系，当我们需要优化启动速度的时候，优化冷启动速度即可。
但是该命令我们只是大概知道应用的启动速度，但并不知道我们的应用具体哪个位置耗时，影响启动速度，后续我会介绍如何获取启动具体耗时时间。

3. 常规获取时间方法

常规获取时间方法无非就是在方法执行前记录下时间，在方法执行完毕后记录时间，两者时间之差就是该方法执行的时间，封装一个基础类如下：

public class LaunchTimer {

 private static final String TAG = "LaunchTimer";
 private static long sTime;

 public static void startRecord() {
 sTime = System.currentTimeMillis();
 }

 public static void endRecord() {
 long cost = System.currentTimeMillis() - sTime;
 NLog.i(TAG, "执行耗时：%s", cost);
 }

}

使用方式如下，可以直观的看出createController方法执行的时间

createController耗时

这样已经很直观了，可以具体到该方法的执行时间，如果要继续分析则对该方法内部继续执行该代码即可。但是这里有一个问题如果要知道10个或者更多方法的执行时间，这个方法看起来是可以，但写起来过于繁琐，且不符合程序员的习惯，关于这种场景后面会介绍如何处理。

4. TraceView和SysTrace工具使用

TraceView使用：TraceView是Android平台配备一个很好的性能分析工具，它可以通过图形化的方式让我们了解我们要跟踪的程序的性能，并且能具体到方法。
使用方式：

通过Android studio自带的traceview查看（Android profiler）。
通过Android SDK自带的Debug。
通过DDMS中的traceview查看。
本文主要介绍第二种方式，通过sdk中的方法，对应用进行打点获取相关信息：

 @Override
 public void onCreate(final Bundle icicle) {
 setTheme(R.style.BrowserTheme);
 Intent intent = getIntent();
 NLog.i(LOGTAG,"onCreate");
 super.onCreate(icicle);
 //开始记录，且该方法可以设置文件大小和路径
 Debug.startMethodTracing("browser.trace");
 Controller controller=createController();
 mController = controller;
 getWindow().getDecorView().setSystemUiVisibility(
 View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN|View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR);
 controller.handleThirdPartyIntent(intent);
 //结束记录
 Debug.stopMethodTracing();
 }

如上可以在目录下可以生成如下文件

/sdcard/Android/data/com.xxx.xx.browser/files/browser.trace

导出改文件，通过Android Studio的profile打开改文件

traceview

1处可以看出有多少线程。
2处可以看出具体方法的耗时。
3处有两个选项：

wall clock time:代码在线程上执行的真正时间[有一部分是等待cpu轮询时间]
thread time :cpu执行的时间
一般是优化的是cpu执行时间
结合业务代码走查发现Controller0线程为一个线程，因此主线程一些操作可以放进去执行，从而减少main线程的耗时。走查代码可以发现在Controller0线程中执行如下

 requestPermission();
 ExecutorService service = Executors.newSingleThreadExecutor(new NamedThreadFactory("Controller"));
 Future<Boolean> future = service.submit(new Callable<Boolean>() {
 @Override
 public Boolean call() throws Exception {
 try {
 asyncInit();

 } catch (Exception e) {
 return false;
 }
 return true;
 }
 });

requestPermission()方法执行在main线程中，因此我们可以把其放在Controller0线程中执行，从而减少main线程的的时间

 ExecutorService service = Executors.newSingleThreadExecutor(new NamedThreadFactory("Controller"));
 Future<Boolean> future = service.submit(new Callable<Boolean>() {
 @Override
 public Boolean call() throws Exception {
 try {
 requestPermission();
 asyncInit();

 } catch (Exception e) {
 return false;
 }
 return true;
 }
 });

经测试发现无问题，且对比此时的trace文件发现修改前后main线程时间相对来说减少很多。

SysTrace使用：
SysTrace用于收集可帮助您检查原生系统进程的详细系统级数据，例如CPU调度、磁盘活动、应用线程等，并解决掉帧引起的界面卡顿。
使用方式：

在代码的开始位置加上tag

 TraceCompat.beginSection("AppOnCreate");

然后指定位置结束

TraceCompat.endSection();

即可以抓取到整个应用在此过程的相关信息,例如在onCreate方法中添加上述两行代码，执行相关python命令：

python systrace.py -b 32768 -t 10 -a com.xxx.xxx.browser -o browser.html sched gfx view wm am app

操作相关应用，即可以抓取整个过程的相关信息：

systrace

即可以看到添加的tag“AppOnCreate”，对应的时间信息：

Wall Duration 代表的方法从开始到结束的耗时
CPU Duration 代表CPU的执行时间
通过这两个参数可以看出此流程中执行的时间等相关信息
我们都知道CPU是轮询模式，因此优化的方向可以说是两个方向，提高CPU的核数和优化CPU执行的时间。

5. 通过AOP获取时间

AOP:面向切面编程(Aspect-Oriented Programming)。如果说，OOP如果是把问题划分到单个模块的话，那么AOP就是把涉及到众多模块的某一类问题进行统一管理。打个比方Android 里面PMS，AMS都拥有各自的职责，但是他们都需要通过log系统管理log，这就是一种AOP思想。

AspectJ实际上是对AOP编程思想的一个实践，当然，除了AspectJ以外，还有很多其它的AOP实现，例如ASMDex，但目前最好、最方便的，依然是AspectJ。
AspectJ的使用如下：
根目录gradle下引用：

 classpath 'com.hujiang.aspectjx:gradle-android-plugin-aspectjx:2.0.0'

app目录gradle文件下引用：

 implementation 'org.aspectj:aspectjrt:1.8.+'

此两处引用完成之后，就是代码编写：

package com.xx.xxx.browser.aspect;

import android.util.Log;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.Signature;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class IntercepLifeCycleAOP {
 //获取该Activity下的所有on开头的方法耗时
 @Around("execution(* com.xxx.xxx.BrowserActivity.on**(..))")
 public Object getTime(ProceedingJoinPoint joinPoint) {
 Object proceed = null;
 long start = System.currentTimeMillis();
 try {
 proceed = joinPoint.proceed();
 } catch (Throwable throwable) {
 throwable.printStackTrace();
 }
 long end = System.currentTimeMillis();
 Log.d("IntercepLifeCycleAOP", joinPoint.getSignature().getName() + ":执行时间:" + (end - start));
 return proceed;

 }

}

引入之后结果如下：

AspectJ

可以看到具体方法的耗时。
采用注解方式，其中Around 需要有一定的AspectJ相关的语法

6. 用户体验优化

主题优化：通过给应用设置一个透明主题，在应用启动完成之后，再给其赋予本该有的主题，通过对启动页的主题设置后，就会将白屏/黑屏抹去，用户点击App的图标就展示启动图，让用户先产生启动很快的“错觉”。
动画兼容：根据不同年代的机型可以选择执行或不执行相关动画，或者延迟其他相关操作,可根据device-year-class来判断具体年份
UI布局优化。