qq_36428821的博客

GC Root在 JVM/ART 里，垃圾回收的时候会先找一批“根对象”（GC Roots）。这些根对象是永远不会被回收的静态变量 (static field)：因为它们属于类，被类加载器持有，只要类没卸载，就一直活着。线程栈上的局部变量。JNI 全局引用。GC 算法会从 GC Roots 出发，沿着对象引用一路“走下去”，所有能走到的对象都是存活的，不能走到的才会被回收。

→ 被 WeakReference 监控。GC 后没回收→ 怀疑泄漏。Dump HPROF→ 分析对象关系。Shark 找到静态引用链→ 报告给你。

LeakCanary 原理可以概括为：用弱引用监控销毁后的对象。定时 GC 看对象是否被回收。没回收就dump 内存快照。用Shark 分析内存快照，找到引用链，告诉你谁在持有。

LeakCanary 官方文档明确推荐目前在 Debug 构建中使用的版本是：该版本于发布，包含多个修复和改进，例如 ProGuard mapping 支持及常见 AOSP 框架泄漏的自动忽略等 (

很多时候泄漏是因为某个全局对象忘了解除引用。

我们都知道，现在的App已经由增量阶段转化为存量阶段。所以做好一款App是比做出一款App更重要的事情，这也是我写性能优化这个专栏的初衷。我先大概讲一下性能优化我准备讲那几块，大家都知道性能优化的方向有很多，不可能都去讲解。删繁就简就显得尤为重要，大家不管是看源码还是学技术，学到核心才是最关键的，这也是我最近一段时间才逐渐领悟到的。文章更新的顺序也会按这个顺序来，我个人感觉性能优化掌握这几块通用的基本差不太多，如果后面有从事性能优化专项工作的同学可以在这个基础上深入。

我记得以前公司做过一个AB测试，包体积越小，客户下载意愿越高，其实这个也很好理解。那么如何去优化包体积呢？1.图片使用webp格式2.启用资源缩减buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt')

小技巧：Android Studio可以通过日志的方式查看应用冷启动和热启动的时间。在Logcat里面搜索display，verbose下，可以看到如下的打印：ActivityTaskManager: Displayed com.example.myapplication/.MainActivity: +1s95ms这里是一个冷启动时间。应用启动后按back回退到桌面，然后在点击icon进来：ActivityTaskManager: Displayed com.example.m

理想情况下，60 FPS 以上就不会卡顿，就是 1 秒内要有 60 帧，所以每一帧要在 16ms 内绘制完成。如果一个页面无法在 16ms 内完成渲染，就会感到卡顿。过度绘制在“开发者选项”中打开“调试 GPU 过度绘制”（对未默认开启硬件加速的界面需要同时打开“强制进行 GPU 渲染”）。无色：没有过度绘制，每个像素绘制了 1 次。 蓝色：每个像素多绘制了 1 次。大片的蓝色可以接受，如果整个窗口是蓝色的，可以尝试优化减少一次 绘制。 绿色：每个像素多绘制了 2 次。 淡红：每个像素多绘

Android性能优化中最为关键的估计要算内存优化，内存优化最多的估计就是Bitmap内存问题了。下面我们研究一下Bitmap内存模型，以便于后面更加轻松深刻的进行大图片的内存优化。1.如何获取Bitmap所占用的内存？bitmap.getWidth()*bitmap*getHeight()*1个像素点所占内存那么如何计算一个像素点的内存呢？1个像素一般是ARGB，就是4个byte。width*height*4/1024/1024就是内存M数。...

点击 Profiler 的cpu，选择你要调试的设备，然后点击 record，然后点击 stop，最后出现的效果如下：很明显，可以很清晰的看到方法执行的层级以及耗时。Self:代码本身耗时Children:子方法耗时...

应用启动的分类：冷启动时间：冷启动表示用户首次打开应用，这时进程还没创建，包含了Application创建的过程。冷启动时间指从第一次用户点击Launcher中的应用图标开始，到首页内容全部展示出来的时间。 热启动时间：热启动表示用户在首页按了返回，首页Activity已经Destroy，不过Application仍在内存中存在，对应的进程并没有被杀掉，不包含Application创建过程。热启动时间指在Application仍然存在的情况下，从用户点击桌面图标，到首页内容全部展示出来的时间。我们能