maniuT的博客

最近一直忙于音视频SDK的开发，遇到很多问题，简单来说，就是怎么让别人接入SDK时越简单越好。相信大多数Android开发都会遇到一个场景，给TextView或Button添加背景颜色，修改圆角，描边等需求。一看到这样的实现效果，自然就是创建drawble文件，设置相关属性shap，color，radius等。然后将drawble文件设置给对应的view即可实现想要的效果。但是作为一个SDK，如果不同的app都需要修改自己独特的颜色，圆角等需求，如何以最小的改动来满足不同app的需求呢？

我们从电脑系统的窗口去理解Activity启动一个程序的时候，程序就会在电脑桌面上创建一个窗口，创建的那一瞬间（通常会很快，可能不需要1秒）就相当于Activity的onCreate()。创建完成后，窗口就可以被用户所看见了，被用户看到的那一瞬间就相当于Activity的onStart()。通常来说，一个新启动的程序会自动获得焦点并可被用户交互，因此onStart()之后，窗口会被置顶到顶层，这一瞬间就相当于Activity的onResume()。

内部会启动协程，所以适合当副作用中有耗时任务时的场景下；当需要在可组合项外启动协程时（如onClick中），可以使用rememberCoroutineScope适合有资源需要收尾的场景下，内部一定要重写onDispose()，用于释放资源、解注册等操作；对于包含长期操作的副作用很有效，尤其适合用在重启这些操作时代价高昂的场景中；SideEffect每次重组时都会执行内部的lambda，不过SideEffect 能确保可组合项成功重组之后才会执行内部的 Lambda。

在我们的开发中，经常会遇到各个模块中引入了相同的三方库，但是三方库版本又各不相同。不管采用哪种方式，我们都需要有一个决议机制，保证依赖版本全局的唯一性，大家遵循这个机制进行依赖管理才能尽可能的避免这个问题。1.1.1 中我们配置的 repositories ，里面的 url 就是依赖项上川岛远端仓库的 url，远端仓库起一个桥梁的作用，把开发者和依赖库作者连接起来。差别在于，如果没开启离线编译，每次编译的时候都会去检查版本，对于没指定版本号或者动态版本号的依赖每次都会以最新的版本进行编译。

最近在翻Jetpack库，发现了DataStore，官方是这么说的：Jetpack DataStore 是一种数据存储解决方案，允许您使用协议缓冲区存储键值对或类型化对象。DataStore 使用 Kotlin 协程和 Flow 以异步、一致的事务方式存储数据。如果您目前是使用存储数据的，请考虑迁移到 DataStore。显而易见，在需要存储较小或简单的数据集时，DataStore比起SP更加简单且安全性更高，所以学习使用DataStore是很有价值的。

通过从源代码的角度分析安卓 14升级后出现双弹窗异常的原因，并根据调查结果提出解决方案，可以更好地定位问题并实施有效的修复措施。这种方法需要对系统和应用程序的源代码进行深入的检查和理解，并确保修复后的应用程序在新系统上能够正常运行。

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

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

（1）获取User类的全部类信息，包括方法、字段、SUID等等，将其封装在ObjectStreamClass中；（2）在拿到全部类信息后，会将全部的类信息以及字段数据转换成二进制数据。从源码中我们可以看到，在统计类信息的时候，会检查两个方法是否存在，readObject和writeObject，而且只要实现了这两个方法，那么就不会走defaultWriteFields方法，

……

当时对Android理解不深, 考虑的不全面, 直接回答了在onDraw结束时通过postDelay发送一个(1000 / 帧数)ms的延时消息触发。

下面是允许你定义需要执行的任务，包括延迟执行、定时执行和根据触发条件执行的任务。你可以创建单次或重复性任务。你可以创建任务链，将多个任务按顺序排列，以确保它们以特定顺序执行。这对于处理复杂的工作流非常有用。支持约束，这意味着你可以指定任务执行的条件，例如在特定网络状态下、设备充电时等。这有助于减少不必要的任务执行，提高电池寿命和性能。能够选择最佳的后台任务调度方法，以适应不同Android版本和制造商的设备。

Launcher 进程通过 Binder 向 system_server 进程的 AMS 发送启动 Activity 请求AMS 判断如果应用进程不存在，通过 socket 向 zygote 进程发送 fork 应用进程命令应用进程启动之后，调用方法启动消息轮循，建立 Binder 通信AMS 通过 Binder 调度 ActivityonCreateonResume等生命周期onCreate中通过传入的自定义布局构建以 DecorView 为 Root 的 View 树onResume。

本文提供一种异步编程的思路，借鉴了Promise思想来重构了Android的异步代码。通过Promise组件提供的多种并发模型能够更优雅的解决绝大部分的场景需求。

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

Channel 和 Flow 是 Kotlin 协程库中的两个关键概念，它们用于处理数据流和异步操作。它们允许您以异步的方式生成、发送、接收和处理数据，而无需担心线程管理或回调地狱。让我们一起深入了解它们的内部工作原理和高级用法。

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

这就是我遇到的问题：单纯的根据TextView在子线程可以更新得出的结论，总的来说要想不崩溃还得绕过中的的检测。至于研究它有什么用，只有知道理解源码的流程，才能写出更好的东西。

这样, 我们就可以绕过使用。

Glide 作为常用的图片加载框架，框架层面已经对内存方面有不少优化，但作为一个图片框架，确保正确性一定是第一位的，因此在应用层还可以在适当的场景做一些额外的优化，当然你需要了解优化设置可能产生的问题。由于图片设置了 centerCrop 属性，在直观看图片会按等比居中缩放，但由于 decode 发生在 scaleType 生效之前，因此使用 Glide 加载图片时会以 ImageView 的实际尺寸（即全屏） 的宽高来解码图片，由此产生了不必要的内存开销。为了帮助到大家更好的掌握好 开源框架相关知识点，

以终为始，还是要问一问为什么，即我们为什么要学习Handler消息机制，Handler消息机制有什么作用？首先，你要知道，Handler消息机制和Handler不一样哦，Handler只是指Handler这个具体类，而Handler消息机制是包括Handler在内的一系列相关类组成的一个机制。Handler消息机制里面，有几个非常关键的角色，需要逐个捋清。下面，咱们挨个说说综上，关于ThreadLocal，可以这样描述它能够映射线程本地变量，映射的原理，就是不同的线程，ThreadLocalMap不同。

通过定义不同的ItemBinder将页面划分为不同模块，实现UI和交互解耦，单个ItemBinder也可以在其他页面进行复用。通过后台数据动态的添加ItemBinder页面组装更灵活。任务分拆，提高开发效率。

众所周知，今年的互联网行业就业率并不是很好，像“开猿截流，公司倒闭”等事件时有发生，感觉市场对于人才的需求量降低了，给原本不景气的Android 开发行业增添了不少的难度。随着新能源汽车行业的脱颖而出，不少Android 开发开始有了转行做Android 车载开发的想法，想去打破这层困境。首先认识一下像右侧是汽车的中控、副驾屏幕，操作系统是Android 系统，而左侧侧是汽车的仪表屏幕，一般是QNX系统。，这些都是后续可以去知识补充一下。

我们从电脑系统的窗口去理解Activity启动一个程序的时候，程序就会在电脑桌面上创建一个窗口，创建的那一瞬间（通常会很快，可能不需要1秒）就相当于Activity的onCreate()。创建完成后，窗口就可以被用户所看见了，被用户看到的那一瞬间就相当于Activity的onStart()。通常来说，一个新启动的程序会自动获得焦点并可被用户交互，因此onStart()之后，窗口会被置顶到顶层，这一瞬间就相当于Activity的onResume()。

最后点题下行情真的非常差的，尤其是对大龄开发来说，如果不是必要情况下真的不建议大家裸辞找工作的。面试的过程中建议大家都还是提早准备下，模拟下面试环境什么的，珍惜每一次的面试机会，毕竟用一次少一次的。招人的公司就这么几家，如果错过了可能就是错过了(废话文学)。最后知识梳理了一下前面面试中问的一些技术问题，整理了一些的电子书和面试笔记等学习文档进行参考学习，这些笔记将各个知识点进行了完美的总结(包含了很多内容：Android 基础、Java 基础、Android 源码相关分析、常见的一些原理性问题等等)。

在App中，使用列表来显示数据是十分常见的。使用列表来展示数据，最好不要一次加载太多的数据，特别是带图片时，页面渲染的时间会变长，常见的做法是进行分页加载。本文介绍一种无感实现自动加载更多的实现方式。

{// ...getName(): 当前transform的名字，能够在打包过程中看到它对应生成的。: 指定要处理的输入类型，上面的设置就表示只处理字节码，不处理资源。getScope(): 表示处理输入的范围，上面的设置表示整个项目的所有module和所有的依赖。: 表示是否支持增量更新，最好选择是。如果是否的话，每次打包都相当于清除缓存后重新打包；如果是是的话，只会处理修改后的文件。: 方法为处理插桩的入口函数。

MMKV 是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今在微信上使用，其性能和稳定性经过了时间的验证。近期也已移植到 Android / macOS / Win32 / POSIX 平台，一并开源。可以看出它也可以用于替代 SP，操作也与 SP 类似，相较于 DataStore 更好上手，所以我干脆也写一篇文章介绍下如何使用 MMKV。

Cronet是 google chromium 的网络组件，可单独编译成库提供给 Android/Ios 应用使用。Cronet在性能方面表现出色，目前已经有 Youtube、Goolge 全家桶等大量应用使用 Cronet 作为网络模块。支持 HTTP2/QUIC/websocket 协议支持对请求设置优先级标签可以使用内存缓存或磁盘缓存来存储资源支持 Brotlin 压缩（有研究表明，对于文本文件，相同的压缩质量下，brotlin 通常比 gzip 高出了20%的压缩率）

在Java层， 创建Socket的方式是直接构造 java.net.Socket对象，我们先跟踪其构造函数的实现。在构造函数中，会调用setImpl()函数，继续跟踪setImple()实现setImpl()函数先判断 factory是否为空，如果不为空则 使用factory创建SocketImpl实例，否则直接通过 SocksSocketImple()构造函数创建。

根据以上分析和实际测试结果，第一次同步的时候，两个方案速率相近，而第一次同步完成之后，新的方案效率就高得多。因为第一次同步的时候，两种同步方案可能都需要对远程的全部文件进行拉取。而第一次之后，新的同步方案只需要判断文件的上次修改时间，因此请求的数量和所有目录、子孙目录的数量相近（每次至少请求一次目录下的文件/目录信息）。实际测试结果表明，600 个文件同步一次只需要 60s （其中，为避免向服务器请求过于频繁，每个文件处理延时时间为 50ms）.以上就是基于 Android 系统的文件同步设计思路的分享。

Retrofit网络请求我想大家都不陌生，今天我就来梳理一下技术是如何一步一步进步，逼格是如何一步一步变高的。

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

通过 mmap 技术实现的高性能通用 key-value 组件。同时选用 protobuf 协议，进一步压缩数据存储。标准 protobuf 不提供增量更新的能力，每次写入都必须全量写入。考虑到主要使用场景是频繁地进行写入更新，我们需要有增量更新的能力：将增量 kv 对象序列化后，直接 append 到内存末尾；这样同一个 key 会有新旧若干份数据，最新的数据在最后；那么只需在程序启动第一次打开 mmkv 时，不断用后读入的 value 替换之前的值，就可以保证数据是最新有效的。

分享一个没什么技术含量但是我觉得挺有意思的东西，很多第三方SDK初始化的时候都需要我们传入一个context进去，拿到context之后SDK就可以做很多事了，比如打开activity、弹窗、获取文件目录之类的。这里我想简单的去处理下它们的使用权限，给它们传入一个被代理的context，让它们无法为所欲为。

2010~2020可以算移动客户端的黄金十年了，微信、淘宝、抖音等国民级应用都诞生于这十年间，也顺带产生了不少技术上的黑科技（比如动态化、跨平台、热修复）。然而现在头部公司的稳定，App独立生存的空间被不断挤压，中小型企业裁员的裁员，倒闭的倒闭，招人的公司有限。像上海这边就字节、PDD、华为、美团、小红书这些在大量招人，在招聘平台脉脉、拉勾、BOSS上基本上也是这些有反馈。

为了解决上面的问题，我们自然很容易想到要把其中可以共享的配置抽取出来，然后在每个 module 中引用这些配置。我们可以编写 1 个预编译插件 AndroidLibraryPlugin，在其中去处理这些共享的构建逻辑，然后在需要的 module 中引用这个插件。

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

本篇旨在帮助小伙伴们了解和使用Compose中BOM相关的知识，在Compose的开发过程中更加便捷、统一的管理相关依赖信息。BOM在使用过程中还是比较容易上手的，也是极大程度上帮助开发者更轻松的管理Compose相关依赖信息，感兴趣的小伙伴们赶紧上手体验下吧～

最近一直忙于音视频SDK的开发，遇到很多问题，简单来说，就是怎么让别人接入SDK时越简单越好。相信大多数Android开发都会遇到一个场景，给TextView或Button添加背景颜色，修改圆角，描边等需求。一看到这样的实现效果，自然就是创建drawble文件，设置相关属性shap，color，radius等。然后将drawble文件设置给对应的view即可实现想要的效果。但是作为一个SDK，如果不同的app都需要修改自己独特的颜色，圆角等需求，如何以最小的改动来满足不同app的需求呢？