Android Performance Studio 是一个开源、跨平台的 Android 性能分析工作台：从 Layout Inspector 到 Perfetto，从 HPROF 到 batterystats，采集、查看、关联、定位在一个窗口里完成。本地优先。 一、性能问题最难的地方，不是修，是找“首页滑动有点卡”“启动要两秒多”“内存又涨了 200MB”。 这三句话，背后往往是三套完全不同的工具链。 滑动卡顿，你要打开 Android Studio Profiler 抓 CPU，或者用 Perfetto 抓系统 trace，盯着 RenderThread 和 SurfaceFlinger 看；内存涨了，你要导 HPROF，翻类直方图、支配树和引用链；启动慢，你要跑 Macrobenchmark，看 TTID、TTFD 和 Baseline Profile；耗电异常，你要导 batterystats，再去 Battery Historian 里对 Wakelock 和 Alarm；再加上 simpleperf 看 Native 热点、AGI 看 GPU、OkHttp...

Android ANR（Application Not Responding）分析看起来像是在“读日志”，但真正困难的地方并不只是日志太多，而是证据太散、时间线不一致、系统上下文复杂，并且很容易因为某一段醒目的堆栈或日志而过早定责。 llm-anr 这个仓库要解决的正是这个问题：把 trace、EventLog、logcat、AnrManager dump、meminfo、kernel log 等多源原始材料，转换成按 ANR 事件隔离、可审计、可复盘的证据工作区，再引导 AI 或人工分析者逐层完成保守分析。 这篇文章从三个角度介绍这个项目：它为什么这样设计、开发流程如何组织，以及当前最终交付出了什么能力。 项目地址：yuchuangu85/llm-anr: Agent-driven Android ANR evidence extraction and AI-assisted root cause analysis pipeline. 一、项目要解决的问题在实际 Android 稳定性分析中，ANR bugreport...

上一章介绍了为什么要引入dagger，这节我们再贴一张Launcher3 引入dagger后的流程图，以及生成对象图。能够更清晰帮助我们理解Dagger的流程和作用。

从Android 16的qpr2版本开始Launcher3全面引入了Dagger，为什么要引入Dagger，我们看一下引入Dagger的架构对比。 引入前： 引入后： 再来一张放一起的图，更清晰： Dagger2 的引入核心目标是： 减少传统静态单例依赖 旧版 Launcher 大量使用 LauncherAppState.getInstance()、SomeSingleton.INSTANCE 等静态单例，这导致： 生命周期难以控制 测试难以替换依赖 进程或 Activity 生命周期边界不清 通过 引入Dagger2，将对象的创建与依赖关系交由 编译期生成的 Component/Module 管理。 明确依赖边界和作用域 Dagger2 的 Scope 注解用于划分对象生命周期： @LauncherAppSingleton：App 级单例，与进程生命周期绑定 @ActivityContextSingleton：ActivityContext 级单例，与 Activity 生命周期绑定 通过...

Launcher3项目是一个非常大、非常复杂的项目，虽然从界面看Launcher的界面很少，也不复杂，但是涉及的UI，动画，手势等非常多，与SystemUI，窗口都深度绑定，如果没有看过Launcher3源码还是比较难理解的。 Launcher3从整体的架构来看是分为两部分：一部分是基础部分，就是不与SystemUI和窗口绑定的，一部分（Quickstep）是与SystemUI和窗口绑定的。 基础部分一般是给开发三方桌面使用的，可以在任何Android手机安装，Quickstep部分是给手机厂商用的，依赖SystemUI和窗口。 先从架构开始，逐步分析整个Launcher3项目。 这篇先看看基础部分的架构： 由于内容比较多，这里也只是显示了部分内容，还有很多的内容没有呈现，比如一些动画，拖拽，手势等，后续逐步放出。 这个图先让我们对基础部分的架构有个了解，以帮助我们更好的学习整个Launcher3项目。

基于Google AOSP源码中的Launcher3源码进行分析：

​ 前几天Karpathy分享了他最新的工作流：使用 LLM 构建个人知识库（Personal Knowledge Base），这条推文一发布，引发大量关注和点赞，两天后，他把这套方法论写成了一份 gist 发到 GitHub（llm-wiki） 上，开源给所有人。 ​ 我最近也看到很多介绍这个构建知识库的帖子，但是很少有如何实战构建自己的知识库的操作步骤，所以开始也是很迷茫，到底该如何构建自己的知识库，正好今天没事找到一篇介绍如何使用的，我本地也实战了一下，记录一下操作步骤。 ​ 知识收集、整理是非常耗费时间的，我做开发十多年也整理了很多知识，放到github，博客，公众号，但是没有一个非常好的的管理方式，正好这个方法能够解决我的问题，可能也会解决很多人管理知识的问题。 ​ 下面我介绍下我的操作步骤。 准备工具 Obsidian – https://obsidian.md/ ：下载安装，这个是一个读取显示md文件的软件，具有很强大的功能，由于我也是刚开接触，因此很多还不熟悉，因此还在摸索阶段。 obsidian web clipper –...

安装虚拟机选用：OrbStack · Fast, light, simple Docker & Linux虚拟机 安装后，启动OrbStack，macOS系统选用的amd64的Linux系统，安装完成后设置内存为32G以上否则可能会报错。 配置好后，启动虚拟机，然后开始准备下载源码。 源码下载 使用清华镜像，一定要在虚拟机下面下载，在mac下直接下载，会报错。 清华镜像：Aosp | 镜像站使用帮助 | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror 根据里面的教程下载AOSP源码，我下载的是 12repo init -u http://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android16-qpr2-releaserepo sync -c -j10 编译步骤代码下载后进入代码根目录， 执行： 1source build/envsetup.sh 然后执行： 1lunch...

...

安装官方安装命令，要先安装docker客户端。 12docker volume create n8n_datadocker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n 安装到第二步时报错： 12docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8nUnable to find image 'docker.n8n.io/n8nio/n8n:latest' locally 需要翻墙 或者 根据：docker.n8n.io/n8nio/n8n:latest · Issue #3081 · kubesre/docker-registry-mirrors提示使用： 1docker run -it --rm --name n8n -p 5678:5678 -v...