每日新聞摘要

PennyWise AI is a privacy-focused Android application that automatically tracks expenses by parsing bank transaction SMS messages entirely on-device. The app intercepts individual SMS notifications (without modifying the inbox or sending messages) and uses local AI models to extract key details such as amount, merchant, category and date. It detects recurring subscriptions, supports multi-currency tracking and parsing for 40+ banks across multiple countries, and includes an on-device natural-language AI assistant for queries like spending by category or merchant. The project is open-source and written in Kotlin, with community metrics (354 stars, 56 forks, 22 open issues), and serves as a practical reference for developers building edge machine-learning solutions that prioritize user data privacy while automating financial recordkeeping.

PennyWise AI 是一款以隐私为先的 Android 开源应用，通过设备端 AI 自动解析银行交易短信，提取金额、商户、类别与日期，并不会修改收件箱或将信息发送到云端。它支持 40 多家银行与多币种、多区域的解析，能够自动检测订阅服务并生成清晰的可搜索收支时间线。内置的离线 AI 助手支持自然语言查询消费记录，简化个人理财流程。源代码以 Kotlin 编写，适合作为实现边缘机器学习与隐私保护功能的实务参考（项目星数 354、分支 56、开启议题 22）。

This post, part of the StreamBox branch-by-branch series, explains the author's decision to add an explicit boundary between the domain layer and the user interface, which he terms a 'mapper.' The mapper's role is to translate or adapt domain models into UI-friendly representations and to prevent UI-driven changes from leaking into core business logic. By treating mapping as a distinct responsibility, the pattern encourages separation of concerns, reduces coupling between layers, and makes both domain logic and UI code easier to evolve and test independently. The article focuses on the rationale for this architectural wall and why naming and enforcing that boundary helps maintain clarity and robustness in application design.

本文是 StreamBox branch-by-branch 系列的一篇，作者解释了为什么在领域（Domain）与用户界面（UI）之间添加一个明确的边界，并将其称为“mapper”。mapper 的职责是将领域模型转换为适合 UI 使用的表示，阻止 UI 导向的改动渗入核心业务逻辑。把映射作为独立责任有助于分离关注点、降低各层之间的耦合，并使领域逻辑与界面代码更易于独立演进与测试。文章重点阐述了建立并命名该边界的理由，以及它如何提高应用架构的清晰性和稳健性。

Exposed 1.0 is the first major release of the Kotlin SQL library, marking a significant milestone with a stable API that promises no breaking changes until the next major version. The release adds highly requested R2DBC support, enabling reactive drivers to work with Exposed’s SQL DSL, plus performance enhancements and bug fixes. Spring users benefit from continued support for Spring Boot 3 and compatibility with Spring Boot 4, better transaction management, and GraalVM native image improvements. The project provides examples for Ktor and Spring, a migration guide for moving from version 0.61.0 to 1.0, and encourages joining the #exposed channel on Kotlin Slack for questions. The announcement also highlights a KotlinConf 2025 talk by Chantal Loncle and thanks numerous contributors whose pull requests were included.

Exposed 1.0 是該專案的首個重大版本，具有里程碑意義：發布了穩定的 API，承諾在下一个 major 版本前不會有破坏性变更；同時加入社群高度期待的 R2DBC 支持，使反应式驱动能与 Exposed 的 SQL DSL 配合使用。版本還包含性能提升與修复，继续支持 Spring Boot 3 并兼容 Spring Boot 4，改善事务管理并增强 GraalVM 原生镜像支持。官方提供从 0.61.0 到 1.0 的迁移指南、Ktor 与 Spring 示例，并邀请开发者加入 Kotlin Slack 的 #exposed 频道交流，同时向为本次发布贡献代码的众多贡献者致谢。

Ktor 3.4.0 focuses on stability and fixes while adding several notable features. It completes OpenAPI document generation by introducing a runtime describe API and a compiler plugin (and integration via the Ktor Gradle plugin) so Swagger models are produced from routing metadata. The OkHttp client engine gains duplex streaming for HTTP/2, allowing simultaneous request-body send and response receive. Compression plugin adds Zstd support via ktor-server-compression-zstd with configurable compressionLevel. The new HttpRequestLifecycle plugin cancels in-flight requests when clients disconnect (cancelCallOnClose = true), leveraging structured concurrency to clean up coroutines; currently supported on Netty and CIO engines. The release emphasizes performance and invites developers to join the Ktor Early Access Program and start projects at start.ktor.io. The blog thanks the community for feedback and issue reports.

Ktor 3.4.0 以提升稳定性与修复长期问题为重点，同时引入多项功能：通过新增的 describe API 与编译器插件（并可由 Ktor Gradle 插件启用），实现了运行时由路由信息生成的 OpenAPI 文档；OkHttp 客户端引擎新增对 HTTP/2 的双向流，允许在发送请求体的同时接收响应；Compression 插件通过 ktor-server-compression-zstd 模块添加了 Zstd 支持并可配置压缩等级；HttpRequestLifecycle 插件可在客户端断开时取消正在进行的请求并利用结构化并发清理资源（当前支持 Netty 与 CIO 引擎）。团队也邀请开发者加入 Early Access Program 并在 start.ktor.io 启动新项目，感谢社区的反馈与问题报告。

This issue of Java Weekly highlights Functional Optics for Modern Java (Part 1), which improves how developers update nested immutable data by composing access paths to avoid long copy-constructor cascades. The newsletter also collects recent Java and cloud-native coverage—AOT cache optimizations, reduced sampling costs, faster builds, virtual thread states, Spring AI agentic patterns, warmup and scaling topics, flaky-test strategies, and guidance for choosing LLMs. It lists webinars and presentations on Java's 2026 plans, the Static Dynamic JVM, Spring podcasts, concurrency lessons, and SRE AI agents. Several upgrades are called out for immediate attention, including Spring gRPC 1.0.1, Quarkus 3.30.6, Netflix Zuul, Grails, and Apache Camel. The Pick of the Week promotes a hands-on Spring Boot live webinar aimed at teams working across Boot 2.x–4.x.

本期主要介绍 Functional Optics for Modern Java（第一部分），该方法弥补了模式匹配在读取嵌套不可变数据方面的不足，使更新操作无需层层拷贝构造即可以单一表达式完成。周刊还收集了多篇值得关注的技术文章，涉及 Java 的 AOT 缓存优化、采样成本显著降低、构建加速、虚拟线程状态、Spring AI 代理模式、启动与热身问题、易碎测试的对策以及如何为云原生时代优化 Java。名单中还包含多场网络研讨会与演讲，以及若干重要组件的版本更新，推荐参加一场针对 Spring Boot（2.x、3.x 及 4.x 规划）的实务直播活动作为本周精选。

This tutorial demonstrates how to handle hidden and read-only input fields in web automation by combining Selenium with direct JavaScript DOM manipulation. It explains that Selenium's sendKeys() emulates keyboard events and therefore cannot operate on elements a human cannot interact with, like hidden inputs or fields controlled by scripts. The article shows a complete setup: Maven dependencies (selenium-java and spring-boot-starter-web), a Spring Boot application exposing an HTML form, a controller that receives form submissions, and a Selenium script. The Selenium code fills visible fields with sendKeys() and uses JavascriptExecutor to assign a value to a hidden input before submitting the form; the server console output verifies the values were received. The guide concludes that using JavascriptExecutor is a deliberate, necessary technique to ensure automated tests include all data the server expects.

本文展示了如何在自动化测试中处理隐藏与只读输入字段——关键在于理解 Selenium 的 sendKeys() 是模拟键盘事件，因而不能操作用户无法触及的元素。文章提供完整示例：Maven 依赖（selenium-java 与 spring-boot-starter-web）、在 localhost:8080 运行的 Spring Boot 应用、用于接收表单的控制器和 HTML 页面，以及 Selenium 脚本。示例对可见字段使用 sendKeys()，对隐藏字段通过 JavascriptExecutor 直接修改 DOM 的 value，然后提交表单，服务器控制台的输出用以验证接收到的值。结论指出，对于隐藏或由脚本填充的字段，直接在 DOM 上用 JavaScript 设置值是必要且恰当的方式。

This article demonstrates why Micrometer gauges can return NaN when exposing in-memory Java objects to Prometheus and how to fix it. By default, Micrometer avoids memory leaks by holding weak references to monitored objects; if the object is only weakly reachable it can be reclaimed by the JVM, leaving the gauge unable to call its value function and reporting NaN. The tutorial reproduces the issue using Spring Boot Actuator, inspects the root cause (interaction between Java garbage collection and Micrometer’s weak-reference design), and offers solutions: maintain a strong reference to the monitored object (for example, store it as a field) or enable strong references explicitly with Gauge.Builder.strongReference(true). With these changes, metrics remain stable and report actual values instead of NaN.

本文展示了 Micrometer Gauge 在暴露内存对象为指标时为何会出现 NaN 以及如何解决。Micrometer 为避免内存泄漏，默认对被监控对象使用弱引用；若对象在方法执行结束后没有其他强引用，JVM 会回收该对象，导致 Gauge 在被抓取时无法访问对象而返回 NaN。作者以 Spring Boot Actuator 重现该问题，解析根因（Java 垃圾回收与 Micrometer 弱引用的交互），并演示修复方法：将对象保存为类字段以维持强引用，或在 Gauge.Builder 中启用 .strongReference(true)。应用这些方法可确保指标对 Prometheus 等监控系统保持准确可靠。

This tutorial demonstrates integrating Open J Proxy (OJP) with a Spring Boot application using a local PostgreSQL and Dockerized OJP server. OJP provides a Type 3 JDBC driver and Layer 7 proxy: applications obtain virtual JDBC connections while the driver forwards executed statements to the OJP Server via gRPC. The server owns and pools real database connections centrally, reducing connection storms and improving resource sharing across services. Steps include running PostgreSQL and the OJP server in Docker, creating a Spring Boot project, excluding HikariCP, adding the ojp-jdbc-driver dependency, and configuring application.properties to use the ojp[host:port]_postgresql URL and SimpleDriverDataSource so pooling is delegated to OJP. A small CRUD example verifies SQL flows through OJP. The guide notes OJP’s compatibility with other JVM frameworks and multiple databases and suggests multinode, serverless, or non-Java gRPC integrations as next steps.

本教程示范如何在 Spring Boot 应用中整合 Open J Proxy (OJP)，以本地 PostgreSQL 和 Docker 化的 OJP 服务器为例。OJP 作为 Type 3 JDBC 驱动与 Layer 7 远端代理，应用获取虚拟连接，实际 SQL 在执行时通过 gRPC 发给 OJP Server，由服务器统一管理后端连接与连接池，从而降低连接风暴并稳定数据库负载。指南包括启动 PostgreSQL 与 OJP 容器、创建 Spring Boot 项目、排除 HikariCP、添加 ojp-jdbc-driver 依赖，并在 application.properties 中使用 ojp[host:port]_postgresql URL 和 SimpleDriverDataSource，以将连接池职责委托给 OJP。通过简单 CRUD 示例验证数据流，且说明 OJP 支持多种框架与数据库，并提出后续的部署与整合方向。

This tutorial demonstrates how to build a conversational AI agent with the Google Agent Development Kit (ADK) in the Java ecosystem. It walks through adding the google-adk dependency, meeting runtime requirements (Java 17+, setting GOOGLE_API_KEY), and defining a system prompt that shapes the agent's persona (Baelgent: a concise, Java/Spring-flavored responder). Configuration is handled via @ConfigurationProperties and application.yaml where the example uses the gemini-2.5-flash model. The agent is constructed as a BaseAgent using LlmAgent.builder(), and an AgentService uses InMemoryRunner plus an in-memory session cache to maintain conversation history across interactions. The ADK's function-calling capability is shown by registering an AuthorFetcher.fetch method with FunctionTool, enabling the agent to call Java code and incorporate results. Finally, a REST endpoint (/api/v1/agent/interact) exposes the agent and example requests illustrate persona, context continuity, and tool invocation.

本文介绍如何使用 Google ADK 在 Java 环境中构建会话式 AI 代理 Baelgent。步骤包括在 pom.xml 添加 google-adk 依赖、确保 Java 17 以上并设置 GOOGLE_API_KEY 环境变量，建立 system prompt 来定义代理的角色（以 Java/Spring 术语简洁回答），并在 application.yaml 与 @ConfigurationProperties 中配置代理名称、描述与所用模型（示例为 gemini-2.5-flash）。通过 LlmAgent.builder() 构造 BaseAgent，并在服务层使用 InMemoryRunner 配合并发哈希表缓存 session，以维持多次交互的会话上下文。示例还展示了如何用 FunctionTool 注册 AuthorFetcher.fetch，使模型在需要时调用 Java 方法并将结果纳入回复，最终通过 /api/v1/agent/interact 暴露 REST API 进行交互。

This article explains how to download, install, run, and deploy applications on Payara Server. Payara is a fork of GlassFish that implements the Jakarta EE platform and can also run MicroProfile applications. The Community Edition is available in Full and Web Profile distributions. The server is managed with the asadmin command-line tool, which handles domain lifecycle operations (start-domain, stop-domain, restart-domain, create-domain) and deployments; the default domain is domain1. A basic example shows adding jakarta.servlet-api as a provided dependency, packaging the project as a WAR, creating a HelloPayara servlet that responds at /hello, and building with mvn clean package. Applications may be deployed via asadmin deploy or through the Admin Console at http://localhost:4848. The article also contrasts Payara’s full-featured enterprise capabilities with lighter servers like Tomcat, noting a larger footprint and that Payara Enterprise requires a paid subscription.

本文演示如何在本地下载、安装并启动 Payara Server，以及如何部署一个简单的 Jakarta EE 应用以验证服务器运行。Payara 为 GlassFish 的分支，兼容完整的 Jakarta EE 平台并支持 EJB、WebSocket、JPA 等技术，也可运行 MicroProfile 应用。社区版提供 Full Profile（完整功能）和 Web Profile（精简运行时）。Payara 附带 asadmin 命令行工具用于域的创建与生命周期管理（默认 domain1）以及应用部署。示例说明在 pom.xml 引入 jakarta.servlet-api（scope=provided）、设置 packaging 为 war、编写响应 /hello 的 HelloPayara servlet，然后运行 mvn clean package 生成 WAR。可用 ./asadmin deploy 或管理控制台（http://localhost:4848）部署。文章并讨论了 Payara 的企业功能、较大资源开销与付费企业版等权衡。

Elasticsearch does not support in-place renaming of fields because indexed documents are stored in immutable Lucene segments and mappings are descriptive rather than transformative. Updating a mapping alone won’t change existing documents, so the correct method is to create a new index with the updated field mapping and reindex existing documents using a transformation script that copies the value from the old field to the new field and removes the old key. Before reindexing, inspect index mappings, sample documents, and ingestion pipelines to avoid inconsistencies. Use index aliases to switch traffic to the new index for zero-downtime cutovers and easy rollback. Follow best practices: ensure analyzers and field settings match, run reindexing in staging, throttle or schedule during maintenance windows, and update ingestion clients to write the new field before migration to preserve data integrity.

Elasticsearch 无法直接在原地重命名字段，因为已索引的文档位于不可变的 Lucene segments，mapping 仅描述字段属性并不会修改现有数据。正确流程是创建一个包含新字段定义的新索引，然后使用 _reindex API 并配合脚本，在复制过程中把 old_field 的值复制到 new_field 并移除旧键。操作前应检查索引 mapping、抽查文档并审查摄取管道与客户端逻辑，确保重命名后数据一致。完成重索引后通过索引别名切换以实现零停机并便于回滚。建议在预演环境执行、对齐分析器与字段设置、控制重索引负载，并在迁移前先让摄取端写入新字段以保障数据完整性。

This tutorial demonstrates how to map different Java types to String using MapStruct. It starts with a Maven setup that adds the MapStruct dependency and JUnit for testing. Simple examples show automatic conversion of primitives (an int age to String in Person → PersonDTO) and enums (MapStruct calls enum.name() for enum→String). For dates, the @Mapping(dateFormat = "yyyy-MM-dd") attribute instructs MapStruct to use DateTimeFormatter to produce formatted strings from LocalDate. The guide also covers null handling: nullValueMappingStrategy (for returning default instances) and custom @Named mapping methods to replace null field values with defaults. Unit tests for each case verify the generated, type-safe, compile-time mapping code. Overall, MapStruct reduces boilerplate and produces predictable DTO string representations for API or UI output.

本教程演示如何使用 MapStruct 将不同 Java 类型映射为字符串。以 Maven 项目示例引入 MapStruct 和 JUnit，展示基本示例：将 int 字段映射为字符串（Person → PersonDTO）以及枚举映射为字符串（MapStruct 调用 enum.name()）。对于日期，使用 @Mapping 的 dateFormat 属性并借助 DateTimeFormatter 将 LocalDate 转为格式化字符串。关于空值处理，介绍 nullValueMappingStrategy（例如 RETURN_DEFAULT 返回默认目标实例）以及通过 @Named 的自定义方法为单个字段提供默认值。各例配有单元测试以验证映射结果。总体来说，MapStruct 在编译期生成类型安全的映射代码，减少样板并提高可维护性。

Java Weekly Issue 630 highlights Spring and wider Java ecosystem news, focusing on Spring AI agentic patterns with two deep-dive posts about asking users for clarification and addressing agent task forgetfulness. The issue collects links to key developments such as the Jakarta Persistence 4.0 milestone, the OpenJDK January 2026 critical patch, a decade-long Java garbage collection guide, and practical pieces on functional optics, GPU optimization from Java, and avoiding JPA pitfalls with Kotlin. It lists notable releases (Spring Framework 7.0.3, Spring Security 7.1.0-M1, Quarkus, WildFly 39, Gradle 9.3.0, Hibernate ORM 7.2.1.Final, Elasticsearch 9.2.4, Vert.x, JobRunr) and upcoming webinars. The Technical & Musings section recommends further reading, and the Pick of the Week points to an essay on common logical fallacies.

本期 Java Weekly 侧重 Spring 与 Java 生态的最新动态，重点推荐两篇关于 Spring AI agentic patterns 的深度文章，讨论在执行前向用户澄清以及修复代理忘记任务的方法。文中还汇集了 Jakarta Persistence 4.0 里程碑、OpenJDK 2026 年 1 月关键修补、十年 Java 垃圾回收指南、功能性 optics、Java 的 GPU 优化以及 Kotlin 与 JPA 的常见陷阱等资源。列表式更新包含多项重要发布（如 Spring Framework 7.0.3、Spring Security 7.1.0-M1、Quarkus、WildFly 39、Gradle 9.3.0、Hibernate ORM 7.2.1.Final、Elasticsearch 9.2.4、Vert.x、JobRunr）并推荐相关线上讲座与技术随笔，周荐文章为关于常见逻辑谬误的讨论。

Before Strong Skipping Mode became the default, using immutable collections (kotlinx ImmutableList) was recommended to improve Compose stability and skipping. Now that Strong Skipping Mode is default, converting List<T> to ImmutableList<T> doesn't automatically yield better performance in typical apps. The article compares three cases: an unchanging list instance, a list instance that only changes with content, and frequently recreated list instances with identical content. If the instance never changes, both List<T> and ImmutableList<T> act similarly. If the instance only changes when content changes, ImmutableList adds conversion and O(N) equality costs that are unnecessary since recomposition occurs anyway. If identical content is recreated often, ImmutableList can help by enabling higher-level skipping, but its conversion and equals costs may still outweigh saved work—especially with lazy composables. Conclusion: don't convert defensively; measure and optimize where real bottlenecks appear.

在 Strong Skipping Mode 成为默认之前，Compose 常建议使用不可变集合（kotlinx ImmutableList）以提升稳定性和跳过效果。但默认模式改变后，把来自 Retrofit、Room 等的数据从 List<T> 转为 ImmutableList<T> 并不总是带来性能提升。文章以三种情形比较：实例永不变、仅在内容变更时替换实例、以及内容相同但频繁重建的实例。若实例不变，二者差异很小；若仅在内容变更时替换，ImmutableList 引入的转换与 O(N) 相等比较会成为额外开销；若频繁重建相同内容，ImmutableList 可能帮助上层跳过，但其成本有时会超过节省。结论：不必事前防御性地全部转换，应该以实际测量的瓶颈为依据再优化。

The article argues that encapsulation—hiding state and exposing behavior—becomes crucial when writing tests for domain logic. Using a Wallet example, it shows that a non-encapsulated design keeps business rules outside the model, which allows callers to mutate state directly and lets impossible or invalid states occur unnoticed. Tests in that design only validate correct usage by convention rather than enforcing domain invariants. By moving rules into the Wallet itself (private state, read-only views, and a single add operation), invalid inputs are rejected at the boundary, impossible states cannot be constructed, and bypassing rules is prevented. The core point is not the conditional checks but their placement: encapsulation makes domain objects authoritative about their correctness, yielding simpler tests, fewer broken tests during refactors, and consistent enforcement of invariants.

文章以一个 Wallet（钱包）示例说明封装的重要性：在未封装的设计中，业务规则位于外部（如仓库），任意调用者可以直接修改交易列表或余额，导致不合法或不可能的状态，而测试只是在验证约定的正确使用。将规则内置到 Wallet（私有状态、只读视图与单一的添加交易操作）后，边界会拒绝无效输入，不可能状态无法被构造，规则无法被绕过。关键不在于 if 语句本身，而是它们所在的位置：封装让领域对象负责自身正确性，使测试更可信，重构时破坏测试的概率降低。

KMP WorkManager is a Kotlin Multiplatform task orchestration library that brings enterprise-grade, reliable background processing to both Android and iOS. It addresses platform gaps—Android’s persistent WorkManager vs. iOS’s opportunistic BGTaskScheduler—by offering a pure Kotlin API, robust state restoration, and strategies for platform limits. Key engineering choices include an append-only O(1) queue on iOS for high-performance persistence (benchmarks showing 13–40× improvements), a graceful-shutdown/savepoint mechanism that resumes multi-step chains without restarting work, and Transparent Exact Alarms with explicit iOS behaviors (show notification, attempt background run, or throw error). The library avoids Swift callbacks so shared ViewModel code requires no platform boilerplate, is production-focused (236+ tests, documentation, roadmap), is available on Maven Central (dev.brewkits:kmpworkmanager:2.1.2), and includes a demo app.

KMP WorkManager 是为 Kotlin Multiplatform 提供企业级后台任务编排的库，旨在统一 Android 与 iOS 的后台处理行为。它解决了 Android 的持久任务与 iOS 的机会主义调度之间的差异，提供纯 Kotlin 的 API、可靠的状态恢复机制和应对系统资源限制的策略。关键实现包括：iOS 持久化重写为 Append-Only O(1) 队列以显著提速（基准显示 13–40× 提升）、优雅关机与保存点使多步链可从最后成功步骤继续、以及 Transparent Exact Alarms 允许运维在 iOS 上选择显示通知、尝试后台执行或抛错。项目面向生产（236+ 测试、完整文档、示例 App），已发布于 Maven Central（dev.brewkits:kmpworkmanager:2.1.2），并在持续维护与更新。

Android apps seldom fail due to a single glaring bug; instead they degrade quietly when the surrounding ecosystem changes. In a practical post-mortem, the author recounts several production incidents encountered over the past year: background work that stopped without errors, lifecycle-related memory leaks when using Kotlin Flow, target SDK upgrades that altered runtime behavior, notifications failing on newer Android versions without crashes, CI builds breaking due to unmanaged dependencies, and OEM-specific power-management quirks. Rather than a rant, the write-up analyzes each failure from engineering and architecture perspectives and provides up-to-date fixes, strategies, and real code examples to diagnose and remediate the issues. The piece emphasizes defensive design—adapting to SDK changes, handling background execution limits, managing lifecycle scope, securing CI dependency management, and accounting for OEM battery optimizations—and points readers to the full Medium article for detailed code snippets and implementation guidance.

Android 应用通常不是由单一重大错误引起崩溃，而是在 SDK 升级、后台执行限制、OEM 行为变更或依赖项更新之后悄然失效。作者从工程与架构角度，对过去一年遇到的多起生产问题进行实务事后分析：后台工作静默停止、使用 Kotlin Flow 时的生命周期泄漏、Target SDK 升级改变运行时行为、较新 Android 版本上通知失效但不崩溃、CI 因未管理的依赖中断，以及 OEM 特有的电源管理问题。文章并非抱怨，而是提供即时的修复策略与真实代码示例，强调防御性设计与问题诊断，完整内容与代码请见 Medium 文章。

By 2026 Kotlin Multiplatform (KMP) has shifted from an experimental option to a mainstream choice for teams that want shared logic without compromising native iOS fidelity. The ecosystem supports three practical tiers: keep native SwiftUI for views while sharing logic; use Compose Multiplatform for utility screens and reserve hero screens for SwiftUI (the common hybrid approach); or adopt full Compose UI enabled by Skiko’s direct Metal rendering. Swift Export’s stabilization removes Objective‑C glue, exposing Kotlin types and suspend functions as native Swift entities, simplifying workflows. Real-world cases show large code reductions (42%) and high user parity in shared UI tests, though extreme hardware-dependent components can still suffer (example: a 15% framerate drop in a trading chart). Remaining risks include opaque Compose views for XCTest and careful memory handling for large iOS objects. Tooling (Junie, Fleet, SKIE) eases migration and interop.

到 2026 年，Kotlin Multiplatform 已从“有趣的黑马”转为偏重共用逻辑且保留高保真 iOS 体验团队的默认架构。生态系统形成三种实际取舍：仅共用逻辑并用 SwiftUI 做视图；混合式将设置、表单等工具型界面用 Compose 共用、核心页面保留 SwiftUI（主流做法）；或在 Skiko 的 Metal 渲染支持下实现全 Compose UI。Swift Export 的稳定化取消了 Objective‑C 中间层，使 Kotlin 类与 suspend 函数在 Swift 中表现为本地类型与 async，显著减少黏合工作。实作案例显示代码量下降 42%、大多数 beta 用户无法区分 Compose 与 SwiftUI 页面，但对高频硬件依赖的组件仍可能出现帧率下降（示例为交易图下降 15%）。同时需注意 Compose 在 XCTest 中呈现为不可拆分的单一视图，以及处理大型 iOS 对象时的内存管理风险。

LeetCode problem 217, "Contains Duplicate," asks whether any value appears at least twice in an array. Classified as Easy and tagged Arrays and HashSet, it centers on efficiently detecting repeated elements. The typical and straightforward approach iterates through the array while inserting seen values into a hash set; if an element is already present, the algorithm returns true, otherwise it finishes scanning and returns false. Using a hash set yields expected O(n) time with O(n) extra space; alternatively, sorting can detect duplicates with O(n log n) time but different space trade-offs. The brief Stackademic post lists the title, difficulty, and topic tags and links to the original problem for further reading.

LeetCode 第217题“Contains Duplicate”询问数组中是否有任一值出现至少两次。该题标注为 Easy，主题包括 Arrays 与 HashSet。常见方法是遍历数组，将已见元素加入哈希集合（HashSet），若遇到已存在的元素则返回 true，否则扫描结束返回 false。使用哈希集合在平均情况下可实现线性时间复杂度并且实现简单；也可以通过排序以不同的时间与空间折衷来检测重复。Stackademic 的文章简要列出题目标题、难度和主题标签，并提供链接以便进一步阅读。

This article breaks down how the Jetpack Compose compiler plugin detects and minimizes UI recomposition by leveraging the Slot Table, positional memoization, and generated bytecode. It outlines the Slot Table as the runtime structure that records composable calls and their associated state, explains how positional memoization lets the framework avoid unnecessary work by matching call positions rather than identities, and shows that the compiler emits bytecode to read, write, and compare stored values at runtime. The piece emphasizes why these mechanisms matter for UI performance and predictability, and guides readers through the conceptual flow from source code annotations to the low-level operations that drive efficient updates in Compose-based interfaces.

本文拆解了 Jetpack Compose 编译器插件如何借助 Slot Table、位置化记忆和自动生成的字节码来检测并减少 UI 的重新组合。文章介绍了 Slot Table 在运行时如何记录 composable 的调用顺序与关联状态，解释了位置化记忆如何通过基于位置的匹配避免额外工作，并指出编译器会生成字节码以在运行时读取、写入和比较这些值。作者强调这些机制对界面性能和可预测性的影响，并阐述了从源码标注到低层操作驱动高效更新的概念流程。

This article focuses on three Kotlin collection extension functions—associate, associateBy, and associateWith—and how they help transform collections into maps. It explains the roles of each function: associate builds a map by mapping elements to key-value pairs produced by a transform, associateBy creates a map keyed by a selector function (with elements or transformed values as values), and associateWith builds a map from each element to a computed value. The piece compares their typical use cases, discusses behavior with duplicate keys (last value wins) and nullability considerations, and highlights when to prefer one function over another for clearer, more idiomatic code. Practical examples and tips illustrate how to convert lists and sequences into maps efficiently and readably for everyday Kotlin development.

本文聚焦 Kotlin 的三种集合扩展函数：associate、associateBy 与 associateWith，讲解它们在将集合转换为 Map 时的用途与差异。associate 通过转换函数为每个元素生成键值对；associateBy 使用选择器函数作为键，值为元素或转换后的结果；associateWith 将每个元素映射到一个计算出的值。文章比较典型使用场景，讨论重复键（以最后一个值生效）和可空性等须注意的问题，並提供实用建议与示例，帮助开发者在日常开发中更清晰、惯用地把 List 或 Sequence 等集合转换为 Map。

Dave LumAI’s Episode 18 contrasts bombastic language design with Kotlin’s restrained approach. Rather than arriving 'in a leather jacket' and proclaiming a total rewrite, the piece frames Kotlin as a language that addresses Java’s shortcomings without forcing disruptive change. It highlights Kotlin’s pragmatic interoperability, concise syntax, and gradual adoption path that lets existing Java codebases coexist with newer Kotlin modules. The article uses a family-argument metaphor to stress that improvements can be introduced politely—by offering safer defaults, clearer constructs, and tooling that integrates with established workflows—rather than by demanding immediate replacement. For teams and maintainers, Kotlin is presented as a practical alternative that reduces migration friction while delivering modern language ergonomics, making it possible to evolve a codebase incrementally instead of triggering a divisive overhaul.

Dave LumAI 在第18集中用比喻对比了不同编程语言的姿态：有些语言夸张地宣称要彻底重写一切，而文章把 Kotlin 描绘为一种更克制的选择，旨在修补 Java 的不足而不迫使大刀阔斧的替换。文中强调 Kotlin 与既有 Java 生态的互通性、更简洁的语法与可逐步采用的路径，指出通过更安全的默认设置、清晰的语言构造和兼容的工具链，团队可以在不引发剧烈争论的前提下逐步改进代码库。

In "From Scala to Kotlin: A Frustrated Engineer’s Honest Take," Seetaramayya Vadali admits he feels frustrated and emotional about the transition from Scala to Kotlin. He underscores that his emotions are not merely personal reactions but are rooted in tangible technical and cultural changes affecting engineers and teams. The excerpt frames the piece as a candid, personal perspective that links human feelings to concrete shifts—such as tooling, ecosystem expectations, and team practices—without detailing specific grievances in the short excerpt. The author invites readers to consider both the emotional and technical dimensions of language migration, presenting an honest account that aims to explain why the switch matters on multiple levels and pointing readers to the full Medium post for the complete argument.

在《From Scala to Kotlin: A Frustrated Engineer’s Honest Take》中，作者 Seetaramayya Vadali 坦言对从 Scala 迁移到 Kotlin 感到沮丧且情绪化，但强调这些情绪并非无端，而是扎根于真实的技术与文化变迁。摘录呈現為一段誠懇的個人觀察，指出語言遷移牽涉到工具、生態與團隊實務等具體面向，這些改變會轉化為工程師的情緒反應。作者希望讀者同時關注人性面與技術面，並在 Medium 連結中閱讀完整論述。

This article examines two Kotlin Standard Library utilities—associate and associateTo—and how they help convert collections into maps. It explains their roles, differences, and typical use cases: associate produces a new Map from a collection using key/value selectors, while associateTo writes entries into an existing mutable Map, which can avoid allocations when reusing a destination. The piece highlights when to prefer one over the other, common patterns for transforming collection elements into map entries, and practical tips for writing concise, idiomatic Kotlin using these functions. Readers gain a clearer understanding of how to build maps from collections and when to reuse a destination map for performance or code-structure reasons.

本文介绍 Kotlin 标准库中将集合转换为映射的两个实用函数：associate 与 associateTo，解析它们的作用与差异。associate 根据键值选择器从集合生成并返回新的 Map；associateTo 则把条目写入传入的可变 Map，适合复用目标以减少分配开销。文章讨论何时使用各自函数、常见的转换模式，以及在写出简洁且惯用的 Kotlin 代码时可参考的实践与效能考量，帮助读者更明确地将集合构造成 Map。

This short article presents a clear, practical roadmap for Android development using Kotlin, organized into three progression levels: Junior, Mid, and Senior. It focuses on the topics and skills employers typically expect at each stage, helping developers prioritize what to learn as they advance. Intended as a concise guide rather than exhaustive documentation, the roadmap is useful for planning study, preparing for interviews, and aligning personal growth with industry needs. Readers can use it to identify gaps in their knowledge, set milestones, and communicate their competencies to hiring teams. Although brief, the piece aggregates realistic workplace expectations into actionable learning milestones, making it easier for learners to map effort to career targets and to build a coherent progression that hiring managers recognize.

这篇短文提供一份清晰且实用的 Android（Kotlin）学习路线，按初级→中级→高级三层拆分主题，指出企业在每个阶段实际期待的技能。文章以实务为导向，帮助开发者确定学习优先级、规划进阶目标，并可用于面试准备或与雇主对齐职业发展。它并非详尽教程，而是将职场需求转化为可执行的学习里程碑，便于检视能力差距、建立作品集并展示成长轨迹。

Hidden memory leaks in Android applications are a common but often invisible cause of progressive slowdowns and instability. Because leaks can accumulate gradually or only trigger under specific conditions, they may evade casual testing and appear as unexplained performance regressions in production. Typical causes include accidentally retained Contexts or Views, static references, unremoved listeners or callbacks, and background tasks that outlive their intended scope. Effective mitigation relies on systematic detection with tools like profilers and LeakCanary, disciplined lifecycle management, avoiding long-lived strong references to UI or Context objects, and thorough testing under realistic workloads. Proactive monitoring, regular memory profiling, and adhering to memory-safe patterns during development help unmask and eliminate these silent performance killers before they affect end users.

隐蔽的内存泄漏是 Android 应用中常见但难以直接观察的性能问题，会随着时间消耗更多内存，从而引发运行缓慢或不稳定。由于某些泄漏仅在特定条件或长期运行后显现，常规测试可能察觉不到。典型原因包括错误保留的 Context 或 View、静态引用持有 UI 对象、未注销的监听器或回调，以及超出预期生命周期的后台任务。有效应对需要使用内存分析工具（如 Android Profiler、LeakCanary 等）、严格管理组件生命周期、避免对 UI/Context 的长寿命强引用，并在逼近真实使用场景下进行持续监控与测试，从而在影响用户之前发现并修复泄漏。

In "Stop Letting ViewModels Decide: The Day I Added a Use Case Layer," Manish Dubey describes introducing a use-case layer so ViewModels no longer make business decisions. The post, part of the StreamBox branch-by-branch series, presents the change as a focused refactor: extracting business logic and decision-making into dedicated use-case classes while leaving ViewModels to manage UI state and presentation. The author frames the adjustment as a practical improvement for code clarity, separation of concerns, and easier testing. Written as a concise case study, the article outlines the author’s motivations and the practical direction of the refactor and points readers to the full Medium post for branch-level implementation details.

本文由 Manish Dubey 撰写，记录作者在项目中新增 use‑case 层的经历，目的在于不再让 ViewModel 承担决策与业务逻辑。作为 StreamBox branch‑by‑branch 系列的一篇文章，作者描述将决策逻辑抽离到独立的 use‑case 类中，使 ViewModel 专注于 UI 状态与表现。文章以实务重构为核心，说明此做法如何带来更清晰的职责划分与更容易的测试，并指向 Medium 原文以获取分支级的实现细节。