HttpURLConnection → OkHttp + Kotlin 老写法（Java + HttpURLConnection） 问题在哪里 手写 Socket 级别的连接管理、超时、流读取

SQLite 手动升级 → Room Migration 老写法（Java + SQLiteOpenHelper） 问题在哪里 版本号和 SQL 全靠自己维护

文件读写（Java IO）→ Kotlin 扩展函数 老写法（Java） 问题在哪里 try-catch-finally 嵌套层层叠叠，实际有用的就两行读写代码，其余全是样板

ContentProvider → Room + Repository 老写法（Java + ContentProvider） 自定义 ContentProvider

CountDownTimer → Flow 老写法（Java） 问题在哪里 CountDownTimer 不感知生命周期，Activity 退出后 tick 还在跑，回调会操作已销毁的 View 导致

DLNA 渲染端排障实战：从 20s 卡顿到 stale subscriber 的两周追凶之旅 一、项目背景 我们维护一个 Android DLNA 盒子（基于 Platinum/Neptune UP

SharedPreferences → DataStore 老写法（Java + SharedPreferences） 问题在哪里 apply() 是异步写入但无返回值，写没写成功不知道

线程安全集合 → 协程安全替代 老写法（Java） 问题在哪里 Collections.synchronizedList 只保护单个方法调用，遍历时仍需要手动 synchronized 块

Timer → Coroutines 老写法（Java） 问题在哪里 Timer 用单个后台线程执行所有任务，一个 TimerTask 抛异常整个 Timer 直接挂掉，其他排队的任务全部作废

Cursor 操作 → Room DAO 老写法（Java + Cursor） 问题在哪里 getColumnIndex 依赖字符串，字段名写错返回 -1，然后 getString(-1) 直接崩

Java 方法调用看起来只是一次普通的 obj.method(arg)，但背后其实经历了源码、编译器、class 文件和 JVM 运行时多个层次。 源码层面要区分重载和重写；编译期会确定重载目标；cl

批量写入 → Room 事务 老写法（Java + SQLite） 问题在哪里 不用事务时，每条 insert 都是一次独立的磁盘写入，1000 条数据可能要几秒甚至十几秒

XML 布局 → Compose 声明式 UI 老写法（XML） Java 中绑定事件： 问题在哪里 XML + Java 绑定是两套独立的东西：布局结构写在一处，行为逻辑写在另一处

Handler/Looper → Coroutines 老写法（Java） 问题在哪里 Handler 三个问题：线程间消息用 what 整型区分，代码一多根本记不住哪个数字代表什么；Message

Java 中的数组为什么一定要 new 出来？更深一点说，为什么 Java 的数组通常要在堆上申请？

XML 主题 → Compose Material3 主题 老写法（XML 主题） res/values/colors.xml： res/values/themes.xml

​ 多数Android平板老项目初始仅支持横屏展示，在业务需求升级、设备适配多元化的场景下，需要兼容竖屏显示效果。常规适配方式需重构布局文件，改造成本高、易引发兼容bug。本文记录一种零布局修改、纯代

Fragment 手动跳转 → Navigation 组件 老写法（Java） 问题在哪里 Fragment 之间的跳转、传参、返回栈、返回结果全要手写

算法刷题笔记：一维DP没那么难，状态想清楚就赢了一半 哈喽大家好！今天我们聊聊一维动态规划，这可是算法里的重头戏。 很多同学听到DP就头疼，其实动态规划的核心就一句话：记住你算过的东西，别重复算