1

在Android中，线程是程序执行的最小单元。每个应用都有一个主线程（也称为UI线程），负责处理用户界面的事件和更新UI。同时，应用可以创建额外的线程来执行后台任务，以避免阻塞主线程。进程是程序运行的一个实例。一个应用可能包含多个进程，每个进程有自己的独立内存空间，但它们可以共享应用的资源。在Android中，每个应用都运行在自己的进程中。// 一些需要同步的代码块关键字用于实现线程同步，确保多个线程不会同时执行某个方法或代码块，从而避免数据竞争和不一致性。

相信伙伴们在日常的开发中，一定对图片加载有所涉猎，而且对于图片加载现有的第三方库也很多，例如Glide、coil等，使用这些三方库我们好像就没有啥担忧的，他们内部的内存管理和缓存策略做的很好，但是一旦在某些场景中无法使用图片加载库，或者项目中没有使用图片加载库而且重构难度大的情况下，对于Bitmap内存的管理就显得尤为重要了，一旦使用出现问题，那么OOM是常有的事。

玩儿东西还是要弄明白这个东西的成立基础是什么，或者负面因素有哪些。需要有足够的数据支持冷热分离和重排序，否则这些优化可能不会带来明显的性能提升，甚至可能会造成额外的开销。冷热分离和重排序的实现需要考虑数据的生命周期，避免数据被错误地缓存或销毁。冷热分离和重排序可能会导致数据的展示顺序不符合用户的期望，需要进行适当的处理，以保证数据的展示效果。在实现时需要考虑多线程安全问题，避免因并发访问导致的数据错乱或其他异常情况。

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

但是 CPU 和 GPU 写数据是不可控的，所以会出现 buffer 里有些数据根本没显示出来就被重写了，即 buffer 里的数据可能是来自不同的帧，当屏幕刷新时，此时它并不知道 buffer 的状态，因此从 buffer 抓取的帧并不是完整的一帧画面，即出现画面撕裂。屏幕刷新的机制大概就是： CPU 执行应用层的测量，布局和绘制等操作，完成后将数据提交给 GPU，GPU 进一步处理数据，并将数据缓存起来，屏幕由一个个像素点组成，以固定的频率（16.6ms）从缓冲区中取出数据来填充像素点。

除了线程方法栈的dump，其他的方式都不适合线上分析。不要以为学会了方法栈的dump和虚拟机堆内存的dump就能够彻底解决这些问题，他们只是帮你发现这些问题，要彻底解决这些问题还需要很多其他方面的知识。

帧率是指在一秒内，应用程序能够渲染的图像帧数量。通常以FPS（Frames Per Second）表示。例如，一个应用在每秒内渲染了60帧，那么它的帧率就是60 FPS。帧率越高，用户体验越流畅，但帧率的稳定性也同样重要。

在具体的代码实现中已经做了很多优化工作，不会影响APP正常使用，也不会导致耗电增多或导致系统卡顿之类的问题，完全可以放心使用。为了防止我们的广告服务被系统杀死，可以设置我们的APP为系统白名单或者允许后台运行等一系列保活方法让它多活一会吧。为了帮助到大家更好的全面清晰的掌握好启动优化，准备了性能优化相关的核心笔记（包含了启动优化、内存优化、网络优化……

通过 http(s) 的连接复用机制，我们可以考虑使用预连接来优化 APP 中某些场景的网络请求速度，这需要我们根据实际业务场景以及服务器压力来判断是否进行预连接。另外我们可以适当调大连接池的容量和超时时间，由于连接是双向的，即使客户端把 Connection 一直保留，服务端也会根据实际连接数量和时长来自动关闭连接的，所以调大连接池一般不会增大服务器压力。

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

文章主要讲解了关于R8编译器在整个编译过程中对apk代码以及资源的一些优化操作，主要集中在代码缩减，资源缩减，代码混淆，代码优化这几部分，其中对代码混淆做了一个比较全面的分析。

假设我们有一个应用，它的功能是在一个TextView上显示一个计数器，每隔一秒钟就更新一次计数器的值。为了实现这个功能，我们使用了一个Handler来发送空消息，并在接收到消息时更新计数器的值，并再次发送空消息，形成一个循环。同时，为了模拟一些复杂的业务逻辑，我们在循环中创建了大量的数组对象。这段代码看起来没有什么问题，但是当我们运行这个应用时，我们会发现应用的内存使用情况非常不稳定，内存曲线呈现出明显的锯齿状，GC事件也非常频繁。这就是典型的内存抖动的现象。

内存抖动是指内存频繁分配和回收导致的不稳定现象。在Java中，内存分配和回收是由垃圾回收器（GC）来管理的。GC会定期扫描内存中的对象，判断哪些对象是无用的，然后释放它们占用的空间。这个过程称为垃圾回收（GC）。GC是一种有益的机制，它可以避免内存泄漏，提高内存利用率。但是，如果GC过于频繁或者耗时过长，就会影响应用的运行效率。当GC发生时，应用的线程会被暂停，等待GC完成后才能继续执行。这个过程称为GC停顿（GC Pause）。

安卓内存优化是一个很重要的话题，有很多方面可以考虑，比如避免内存泄漏、减少内存抖动、优化图片加载、使用缓存和对象池等。下面我举一些代码案例，分别展示不合适的写法和高性能的写法。欢迎评论区留言指正和补充。

IOCanaryPlugin通过hook底层io方法open、read、write、close来实现对io操作的拦截，于是所有的io操作都会被监控到，这样就可以在每一个io操作的过程中记录操作的信息，并分析io操作是否超过设定阈值，如满足条件则进行上报。

在我们App开发过程中，网络是必不可少的，几乎很难想到有哪些app是不需要网络传输的，所以网络问题一般都是线下难以复现，一旦到了用户手里就会碰到很多疑难杂症，所以对于网络的监控是必不可少的，针对用户常见的问题，我们在实际的项目中也需要添加优化策略。

作为一个Android程序员，性能优化是无法避开的事情，并且性能优化也是Android中最有挑战的工作之一，性能问题和Bug不同，后者的分析和解决思路更清晰，很多时候从应用日志即可直接找到问题根源，而性能问题，其排查思路更为复杂一些。对App进行性能优化，**是一个系统性的工程，对工程师的技术广度和技术深度都有所要求。**一个简单的应用，它不仅包含了应用代码本身，还和虚拟机、存储、网络等紧密相关，线上应用一旦出现了性能问题，需要我们从多方面去考虑。

关于卡顿这件事已经是老生常谈了，卡顿对于用户来说是敏感的，容易被用户直接感受到的。那么究其原因，卡顿该如何定义，对于卡顿的发生该如何排查问题，当线上用户卡顿时，在线下无法复现时，又如何获取信息来定位问题?一般来说， 12FPS (每秒显示帧数)为最低标准，低于 12fps 画面基本上就不是连续的，而当大于 60FPS 时，人眼很难区分出来明显的变化，所以 60FPS 是衡量一个界面流畅程度的重要指标。但 FPS 低并不意味着卡顿发生，而卡顿发生 FPS 一定不高，而是以一段时间内的掉帧程度来衡量的。

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

……

Android 系统对每个app都会有一个最大的内存限制，如果超出这个限制，就会抛出 OOM，也就是Out Of Memory。本质上是抛出的一个异常，一般是在内存超出限制之后抛出的。最为常见的 OOM 就是内存泄露(大量的对象无法被释放)导致的 OOM，或者说是需要的内存大小大于可分配的内存大小，例如加载一张非常大的图片，就可能出现 OOM。

Android中一个window对应一个Canvas，window下的所有视图(View/ViewGroup)使用的都是同一个canvas，视图树的父节点在调用子视图的View.draw之前，会对Canvas进行裁切，裁切的区域就是View在屏幕中所占的矩形区域，这也就是为什么超过View边界的内容会被裁切掉的原因。既然过渡绘制值一个像素点被绘制多次，我们只要保证图片或者背景颜色不要叠加在一起即可。正确的方式应该是尽量减少带背景的View产生重叠区域。如果重叠，使用canvas的clipRect进行裁切。

了解计算执行任务时间了解AOP面向切面编程知识了解AsyncTask的核心线程数及运用学习了初始化数据时异步优化方案。

大家都知道使用LeakCanary可以监控项目中存在的，那么LeakCanary是怎么实现的呢？LeakCanary通过检测程序中对象的引用关系，收集应该被回收的对象并标记，随后等待GC后，检查该对象是否按预期回收即可，目前LeakCanary支持Service，Activity，Fragment，ViewModel以及View的泄漏检测，接下来我们一起来看下Service的关联部分。首先，我们考虑如果要认定一个Service对象可以被回收，前提条件是什么？

通过 http(s) 的连接复用机制，我们可以考虑使用预连接来优化 APP 中某些场景的网络请求速度，这需要我们根据实际业务场景以及服务器压力来判断是否进行预连接。另外我们可以适当调大连接池的容量和超时时间，由于连接是双向的，即使客户端把 Connection 一直保留，服务端也会根据实际连接数量和时长来自动关闭连接的，所以调大连接池一般不会增大服务器压力。

一个像素的所占用的字节数计算的，宽高没变，在内存中占用的大小自然不会变，质量压缩的原理是通过改变图片的位深和透明度来减小图片占用的磁盘空间大小，所以不适合作为缩略图，可以用于想保持图片质量的同时减小图片所占用的磁盘空间大小。质量压缩并不会改变图片在内存中的大小，仅仅会减小图片所占用的磁盘空间的大小，因为质量压缩不会改变图片的分辨率，而图片在内存中的大小是根据width。inSampleSize只能设置为2的平方，不是2的平方则最终会减小到最近的2的平方数，如设置7会按4进行压缩，设置15会按8进行压缩。

……

比如用户在看股票，正常60秒刷新一次，可到了60秒，触发了刷新但是刷新处理逻辑耗时较长，导致新的数据在下一个60秒之前的第59秒才回来，用户基本无感知，主要说的是内部耗时的问题，这种情况可以粗略的理解为微观卡顿。首先，我认为卡顿产生的原因主要是某些逻辑处理时间超出了我们的预期阈值，这些耗时操作影响了页面的刷新，当刷新的频率和速度（60帧/s）低于我们的预期时，就会产生我们理解的卡顿。比如用户点击了登录，预期是得到登录成功/失败的反馈，可现在没有页面刷新，实际的刷新耗时超出了预期，这就是直观的卡顿。

启动性能是百度App最核心指标之一。用户希望应用能够及时响应并快速加载，启动时间过长的应用不能满足这个期望，并且可能会令用户失望，这种糟糕的体验可能会导致用户在应用商店针对您的应用给出很低的评分，甚至完全抛弃您的应用。启动性能的优化成为了体验优化中最关键的一环，百度App在此方向持续投入，不断优化，提升用户体验。

上述 方案代码量其实不多，因此我 在github上建了一个工程用来模拟并解决QueueWork任务阻塞造成的ANR问题， 可供参考 https://github.com/Knight-ZXW/SpWaitKiller . 在上线时，应当对使用到SP的业务进行相应的测试，比如如果存在跨进程组件依赖同一个SP文件的情况，由于我们取消了Activity 在Stop时的 SP文件变更的刷盘行为，因此如果跳转到其他进程的组件，而该组件又依赖于跳转前的SP变更的最新配置值，那么可能会出现问题。

如果你已经有 2 - 3 年以上开发经验还不懂的怎么去优化自己的项目，那就有点说不过去了，下面是我自己总结的一套通用级别的 Android 性能优化。如果你正在找工作, 那么你需要一份Android 高级开发面试宝典有做过。比如重复绘制，还有大图长图有过优化。那具体说一说最后也是结合真实场景具体说一个。

内存泄漏是程序界永恒的话题，对于Android开发来说尤为重要，想让你的App表现得更优雅，了解并治理内存泄漏问题势在必行。何为内存泄漏?Android 常见内存泄漏场景Java匿名内部类会导致泄漏吗？Java的Lambda是否会泄漏？Kotlin匿名内部类会导致泄漏吗？Kotlin的Lambda是否会泄漏？Kotlin高阶函数的会泄漏吗？内存泄漏总结将函数类型当做形参或返回值的函数称为高阶函数。高阶函数在Kotlin里无处不在，是Kotlin简洁写法的一大利器。

启动速度优化是 android 开发中的常见需求，除了一些常规的手段之外，也有一些黑科技手段，我们来看一下这些黑科技手段是否有效，以及如何实现本文主要是对Android 性能优化小册相关内容的学习实践，加入了自己的理解与实践内容，感兴趣的同学可以点击查看小册。2在性能优化中除了一些常规手段外，也经常有一些黑科技手段，本文主要介绍了启动优化中的线程优先级设置，核心线程绑定大核，GC 抑制等手段， 讲解了一下这些黑科技手段是否有效，以及具体是怎么实现的，希望对你有所帮助。

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

目前的组件优化到了一个能用的程度了，文中也说了，其实还能进一步优化，比如耗时计算放到新线程，或者改用C++重写，应该还能优化一些，但是懒得去实现了。这一趟优化下来也确实令我学到了不少东西，已经收获满满了，不过学习的脚步不能停下，还有很多细节是需要学习的，一步步来吧。对于复杂UI的优化，希望文中的一些思路能帮到大家，就写到这里好了。

在应用开发中，耗电是我们需要关注的重点。但是，开始进行耗电优化时，我们常常感到无从下手。这篇文章将介绍耗电优化的相关要点，让我们优化时有一个方向。

...

往往对性能优化只停留在“使用过”甚至是“听说过”的阶段，这其中甚至不乏一些工作 5 年以上的 Android 工程师，而对于。由于业务需求，我们常常需要进行性能优化，而优化并不总是对一个单纯环境进行，是面对一个复杂的已投产系统。对于大部分程序员来说，哪怕工作很久经验丰富，但依然会出现面对棘手问题束手无策的状况，大多是因为。，不管你去面试哪家大厂，性能应该是必问项，而且使用范围广，无论如何是避不开的；说白了，知道怎么用是一方面，知道为什么则是更为。，你对性能优化掌握的越深入，意味着你能做的事情越多。

着色器是在 GPU（图形处理单元）上运行的代码。当 Flutter 渲染的 Skia 图形后端首次看到新的绘制命令序列时，它有时会生成和编译一个自定义的 GPU 着色器用于该命令序列。使得该序列和潜在类似的序列能够尽可能快地渲染。然而不幸的是，Skia 着色器生成和编译的过程与帧的工作是依次进行的。编译过程可能需要几百毫秒的时间，而对于 60 帧/秒 (frame-per-second) 的显示来说，一个流畅的帧必须在 16 毫秒内绘制完成。因此，编译过程可能导致数十帧被丢失，使帧数从 60 降到 6。

上面关于 LeakCanary 的问题，不会的话去查一查吧，再深入的话会接触到 Matrix ，关于 Matrix 的记录我也写过，看这里Matrix-TraceCanary 实际使用* 本文重点是在整理，提到的东西不新，但是比较经典。整理这个过程挺好的，过程中会锻炼自己的总结概括能力，仔细审视自己提及到的知识点是否正确，所以你也开始吧。知识体系非常重要，零散接受知识点的话比较被动，所以学习过程中就需要整理自己的知识体系，这样面试的时候就可以从点到面展开了「我假设的。