本文内容整理自享学团队直播课《App 启动流程源码分析（五）》 一、从启动屏动画到 Application 有一个很容易复现的现象：给 Application.onCreate 的头尾各打一个 Trace.beginSection / endSection，测出来只有 30ms；但用 adb shell am start -W 量整体，接入几个三方 SDK 前后 TotalTime 涨了一百多毫秒

本文内容整理自享学团队直播课《App 启动流程源码分析（四）》 一、App启动性能标准设定 点击桌面图标，屏幕立刻被一整块纯白（或纯黑）铺满，几百毫秒后才切成 App 的真实界面。可以通过在冷启动过程中执行 adb shell dumpsys window windows grep -i starting进行流程观测，通过上述命令能看到一个类型为 TYPEAPPLICATIONSTARTING

本文整理自技术讲解视频《告别冗长类型：auto 虽好，但切忌无脑到处乱用》 一、C++类型声明痛点 写 C++ 最没意义的一类劳动，就是重复编译器早就知道的东西。容器类型写在 begin 的返回类型里，可你还是得把 std::map::iterator 这一长串完整敲出来，敲完还得祈祷没拼错。复杂的嵌套返回类型更夸张，只能从别处复制粘贴一大段。 C# 用 var 早就解决了这类问题（隐式推导，

本文内容整理自享学团队直播课《App 启动流程源码分析（三）》 一、从 WMS 方向看启动，问题落在哪里 冷启动的耗时账单最后要落到"首帧什么时候上屏"，这条线的终点在 WMS 一侧。但往回追一步就会撞上一个不太好回答的地方：进程创建完成、ApplicationThread 回连 AMS 之后，AMS 在同一段加锁逻辑里干了两件事——把 Application 的信息发过去，以及把 Activit

本文内容整理自享学团队直播课《App 启动流程源码分析（二）》 一、本集要解决的问题 《一》把"启动"的边界定死了：从点击 icon 到主 Activity 显示。也画了四进程的地图，结尾留了一个口子——下一篇从 Launcher 的 startActivity 跟到 AMS 请求 Zygote fork。本集从这个口子接上。 核心问题只有一个：从点击桌面图标，到 App 进程真正跑起来并创建好

本文内容整理自享学团队直播课《App 启动流程源码分析（一）》 一、耳熟能详的优化方向，为什么不足以解决问题 避免主线程 IO、减少主线程耗时、减少布局层级、优化线程的使用方式、对部分启动任务做懒加载与按需加载、用 profile 工具定位热点——这些条目出现在几乎每一份启动优化清单里。它们单独看都成立，麻烦在于它们是并列的散点，条目之间没有先后关系，也没有权重。 散点式优化的典型失效方式，是注意

一、为什么需要理解事件分发 Android 提供的原生控件——比如 Button、ScrollView、RecyclerView——内部已经把事件处理逻辑写好了。用它们的时候，你几乎不需要操心事件冲突的问题。 但一旦开始写自定义 View，情况就变了。比如你做了一个自定义的滑动面板，里面嵌套了一个列表，手指一滑，要么外面的面板不动，要么里面的列表不响应。这就是事件冲突。 要解决冲突，就必须搞清楚两

当 Coding Agent 已经足够快，一晚上能替你写几千行代码，真正的问题就变了：不再是"它写不写得动"，而是"它写出来的是不是你要的"。很多人第一反应是 vibe coding 那种玩法——丢一个"给我一个按钮"的 prompt，看结果，挑毛病，再让 agent 重来，循环到满意为止。对按钮它挺好使，对一个要维护一年的项目，它留下的是一长串没保存的对话历史，和一堆一次性代码。 规范驱动开发（