SongHang's Blog
0%

启动优化

Posted on In Views:

一 、启动优化

启动耗时统计

TTID：初步显示所用时间

系统日志统计，logcat 包含一个输出行，其中包含名为 Displayed 的值。此值代表从启动进程到在屏幕上完成对应 Activity 的绘制所用的时间。

adb 命令统计，查看启动时间的另一种方式是使用命令:shell am start -S -W com.example.app/.MainActivity

TTFD：完全显示所有时间

衡量这些异步加载资源所耗费的时间，我们可以在异 步加载完毕之后调用 activity.reportFullyDrawn() 方法来让系统打印到调用此方法为止的启动耗时。

启动优化

  1. 合理使用异步初始化、延迟初始化、懒加载机制
  2. 启动过程避免耗时操作，如数据库IO操作不要在主线程执行
  3. 类加载优化提前异步执行类加载
  4. 合理使用IdleHandler进行延迟初始化那些在主线程的工作，给MessageQueue添加IdleHandler，把主线程耗时操作放在IdleHandler#queueIdle()中，这样耗时操作会在布局绘制完显示后再执行，提升用户体验。如果耗时操作用在了界面view绘制之前的话，就会出现view先是白的，再出现。
  5. 简化布局

CPU Profile/TraceView

如果发现显示时间比希望的时间长，则可以继续尝试识别启动过程中的瓶颈。 查找瓶颈的一个好方法是使用 Android Studio CPU 性能剖析器。

Traceview是android平台配备一个很好的性能分析的工具。它可以通过图形化的方式让我们了解我们要跟踪 的程序的性能，并且能具体到每个方法的执行时间。但是目前Traceview 已弃用。如果使用 Android Studio 3.2 或更高版本，则应改为使用 CPU Profiler

CPU Profile：检查应用的 CPU 使用率和线程活动，也可以检查记录的方法跟踪数据、函数跟踪数据和系统跟踪数据的详情。记录方法执行时间。

选择记录配置

Edit configurations 为捕获的分析信息选择适当的记录配置：对 Java 方法采样、跟踪 Java 方法。

在 Threads 时间轴中查看 Call Chart，并从 Analysis 窗格中查看 Flame Chart、Top Down、Bottom Up 和 Events 标签页，查看方法执行时间。

通过工具可以定位到耗时代码，然后查看是否可以进行优化。对于APP启动来说，启动耗时包括Android系统启动 APP进程加上APP启动界面的耗时时长，我们可做的优化是APP启动界面的耗时，也就是说从Application的构建到 主界面的 onWindowFocusChanged 的这一段时间。因此在这段时间内，我们的代码需要尽量避免耗时操作，检查的方向包括:主线程IO;第三方库初始化或程序需要 使用的数据等初始化改为异步加载/懒加载;减少布局复杂度与嵌套层级;Multidex(5.0以上无需考虑)等。

Debug API

除了直接使用 Profiler 启动之外，我们还可以借助Debug API生成trace文件。可以使用 Debug 类进行应用插桩，生成跟踪日志。开始记录跟踪数据的位置调用 startMethodTracing(“文件名”)。可以指定 .trace 文件的名称，方法结束的地方停止跟踪，调用 stopMethodTracing()。用Profiler分析trace文件，把.trace文件拖到AS文件编辑框部分。

1
2
3
4
5
6
7
8
9
10
11
public class MyApplication extends Application {
public MyApplication() { Debug.startMethodTracing("enjoy");
}
//.....
}
public class MainActivity extends AppCompatActivity {
@Override
public void onWindowFocusChanged(boolean hasFocus) { super.onWindowFocusChanged(hasFocus); Debug.stopMethodTracing();
}
//.......
}

启动方法跟踪：startMethodTracing()，对应用的运行速度会减慢，开始和停止跟踪的方法在整个应用进程内均有效。

启动基于采样的方法跟踪，对运行时性能的影响较小，请调用带有指定采样间隔时间的 startMethodTracingSampling(tracePath,bufferSize,intervalUs)（而不是调用 startMethodTracing())，系统会定期收集示例，直至您的应用调用 stopMethodTracing()。

StrictMode严苛模式

StrictMode是一个开发人员工具，它可以检测出我们可能无意中做的事情，并将它们提请我们注意，以便我们能够修复它们。

StrictMode最常用于捕获应用程序主线程上的意外磁盘或网络访问。帮助我们让磁盘和网络操作远离主线程，可以 使应用程序更加平滑、响应更快。

在debug中开启StrictMode严苛模式，自动检测代码是否有违规操作(主线程执行IO操作)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class MyApplication extends Application {
    @Override
public void onCreate() {
if (BuildConfig.DEBUG) {
//线程检测策略
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectDiskReads() //读、写操作
.detectDiskWrites()
.detectNetwork() // or .detectAll() for all detectable problems .penaltyLog()
.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中设置背景图的方式来解决，然后在Activity的onCreate方法，把Activity设置回原来的主题。这么做，只是提高启动的用户体验。并不能做到真正的加快启动速度。

MessageQueue.IdleHandler#queueIdle()

作用：提供一个android没有的声明周期回调时机；可以结合HandlerThread，用于单线程消息通知器。

1
2
3
4
5
6
7
8
9
10
//通过Looper往MessageQueue添加IdleHandler
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
           @Override
           public boolean queueIdle() {
             //主线程耗时操作
             //或者结合HandlerThread时触发消息mListener.onDataChange
              ...
               return false;
          }
});

在looper里面的message暂时处理完了，这个时候会回调这个接口，返回false，那么就会移除它，返回true就会在下次message处理完了的时候继续回调。Idle就是队列为空的意思，那么的onResume和measure, layout, draw都是一个个message的话，这个IdleHandler就提供了一个它们都执行完毕的回调了。

IdleHandler的使用场景

1. GC

ActivityThread.GcIdler系统会将它加入到主线程的Handler中，当主线程消息队列处于休眠状态的时候尝试出发一次GC，我们看到GcIdler的queueIdle返回false，表示该GcIdler只会触发一次。

2. LeakCanary检测Activity内存泄漏

LeakCanary会在Activity调用onDestroy之后，监听该Activity是否被正常回收，但是监听Activity的回收情况是比较耗性能的，有可能影响到主线程UI的渲染，LeakCanary为了避开主线程UI渲染，就会使用IdleHandler，在主线程空闲的时候触发监听。

3. Activity中的耗时操作

当我们打开一个Activity的时候，在onCreate中有可能会进行一些耗时但又不那么紧急的操作，这些操作可以延后一段时间执行，此时我们就可以使用IdleHandler实现，等主线程中消息处理完成处于休眠状态的时候，在IdleHandler的queueUdle方法中再触发这些操作。

android本身提供的activity框架和fragment框架并没有提供绘制完成的回调，如果我们自己实现一个框架，就可以使用这个IdleHandler来实现一个onRenderFinished这种回调了。

原因

ActivityThread.handleResumeActivity()过程：先执行performResumeActivity()#onResume()方法，

后执行wm.addView(decor, l)#ViewRootImpl.requestLayout()#performTraversals()#measure()流程，所以onResume()并不是activity的View绘制完成后的回调，而是先于绘制的，想在界面绘制出来后做点什么，那么在onResume里面显然是不合适的，它先于View的绘制measure等流程了

二、卡顿分析

Layout Inspector：查看布局视图层次结构，Tools->Layout Inspector

CPU Profiler：选择记录配置 Edit configurations->Profiling->Start this recording on startup-> Trace System Calls跟踪系统调用。检查应用与系统资源的交互情况，检查线程状态的确切时间和持续时间、直观地查看所有内核的 CPU 瓶颈在何处，功能类似Systrace。

Systrace：Systrace 是Android平台提供的一款工具，用于记录短期内的设备活动，页面滑动卡顿分析，systrace 提供的其他系统级数据可帮助您检查原生系统进程并排查丢帧或帧延迟问题。

在抓取systrace文件的时候，切记不要抓取太长时间，也不要太多不同操作。打开抓取的html文件，可以看到我们应用存在非常严重的掉帧，

1
python systrace.py -t 5 -o F:\Lance\optimizer\lsn2_jank\a.html gfx input view am dalvik sched wm disk res -a com.enjoy.example

Trace API：Android 提供了Trace API能够帮助我们记录收集自己应用中的一些信息 : Trace.beginSection()与Trace.endSection()。有了大概怀疑的具体的代码块或者有想了解的代码块执行时系统的状态，还可以结合 Trace API 打 标签。

1
2
3
4
5
6
7
8
public class MainActivity extends AppCompatActivity {
 @Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);  
  TraceCompat.beginSection("enjoy_launcher"); //Trace.beginSection()
  setContentView(R.layout.activity_main);
  TraceCompat.endSection(); //Trace.endSection() }
}

App层面监控卡顿

systrace可以让我们了解应用所处的状态，了解应用因为什么原因导致的。若需要准确分析卡顿发生在什么函数，资源占用情况如何，目前两种主流有效的app监控方式如下:

1、 利用UI线程的Looper打印的日志匹配，如BlockCanary。
2、 使用Choreographer.FrameCallback，如ArgusAPM。

Matrix：字节码插桩技术，在所有的方法开始处和结束处，添加记录时间的代码。

BlockCanary、ArgusAPM对于一些简单方法堆栈容易定位到具体耗时方法，但可能定位的不太准确，对于一些复杂的方法堆栈就比较难准确定位到真正耗时的方法了，这时可考虑使用Matrix。

Looper日志检测卡顿

Android使用消息机制进行UI更新，UI线程有个Looper，在其loop方法中会不断取出message，调用其绑定的 Handler在UI线程执行。如果在handler的dispatchMesaage方法里有耗时操作，就会发生卡顿。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public static void loop() { 
//......
for (;;) { 
//......
Printer logging = me.mLogging; 
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what); }

msg.target.dispatchMessage(msg); 

if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); }
//......
} }

只要检测 msg.target.dispatchMessage(msg) 的执行时间，就能检测到部分UI线程是否有耗时的操作。注意到这行 执行代码的前后，有两个logging.println函数，如果设置了logging，会分别打印出*>>>>> Dispatching to和 <<<<< Finished to *这样的日志，这样我们就可以通过两次log的时间差值，来计算dispatchMessage的执行时 间，从而设置阈值判断是否发生了卡顿。

Looper提供了 setMessageLogging(@Nullable Printer printer)方法，所以我们可以自己实现一个Printer，在 通过setMessageLogging()方法传入即可。其实这种方式也就是 BlockCanary 原理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
public class BlockCanary {
  public static void install() {
   LogMonitor logMonitor = new LogMonitor();
   Looper.getMainLooper().setMessageLogging(logMonitor); }
}

public class LogMonitor implements Printer {
private StackSampler mStackSampler; 
private boolean mPrintingStarted = false; 
private long mStartTimestamp;
// 卡顿阈值
private long mBlockThresholdMillis = 3000;
//采样频率
private long mSampleInterval = 1000;
private Handler mLogHandler;
public LogMonitor() {
  mStackSampler = new StackSampler(mSampleInterval);
 HandlerThread handlerThread = new HandlerThread("block-canary-io"); handlerThread.start();
  mLogHandler = new Handler(handlerThread.getLooper());
}

@Override
public void println(String x) {
//从if到else会执行 dispatchMessage，如果执行耗时超过阈值，输出卡顿信息
if (!mPrintingStarted) { //记录开始时间
mStartTimestamp = System.currentTimeMillis();
mPrintingStarted = true; 
mStackSampler.startDump();
} else {
final long endTime = System.currentTimeMillis();
mPrintingStarted = false;
//出现卡顿
if (isBlock(endTime)) {
     notifyBlockEvent(endTime);
            }
mStackSampler.stopDump(); 
}
}
private void notifyBlockEvent(final long endTime) {
mLogHandler.post(new Runnable() {
@Override
public void run() { 
//获得卡顿时 主线程堆栈
 List<String> stacks = mStackSampler.getStacks(mStartTimestamp, endTime);
 for (String stack : stacks) {
 Log.e("block-canary", stack); }
}
});
}

private boolean isBlock(long endTime) {
  return endTime - mStartTimestamp > mBlockThresholdMillis;
}
}

Choreographer.FrameCallback

Android系统每隔16ms发出VSYNC信号，来通知界面进行重绘、渲染，每一次同步的周期约为16.6ms，代表一帧 的刷新频率。通过Choreographer类设置它的FrameCallback函数，当每一帧被渲染时会触发回调

FrameCallback.doFrame (long frameTimeNanos)函数。frameTimeNanos是底层VSYNC信号到达的时间戳 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class ChoreographerHelper {
    public static void start() {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) { Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
long lastFrameTimeNanos = 0;
@Override
public void doFrame(long frameTimeNanos) { //上次回调时间
if (lastFrameTimeNanos == 0) {
lastFrameTimeNanos = frameTimeNanos; Choreographer.getInstance().postFrameCallback(this); return;
}
long diff = (frameTimeNanos - lastFrameTimeNanos) / 1_000_000; if (diff > 16.6f) {
//掉帧数
int droppedCount = (int) (diff / 16.6); }
lastFrameTimeNanos = frameTimeNanos;
Choreographer.getInstance().postFrameCallback(this); }
}); }
} }

通过 ChoreographerHelper 可以实时计算帧率和掉帧数，实时监测App页面的帧率数据，发现帧率过低，还可以自动保存现场堆栈信息。Looper比较适合在发布前进行测试或者小范围灰度测试然后定位问题，ChoreographerHelper适合监控线上环境 的 app 的掉帧情况来计算 app 在某些场景的流畅度然后有针对性的做性能优化。

三、布局优化

层级优化

使用merge标签

当我们有一些布局元素需要被多处使用时，这时候我们会考虑将其抽取成一个单独的布局文件。在需要使用的地方 通过 include 加载。

使用ViewStub 标签

如果view不一定会显示，此时可以使用 ViewStub 来包裹此View 以避免不需要显示view但是又需要加载view消耗资 源。viewstub是一个轻量级的view，它不可见，不用占用资源，只有设置viewstub为visible或者调用其inflater()方法 时，其对应的布局文件才会被初始化。

过度渲染

过度绘制是指系统在渲染单个帧的过程中多次在屏幕上绘制某一个像素。例如，如果我们有若干界面卡片堆叠在一 起，每张卡片都会遮盖其下面一张卡片的部分内容。但是系统仍然需要绘制堆叠中的卡片被遮盖的部分。

GPU 过度绘制检查 ：手机开发者选项中能够显示过度渲染检查功能，通过对界面进行彩色编码来帮我们识别过度绘制，粉色:过度绘制 3 次，红色:过度绘制 4 次或更多次。

解决过度绘制问题，可以采取以下几种策略来减少甚至消除过度绘制:

  • 移除布局中不需要的背景：默认情况下，布局没有背景，这表示布局本身不会直接渲染任何内容。但是，当布局具有背景时，其有可能会导致过度绘制。如子视图完全覆盖父视图背景时，父视图就不需要背景。
  • 使视图层次结构扁平化：优化视图层次结构来减少重叠界面对象的数量，从而提高性能
  • 降低透明度：对于不透明的 view ，只需要渲染一次即可把它显示出来。但是如果这个 view 设置了 alpha 值，则至少需要渲染两次。

布局加载优化

异步加载

LayoutInflater加载xml布局的过程会在主线程使用IO读取XML布局文件进行XML解析，再根据解析结果利用反射 创建布局中的View/ViewGroup对象。这个过程随着布局的复杂度上升，耗时自然也会随之增大。Android为我们 提供了 Asynclayoutinflater 把耗时的加载操作在异步线程中完成，最后把加载结果再回调给主线程。

1
2
3
4
5
6
7
8
9
10
dependencies {
implementation "androidx.asynclayoutinflater:asynclayoutinflater:1.0.0"
}

 new AsyncLayoutInflater(this)
.inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() { @Override
public void onInflateFinished(@NonNull View view, int resid, @Nullable ViewGroup parent) {
           setContentView(view);
//......
} });

1、使用异步 inflate，那么需要这个 layout 的 parent 的 generateLayoutParams 函数是线程安全的;

2、所有构建的 View 中必须不能创建 Handler 或者是调用 Looper.myLooper;(因为是在异步线程中加载的，异

步线程默认没有调用 Looper.prepare );
3、AsyncLayoutInflater 不支持设置 LayoutInflater.Factory 或者 LayoutInflater.Factory2;

4、不支持加载包含 Fragment 的 layout
5、如果 AsyncLayoutInflater 失败，那么会自动回退到UI线程来加载布局;

掌阅X2C思路 https://github.com/iReaderAndroid/X2C/blob/master/README_CN.md