SharedTransitionObserver 内存泄漏问题问题背景： 项目中使用 SharedTransitionLayout 来完成 两个元素之间的共享元素动画，但是，在持有该共享元素组件的页面退出之后，发现有内存泄漏，GCROOT 指向的是 SharedTransitionObserver 单例对象 中的一个列表中的元素。 123456789101112131415161718192021

Compose 预览和调试预览添加依赖 123456dependencies { implementation "androidx.compose.ui:ui:1.0.0" implementation "androidx.compose.material:material:1.0.0" debugImplementation &

Jetpack Compose 是一个声明式 UI 框架，旨在简化 Android 应用的 UI 开发。它通过可组合函数（Composable functions）来描述 UI，这些函数可以动态响应状态变化。 Compose 声明式 UI ，数据沿层次结构向下传递，渲染UI；事件沿层次结构向上传递，更新数据状态。 Compose 的动画系统是全新的，不依赖于传统的 View 动画或属性动画。它

c/c++ 编译器， 下载与安装gcc: GCC（GNU Compiler Collection）是由 GNU 开发的编程语言编译器。 GCC编译工具链（toolchain），是指以GCC编译器为核心的一整套工具，主要包括： gcc-core：即GCC编译器，用于完成预处理和编译过程，把C代码转换成汇编代码。 Binutils ：除GCC编译器外的一系列小工具包括了链接器ld，汇编器a

c++ 中的 header 文件 通过 header 文件来 声明，只需要 include 相对应的 header 文件就可以 正确的链接到对应的函数 log.h 123456#ifndef LOG#define LOGvoid Log(const char* message);#endif log.cpp 12345678#include <iostream>#include &q

Jetpack Compose 中的性能优化 在创建一个 Composable 功能时，开发人员不必考虑 Compose 在后台是如何工作的，这很好。然而，这样做有一个缺点——声明性降低了透明度和对正在发生的事情的理解，有些事情开始看起来像“魔法”。 Jetpack Compose 中的界面是使用 Composable 函数图构建的。 每次函数参数的值发生变化时，都会发生重组，即重新执行函数。在大

Mavericks 是 Airbnb 的 Android MVI 框架，是一种响应式的 UI 框架。 Mavericks 建立在以下现有技术和概念之上： Kotlin 语言 Android Architecture Components（Lifecycle、ViewModel 等） Kotlin Flow React (概念) Mavericks 吸收了来自 React 的响应式思想，同时 M

一句话描述： 使用 Kotlin DSL （Domain-Specific Language，领域特定语言）和 ValueAnimator 实现一个动画框架，以 DSL 的方式来方便、快速的实现对 view 的各种属性动画。 通过 Kotlin DSL 的方式来组合针对 view 的多个属性的动画，用于快速、简单的实现复杂的组合动画效果。简单又好用——使用示例： 12345678910111213

Android的Apk构建流程主要包括资源的编译和代码的编译。梳理清楚打包构建过程能够帮助我们理解为什么编译耗时久以及如何去优化。我们可以从以下两个方面去理解Android的Apk打包构建的过程： Apk构建步骤 Apk自动化构建中的Gradle Task Apk构建步骤 Apk的构建主要包括以下几个步骤： 资源文件的编译，包括通过aapt工具编译（AndroidManifest.xml，

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新的一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）— Clean Code 随着需求的不断增加和变更，业务逻辑越来越复杂，参与开发的人也越来越多，多人协作