Android性能优化之xxx

android 性能优化

参考

Android APP 性能优化的一些思考

01 | 崩溃优化（上）：关于“崩溃”那些事儿

知识

ANR

Android ANR问题总结

那么哪些场景会造成ANR呢？

理解Android ANR的触发原理

• Service Timeout:比如前台服务在20s内未执行完成；
• BroadcastQueue Timeout：比如前台广播在10s内未执行完成
• ContentProvider Timeout：内容提供者,在publish过超时10s;
• InputDispatching Timeout: 输入事件分发超时5s，包括按键和触摸事件。

分析

• 从log中找到ANR反生的信息：可以从log中搜索“ANR in”或“am_anr”，会找到ANR发生的log，该行会包含了ANR的时间、进程、是何种ANR等信息，如果是BroadcastReceiver的ANR可以怀疑BroadCastReceiver.onRecieve()的问题，如果的Service或Provider就怀疑是否其onCreate()的问题。

• 在该条log之后会有CPU usage的信息，表明了CPU在ANR前后的用量（log会表明截取ANR的时间），从各种CPU Usage信息中大概可以分析如下几点：

  • (1). 如果某些进程的CPU占用百分比较高，几乎占用了所有CPU资源，而发生ANR的进程CPU占用为0%或非常低，则认为CPU资源被占用，进程没有被分配足够的资源，从而发生了ANR。这种情况多数可以认为是系统状态的问题，并不是由本应用造成的。
  • (2). 如果发生ANR的进程CPU占用较高，如到了80%或90%以上，则可以怀疑应用内一些代码不合理消耗掉了CPU资源，如出现了死循环或者后台有许多线程执行任务等等原因，这就要结合trace和ANR前后的log进一步分析了。
  • (3). 如果CPU总用量不高，该进程和其他进程的占用过高，这有一定概率是由于某些主线程的操作就是耗时过长，或者是由于主进程被锁造成的。

• 除了上述的情况(1)以外，分析CPU usage之后，确定问题需要我们进一步分析trace文件。trace文件记录了发生ANR前后该进程的各个线程的stack。对我们分析ANR问题最有价值的就是其中主线程的stack，一般主线程的trace可能有如下几种情况：

  • (1). 主线程是running或者native而对应的栈对应了我们应用中的函数，则很有可能就是执行该函数时候发生了超时。
  • (2). 主线程被block:非常明显的线程被锁，这时候可以看是被哪个线程锁了，可以考虑优化代码。如果是死锁问题，就更需要及时解决了。
  • (3). 由于抓trace的时刻很有可能耗时操作已经执行完了（ANR -> 耗时操作执行完毕 ->系统抓trace），这时候的trace就没有什么用了，主线程的stack就是这样的：

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x757855c8 self=0xb4d76500
  | sysTid=3276 nice=0 cgrp=default sched=0/0 handle=0xb6ff5b34
  | state=S schedstat=( 50540218363 186568972172 209049 ) utm=3290 stm=1764 core=3 HZ=100
  | stack=0xbe307000-0xbe309000 stackSize=8MB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/3276/stack)
  native: #00 pc 0004099c  /system/lib/libc.so (__epoll_pwait+20)
  native: #01 pc 00019f63  /system/lib/libc.so (epoll_pwait+26)
  native: #02 pc 00019f71  /system/lib/libc.so (epoll_wait+6)
  native: #03 pc 00012ce7  /system/lib/libutils.so (_ZN7android6Looper9pollInnerEi+102)
  native: #04 pc 00012f63  /system/lib/libutils.so (_ZN7android6Looper8pollOnceEiPiS1_PPv+130)
  native: #05 pc 00086abd  /system/lib/libandroid_runtime.so (_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+22)
  native: #06 pc 0000055d  /data/dalvik-cache/arm/system@framework@boot.oat (Java_android_os_MessageQueue_nativePollOnce__JI+96)
  at android.os.MessageQueue.nativePollOnce(Native method)
  at android.os.MessageQueue.next(MessageQueue.java:323)
  at android.os.Looper.loop(Looper.java:138)
  at android.app.ActivityThread.main(ActivityThread.java:5528)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:740)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:630)

当然这种情况很有可能是由于该进程的其他线程消耗掉了CPU资源，这就需要分析其他线程的trace以及ANR前后该进程自己输出的log了。

ChkBugReport

https://blog.csdn.net/gjsisi/article/details/12105145?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.nonecase

adb bugreport /Users/xxx/

ANR reason主要有以下几类：

• 无窗口, 有应用：Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.
• 窗口暂停: Waiting because the [targetType] window is paused.
• 窗口未连接: Waiting because the [targetType] window’s input channel is not registered with the input dispatcher. The window may be in the process of being removed.
• 窗口连接已死亡：Waiting because the [targetType] window’s input connection is [Connection.Status]. The window may be in the process of being removed.
• 窗口连接已满：Waiting because the [targetType] window’s input channel is full. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度].
• 按键事件，输出队列或事件等待队列不为空：Waiting to send key event because the [targetType] window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度].
• 非按键事件，事件等待队列不为空且头事件分发超时500ms：Waiting to send non-key event because the [targetType] window has not finished processing certain input events that were delivered to it over 500ms ago. Wait queue length: [waitQueue长度]. Wait queue head age: [等待时长].

避免ANR

目标

从图中可以看到，打造一个高质量的应用应该以4个方向为目标：快、稳、省、小。

• 快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。
• 稳：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。
• 省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。
• 小：安装包小可以降低用户的安装成本。

卡顿优化

Android性能优化 - 消除卡顿
Android 的屏幕刷新机制

什么是卡顿

iOS 渲染原理解析

垂直同步 Vsync + 双缓冲机制 Double Buffering

解决屏幕撕裂、提高显示效率的一个策略就是使用垂直同步信号 Vsync 与双缓冲机制 Double Buffering。根据苹果的官方文档描述，iOS 设备会始终使用 Vsync + Double Buffering 的策略。

垂直同步信号（vertical synchronisation，Vsync）相当于给帧缓冲器加锁：当电子束完成一帧的扫描，将要从头开始扫描时，就会发出一个垂直同步信号。只有当视频控制器接收到 Vsync 之后，才会将帧缓冲器中的位图更新为下一帧，这样就能保证每次显示的都是同一帧的画面，因而避免了屏幕撕裂。

但是这种情况下，视频控制器在接受到 Vsync 之后，就要将下一帧的位图传入，这意味着整个 CPU+GPU 的渲染流程都要在一瞬间完成，这是明显不现实的。所以双缓冲机制会增加一个新的备用缓冲器（back buffer）。渲染结果会预先保存在 back buffer 中，在接收到 Vsync 信号的时候，视频控制器会将 back buffer 中的内容置换到 frame buffer 中，此时就能保证置换操作几乎在一瞬间完成（实际上是交换了内存地址）。

掉帧 Jank

启用 Vsync 信号以及双缓冲机制之后，能够解决屏幕撕裂的问题，但是会引入新的问题：掉帧。如果在接收到 Vsync 之时 CPU 和 GPU 还没有渲染好新的位图，视频控制器就不会去替换 frame buffer 中的位图。这时屏幕就会重新扫描呈现出上一帧一模一样的画面。相当于两个周期显示了同样的画面，这就是所谓掉帧的情况。

如图所示，A、B 代表两个帧缓冲器，当 B 没有渲染完毕时就接收到了 Vsync 信号，所以屏幕只能再显示相同帧 A，这就发生了第一次的掉帧。

三缓冲 Triple Buffering

事实上上述策略还有优化空间。我们注意到在发生掉帧的时候，CPU 和 GPU 有一段时间处于闲置状态：当 A 的内容正在被扫描显示在屏幕上，而 B 的内容已经被渲染好，此时 CPU 和 GPU 就处于闲置状态。那么如果我们增加一个帧缓冲器，就可以利用这段时间进行下一步的渲染，并将渲染结果暂存于新增的帧缓冲器中。

如图所示，由于增加了新的帧缓冲器，可以一定程度上地利用掉帧的空档期，合理利用 CPU 和 GPU 性能，从而减少掉帧的次数。

屏幕卡顿的本质
手机使用卡顿的直接原因，就是掉帧。前文也说过，屏幕刷新频率必须要足够高才能流畅。对于 iPhone 手机来说，屏幕最大的刷新频率是 60 FPS，一般只要保证 50 FPS 就已经是较好的体验了。但是如果掉帧过多，导致刷新频率过低，就会造成不流畅的使用体验。

这样看来，可以大概总结一下

屏幕卡顿的根本原因：CPU 和 GPU 渲染流水线耗时过长，导致掉帧。
Vsync 与双缓冲的意义：强制同步屏幕刷新，以掉帧为代价解决屏幕撕裂问题。
三缓冲的意义：合理使用 CPU、GPU 渲染性能，减少掉帧次数。

代码检测卡顿

Android UI性能优化 检测应用中的UI卡顿

利用loop()中打印的日志

大家都知道在Android UI线程中有个Looper，在其loop方法中会不断取出Message，调用其绑定的Handler在UI线程进行执行。

大致代码如下：

public static void loop() {
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue;
    // ...
    for (;;) {
        Message msg = queue.next(); // might block
        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        // focus
        msg.target.dispatchMessage(msg);
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
        // ...
        }
        msg.recycleUnchecked();
    }
}

第15行代码，就是有可能发生卡顿的地方，注意这行代码的前后，有两个logging。如果设置了logging，会分别打印出“>>>>> Dispatching to”和“<<<<< Finished to”这样的Log。这样就给我们监视两次Log之间的时间差，来判断是否发生了卡顿。

public final class Looper {
    private Printer mLogging;
    public void setMessageLogging(@Nullable Printer printer) {
        mLogging = printer;
    }
}
public interface Printer {
    void println(String x);
}

所以，我们可以自己实现一个Printer，在通过setMessageLogging()方法传入即可。

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
       Looper.getMainLooper().setMessageLogging(new Printer() {
            private static final String START = ">>>>> Dispatching";
            private static final String END = "<<<<< Finished";
            @Override
            public void println(String x) {
                if (x.startsWith(START)) {
                    LogMonitor.getInstance().startMonitor();
                }
                if (x.startsWith(END)) {
                    LogMonitor.getInstance().removeMonitor();
                }
            }
        });
    }
}

LogMonitor的代码如下：

public class LogMonitor {
    private static final long TIME_BLOCK = 1000L;
    private static LogMonitor sInstance = new LogMonitor();
    private HandlerThread mHandlerThread = new HandlerThread("log");
    private Handler mHandler;
    private LogMonitor() {
        mHandlerThread.start();
        mHandler = new Handler(mHandlerThread.getLooper());
    }
    private static Runnable mRunnable = new Runnable() {
        @Override
        public void run() {
            StringBuilder sb = new StringBuilder();
            StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace();
            for (StackTraceElement s : stackTrace) {
                sb.append(s.toString() + "\n");
            }
            Log.e("TAG", sb.toString());
        }
    };
    public static LogMonitor getInstance() {
        return sInstance;
    }
    public void startMonitor() {
        mHandler.postDelayed(mRunnable, TIME_BLOCK);
    }
    public boolean isMonitor() {
        return mHandler.hasCallbacks(mRunnable);
    }
    public void removeMonitor() {
        mHandler.removeCallbacks(mRunnable);
    }
}

我们假设阀值是1000ms，也就是说超过1000ms的都算卡顿。
当“>>>>> Dispatching to”打印了，我们就发送一个延迟1秒钟的任务，这个任务会打印出造成卡顿的UI线程里的堆栈信息。
如果在1秒钟之内我们检测到了“<<<<< Finished to”打印，就会移除这个延迟1秒的任务。
如果1秒内没有检测到“<<<<< Finished to”打印，

BlockCanary就是基于这个原理实现的。

利用Choreographer

Android性能优化第（十 一）篇---卡顿分析，正确评测流畅度

Choreographer就是一个消息处理器，根据vsync 信号 来计算frame，而计算frame的方式就是处理三种回调，包括事件回调、动画回调、绘制回调。这三种事件在消息输入、加入动画、准备绘图layout 等动作时均会发给Choreographer。

有的时候会看到这样的log，系统帮助我们打印出了跳帧数：

02-07 19:47:04.333 17601-17604/zhangwan.wj.com.choreographertest D/dalvikvm: GC_CONCURRENT freed 143K, 3% free 9105K/9384K, paused 2ms+0ms, total 6ms
02-07 19:47:04.337 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 60 frames!  The application may be doing too much work on its main thread.
02-07 19:47:11.685 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 85 frames!  The application may be doing too much work on its main thread.
02-07 19:47:12.545 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames!  The application may be doing too much work on its main thread.
02-07 19:47:14.893 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames!  The application may be doing too much work on its main thread.
02-07 19:47:23.049 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames!  The application may be doing too much work on its main thread.
02-07 19:47:23.929 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 37 frames!  The application may be doing too much work on its main thread.
02-07 19:47:24.961 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 61 frames!  The application may be doing too much work on its main thread.
02-07 19:47:25.817 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames!  The application may be doing too much work on its main thread.
02-07 19:47:26.433 17601-17601/zhangwan.wj.com.choreographertest I/Choreographer: Skipped 36 frames!  The application may be doing too much work on its main thread.

这个log就出自于Choreographer中

public final class Choreographer {
    void doFrame(long frameTimeNanos, int frame) {
        final long startNanos;
        synchronized (mLock) {
            if (!mFrameScheduled) {
                return; // no work to do
            }
            //当前时间
            startNanos = System.nanoTime();
            //抖动间隔
            final long jitterNanos = startNanos - frameTimeNanos;
            //抖动间隔大于屏幕刷新时间间隔（16ms）
            if (jitterNanos >= mFrameIntervalNanos) {
                final long skippedFrames = jitterNanos / mFrameIntervalNanos;
                //跳过了几帧！，也许当前应用在主线程做了太多的事情。
                if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
                    Log.i(TAG, "Skipped " + skippedFrames + " frames!  "
                            + "The application may be doing too much work on its main thread.");
                }
                //最后一次的屏幕刷是lastFrameOffset之前开始的
                final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
                if (DEBUG) {
                    Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms "
                            + "which is more than the frame interval of "
                            + (mFrameIntervalNanos * 0.000001f) + " ms!  "
                            + "Skipping " + skippedFrames + " frames and setting frame "
                            + "time to " + (lastFrameOffset * 0.000001f) + " ms in the past.");
                }
                //最后一帧的刷新开始时间
                frameTimeNanos = startNanos - lastFrameOffset;
            }
            //由于跳帧可能造成了当前展现的是之前的帧，这样需要等待下一个vsync信号
            if (frameTimeNanos < mLastFrameTimeNanos) {
                if (DEBUG) {
                    Log.d(TAG, "Frame time appears to be going backwards.  May be due to a "
                            + "previously skipped frame.  Waiting for next vsync.");
                }
                scheduleVsyncLocked();
                return;
            }
            //当前画面刷新的状态置false
            mFrameScheduled = false;
            //更新最后一帧的刷新时间
            mLastFrameTimeNanos = frameTimeNanos;
        }
        //按照优先级策略进行画面刷新时间处理
        doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
        doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
        doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
        if (DEBUG) {
            final long endNanos = System.nanoTime();
            Log.d(TAG, "Frame " + frame + ": Finished, took "
                    + (endNanos - startNanos) * 0.000001f + " ms, latency "
                    + (startNanos - frameTimeNanos) * 0.000001f + " ms.");
        }
    }
}

当跳帧数大于设置的SKIPPED_FRAME_WARNING_LIMIT 值时会在当前进程输出这个log。由于 SKIPPED_FRAME_WARNING_LIMIT 的值默认为 30，所以上面的log并不是经常看到。

方法一

如果我们用反射的方法把SKIPPED_FRAME_WARNING_LIMIT的值设置成1，这样可以保证只要有丢帧，就会有上面的log输出来。

static {
    try {
        Field field = Choreographer.class.getDeclaredField("SKIPPED_FRAME_WARNING_LIMIT");
        field.setAccessible(true);
        field.set(Choreographer.class, 1);
    } catch (Throwable e) {
        e.printStackTrace();
    }
}

只要捕获这个log提取出skippedFrames 就可以知道界面是否卡顿。

方法二

上面的方法只能让我们知道丢帧了，却无法知道更详细定位问题的信息了。
在Choreographer中有个回调接口，FrameCallback。

public interface FrameCallback {  
  //当新的一帧被绘制的时候被调用。  
   public void doFrame(long frameTimeNanos);
}

public class BlockDetectByChoreographer {
    public static void start() {
        Choreographer.getInstance()
            .postFrameCallback(new Choreographer.FrameCallback() {
                @Override
                public void doFrame(long l) {
                    if (LogMonitor.getInstance().isMonitor()) {
                        LogMonitor.getInstance().removeMonitor();                    
                    } 
                    LogMonitor.getInstance().startMonitor();
                    Choreographer.getInstance().postFrameCallback(this);
                }
        });
    }
}

第一次的时候开始检测，如果大于阈值则输出相关堆栈信息，否则则移除。

方法三

Cockroach原理

卡顿的原因

Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：

• UI 绘制
  
  • 绘制
  • 刷新
• 应用启动
  
  • 冷启动
  • 热启动
• 页面跳转
  
  • 页面间切换
  • 前后台切换
• 响应
  
  • 按键
  • 系统事件
  • 滑动

这4类卡顿场景的根本原因可以分为两种：

• 界面绘制。主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
• 数据处理。导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。

优化建议

布局优化

我们知道一个页面的测量布局都是通过递归来完成的，所以多叉树遍历的时间与树的高度h有关。
那布局优化有哪些方法呢，主要通过减少层级、减少测量和绘制时间、提高复用性三个方面入手。

• 减少层级。合理使用 RelativeLayout 和 LinerLayout，合理使用Merge。
• 提高显示速度。使用 ViewStub，它是一个看不见的、不占布局位置、占用资源非常小的视图对象。
• 布局复用。可以通过 标签来提高复用。
• 尽可能少用wrap_content。wrap_content 会增加布局 measure 时计算成本，在已知宽高为固定值时，不用wrap_content 。
• 删除控件中无用的属性。

避免过度绘制

过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。

如何避免过度绘制呢，如下：

• 布局上的优化。移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片
• 自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

启动优化

通过对启动速度的监控，发现影响启动速度的问题所在，优化启动逻辑，提高应用的启动速度。启动主要完成三件事：UI 布局、绘制和数据准备。因此启动速度优化就是需要优化这三个过程：

• UI 布局。应用一般都有闪屏页，优化闪屏页的 UI 布局，可以通过 Profile GPU Rendering 检测丢帧情况。
• 启动加载逻辑优化。可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。
• 数据准备。数据初始化分析，加载数据可以考虑用线程初始化等策略。

合理的刷新机制

在应用开发过程中，因为数据的变化，需要刷新页面来展示新的数据，但频繁刷新会增加资源开销，并且可能导致卡顿发生，因此，需要一个合理的刷新机制来提高整体的 UI 流畅度。合理的刷新需要注意以下几点：

• 尽量减少刷新次数。
• 尽量避免后台有高的 CPU 线程运行。
• 缩小刷新区域。

工具使用

Profile GPU Rendering

在手机开发者模式下，有一个卡顿检测工具叫做：Profile GPU Rendering（GPU呈现模式分析）

条形图说明

• 水平方向的一根绿线代表16ms。
• 每条都代表一帧画面所有工作内容
• 每条中不同的颜色代表不同的工作内容

Android Profiler

shallow size & retained size

Shallow Size和Retained Size。

• shallow size: 表示自身对象占用的大小。
• retained size: 自身对象+引用对象的retained大小。

先借用一张图，这张图更能清楚的表示他们之间的计算关系:

B的shallow size = B;
B的retained size = B shallow size + C retained size + D retained size;

在举例之前，首先要了解JAVA对象在堆中的存储，我们以32位JVM虚拟机为例:
JAVA对象在堆中共有3个部分组成:

• 对象头
  对象头又包含两部分数据；

  • 运行时数据。 32位JVM为32位即4byte.64位为8byte.
  • 类型指针。

• 实例数据
  即存放实例变量的数据，变量类型包括两种 基本类型变量和引用变量。
  基本类型变量所占据的字节大小就不说了，引用变量我们存放的是指针。

• 填充数据
  对象存储空间为8byte的整数倍，如果对象头+实例数据不足8byte的整数倍，则进行填充。

说到引用类型大小，
32位虚拟机下引用占据4byte.
64位虚拟机下如果不开启指针压缩，则引用占据8byte。

下面我们根据例子进行说明:

public class TestObjSize {
    private int a = 1;
    private boolean b = true;
    private TestObjSize testObjSize;
    public static void main(String[] args) {
        Object object = new Object();
        TestObjSize test = new TestObjSize();//这个new出来的对象记为obj1
        test.testObjSize = new TestObjSize();//这个new出来的对象记为obj2
        System.out.println(object.hashCode());
        System.out.println(test.hashCode());
        try {
            Thread.sleep(3000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

我们先分析下TestObjSize的shallow size：

因为shallow size与实例变量是否有引用无关，所以：

shallow size = 4byte(对象头) + 4byte(类型指针) + 4byte(int a) + 1byte(boolean b) + 4byte(TestObjSize引用) = 17;

而17不是8的整数倍，所以会有7个byte的填充数据，最终TestObjSize类型的实例对象的 shallow size = 24;

根据例子，我们看到obj2对象的testObjSize = null，所以：

obj2的retained size = obj2的shallow size = 24;

而obj1对象的testObjSize为obj2，所以：

obj1的retained size = obj1的shallow size + obj2的retained size = 48;

最后附上heapdump！

其他

内存优化

减少对象的内存占用

• 压缩
  
  • 用更小的表示 文件路径 -》 md5
  • 轻量级的数据结构
    使用SparseArray
  • Bitmap的处理
    使用inSampleSize：缩放比例，
    解码格式 使用rgb565
  • 对象复用。减少对象的重复创建，从而减少内存的分配与回收。
    File与File的父亲，路径可以减少 path = 父亲.path + 自己
  • 对象池。
    Message池
    尽量使用线程池

内存抖动

• StringBuilder
• 尽量避免在循环体内创建对象，应该把对象创建移到循环体外。
• 注意自定义View的onDraw()方法会被频繁调用，所以在这里面不应该频繁的创建对象。
• 当需要大量使用Bitmap的时候，试着把它们缓存在数组中实现复用。
• 对于能够复用的对象，同理可以使用对象池将它们缓存起来。

延迟加载

• 类似于ViewStub

避免内存泄漏。

• 集合类
• Static关键字修饰的成员变量
• 非静态内部类 / 匿名类 AsyncTask Activity
• 资源对象使用后未关闭 例如handlerThread
• LeakCanary [kə'neri]

布局优化

选择耗时少的布局 FrameLayout 》 LinearLayout 》 RelatveLayout
减少布局层级 merge
提高布局复用性 include
减少测量绘制时间 viewstub onDraw里面不要进行初始化操作
hierarchy ['haɪə.rɑrki]

绘制优化

onDraw里面不要初始化对象
避免onDraw复杂计算 执行大量的计算 职责分离 计算放到其他函数
避免过渡绘制 clip方法