本文统一梳理二叉树最常见的五种遍历方式，内容覆盖 LintCode 第 66 到 71 题，所有示例代码都以 Java 实现并已在平台上提交通过。开篇先明确问题的输入输出：给定一棵二叉树的根结点，返回一个按特定顺序排列的序列。文章结合一棵具体的二叉树，直观列出前序、中序、后序三种遍历各自得到的结果，并解释它们的区别只在于访问根结点的时机不同。随后介绍层序遍历，即借助队列实现的广度优先搜索，按层从左到右依次访问节点；最后讲解锯齿形遍历，它在层序遍历的基础上按层交替改变访问方向。每种遍历都给出了可直接参考的完整代码。

关于 Android Binder 的资料浩如烟海，但作者发现大多数文章都在反复兜售那几个名词——Binder 驱动、一次拷贝、内存映射，然后贴上成堆的系统源码和函数调用时序图，却很少有人站在一个更高的视角讲清楚 Binder 这套框架究竟是什么、当初是为了解决什么问题而设计的。本文正是从这样一个宏观角度出发，不纠缠于繁琐的源码分析。文章从源流讲起：它的前身来自 BeOS 操作系统中的一项设计，后来随着 Palm 公司的几番收购，被 Andy Rubin 在创建 Android 时带了进去；团队对管道、Socket、匿名共享内存等传统方案做过考察，却都无法同时满足移动设备在安全性、性能与易用性上的要求，这才有了后来的选择，而这一方案的开源版本便是用 C++ 编写的 OpenBinder，一个类似于 Windows 上的 COM 与 Unix 上的 CORBA 那样的分布式组件架构。

Kotlin 已经成为 Android 官方支持的语言，androidx 中的库基本都提供了配套支持，从官方的态度来看 Kotlin 今后会逐步成为 Android 开发的主流。本文站在一个 Android 开发者的角度，系统梳理了 Kotlin 相比 Java 最常用的那些优点：从语言层面强制开发者处理可空变量的空安全设计、直接消灭大量样板代码的取值与赋值访问、表现力更强的 when 表达式、让异步代码像同步一样书写的协程、基于属性委托的延迟初始化、简洁的 lambda 表达式、可以用装饰器思路为已有类型增加能力的扩展函数、丰富易用的集合操作、便于组织单例的对象声明，以及在编译期守住类型的类型推断。在介绍完这些优点之后，文章也客观讨论了 Kotlin 自身存在的问题，建议读者取其精华。

这是一篇纯粹的摄影作品分享，主题是光与影。文章没有额外的文字叙述，而是依次陈列了编号从一到十五共十五张照片，用画面本身说话。作者把镜头对准日常场景中稍纵即逝的光影瞬间，借助光线与阴影的交错、明暗之间的层次对比来组织画面语言，让整组作品呈现出安静而克制的气质。从文件的命名方式可以看出，这些照片在拍摄之后大多使用同一款后期工具进行了处理，作者对色调与明暗做了统一的调整，使十五张照片保持了相对一致的观感，点开页面即可按顺序从头浏览。

有人提出这样一个问题：向一个键类型为整型的 HashMap 中存入键值 1 之后，用 int 类型的 1 能够正常取到值，换成 byte 类型的变量去取却得到了空，难道不是 byte 自动转型为 int 再装箱成整型对象吗。本文逐步拆解了这个看似反直觉的现象。HashMap 内部依据键对象的哈希值来定位数据，而 Java 集合只接受引用类型，原始类型传入时会被自动装箱，于是存入时实际使用的是整型的包装对象，取出时却变成了 byte 的包装对象。由于判断对象是否相等依赖的是 equals 方法，而整型包装对象与 byte 包装对象连类型都不同，比较结果自然为假。更进一步，文章指出 HashMap 的存入方法有泛型约束而取出方法的入参只是普通对象，并据此讨论了为何 Kotlin 的集合能在编译期就把这类错误拦下来。

网上常有人争论 Java 的构造方法到底有没有返回值，两种观点各执一词谁也说服不了谁。作者没有停留在争论上，而是直接查阅 Java 语言规范寻找权威答案：规范中明确指出构造器、静态初始化器和对象初始化器都不是类的成员，因此也不被子类继承，同时又说明构造器的声明看起来就像一个没有返回值的方法声明。两句话放在一起，问题便清楚了——这其实是一个由英文译成中文造成的误会。Java 类的成员只有成员变量、普通方法和内部类型三种，构造器负责对象的初始化，它与方法是两个彼此平等的概念而非包含关系，把它译成构造方法并不合适，既然它都不是方法，自然也就谈不上返回值。文章还从虚拟机层面补充：构造器在字节码中对应编译期生成的初始化代码块并使用 invokespecial 指令执行，普通方法则使用 invokevirtual。

EventBus 是一个基于事件发布订阅模式的事件总线框架。本文先用官网的经典示意图讲清楚这套模式的基本概念与运作步骤：订阅者、发布者、事件与事件总线四个角色彼此协作，事件从发布者经由总线分发给多位订阅者，本质上也是一种生产者与消费者的模型。进入源码分析之前，文章以表格形式把各个角色与其在 EventBus 中的具体实现类一一对应起来——真正的订阅者是以方法为单位存在的订阅方法对象、发布者由事件总线类本身兼任、事件则是普通的 Java 类，此外还介绍了封装订阅信息的类、用于构造的构造器以及基于反射查找注解方法的关键类，并说明对象采用 Builder 设计模式完成构造。随后分五个小节逐一深入源码，重点剖析订阅过程、取消订阅过程、事件发布过程、粘性事件的处理以及底层的线程调度机制。

一道经典的链表面试真题：给定两个单向链表的首结点，找出它们的第一个交点，不存在交点时返回 null。文章从单向链表的四个基本特性出发，指出相交的链表必然呈现 Y 型而非 X 型，因此两条链表的尾结点一定相同。主解法分为四步：先分别遍历到两个链表的尾部并比较尾结点是否相等以确定有没有交点，同时在遍历过程中记录各自的长度，让较长的链表先行走过长度差值到达所谓的等长点，最后两条链表同步向后推进，第一次相等的结点即为所求。文中给出完整的 Java 实现并分析了时间复杂度，另外补充了一种先反转两个链表再比较的替代思路。

volatile 关键字是什么意思、到底有什么作用，是 Java 面试中的高频题目，但不少开发者对它只是一知半解，仅仅知道它与并发编程有关。本文从 Java 语言规范的原文出发，提炼出四个关键点：语言允许多线程访问共享变量、通常通过加锁来保证互斥访问、除此之外还提供了 volatile 这种更轻量的机制、被它修饰的变量能够获得可见性保证。那么可见性又是什么？文章指出它源于 CPU 的缓存一致性问题：现代处理器普遍采用多级缓存与多核设计，每个核心都可能把内存数据复制进自己的缓存，线程运行在不同核心上时读到的很可能只是各自的副本，某个线程做出的修改对另一个线程便是不可见的。volatile 正是虚拟机在规范层面对此给出的约束，它保证写操作能立刻对其他线程可见，特别适合一写多读的场景以避开加锁带来的性能损耗，其底层实现则依赖于处理器之间的缓存一致性协议。

Java 的类对象都是在堆上分配内存吗，这是虚拟机面试中的一道经典题目，答案其实是否定的。文章先回顾标准虚拟机的内存划分：栈内存、堆内存、程序计数器、方法区与本地方法栈，其中每个线程都拥有独立的调用栈，方法调用依靠栈帧的创建与销毁来完成，引用变量与基础类型在栈帧内分配，而对象则在堆上分配。随后作者通过一个只在方法内部创建并使用的对象提出假想：既然它的生命周期与方法一致，如果直接在栈上分配内存，就能省去堆内存的寻址开销，也不必再依赖垃圾回收来释放。这个假想是成立的，其技术基础正是逃逸分析：当对象没有逃逸出所在方法时可以启用栈上分配甚至标量替换，没有逃逸出线程时则可以消除不必要的同步锁。文章列举了不同逃逸范围与对应的优化策略，并给出 HotSpot 的实现参考。