chuyouyinghe的专栏

日志函数中看似简单的开关控制实则存在性能隐患。即使日志关闭，字符串拼接、对象序列化和格式化操作仍会在调用时执行，产生不必要的内存和CPU开销。通过将日志内容封装在Lambda表达式并用inline标记，可以确保日志构建逻辑只在开关开启时执行。性能测试显示，这种优化在复杂场景下能显著降低资源消耗，避免因日志累积导致的应用卡顿或崩溃。建议开发者在关键路径上优先考虑这种延迟执行的日志方案，在保证调试便利性的同时提升性能表现。

本文详细介绍了 APKTool 的使用方法和技术原理。APKTool 主要应用于逆向工程、调试和修改已编译的 APK 文件。文章首先解释了 APK 文件的反编译过程，包括 APK 的解压、DEX 文件的 smali 转换和资源文件的解码。接着，讨论了 APK 的重新打包过程，包括资源的重新编译、smali 文件的 DEX 转换、APK 的打包和签名。

AVF的安全特性为移动设备提供了强大的保护。通过其分层安全方法、机密性、完整性和可用性的维护，以及Hypervisor和客户机OS的安全特性，AVF确保了移动设备在面对日益复杂的威胁时，能够保持安全和可靠。随着技术的不断进步，我们期待AVF能够继续为移动设备的安全性提供更多的创新和改进。

内存抖动是指频繁的内存分配和回收，导致垃圾回收器频繁运行，从而影响性能。内存溢出是指应用程序尝试分配的内存超过了系统可用的内存。内存泄漏是指应用程序中某些对象不再被使用，但仍然被引用，导致垃圾回收器无法回收它们，从而消耗内存。Android Studio Profiler：内置的性能分析工具，可以监控内存使用情况。LeakCanary：一个开源的内存泄漏检测工具，可以自动检测和报告内存泄漏。将启动页和主页面合并，减少Activity切换的时间。减少不必要的网络请求，使用缓存来存储重复请求的结果。

Java Native Interface（JNI）是一个强大的机制，允许Java代码与其他语言编写的应用程序或库（主要是C和C++）进行交互。这种能力极大地扩展了Java的应用范围，使得可以在Java平台上执行高性能计算或调用系统级API。然而，正确和高效地使用JNI不仅需要对其机制有深入的理解，还需要关注安全性和性能优化。本文将全面介绍JNI的基础知识，并提供实用的最佳实践、性能优化技巧和安全策略。

OOM的问题在Android中也是非常常见了，所以这里单独拎出来说说。OOM产生的条件：待申请的内存大于系统分配给应用的剩余内存。OOM原因大致可以归为以下几类堆内存分配失败堆内存溢出没有足够的连续内存空间创建线程失败（pthread_create (1040KB stack) failed: Try again）FD数量超出限制Native虚拟内存OOM以上简单介绍了一下我们在工程中如何针对各类崩溃信息进行收敛，值得欣喜的是经过几年的努力基本可以将崩溃控制在万一。

Java Native Interface（JNI）是一个强大的机制，允许Java代码与其他语言编写的应用程序或库（主要是C和C++）进行交互。这种能力极大地扩展了Java的应用范围，使得可以在Java平台上执行高性能计算或调用系统级API。然而，正确和高效地使用JNI不仅需要对其机制有深入的理解，还需要关注安全性和性能优化。本文将全面介绍JNI的基础知识，并提供实用的最佳实践、性能优化技巧和安全策略。

目前看来 Android 15 上需要适配的难度不高，毕竟 16K Page Size 应该是明年的事情，而且按照目前情况猜测，更多也支持明年 Google Play 上会开始要求，国内估计还会继续延迟，真正需要在国内启用 16K Page Size 也许会更晚。所以，勇敢的少年，是时候开始吃螃蟹了。Android 15 正式发布到 AOSP ，来了解下新特性和适配需求作者：恋猫de小郭链接：https://juejin.cn/post/7410645914585317403来源：稀土掘金。

当垃圾回收算法是 CC（并发复制）的时候，compactiing_gc 是true，从 compacting 这个词加上过去一些垃圾回收算法八股文的学习，我们可以推测，这个代表的应该是是否移动对象，压缩碎片空间的意思。kGcCauseForNativeAlloc: NativeAllocationGcWatermark 超出的时候调用的，这个涉及到native分配的机制，感兴趣的也可以研究一下。返回了本次gc的类型。分别是不执行gc、回收本次分配的对象、回收ZtgoteSpace之外的对象、完整的回收。

到这里我们基本把主线程锁等待监控的方案思路和关键技术点过了一遍，通过上述方法，我们就能实现我们自己的主线程锁监控。Android主线程锁监控原理和实现。

进程-Process 是程序的一个运行实例。通常会有唯一一个pid与之对应。但pid不是绝对唯一的，当进程死亡后pid会被回收给另外的进程使用。在Android世界里，App开发者很容易认为系统的四大组件就是进程的载体，实际上，它们不能算是完整的进程实例，最多只能算是进程的组成部分。

Android 的 Context 大家肯定是不陌生了，它是安卓开发中不可或缺的概念，它允许我们访问系统资源，管理应用程序的生命周期，并与系统交互。实际开发中我们在使用 Toast，使用 Dialog，启动 Activity 与 Service ，加载资源，操作数据库，获取 App 相关的文件路径，创建 View 等操作时，都会涉及到一个 Context 引用。

其实 setView 是在 onResume 方法之后，内部流程是通过 PhoneWindow 获取 WindowManagerImpl 来调用 addView 方法，其内部会调用 WindowManagerGlobal.addView 方法，最后调到 ViewRootImpl 的 setView 方法。从源码中可以看到，View 的 onDetachedFromWindow 方法其内部是由 View 的 dispatchDetachedFromWindow 调用的。

shouldShowRequestPermissionRationale() 是 Android 系统中的一个 API，用于检查用户是否应该看到权限请求解释. 当您第一次请求一个危险权限时，系统会自动显示一个解释对话框，说明该权限的用途以及为什么您的应用需要它。14平台，录音应用需要申请麦克风权限，点击录音按钮时候会先检测是否有麦克风权限，如果有则直接开始录音，否则申请麦克风权限，当用户测试时候2次出现权限申请弹框都都选择不允许，第三次次就不再权限申请弹框。false: 表示用户不应该看到权限请求解释。

viewID是根据view的层级来确定的，如果项目进行重构或者变更层级，相同view的viewID就会变化，导致很多view要重新配置，有一种约束ID的方案，就是单独生成一个view与viewID的对应表，但是这样在添加新view时又要做相应的对应，也会带来开发上的不便利，所以目前还是维持现有的生成viewID的方案，当遇到重构或者层级变动的问题时就只能将上报的点迁移并重新生成viewID再上报，这是一个待优化的方向，后续想到合适的方案时会将其优化。然后在回调中做相应的操作，可以实现代码解藕。

到这里，Bitmap 的分配和回收过程就分析完了。你会发现在 Android 8.0 以前的版本，Bitmap 的像素数据是存在 Java 堆的，Bitmap 数据放在 Java 堆容易造成 Java OOM，也没有完全利用起来系统 Native 内存。那么，有没有可能让低版本也将 Bitmap 数据存在 Native 层呢？关注我，带你建立核心竞争力，我们下次见。参考资料管理位图内存 —— Android 官方文档。

一直以来，Android 系统仅支持 4KB 的内存分页大小，这在一定程度上限制了整体的性能。而随着设备制造商不断打造具有更大物理内存 (RAM) 的设备，这些设备中的许多可能会配置 16 KB（最终更大）的分页大小，作为 Android 系统设计者，是时候考虑是否需要支持 16KB 的设备了。所以，Google 团队的和于 2023 年针对 16KB 分页大小的 Android 性能表现进行了详细测试。

启动性能是App使用体验的门面，耗时过长会降低用户使用兴趣。对于开发者来说，通过各种技术手段来提升启动性能缩减启动时长，对整站业务的各项指标提升都会有较大帮助。因此，秒开率优化也成为了各个客户端团队在体验优化方向上十分重要的一环。本文将会结合我自己在项目中优化启动速度的经验，跟大家分享下，我眼里的科学的启动速度优化思路。在我的眼里，科学的优化策略是通用的，不管是针对什么性能指标不管是针对什么课题，思路是差不多的。比如这期的分享是启动优化，其实跟上期分享的。

大家都知道 png 是比较占用App体积的,有没有工具可以在打包前（比如 assembleDebug、assembleRelease）自动去转化所有的 png 图片，包括第三方依赖库里面的呢?之前不经意间发现有一个神器cwebp 转化工具,是不是可以借鉴这种工具自己写个Plugin完成图片转换,同时支持检查大图片，图片大小可配置。话不多说,说干就干~编写插件前,需要思考几个业务痛点怎么拿到所有的 res 资源呢?自动化转换工具Task 的执行时机点?

最后，我们来做个总结。在我们修改屏幕的density之后，仅更新Java层的值，并没有更新C++层。所以导致在获取dimension时，C++层用的是旧值去判断，所以导致dimension获取的不对。在我们更新完density之后，需要调用Resource的方法，去更新C++层的屏幕宽度(dp单位)额外补充两句，可能大家在实际开发过程中很少遇到这种问题，原因应该是，系统默认的屏幕宽度和我们修改density之后的屏幕宽度都比指定的values-wxxdp要大，或者要小，所以难以发现这个问题。

本文从线下发现的GC导致主线程卡顿的问题入手引出抑制GC解决问题的思路，并对ART虚拟机执行GC的类型和触发时机做了详细的分析。从第一性原理出发，寻找可能的两种解决思路，分别是增大并发GC阈值和阻塞ConcurrentGCTask执行，并在这两种思路下探讨可落地的方案，最终成功找到阻塞ConcurrentGCTask执行的方案，并上线通过AB实验验证收益。

大小、请求数、加载时间都大大减少注意优化后的时间chunk-vendors.js和app.js加载一共耗时1.59s，不是1.11+1.59,chunk-vendors的下载解析会阻塞app.js的下载解析，所以一共1.59s。前：image.png后：单页面首屏优化，打包后大小减少64M，加载速度快了13.6秒。

Android功耗优化是指优化Android APP在运行过程中的电量消耗，以获得更长的电池续航时间和更优秀的用户体验。功耗优化包括：设备的动态调频、网络优化、电池感知、界面优化、后台活动优化和内存优化等Android功耗优化指导规范就讲解完毕了，简单的总结一下: Android功耗优化指导规范主要分为五部分内容，第一部分内容是5W2H分析功耗优化。第二部分内容是功耗优化技术方案。第三部分内容是功耗优化方案分析。第四部分内容是功耗APM监控建设。最后一部分内容是总结与展望。

本文章总结了目前市面上常见的一些启动优化常用手段，开发和面试必备哦。首先要做应用启动优化，你得对应用启动流程有个整体甚至细化的了解。

因此，思路1不合适。到这里，我们已经能采集到很多HttpRTT样本、throughput样本了，现在我们要考虑下怎么将这些样本综成计算出一个可以代表设备普遍意义上的HttpRTT、throughput，然后再归类出设备网络类型（慢的网络、一般的网络、快的网络、很快的网络...）。需要注意的是，当我们结束一个时间窗口的时候，需要立刻检测当前并发是否5个以上，而不是等到新的请求到来时，这样能避免类似（图2：时间窗口2）的采样机会被浪费掉，而采样成功的样本数越多，越有利于最终结论的准确性（后面策略层会讲原因）

用于监控应用的 Java 内存泄漏问题，它的核心原理：周期性查询Java堆内存、线程数、文件描述符数等资源占用情况，当连续多次超过设定阈值或突发性连续快速突破高阈值时，触发镜像采集镜像采集采用虚拟机supend->fork虚拟机进程->虚拟机resume->dump内存镜像的策略，将传统Dump冻结进程20s的时间缩减至20ms以内基于shark执行镜像解析，并针对shark做了一系列调整用于提升性能，在手机设备测即可执行离线内存泄露判定与引用链查找，生成分析报告。

要研究内存泄漏框架，KOOM是个不可忽略的优秀开源框架，由快手开源。这将是一个系列的文章。这篇文章作为开篇，来看看KOOM框架的demo是怎么制造Java层面的leak的。下面通过官方给出的Demo代码作为入口，来分析和学习这个开源框架。初始化。

APM，全称是Application Performance Management，也就是应用性能管理，这与我们平时写的业务可能并不相关，但是却承载着App线上稳定的责任。当一款App发布到线上之后，不同的用户有不同场景，一旦App出现了问题，为了避免黑盒，找不到头绪，就需要APM出马了。对于App的性能，像CPU、流量、电量、内存、crash、ANR，这些都会是监控的点，尤其是当App发生崩溃的时候，需要回捞到当前用户的日志加以分析，找到此问题崩溃的堆栈，完成修复。

Add a fast dumper with HeapDumper API

众所周知，Square 出品的内存泄漏检测工具 LeakCanary 可以很方便的检测出 App 中存在的内存泄漏问题。当我们决定要不要在项目中引入 LeakCanary 的时候，经常也会听到声音：• “LeakCanary 接入简单，无需手动初始化。• “LeakCanary 虽好，但就是太卡。• “LeakCanary 虽好，但无法线上使用。一度我也是这么认为的，直到我认真研究了下才发现，事实可能并没有那么简单。本文就是尝试从 LeakCanary 的一些高级用法，来重新论证上述的观点。

因为当方法执行结束时，方法内的参数和局部变量会跟着方法一起结束，都会被回收，而内部类的生命周期可能比方法长（例如：线程）。如果允许修改外部局部变量，而外部方法已经结束，变量可能已经被回收，这会导致数据不一致和不可预测的结果。由于匿名内部类可能会在不同的线程中被执行，如果允许修改外部局部变量，可能会引发线程安全问题。的局部变量编译后的 Class 文件都是一样的，因此访问效率都是一样的。，可以确保在匿名内部类中使用的变量值在其创建时就被固定下来，不会在后续发生变化。的局部变量通常不会直接带来显著的性能提升。

当应用程序支持多种语言或主题时，切换语言或主题通常需要重新启动 Activity 以重新加载配置。虽然 recreate 是一种常用的重建 Activity 方法，但它不支持像在 Activity 之间切换时那样使用过渡动画。特别是在切换 浅色/深色 主题时，由于缺乏过渡动画而显得很生硬。为了提升改善这一点，只能自己实现过渡动画以提供更流畅的用户体验。

传统的图片压缩、冗余资源移除、代码混淆等优化手段可以在一定程度上降低安装包大小，但是在面对大型复杂应用的时候，效果往往很有限，本文将详细介绍我们在中原银行手机银行包大小优化方面的实践经验，并通过一系列技术手段实现了显著的包体积缩减。分包下载：需要移除的so库和assets文件按功能模块进行分包，首次使用时再去下载对应的资源包，这样能确保功能模块依赖的云端资源尽可能的小，大幅降低下载时间，提升下载成功率，减少用户等待时间。商业转载请联系作者获得授权，非商业转载请注明出处。作者：jack5288。

本篇到这里就结束了，我们利用RecyclerView实现了宫格图片的拖拽效果，主要是借助ItemTouchHelper实现，从ItemTouchHelper中我们能看到很多巧妙的的设计，里面有很多值得我们学习的技巧，特别是对事件的处理、绘制顺序调整的方式，如果做吸顶，未尝不是一种方案。另外，在本篇，我们还需要注意的是数据和UI一致性问题，因为在移动的过程中，数据的索引位置可能和UI产生差异需要主动优化，以及notifyItemMoved和notifyItemRemoved的用法。

目录1. 前台服务（Foreground Service）2. 双进程守护3. 使用系统广播拉活5. 白名单6. 第三方推送服务7. 静态广播监听8. 合理利用Activity9. 使用AlarmManager定时唤醒10. 合理设置进程优先级11. 使用sticky广播12. 使用WorkManager13. 合理使用WakeLock14. 合理使用SyncAdapter15. 使用AccountManager16. 适配Doze模式和App Standby。

Coroutine可以提供解析的子线程和切换到主线程，使用挂起函数就不需要接口回调了，并且可以自由的取消任务。所有工作就可以了，复制一份AsyncLayoutInflater代码改造，代码一下子少了很多。中不断从队列中获取布局的解析任务放在子线程中执行，解析完成变成 View 之后通过。，而且不太建议同时间内大量使用，会频繁的切换线程导致CPU碎片时间过多反而会卡顿。当我们的UI布局因为过于复杂，影响冷启动或者用户体验的时候，可以用。，如果大家需要单独定义一个线程池或者添加线程名称等，可以这样操作。

它保存为一种叫做HPROF的二进制格式。对于Android运行android.os.Debug.dumpHprofData(hprofPath)方法后所生成的文件，须要把.hprof文件从Dalvik格式转换成J2SE HPROF格式。使用AndroidSDK提供的hprof-conv工具可运行该转换操作。一个heap dump就是一个程序heap的快照，能够获知程序的哪些部分正在使用大部分的内存。

注解处理器（Annotation Processor）是一种在编译时扫描和处理注解的工具，它可以自动化生成代码、检查代码的正确性、生成文档等。在Android中使用过四种注解处理器：在Android平台，最先支持注解生成代码的库，是由个人开发者提供的一个插件，即android-apt。它只支持javac的方式，使用时需要引入插件 'com.neenbedankt.gradle.plugins:android-apt:1.8'。APT。

智能手机已成为人们日常生活不可或缺的一部分，而Android作为主流移动操作系统，为用户提供了丰富多样的应用体验。然而，随着应用功能的不断复杂化和用户需求的日益提升，Android应用的性能优化也变得越来越重要。流畅的应用体验不仅能够提升用户满意度，更能为应用赢得更多用户和良好的口碑。1.1 什么是性能优化？性能优化是指通过各种手段和策略，提升应用的运行效率和响应速度，从而改善用户体验的过程。1.2 为什么需要进行性能优化？进行性能优化可以带来以下好处：• 提升应用流畅度，改善用户体验。

因为我们为View1设置了TouchDelegate，所以会进入TouchDelegate的onTouchEvent()，如果这个方法返回了ture，View1的onTouchEvent()也会返回true并到此结束，对外宣称View1消费了这个事件，但实际上并不会触发View1的onClick()；，阅读View.java的onTouchEvent()源码可知，这种情况下View1的performClick()不会被调用，也就不会触发View1的onClick()