去年年底做启动优化时，有个比较好玩的 case 给大家分享下，希望大家能从我的分享里 get 到我在做一些问题排查修复时是怎么看上去又low又土又高效的。

在上一篇文章中介绍了可以有效解决WebView多进程崩溃的办法，但隔了两个版本后这个问题竟然死灰复燃，这究竟是怎么回事呢？

在 Android 应用开发过程中，我们会将一些耗时任务放在子线程进行处理，从而避免出现主线程卡顿的情况。

我们这套全新的方案，简洁而不简单，巧妙地实现了无Hack采集，在保证高稳定性和不侵入源码的前提下，优雅地实现了生产环境代码覆盖率的高性能采集，已经过高德地图多版本验证，是一套成熟、稳定且高效的方案。

最近公司要做这个，简单调研了一下，现有的大多数博客也比较旧了，不太合适，总结了这么几个方式吧，一起来学习下。 为什么要清除Android中这些资源呢 是这样的，今天收到的邮件里，有这么一条任务： 资源优化 软件中无用的图片和布局文件,找到并验证是否无用. 这个需要设计一套工具进…

关于Android开发中图片的压缩、上传、列表展示以及大图展示全流程的优化方案，旨在解决图片在各个不同场景中，最快最好的展示给用户

不会卡顿优化？如果你刚开始优化，那别上来就扯 systrace 和 traceview「已废弃」 了，先看看 Android Profiler 吧。 文章读完即可上手内存优化/卡顿优化，避免面试尴尬！

前面讲过，任务调度是影响速度的本质因素之一，这一章我们就来讲讲任务调度的优化。 针对任务调度，我们很自然地就能想到：提高任务的优先级或者减少任务调度的耗时这两条优化方法论。减少调度耗时有不少优化方案，

卡顿对于用户来说是敏感的，容易被用户直接感受到的。那么究其原因，卡顿该如何定义，对于卡顿的发生该如何排查问题，当线上用户卡顿时，在线下无法复现时，又如何获取信息来定位问题？