maniuT的博客

移动 App 特别关注投放转化率指标，而 App 包体积是影响用户新增的重要因素，而 App 的包体积又是影响投放转化率的重要因素。Google 2016 年公布的研究报告显示，包体积每上升 6MB 就会带来下载转化率降低 1%，当包体积增大到 100MB 时就会有断崖式的下跌。对于应用商店，普遍有一个流量自动下载的最大阈值，如应用宝，下载的app超过100M，用流量下载时，会弹窗提示用户是否继续下载，这对下载转化率影响是比较大的。

除了速度及流畅性，内存方向的优化外，还有其他方向的优化，如包体积，稳定性，功耗等，在大型 APP 上都要基于管控业务对资源的使用；度量业务对资源的消耗；让业务在资源紧张时做出更优的策略这三个方向去进行优化，这里我就不再一一展开讲了。当然我这里讲的优化思路并不是大型 app 做性能优化的全部，我讲的只是在做大型 app 的性能时相比于中小型 app 需要额外做的，并且也是效果最好的优化，这些方案在中小型 app 上可能并不需要。

这一篇将从零开始，一步步解决如下这些问题：如何播放单个视频？如何将播放器模块化？如何实现视频流？如何优化视频播放内存？如何优化视频流播放体验？

内存泄漏是指 Android 进程中，某些对象已经不再使用，但被一些生命周期更长的对象引用，导致其占用的内存资源无法被GC回收，内存占用不断增加的一种现象；方法，可以看到这个本地方法把我们的 Activity 传进去了，后续处理不得而知，但基于上面的内存分析我们基本可以断定，正是由于这个方法，Activity 的引用被 Native 的长生命周期对象持有，导致 Activity 出现内存泄漏。但有两个疑问，一是这个内部类是写在方法里的，方法结束时，不会把方法栈中的内部类引用清除掉吗？

在日常开发APP的过程中，难免需要使用第二方库和第三方库来帮助开发者快速实现一些功能，提高开发效率。

当我们在应用程序中启动一个线程的时候，也是有可能发生OOM错误的。当我们看到以下log的时候，就说明系统分配线程栈失败了。这种情况可能是两种原因导致的。第一个就是系统的内存不足的时候，我们去启动一个线程。第二种就是进程内运行的线程总数超过了系统的限制。如果是内存不足的情况，需按照堆内存治理的方式来进行解决，检查应用内存泄漏问题并优化，此情况不作为本次讨论的重点。本次主要讨论进程内运行的线程总数超过了系统的限制所导致的情况。出现此情况时，我们就需要通过控制并发的线程总数来解决这个问题。

内存泄漏是指 Android 进程中，某些对象已经不再使用，但被一些生命周期更长的对象引用，导致其占用的内存资源无法被GC回收，内存占用不断增加的一种现象；方法，可以看到这个本地方法把我们的 Activity 传进去了，后续处理不得而知，但基于上面的内存分析我们基本可以断定，正是由于这个方法，Activity 的引用被 Native 的长生命周期对象持有，导致 Activity 出现内存泄漏。但有两个疑问，一是这个内部类是写在方法里的，方法结束时，不会把方法栈中的内部类引用清除掉吗？

IdleHandlerLagTracer的实现逻辑还是很简单的，它通过hook的方法替换了主线程消息队列的IdleHandlers集合，从而拦截到了IdleHandler的添加和移除逻辑，在拦截到添加IdleHandler的操作时，为原来的IdleHandler做一层代理，从来可以在queueIdle方法执行时做超时监听逻辑，超时未执行完成则收集信息上报，从而发现IdleHandler导致的卡顿问题。

不同于LeakCanary，在Matrix中，主要是通过Resource Canary来监控内存泄漏问题的，且监听的泄漏对象只支持Activity，官方说明如下：结合分析LeakCanary的经验可知，要实现Activity内存泄漏监听，总体上应该要实现两大功能：从 可知，我们可以通过Application.registerActivityLifecycleCallbacks来实现Activity生命周期监控，那么Matrix中又是怎么实现的呢？在Matrix中Resource Canary的实现类是Res

……

dumpsys这个指令很有用，除了可“dumpsys meminfo+包名”以抓取内存，还可以“dumpsys package +包名”查看包信息（此前有看到其他同事使用这个指令查看应用是否有system flag来确定是否是因为没有system标识而被冻结导致的ANR），“dumpsys gfxinfo +包名”查看显示渲染信息进而查看卡顿情况。■ meminfo 内存■ gfxinfo 帧率■ display 显示■ power 电源■ battery 电池。

首先，我们要先明白，什么叫「冷启动」。Android官方对启动的定义，可以参考文档：https://developer.android.com/topic/performance/vitals/launch-time，我们可以在Logcat中，通过Displayed的flitter筛出启动时间。例如：那么阿里集团是如何定义Android应用启动的呢？系统初始化应用初始化首屏展示启动完成（可交互）本文讲重点讲述「应用初始化」和「首屏展示」两个阶段的优化。

我们知道，自定义View的时候有时会重写onDraw方法，但是Android系统是无法检测onDraw里面具体会执行什么操作，从而系统无法为我们做一些优化。这样对编程人员要求就高了，如果View有大量重叠的地方就会造成CPU、GPU资源的浪费，此时我们可以使用canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。下面我们通过谷歌提供的一个小的Demo进一步说明OverDraw的使用。

app卡帧一直是性能优化的一个重要方面，虽然现在手机硬件性能越来越高，明显的卡帧现象越来越少，但是了解卡帧相关的知识还是非常有必要的。本文分两部分从app卡帧的原理出发，讨论屏幕刷新机制，handler消息机制，为什么在主线程执行耗时任务会造成卡帧。另一部分讨论BlockCanary的原理，它是如何检测方法耗时的。大家小时候应该都玩过一个玩具，5毛一本的连环画小书，每一页绘制一幅画，用手指快速翻动会产生一个动画效果。

装模作样的总结一下。线程池调度 + 进阻塞队列单任务数据过大 + 处理任务过慢线程池调度任务是啥场景？有个Queue，来了任务，先入队有个ThreadPool，空闲了，从Queue取任务。那么，当入队的数据结构占内存太大，且ThreadPool处理速度小于 入队速度呢？就会造成Queue中数据越来越多，直到OOM。扫一扫完美的满足了上面条件入队频率足够高入队对象足够大处理速度足够慢。在这个例子中，做的不足的地方：追求并发未考虑机器性能大对象处理不够谨慎。

在Android系统中，我们知道UI线程负责我们所有视图的布局，渲染工作，UI在更新期间，如果UI线程的执行时间超过16ms，则会产生丢帧的现象，而大量的丢帧就会造成卡顿，影响用户体验。

为什么要写这个记录，都是一个非常简单的场景及使用方式，但是从发现这个问题到思考怎么解决却是一次算法学习的实际应用。我们在开发中，不会经常使用算法，但是像这种问题，我们可以用算法的角度去分析优化，这大概就是算法学习的意义。

App程序中己动态分配的堆内存，由于某种原因，App程序未释放或无法释放，会造成系统（手机）内存的浪费。长生命周期对象持有短生命周期对象强引用，从而导致短生命周期对象无法被回收。我们注意这两个关键词堆内存、强引用。上面的内存相关知识也是自己学习的一种总结，有错误的可以留言指正。内存优化，需要对下面的知识有一定的了解。Java内存分配模型Java的四大引用及其使用场景内存检测工具及常用命令GC Root的定义。

1.减少布局层次布局层次越深，绘制所需的时间就越长，因此应该尽可能减少布局层次。可以通过使用 ConstraintLayout 或者自定义 View 来减少布局层次。2.使用合适的布局容器应该选择最适合当前布局需求的布局容器，避免使用过于复杂的布局容器，比如 LinearLayout 嵌套多层、RelativeLayout 的多重嵌套等。3.使用 ViewStub 来延迟加载视图如果布局中包含复杂的视图，可以考虑使用 ViewStub 来延迟加载这些视图，以减少布局的加载时间。

从上面的日志中，我们看到造成ANR的原因是Input dispatching timed out，那么除此之外，还有什么其他的错误。

针对Android UI不流畅的问题，Google提出了Project Butter对Android的显示系统进行了重构。这次重构的三个关键点VSynch 垂直同步Triple Buffer 三重缓存Choreographer 编舞者这篇文章我们主要聊一聊Choregrapher，后续的我们写关于其他。

应用的速度优化是我们使用最频繁，也是应用最重要的优化之一，它包括启动速度优化，页面打开速度优化，功能或业务执行速度优化等等，能够直接提升应用的用户体验。因此，只要是 Android 开发者，肯定或多或少有过速度相关的优化经验。但是大部分人谈到速度优化，只能想到一些零碎的优化点，比如使用多线程、预加载等等。想要回答好这几个问题，我们就需要了解影响和决定应用速度的底层原理及本质。那从底层来看，才是决定应用速度最本质的因素。CPU 和缓存都属于硬件层，任务调度机制则属于操作系统层。

这是以上关于我在工作中遇到的性能问题的及处理的一些总结，性能优化设计的方方面面实在是太多太多，本文不可能将全部的性能问题全部总结的清清楚楚，或许还多多少少存在一些纰漏之处，有不对的地方欢迎指出补充。

本文主要介绍了得物APP资源优化做了的一些动作，其中对资源优化插件的工作模式进行了重点介绍。当然，对于资源依旧有不少手段可以完善，比如提供高效简单的 9 图下发方案，包体积平台增加图片相似度检测能力、把一些次级的资源通过插件包下发都是之后可以尝试的地方。

……

世上没有最好的架构，只有最适合自己的。UI往往是变动最频繁的业务，所以了解各个组件的优缺点，根据业务逻辑去选用最适合的，才是高效开发的捷径。不管怎样，都是有无数坑点的，趋利避害才是UI的归宿。UI最好的经验就是知道各个组件有什么坑点，如何避开。不然随便一个坑，就够开发加好一会儿班了。

当我们在应用程序中启动一个线程的时候，也是有可能发生OOM错误的。当我们看到以下log的时候，就说明系统分配线程栈失败了。这种情况可能是两种原因导致的。第一个就是系统的内存不足的时候，我们去启动一个线程。第二种就是进程内运行的线程总数超过了系统的限制。如果是内存不足的情况，需按照堆内存治理的方式来进行解决，检查应用内存泄漏问题并优化，此情况不作为本次讨论的重点。本次主要讨论进程内运行的线程总数超过了系统的限制所导致的情况。出现此情况时，我们就需要通过控制并发的线程总数来解决这个问题。

内存泄漏指的是应用程序中存在一些对象或者资源无法被垃圾回收器回收，导致内存占用不断增加，最终导致设备性能下降。

启动时间是App使用者的第一体验，很多大厂都通过A/B实验论证启动速度的优化可以带来用户留存的显著收益，尤其是体量大的用户，启动时间缩短一点，留存增长一点，那就带来了非常大的收益。因此，启动性能优化一直是各大厂体验技术团队的重点投入。

关于性能优化，可能我们的第一反应是这是高手做的事情，一直以来我也是这样认为的。但在最近一段时间，在公司项目上做了一些框架的性能优化，让我初步掀开了性能优化的面纱，也对他有了进一步的认识。所以这篇文章结合我做的一些优化，做一些相关经验的分享。性能优化一般情况下分为两类：时间优化与空间优化。前者是降低处理器处理时间，后者是降低内存使用量。归根到底都是降低对硬件资源的使用，来提高程序的性能，从而提高程序运行流畅性、降低功耗等。今天也主要从这两个方面来展开聊一聊。

要监控应用界面是否发生卡顿，需要先了解一下Android应用主线程的渲染机制：Android 系统提供一个稳定的帧率输出机制，让软件层和硬件层可以以共同的频率一起工作,使我们可以享受稳定帧率的画面。大部分手机的屏幕都是60Hz的刷新率，系统为了配合屏幕的刷新频率，每过16.6ms就会发出Vsync信号来通知应用进行绘制。如果每个Vsync周期应用都能完成渲染逻辑，那么应用的FPS就是60，给用户的感觉就是非常流畅。在应用层，实现上述机制的关键类就是。

本文，我们分析了 Android 性能优化的五个误区，但某些情况下数据的结果还并不清晰，我们需要做的就是在优化和修改代码之前尽量做好性能测试。目前，已经有很多工具可以帮助我们分析评估如何优化应用了，如 Android Studio 中的 profilers，它也提供了电池和网络的监测功能。也可以用一些工具做更深入的探究，如 Perfetto 和 Systrace，这些工具会提供更加详细的功能，例如在应用启动或执行过程中发生的具体情况。

稳定（内存溢出、崩溃） 流畅（卡顿） 耗损（耗电、流量） 安装包（APK瘦身） 影响稳定性的原因很多，比如对内存使用不够合理、代码异常、场景考虑不周全、代码逻辑不合理等，都会让应用的稳定性出现问题。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序彻底崩溃。所以做好Crash全局监控，处理闪退同时把崩溃信息、异常信息收集记录起来，以便后续分析;合理使用主线程处理业务，不要在主线程中做耗时操作，防止ANR程序无响应发生。

内存，是Android应用的生命线，一旦在内存上出现问题，轻者内存泄漏，重者直接crash，因此一个应用保持健壮，内存这块的工作是持久战，而且从写代码这块就需要注意合理性，所以想要了解内存优化如何去做，要先从基础知识开始。

通过本文能了解一下内容应用进程起来之后ART(Android Runtime)第一站就是ActivityThread，代码层面上就是ActivityThread的main()方法，是不是很熟悉，爷青回啊，这不就是java的main方法嘛该方法是一个静态方法，里面做了重要的两件事mAppThreadmAppThread上一段分析时已经找打了答案，应用进程被拉起来之后，在创建。

纵观各厂在卡顿和ANR 方面做的探索和方案，我们可以看出，思路上都有重合，在细节方面做了很多针对自身业务和实际情况做的针对性的优化和个性化的开发。总的来说逃不出以下几个步骤ANR的感知上：业界主流的方案就是监听SIGQUIT 信号+误报过滤。腾讯技术团队，提到的OV 厂商对ANR的处理并不是常规的处理，而是做闪退处理，所以要以check主线程正在处理的 Message，延误时间作为辅助防止漏报。

在Android性能监控和优化领域，一个会影响App性能表现的因素与Handler Message Looper机制有关。当Looper里面的Message处理不及时、或数量太多占用过多处理时间时，可能会出现卡顿感，并且不容易定位到卡顿的Message和慢方法。Android本身提供了LooperStats机制来统计和监测Message的处理，并且可以通过LooperStatsService来统计和记录，方便调试和分析。

作为多年的 Android 开发，写了不少应用，但是一个App到底是怎么启动起来的？你要说桌面点一下就启动了，那也对。但是它的启动过程呢？带着这样的疑问，咱们来一步步学习。

在Android开发过程中，当一个对象已经不需要再使用了，本该被回收时，而另个正在使用的对象持有它引用从而导致它不能被回收，这就导致本该被回收的对象不能被回收而停留在堆内存中，内存泄漏就产生了。

View整体布局是通过深度优先的方式来进行组织的，整体形似一颗树，所以优化布局层级主要通过三个方向来实施：