每日新聞摘要 - 2026年03月18日

01

Guide to MyBatis-Flex

Baeldung 作者：Francesco Galgani 發布：03-18 13:16

Guide to MyBatis-Flex

This tutorial builds a Spring Boot 4 sample using MyBatis-Flex to demonstrate entity mapping, CRUD, QueryWrapper queries, and pagination.

重點摘要

Sets up a Spring Boot 4 project with MyBatis-Flex and H2 datasource

Shows CRUD operations via BaseMapper and integration tests

Demonstrates QueryWrapper for filtered, dynamic queries and built-in pagination

MyBatis-Flex simplifies MyBatis by providing a concise programming model for common data access. This tutorial builds a Spring Boot 4 sample using Java 17+, configures an H2 datasource and MyBatis-Flex dependencies, defines an Account entity and BaseMapper-based AccountMapper, and initializes schema and sample data. It demonstrates basic CRUD (insert, select by id, update, delete) via mapper calls, and shows expressive queries with QueryWrapper for combined conditions, dynamic predicates, and ordering. Pagination via mapper.paginate returns page records and metadata. Tests use Spring Boot integration tests with @MapperScan and injected AccountMapper. The article highlights how MyBatis-Flex reduces boilerplate while supporting flexible queries and built-in pagination, making it a practical alternative to JPA/Hibernate for typical persistence tasks. Examples include schema and data SQL scripts, and tests demonstrating expected outcomes to facilitate learning and integration.

MyBatis-Flex 指南

本文以 Spring Boot 4 範例展示 MyBatis-Flex 的实体映射、CRUD、QueryWrapper 查询与分页功能。

重點摘要

建立 Spring Boot 4 项目并设置 MyBatis-Flex 与 H2 数据源

通过 BaseMapper 与整合测试示范插入、查询、更新与删除

使用 QueryWrapper 构建条件查询（含动态条件）并用 mapper.paginate 分页

MyBatis-Flex 在 MyBatis 之上提供更简洁的資料存取模型。本文以 Spring Boot 4（需 Java 17+）搭建示例，加入 mybatis-flex、Spring JDBC 与 H2 依赖，并在 application.yml 配置内存 H2 数据库与 SQL 初始化脚本。示例定义 Account 实体与继承 BaseMapper 的 AccountMapper，提供 schema 与 data 的 SQL 文件以初始化样本数据。通过 Spring Boot 整合测试展示基本 CRUD 流程，并使用 QueryWrapper 进行组合条件查询、动态条件拼装与排序，最后演示 mapper.paginate 返回分页记录与元数据。文章强调减少样板代码、提高查询可读性，适合在不使用 JPA/Hibernate 时处理常见持久化需求，完整代码托管于 GitHub。

MyBatis-Flex 使用指南

本文以 Spring Boot 4 範例展示 MyBatis-Flex 的實體映射、CRUD、QueryWrapper 查詢與分頁功能。

重點摘要

建立 Spring Boot 4 專案並設定 MyBatis-Flex 與 H2 資料庫

透過 BaseMapper 與整合測試示範插入、查詢、更新與刪除

使用 QueryWrapper 建構條件查詢（含動態條件）與 mapper.paginate 分頁

MyBatis-Flex 在 MyBatis 基礎上提供更簡潔的資料存取模型。本文以 Spring Boot 4（需 Java 17 以上）建置範例專案，加入 mybatis-flex、Spring JDBC 與 H2 相依，並在 application.yml 設定內嵌 H2 資料庫與 SQL 初始化腳本。範例定義 Account 實體與繼承 BaseMapper 的 AccountMapper，並提供 schema 與 data 的 SQL 檔以供測試資料。透過 JUnit 整合測試示範基本 CRUD 操作，以及使用 QueryWrapper 組合多重條件、動態查詢與排序，並示範 mapper.paginate 回傳分頁記錄與頁面資訊。文章強調減少樣板程式、提升查詢可讀性，適合作為不以 JPA/Hibernate 為主的常見持久化實作範例，全文程式碼可於 GitHub 查閱。

02

Introduction to TOON Format in Java

Baeldung 作者：John DeRegnaucourt 發布：03-18 13:30

Introduction to TOON Format in Java

TOON is a compact, human-readable format that encodes the same data model as JSON while using significantly fewer tokens by relying on indentation and tabular layouts.

重點摘要

TOON replaces JSON punctuation with indentation and tabular arrays to cut token use

Java support via JToon (official) and json-io (mature; Java 8+), examples use json-io

Tabular TOON yields ~30–44% token savings for uniform collections and integrates with Spring AI

TOON (Token-Oriented Object Notation) encodes the same primitives, objects, and arrays as JSON but uses indentation and optional tabular rows to reduce syntax repetition and save tokens when sending structured data to LLMs. In Java, two libraries exist: JToon (official, Java 17+) and json-io (stable, Java 8+); this article uses json-io for examples. Json-io automatically emits compact tabular arrays for uniform collections (header once, rows of values), offering substantial token savings—benchmarks show roughly 30–44% fewer BPE tokens for multi-item lists versus JSON, and near-CSV efficiency for flat data while still supporting nesting. The piece covers serializing/deserializing, nested structures, token counting with an OpenAI-compatible tokenizer, and a Spring AI starter that converts tool results to TOON. Use TOON when token cost or context-window pressure matters; stick with JSON where ecosystem, schema validation, or interoperability are primary concerns.

Java 中的 TOON 格式入门

TOON 是一种紧凑且可读的格式，编码与 JSON 相同的数据模型，但通过缩进与表格化布局显著减少 token 使用量。

重點摘要

用缩进和表格数组替代 JSON 的标点，减少键名重复带来的 token 消耗

Java 有 JToon（官方）与 json-io（成熟、支持 Java 8+）；示例采用 json-io

对同构对象集合，表格式 TOON 可节省约 30–44% token，并可集成到 Spring AI

TOON（Token-Oriented Object Notation）在语义上与 JSON 等价，但通过换行缩进和带字段头的表格行来减少语法重复，从而在将结构化数据发送给大型语言模型时降低 BPE token 使用。文章介绍了 Java 生态的两种实现：JToon（官方，Java 17+）和 json-io（稳定，Java 8+），并用 json-io 演示单一对象、表格化集合与嵌套结构的序列化与反序列化，以及使用 OpenAI 风格分词器对比 token 数。实测显示对大量同构列表，TOON 比 JSON 节省约 30–44% 的 token；对纯扁平数据接近 CSV 的效率同时还能表示嵌套结构。建议在关注 token 成本或上下文窗口的 LLM 工作流中使用 TOON，常规服务间通信仍以 JSON 为优选。

Java 中的 TOON 格式入門

TOON 是一種緊湊且可讀的格式，編碼與 JSON 相同的資料模型，但透過縮排與表格化布局大幅減少 token 使用。

重點摘要

以縮排與表格陣列替代 JSON 的標點，減少語法重複的 token

Java 實作包含官方 JToon 與穩定的 json-io（支援 Java 8+），範例採用 json-io

對於欄位一致的集合，表格式 TOON 可節省約 30–44% 的 token，並可整合到 Spring AI

TOON（Token-Oriented Object Notation）在語義上等同 JSON，但改以換行縮排與長度/欄位標頭的表格式陳列來避免在每個物件重複鍵名，對送入大型語言模型（LLM）的結構化資料特別省 token。本文比較 Java 生態中兩個實作：JToon（社群官方）與 json-io（成熟、支援 Java 8+），並用 json-io 展示序列化、反序列化、巢狀結構處理與使用 OpenAI 相容 tokenizer 的 token 計量。結果顯示對於大量同構物件列表，TOON 顯著降低 BPE token 數；相對於 CSV，TOON 在表格式資料接近其效率，但同時支援巢狀與混合結構。當 token 成本或上下文視窗有限時建議使用 TOON；若需廣泛互通或驗證工具則仍以 JSON 為主。

03

How to Implement Room Database CRUD in Android with RecyclerView (Step-by-Step Kotlin Guide)

Dev.to Kotlin 作者：Devika Android 發布：03-18 11:52

How to Implement Room Database CRUD in Android with RecyclerView (Kotlin)

This guide demonstrates a practical implementation using RecyclerView to display Room database records and perform real-time CRUD updates with LiveData and Coroutines.

重點摘要

Use Room with Entity, DAO, and a singleton AppDatabase

Observe LiveData for automatic UI updates in RecyclerView

Perform asynchronous CRUD with Coroutines and lifecycleScope

This tutorial walks through implementing complete CRUD (Create, Read, Update, Delete) operations in an Android app using Room Database and Kotlin. It shows how to define an Entity for the user table, create a UserDao with suspend functions for insert/update/delete and a LiveData query for reads, and set up an AppDatabase as a RoomDatabase. A thread-safe singleton DatabaseBuilder ensures a single database instance. The guide ties Room to the UI using a RecyclerView adapter that accepts onDelete and onUpdate callbacks; the Activity uses lifecycleScope to run database operations and observes getAllUsers() LiveData to update the adapter in real time. The example uses Coroutines, LiveData, and modern adapter patterns to provide a scalable, reactive local data storage approach for Android.

在 Android 中使用 RecyclerView 实现 Room 数据库 CRUD（Kotlin 步骤指南）

本指南展示如何结合 RecyclerView、LiveData 与 Coroutines，实现能够实时更新的 Room 数据库 CRUD 功能。

重點摘要

定义 Entity、DAO 并建立单例 AppDatabase

使用 LiveData 观察数据并自动刷新 RecyclerView

通过 Coroutines 与 lifecycleScope 执行异步的 CRUD 操作

本教程演示了在 Android（Kotlin）中实现完整 CRUD 功能的流程：定义 User 实体（Entity）和 UserDao（包含 suspend 的 insert/update/delete 以及返回 LiveData 的查询），并创建继承自 RoomDatabase 的 AppDatabase。采用线程安全的 DatabaseBuilder 单例模式保证唯一数据库实例。Activity 中使用 lifecycleScope 异步插入、更新和删除用户记录，并通过 getAllUsers().observe 观察 LiveData，将变化传给 UserAdapter 在 RecyclerView 中实时显示。示例运用了 Coroutines、LiveData 与适配器模式，提供了一个简洁、可扩展且响应式的本地数据存储实现。

在 Android 中用 RecyclerView 實作 Room 資料庫 CRUD（Kotlin 步驟指南）

本指南示範如何結合 RecyclerView、LiveData 與 Coroutines，實現可即時更新的 Room 資料庫 CRUD 功能。

重點摘要

建立 Entity、DAO 與單例 AppDatabase

透過 LiveData 觀察資料變化並自動更新 RecyclerView

使用 Coroutines 與 lifecycleScope 執行非同步 CRUD 操作

本篇教學示範如何在 Android（Kotlin）中實作完整的 CRUD 流程：建立 User 實體（Entity）定義欄位與主鍵、撰寫 UserDao 提供 insert、update、delete（suspend）與回傳 LiveData 的查詢、搭配 AppDatabase（RoomDatabase）管理資料存取。示例採用 Thread-safe 的 DatabaseBuilder 單例模式確保單一資料庫實例，並在 Activity 中以 lifecycleScope 執行新增/更新/刪除操作，同時透過 getAllUsers().observe 觀察 LiveData，將資料傳給 UserAdapter 顯示於 RecyclerView。整體以 Coroutines 與 LiveData 建構可擴充、反應式的本地資料存取方案。

04

Kotlin Fundamentals Part 17 — Classes in Kotlin — Normal vs Data Class ️

Medium Kotlin 作者：Kishor Ramani 發布：03-18 12:24

Kotlin Fundamentals Part 17 — Classes: Normal vs Data Class

Classes are blueprints for objects; the article examines when to use a normal class versus a data class in Kotlin.

重點摘要

Classes are blueprints for objects

Data classes are for data carriers and auto-generate utility methods

Use regular classes for behavior, complex state, or custom logic

This article explains the distinction between regular classes and data classes in Kotlin and offers guidance on when to use each. Classes serve as blueprints for objects; data classes are optimized for holding data and provide concise declarations plus automatically generated implementations of utility functions such as equals(), hashCode(), toString(), copy(), and componentN() functions. Data classes are appropriate when instances primarily represent data carriers and when value-based equality and convenient copying are desired. Regular classes are better suited when encapsulated behavior, complex or mutable state, custom equality, inheritance hierarchies, or additional methods and logic are needed. The piece also discusses practical considerations such as immutability and cases where auto-generated methods may be insufficient, helping developers choose the most appropriate class type for their design and use cases.

Kotlin 基础第17篇 — 类：普通 class 与 data class 的比较

类是对象的蓝图；文章讨论在 Kotlin 中何时使用普通 class 与 data class。

重點摘要

类是对象的蓝图

data class 适合承载数据并自动生成常用方法

普通 class 适用于行为、复杂或可变状态与自定义逻辑

本文说明 Kotlin 中普通 class 与 data class 的差异，并提供实践选择指引。类是对象的蓝图；data class 适合以数据为主的类型，声明简洁且会自动生成 equals、hashCode、toString、copy 与 componentN 等常用函数，便于以值为基础的比较与复制。若需要封装行为、处理复杂或可变状态、实现自定义相等性或使用继承与额外方法，则普通 class 更合适。文章还讨论不可变性、语法简洁的优势，以及在何种情况下自动生成的方法可能不足，帮助开发者根据用途选择最合适的类类型。

Kotlin 基礎第17篇 — 類別：普通 class 與 data class 的比較

類別是物件的藍圖；文章探討何時在 Kotlin 中使用普通 class 或 data class。

重點摘要

類別是物件的藍圖

data class 適合承載資料並自動產生常用方法

普通 class 適用於行為、複雜或可變狀態與自訂邏輯

本文說明 Kotlin 中普通 class 與 data class 的差異，並提供實務選擇指引。類別是物件的藍圖；data class 適合以資料為主的型別，宣告簡潔且會自動產生 equals、hashCode、toString、copy 與 componentN 等常用函式，方便以值為基礎的比較與複製。若需要封裝行為、處理複雜或可變狀態、實作自訂相等性或利用繼承與額外方法，則普通 class 更為合適。文章同時說明不可變性、語法簡潔的優勢，以及在何種情況下自動產生的方法不敷使用，幫助開發者根據用途選擇最合適的類別類型。

05

9 Kotlin Coroutine Mistakes Android Developers Still Make (Even with Compose)

Medium Kotlin 作者：Rodrigo Kirch 發布：03-18 12:33

9 Kotlin Coroutine Mistakes Android Developers Still Make (Even with Compose)

GlobalScope misuse, Flow collector leaks, coroutineScope vs supervisorScope, and other subtle coroutine bugs that show up in real Android apps.

重點摘要

GlobalScope misuse can create uncancelled work and leaks

Flow collectors may leak if not tied to lifecycle or cancelled properly

Confusing coroutineScope and supervisorScope leads to unexpected cancellations

This article catalogs nine common Kotlin coroutine mistakes that Android developers continue to make, even when using modern UI frameworks like Jetpack Compose. It calls out frequent issues such as misusing GlobalScope (which can spawn work outliving intended lifecycles), leaking Flow collectors when they aren’t tied to lifecycle-aware scopes, and confusing the semantics of coroutineScope versus supervisorScope so failures propagate unexpectedly. The piece highlights how subtle bugs around cancellation, exception handling, and improper scope ownership surface in real apps, and emphasizes adopting structured concurrency and lifecycle-aware scoping to avoid leaks and unpredictable behavior. Practical guidance centers on binding coroutines to appropriate owners, handling exceptions explicitly, and preferring patterns that ensure correct cancellation and resource cleanup.

Android 开发者仍会犯的 9 个 Kotlin Coroutine 错误（即使使用 Compose）

GlobalScope 滥用、Flow collector 泄漏、coroutineScope 与 supervisorScope 的混淆，以及在真实 Android 应用中出现的其他细微 coroutine 错误。

重點摘要

滥用 GlobalScope 会导致无法取消的任务和内存泄漏

若未与生命周期绑定，Flow 的 collectors 易于泄漏

混淆 coroutineScope 与 supervisorScope 会引发意外取消

本文汇总了九个 Android 开发中常见的 Kotlin coroutine 错误，指出即便在使用 Jetpack Compose 的情况下也并非罕见。文章提到常见问题包括 GlobalScope 的误用会让协程超出预期生命周期、Flow collector 未正确绑定或取消会导致泄漏、以及对 coroutineScope 与 supervisorScope 的误解会让失败传播和取消行为不可预测。作者建议采用结构化并发和生命周期感知的作用域、显式处理异常，并确保正确的取消与资源清理，以降低内存泄漏与不确定行为的风险。

Android 開發者仍會犯的 9 個 Kotlin Coroutine 錯誤（即使在 Compose 中也會）

GlobalScope 濫用、Flow collector 洩漏、coroutineScope 與 supervisorScope 的混淆，及其他在真實 Android 應用中出現的細微 coroutine 錯誤。

重點摘要

濫用 GlobalScope 會產生無法取消的工作與記憶體洩漏

Flow 的 collectors 若未綁定生命週期容易洩漏

coroutineScope 與 supervisorScope 的差異常導致意外取消

文章列出九種常見的 Kotlin coroutine 錯誤，指出即便採用 Jetpack Compose，開發者仍會遇到這些陷阱。作者舉例說明像是 GlobalScope 的誤用會讓工作超出預期生命週期、Flow collector 若未妥善綁定生命週期或取消會造成洩漏、以及誤解 coroutineScope 與 supervisorScope 的行為會導致意外取消或錯誤傳播。文中強調需採用結構化併發與生命週期感知的 scope、明確處理例外並確保取消與資源清理機制，以避免難以察覺且會影響穩定性的問題。

06

Android App Development Training in Delhi | Best Android Course for Beginners & Developers

Medium Kotlin 作者：JustAcademy Software Training Institute 發布：03-18 13:23

Android App Development Training in Delhi | Best Android Course for Beginners & Developers

This course is designed for students, freshers, beginners and developers seeking Android app development training in Delhi.

重點摘要

Android app development training offered in Delhi

Targeted at students, freshers, beginners and developers

Published by JustAcademy Software Training Institute on Medium

This Medium post from JustAcademy Software Training Institute announces an Android App Development Training in Delhi. Presented under the title “Android App Development Training in Delhi | Best Android Course for Beginners & Developers,” the brief excerpt states the course is designed for students, freshers, beginners and developers interested in Android development. The available text is a short preview that directs readers to continue reading on Medium for the full article. The snippet itself does not provide detailed information about syllabus, duration, schedule, fees, prerequisites, or enrollment, so prospective learners are advised to follow the Medium link to view the complete post and obtain full course details and contact information.

德里 Android 应用开发培训 | 适合初学者与开发者的最佳 Android 课程

本课程为在德里寻求 Android 应用开发培训的学生、应届生与开发者而设。

重點摘要

在德里提供 Android 应用开发培训

面向学生、应届生、初学者与开发者

由 JustAcademy Software Training Institute 发布于 Medium

这篇由 JustAcademy Software Training Institute 在 Medium 发布的短文，介绍了在德里开展的 Android 应用开发培训。标题为“德里 Android 应用开发培训 | 适合初学者与开发者的最佳 Android 课程”，摘录指出该课程面向学生、应届生、初学者与开发者。当前内容仅为预览并提示读者在 Medium 上继续阅读全文；摘录本身未提供课程大纲、时长、学费、报名或先修条件等具体信息。感兴趣的读者应通过原文链接获取完整课程详情与联系方式。

德里 Android 應用程式開發訓練 | 適合初學者與開發者的最佳 Android 課程

此課程為在德里尋求 Android 應用程式開發訓練的學生、應屆生與開發者而設。

重點摘要

在德里提供 Android 應用程式開發訓練

對象為學生、應屆生、初學者與開發者

由 JustAcademy Software Training Institute 發表於 Medium

這則由 JustAcademy Software Training Institute 發表於 Medium 的短文，介紹在德里舉辦的 Android 應用程式開發訓練。標題稱為「德里 Android 應用程式開發訓練 | 適合初學者與開發者的最佳 Android 課程」，摘錄指出課程為學生、應屆生、初學者與開發者設計。本文僅為預覽並提示讀者至 Medium 上繼續閱讀完整文章；摘錄內未提供課程大綱、時程、學費、報名或先修條件等具體資訊。對該訓練感興趣的人應點開原文以取得完整細節與聯絡方式。

07

Jetpack Compose State Survival Guide: From remember to rememberNavBackStack

Medium Kotlin 作者：chanzmao 發布：03-18 14:34

Jetpack Compose State Survival Guide: From remember to rememberNavBackStack

One of the most critical decisions in Jetpack Compose development is choosing where to store your UI state.

重點摘要

Choosing where to store UI state is a critical decision.

The guide spans techniques from remember to rememberNavBackStack.

Advice focuses on lifecycle and navigation scope for state survival.

This article explains why selecting where to keep UI state is one of the most critical decisions in Jetpack Compose. Covering techniques from remember to rememberNavBackStack, it surveys state-storage approaches and how they relate to component lifecycle, navigation scope, and state survival across recompositions and navigation events. The guide helps developers weigh trade-offs—such as short-lived in-composable memory versus navigation-aware storage—so they can choose an appropriate place for state depending on lifecycle requirements and user flows. It emphasizes practical patterns for preserving UI state when components are recreated or when navigating between destinations. Readers can expect a practical framework to decide which storage mechanism matches their UI's lifecycle and persistence needs, improving consistency and reducing bugs related to unexpected state loss.

Jetpack Compose 状态存活指南：从 remember 到 rememberNavBackStack

在 Jetpack Compose 开发中，选择将 UI 状态存放在哪里是最关键的决策之一。

重點摘要

确定 UI 状态的存放位置非常关键。

文章涵盖从 remember 到 rememberNavBackStack 的技术路径。

以生命周期和导航范围为依据提供实务选择建议。

本文阐述在 Jetpack Compose 中为何选择 UI 状态的存放位置至关重要，並從 remember 到 rememberNavBackStack 介紹不同策略，說明它們與組件生命週期、導覽範圍以及狀態在重組或導覽過程中的存活關係。文章提供實務方向，幫助開發者根據生命週期與持久性需求選擇合適的狀態儲存方式，以提高介面一致性並減少因狀態遺失帶來的錯誤。

Jetpack Compose 狀態存活指南：從 remember 到 rememberNavBackStack

在 Jetpack Compose 開發中，選擇將 UI 狀態儲存在哪裡是最關鍵的決策之一。

重點摘要

決定 UI 狀態的儲存位置至關重要。

內容涵蓋從 remember 到 rememberNavBackStack 的技術。

以生命週期與導覽範圍為基準提供選擇指引。

本文說明在 Jetpack Compose 中選擇儲存 UI 狀態的位置為何至關重要，並從 remember 到 rememberNavBackStack 介紹不同做法，討論它們與元件生命週期、導覽範圍及狀態在重組或導覽間的存活關係。文章提供判斷依據與實務方向，幫助開發者根據生命週期與持久性需求選擇合適的狀態儲存位置，以提升介面一致性並降低因狀態遺失導致的錯誤。

08

GraalVM Native Image, 리플렉션을 넘을 수 있는가?

Medium Kotlin 作者：주진현 發布：03-18 14:39

GraalVM Native Image — Can It Overcome Reflection?

Kotlin + Spring backend's future (Part 2/5).

重點摘要

Examines GraalVM Native Image in relation to reflection

Considers implications for Kotlin and Spring backends

This article is Part 2 of a five-part series

This article examines the question posed by its title: whether GraalVM Native Image can surmount the challenges posed by reflection. Framed within the Kotlin + Spring backend context, the piece situates the discussion as the second installment in a five-part series. Rather than asserting a definitive outcome, it explores compatibility concerns, common limitations of native-image tooling when encountering reflection-heavy frameworks, and the practical considerations developers must weigh when targeting native images from JVM-based Kotlin/Spring applications. The article outlines the problem space and highlights why reflection poses obstacles for ahead-of-time compilation, while indicating the need for specific configuration, tooling support, or alternative design patterns to address those issues in production systems.

GraalVM Native Image：能克服反射限制吗？

Kotlin + Spring 后端的未来（2/5 篇）。

重點摘要

讨论 GraalVM Native Image 与反射的关系

针对 Kotlin 与 Spring 后端场景展开

为该系列文章的第二篇

文章围绕是否能用 GraalVM Native Image 克服反射问题展开讨论，背景为 Kotlin + Spring 的后端开发，并标示为五篇系列的第二篇。作者说明了反射在 ahead-of-time 编译与 native-image 工具链中带来的兼容性与功能限制，强调这不是单一结论的论断，而是阐述问题范畴、反射为何成为障碍，以及在将 JVM 基础的 Kotlin/Spring 应用目标化为原生映像时，开发者需要考虑的配置、工具支持或替代设计等实际对策。

GraalVM Native Image：能克服反射限制嗎？

Kotlin + Spring 後端的未來（2/5 篇）。

重點摘要

探討 GraalVM Native Image 與反射相關問題

聚焦 Kotlin 與 Spring 的後端情境

本篇為五篇系列文章的第二篇

本文圍繞標題提出的問題，探討 GraalVM Native Image 是否能克服反射帶來的限制。文章以 Kotlin + Spring 的後端開發為場景，作為五篇系列的第二篇，描述了在使用 ahead-of-time 編譯與 native-image 工具時，反射如何成為相容性與功能上的挑戰。內容並未強調單一結論，而是說明問題面向、為何反射會阻礙原生映像，以及開發者在將 JVM 基礎的 Kotlin/Spring 應用目標化為 native image 時，可能需採取的設定、工具支援或設計替代方案等現實考量。

09

Kotlin Coroutines — Complete In-Depth Reference

Medium Kotlin 作者：Mahendra Sutar 發布：03-18 14:45

Kotlin Coroutines — Complete In-Depth Reference

From fundamentals to internals — everything you need to use coroutines confidently in your Kotlin projects.

重點摘要

Comprehensive coverage from fundamentals to internals

Designed to enable confident use of coroutines in Kotlin projects

Published on Medium by Mahendra Sutar

This Medium article by Mahendra Sutar is presented as a complete, in-depth reference for Kotlin coroutines. It emphasizes coverage that ranges from foundational concepts to internal implementation details, with the stated aim of giving Kotlin developers the knowledge and context needed to use coroutines confidently in their projects. The piece functions as a consolidated resource for readers seeking both an introduction and deeper technical perspective on coroutines; it directs readers to continue reading on Medium for the full content. The article’s positioning suggests it is intended for developers who want a broad, structured, and detailed reference rather than a short tutorial.

Kotlin 协程 — 完整深入参考

从基础到内部实现 — 为你在 Kotlin 项目中自信使用协程提供所需的一切。

重點摘要

覆盖从基础概念到内部实现

旨在让开发者在项目中自信使用协程

作者 Mahendra Sutar，发表于 Medium

这篇由 Mahendra Sutar 在 Medium 发布的文章，被定位为 Kotlin 协程的完整且深入参考。文章强调内容涵盖从基础概念到内部实现细节，目的是为使用 Kotlin 的开发者提供在项目中自信运用协程所需的知识与背景。作为一个整合性资源，它适合希望从概览到更深层次理解协程的读者，并引导读者在 Medium 上继续阅读完整内容。该文偏向于提供广泛且有结构的参考，而非简短教程。

Kotlin 協程 — 完整深入參考

從基礎到內部實作 — 提供你在 Kotlin 專案中自信使用協程所需的一切。

重點摘要

涵蓋從基礎概念到內部實作

目標是讓開發者在專案中自信使用協程

作者 Mahendra Sutar，在 Medium 發表

這篇由 Mahendra Sutar 在 Medium 發表的文章，定位為 Kotlin 協程的完整且深入參考資料。文中強調內容範圍從基本概念延伸至內部實作細節，目的是讓使用 Kotlin 的開發者獲得在專案中自信運用協程所需的知識與脈絡。文章作為一個整合性的資源，適合希望從概覽到更深技術面理解協程的讀者，並引導讀者前往 Medium 閱讀完整內容。此篇偏向提供廣泛且有架構的參考，而非短篇教學。

10

Handling Accessibility Events Without ANR

Medium Kotlin 作者：Abdullah IŞIK 發布：03-18 14:53

Handling Accessibility Events Without ANR

If you have ever built an AccessibilityService, you have likely run into ANR reports that are hard to reproduce locally.

重點摘要

AccessibilityService can trigger hard-to-reproduce ANRs

Article analyzes root causes of event-handling ANRs

Suggests design and diagnostic approaches to avoid ANR

Many developers building AccessibilityService encounter ANR reports that are difficult to reproduce locally. This article examines that problem, identifies common root causes in how accessibility events are handled, and outlines general approaches to prevent ANR without relying on platform-specific hacks. It discusses why event handling can block the app or the system, how intermittent timing and environment differences make reproduction hard, and how careful design—such as minimizing work on critical threads, batching or deferring nonessential processing, adding instrumentation and robust logging, and validating behavior on real devices and user scenarios—can reduce ANR incidence. The piece emphasizes diagnostic practices, monitoring, and incremental fixes so developers can both find the underlying issue and adopt safer patterns for processing accessibility events in production.

在不发生 ANR 的情况下处理可访问性事件

如果你曾经构建过 AccessibilityService，很可能遇到在本地难以重现的 ANR 报告。

重點摘要

AccessibilityService 易导致难以重现的 ANR

分析事件处理引发 ANR 的根本原因

提出设计与诊断策略以避免 ANR

文章指出，开发 AccessibilityService 时常会遇到难以在本地重现的 ANR 报告，分析了事件处理导致 ANR 的常见根本原因，并提出避免 ANR 的一般做法。文中解释了为何处理可访问性事件可能造成应用或系统卡顿、时序与环境差异如何使重现变得困难，以及通过减少关键线程上的工作量、批处理或延后非必要处理、加强调试与日志记录，并在真实设备与实际情境中验证等策略，可以降低 ANR 发生的概率。文章强调诊断与监控的重要性，并建议通过渐进式修复来定位问题并改进事件处理模式。

在不發生 ANR 的情況下處理可及性事件

如果你曾經建立過 AccessibilityService，很可能遇到在本地難以重現的 ANR 報告。

重點摘要

AccessibilityService 容易引發難以重現的 ANR

分析事件處理導致 ANR 的根本原因

提出設計與診斷策略以避免 ANR

本文指出，開發 AccessibilityService 時常會遇到難以在本地重現的 ANR 報告，分析了事件處理造成 ANR 的常見根本原因，並提出避免 ANR 的一般做法。文章說明了為何處理可及性事件可能導致應用或系統卡頓、時序與環境差異如何讓重現變得困難，以及透過減少關鍵執行緒工作量、批次或延後非必要處理、加強偵錯與日誌、並在真實設備與實際情境驗證等策略，能降低發生 ANR 的機率。文章強調診斷與監控的重要性，以及採行漸進修正以定位問題與改進事件處理模式。

11

Virtual Threads가 리액티브를 죽이는가?

Medium Kotlin 作者：주진현 發布：03-18 14:58

Do Virtual Threads Kill Reactive?

This installment examines whether Java virtual threads might make reactive programming unnecessary in the context of Kotlin and Spring.

重點摘要

Part 3 of a Kotlin + Spring series

Compares virtual threads and reactive programming

Hosted as a continuation on Medium

This Medium post, the third installment in a five-part Kotlin + Spring series, considers whether Java's virtual threads threaten the role of reactive programming. It frames the discussion around how virtual threads simplify concurrency by making blocking code cheaper, and contrasts that with the non-blocking, backpressure-oriented model of reactive systems. The author raises practical questions about performance, scalability, library and framework support, and operational trade-offs, and emphasizes that whether virtual threads 'replace' reactive approaches depends on workload and ecosystem maturity. Rather than declaring a definitive winner, the article situates the debate within Kotlin and Spring development and points readers to further examples and follow-up installments for deeper analysis.

Virtual Threads 会取代 Reactive 吗？

本文在 Kotlin 与 Spring 的背景下探讨 Java 的 virtual threads 是否让 reactive 编程变得多余。

重點摘要

Kotlin + Spring 系列第 3 篇

对比 virtual threads 与 reactive 编程

发布于 Medium，作为系列延续

这篇 Medium 文章是 Kotlin + Spring 系列的第三篇，讨论 Java 的 virtual threads 是否会影响 reactive 编程的必要性。文章指出 virtual threads 让阻塞代码的代价降低，并将其与以非阻塞和背压为特点的 reactive 模式进行对比，同时提出关于性能、可扩展性、库与框架支持以及运维等现实问题的考量。作者并未给出绝对结论，而是指出是否被取代取决于具体负载与生态成熟度，并建议读者参考后续篇章与示例以获得更深入的分析。

Virtual Threads 會取代 Reactive 嗎？

本文探討在 Kotlin 與 Spring 的情境下，Java 的 virtual threads 是否使 reactive 編程顯得多餘。

重點摘要

Kotlin + Spring 系列第 3 篇

比較 virtual threads 與 reactive 編程

文章為 Medium 系列延續內容

這篇 Medium 文章是 Kotlin + Spring 系列的第三篇，討論 Java 的 virtual threads 是否會威脅到 reactive 編程的地位。文章說明 virtual threads 讓阻塞程式碼的成本降低，並與以非阻塞與背壓為核心的 reactive 模式做比較，同時提出效能、可擴展性、函式庫與框架支援，以及實務部署等面向的考量。作者未直接斷言哪方必勝，而是強調取捨取決於具體工作負載與生態成熟度，並引導讀者參考後續篇章與實例以獲得更完整的分析。

12

Koin Educational Series, Production Setup with Annotations and the New Compiler

Medium Kotlin 作者：Tezov 發布：03-18 15:10

Koin Educational Series: Production Setup with Annotations and the New Compiler

This story finally starts the educational series about using dependency injection with annotations in a company-grade application.

重點摘要

Launches an educational series on dependency injection with annotations

Focuses on production-ready setup for company-grade applications

Introduces the new Koin compiler in the context of annotated DI

This post marks the start of an educational series from the Koin team that explores using dependency injection (DI) with annotations in production-grade applications. It introduces the series' goal of guiding developers through a production-ready setup that leverages annotations and the new Koin compiler, showing how DI can be applied in company-grade projects. While this introductory story announces the series and its focus, subsequent posts are expected to cover practical setup details, tooling considerations, and how the new compiler integrates with annotated DI to support maintainable, scalable code. The article is published on the Koin Developers blog and targets developers seeking concrete patterns for adopting Koin's annotated DI in real-world production environments. The series aims to balance conceptual guidance with hands-on direction to help teams implement DI patterns that scale without sacrificing testability.

Koin 教学系列：使用注解与新版编译器的生产环境设置

本文正式开启关于在公司级应用中使用注解进行依赖注入的教学系列。

重點摘要

开启以注解为核心的依赖注入教学系列

聚焦于公司级（生产）环境的设置与实务应用

介绍新版 Koin 编译器与注解式 DI 的整合

本文为 Koin 教学系列的首篇，说明在公司级（production-grade）应用中以注解（annotations）实现依赖注入（DI）的方向与重点。文章宣布将介绍基于注解的生产环境配置与新版编译器的整合方式，旨在为开发团队提供可在真实项目中采用的模式与流程，帮助在大型或企业级项目中引入 Koin 的注解式 DI，同时兼顾可维护性与可测试性。后续内容预计深入配置细节、工具配合与迁移建议，并示范如何在实际项目中应用这些做法。

Koin 教學系列：使用註解與新版編譯器的生產環境設定

本文正式開始以註解在公司級應用中使用依賴注入的教學系列。

重點摘要

啟動以註解為核心的依賴注入教學系列

強調公司級（生產）環境的設定與實務應用

介紹新版 Koin 編譯器與註解式 DI 的整合

本文為 Koin 教學系列的首篇，說明在公司級（production-grade）應用中以註解（annotations）實作依賴注入（DI）的方向與重點。文章宣告將介紹以註解為基礎的生產環境設定與新版編譯器的整合方式，目標是為開發團隊提供可在真實專案中採用的模式與流程，協助在大型或企業等級專案中導入 Koin 的註解式 DI，同時兼顧可維護性與可測試性。後續章節預計深入設定細節、工具協同與遷移建議，並示範如何在實際專案中應用這些做法。

13

Coroutine Dispatchers in Android: The Complete Guide

Medium Kotlin 作者：Sergey Nes 發布：03-18 15:13

Coroutine Dispatchers in Android: The Complete Guide

Every Android developer using coroutines has been here: you open a Repository, stare at a suspend fun, and wonder—do I need…

重點摘要

Explains common Android coroutine dispatchers and their intended uses

Shows when to switch contexts and how to avoid blocking threads

Summarizes best practices for UI, IO, and CPU-bound work

This complete guide to coroutine dispatchers in Android helps developers understand which dispatcher to choose for different workloads and why it matters. It frames the common situation of examining a suspend function and deciding whether to confine execution to the Main dispatcher, offload to IO for networking and disk, or use Default for CPU-intensive tasks. The article explains dispatcher behavior, context switching, and practical patterns to avoid blocking the main thread, maintain structured concurrency, and write safer, more testable code. It also covers common pitfalls and gives guidance on using Dispatchers.Main, Dispatchers.IO, Dispatchers.Default (and alternatives), plus tips for testing and performance considerations. Readers should come away able to select appropriate dispatchers, minimize thread misuse, and structure coroutine usage more intentionally in Android apps.

Android 中的 Coroutine Dispatchers：完整指南

每位使用 coroutine 的 Android 开发者都遇过：打开 Repository，盯着 suspend fun，心想——我需要…

重點摘要

说明常见 dispatcher 及其适用场景

何时切换执行上下文与如何避免阻塞线程

针对 UI、IO 与 CPU 工作提供实用建议

本指南旨在帮助 Android 开发者理解如何为不同任务选择合适的 coroutine dispatcher，强调选择对应用正确运行与性能的重要性。文章从常见困惑出发：面对一个 suspend 函数应该使用 Main、IO 还是 Default，并解释各 dispatcher 的行为与适用场景（如 UI 更新、网络/磁盘 IO、CPU 密集型计算）。內容涉及上下文切换模式、避免阻塞主线程、保持结构化并发，以及测试与性能优化的注意点。阅读后，开发者应能更自信地为不同负载选定 dispatcher，减少线程滥用，使 coroutine 在 Android 项目中更稳健与易维护。

Android 中的 Coroutine Dispatchers：完整指南

每位使用 coroutine 的 Android 開發者都遇過：打開 Repository，盯著 suspend fun，心想──我需要…

重點摘要

說明常見的 dispatcher 與其適用場景

何時切換執行緒上下文與如何避免阻塞

針對 UI、IO 與 CPU 工作提供實務建議

本指南說明在 Android 開發中如何選擇與使用 coroutine dispatcher，幫助開發者釐清不同 dispatcher 的用途與重要性。文章以常見情境為出發：面對一個 suspend 函式應該用 Main、IO 還是 Default，並說明各自對應的使用情境（例如 UI 更新、網路/檔案 IO、CPU 密集運算）。內容涵蓋 dispatcher 行為、上下文切換的實作模式、避免阻塞主執行緒與維持結構化併發的做法，並提出測試與效能上的注意事項。閱讀後，可更有把握地為不同任務選擇合適 dispatcher、減少執行緒誤用，並讓 coroutine 的使用在 Android 專案中更安全與可維護。

14

Google Summer of Code 2026 Is Here: Contribute to Kotlin

Kotlin Blog 作者：Ksenia Shneyveys 發布：03-18 13:11

Google Summer of Code 2026 Is Here: Contribute to Kotlin

If you are a student or an eligible contributor looking to spend your summer working on a real-world open-source project, this is your chance to make a meaningful impact on the Kotlin ecosystem while also benefiting from the mentorship of experienced engineers.

重點摘要

Kotlin Foundation is participating in GSoC 2026 to recruit student contributors.

Featured projects include a compiler fuzzer, Swift→Kotlin interop PoC, Wasm tail call support, and an education landscape report.

Key dates: applications open Mar 16, deadline Mar 31; accepted projects Apr 30; coding begins May 25.

The Kotlin Foundation is joining Google Summer of Code (GSoC) 2026, inviting students and eligible contributors to spend their summer working on real-world Kotlin open-source projects with mentor guidance, a stipend, and production experience. Project ideas include a new modular Kotlin Compiler Fuzzer (Kai) (hard, 350 hrs), a Swift-to-Kotlin interop proof of concept (hard, 350 hrs), tail call support for Kotlin/Wasm (medium, 90 hrs), and a Kotlin education landscape report (medium, 175 hrs). Important dates: contributor applications open March 16, the application deadline is March 31, accepted projects are announced April 30, and coding begins May 25. To apply, pick a project, join the #gsoc channel on Kotlin Slack to consult mentors, review contributor guidelines, prepare a code sample, and submit on the GSoC website. Non-students can consider the Kotlin Ecosystem Mentorship Program; questions can be asked on Slack or via gsoc@kotlinfoundation.org.

Google Summer of Code 2026 来了：为 Kotlin 做贡献

如果你是学生或符合资格的贡献者，想在暑期参与真实的开源项目，这是在经验工程师指导下对 Kotlin 生态产生实际影响的机会。

重點摘要

Kotlin Foundation 参与 GSoC 2026，招募暑期学生贡献者。

项目包括编译器模糊测试器、Swift→Kotlin 互操作概念验证、Wasm 尾调用支持和教育现状报告。

重要日期：3/16 开放申请、3/31 截止、4/30 公布录取、5/25 开始编码。

Kotlin Foundation 参与 Google Summer of Code 2026，邀请学生和合格贡献者在暑期参与 Kotlin 的真实开源项目，在导师指导下获得津贴并积累生产经验。本年度项目示例包括：从零构建的 Kotlin Compiler Fuzzer（Kai，困难，350 小时）、将 Swift API 导入 Kotlin/Native 的概念验证（困难，350 小时）、在 Kotlin/Wasm 后端设计与实现尾调用支持（中等，90 小时）以及研究 Kotlin 教学现状并创建可复用数据集的教育景观报告（中等，175 小时）。重要日程：3 月 16 日开放申请、3 月 31 日截止、4 月 30 日公布录取，5 月 25 日开始编码。申请步骤：选择项目、加入 Kotlin Slack 的 #gsoc 与导师联系、准备代码样本并在 GSoC 网站上提交。非学生可关注 Kotlin 生态导师计划；问题可在 Slack 或发邮件至 gsoc@kotlinfoundation.org 咨询。

Google Summer of Code 2026：為 Kotlin 做出貢獻

如果你是學生或符合資格的貢獻者，想在暑期投入真實開源專案，這是透過經驗工程師指導、對 Kotlin 生態產生實質影響的好機會。

重點摘要

Kotlin Foundation 參與 GSoC 2026，徵求暑期學生貢獻者。

專案包括編譯器模糊測試器、Swift→Kotlin 互通 PoC、Wasm 尾呼叫支援與教育調查報告。

重要日程：3/16 開放申請、3/31 截止、4/30 公布錄取、5/25 開始編碼。

Kotlin Foundation 參加 Google Summer of Code 2026，邀請學生與合格貢獻者在暑期參與 Kotlin 的真實開源專案，透過資深工程師指導取得補助並累積實務經驗。本年度專案示例包含：從頭建構的 Kotlin Compiler Fuzzer（Kai，困難，350 小時）、將 Swift API 匯入 Kotlin/Native 的概念驗證（困難，350 小時）、在 Kotlin/Wasm 後端設計與實作尾呼叫支援（中等，90 小時），以及調查 Kotlin 教學現況並建立可重用資料集的教育景觀報告（中等，175 小時）。申請流程：選擇專案、加入 Kotlin Slack 的 #gsoc 與導師連絡、準備程式範例並於 GSoC 網站在 3/31 前提交。非學生可關注 Kotlin 生態導師計畫；問題可在 Slack 或寄信至 gsoc@kotlinfoundation.org 詢問。

15

How I turned task-to-release routine into a single Android workflow

Medium Kotlin 作者：Nurattin 發布：03-17 23:19

How I turned task-to-release routine into a single Android workflow

We didn't have a broken process — we had a process made of too many small manual steps.

重點摘要

The workflow wasn't broken, but consisted of many small manual steps.

The author consolidated task-to-release into a single Android workflow.

Goal: reduce manual overhead and streamline releases for consistency.

The article explains how the author transformed a multi-step, manually intensive Android release routine into a single streamlined workflow. Rather than fixing a broken process, the author observed that the existing routine was composed of numerous small manual steps that introduced friction and risk. By consolidating those steps into one coherent Android workflow, the effort reduced repetitive manual actions, clarified the end-to-end path from task to release, and improved consistency across releases. The piece covers the motivations for consolidation, considerations and trade-offs when replacing manual checkpoints with automation, and practical lessons about designing robust yet flexible workflows. The central argument is that simplifying many small manual steps into an automated workflow improves developer experience and release reliability.

我如何将从任务到发布的例行流程整合为单一 Android 工作流

我们的流程并不是坏掉，而是由太多小的手动步骤组成。

重點摘要

流程本身没有损坏，但由过多小手动步骤组成。

作者将任务到发布的过程整合为单一 Android 工作流。

目的是减少手动操作，简化发布并提高一致性。

作者描述了如何将原本由许多小而繁琐的手动步骤构成的 Android 发布例行流程，转变为单一且连贯的工作流。关键并非修补一个“坏掉”的流程，而是识别出流程被过多零散手动步骤拆分，导致摩擦与风险。通过将这些分散且重复的步骤合并并自动化，减少了手动操作，理顺了从任务到发布的端到端路径，并提升了发布的一致性。文章还讨论了推动整合的动机、用自动化替代人工检查时的权衡，以及实务上的经验教训。总体观点是：把零散的小步骤简化为连贯的自动化流程，可以改善开发者体验并提高发布可靠性。

我如何將從任務到發佈的例行程序整合為單一 Android 工作流程

我們的流程並非壞掉，而是由太多小的手動步驟組成。

重點摘要

流程不是壞掉，而是被過多小手動步驟拆散。

作者把從任務到發佈的過程整合為單一 Android 工作流程。

目的在減少手動負擔並讓發佈更一致、可維護。

作者說明如何把原本由許多繁瑣小步驟組成、手動密集的 Android 發佈例行程序，轉換為單一且連貫的工作流程。關鍵觀察不是流程失效，而是零散的手動步驟造成摩擦與風險。透過將分散且重複的作業合併與自動化，作者減少了重複操作、釐清了從任務到發布的端到端路徑，並提升發佈的一致性。文章也討論了推動自動化的動機、在以自動化取代人工檢查時需考量的取捨，以及實際上的經驗教訓。結論指出：把許多小手動步驟簡化為連貫的自動流程，可改善開發者體驗並提高發佈可靠度。

16

Beyond Positions: Kotlin’s New Name-Based Destructuring

Medium Kotlin 作者：Nav Singh 發布：03-18 01:24

Beyond Positions: Kotlin’s New Name-Based Destructuring

Name-based destructuring declarations were introduced in Kotlin 2.3.20 and match variables to properties rather than relying on positions.

重點摘要

Introduced in Kotlin 2.3.20 as name-based destructuring

Binds variables to properties instead of positional indexes

Designed to improve clarity and reduce fragility in destructuring

Kotlin 2.3.20 introduced name-based destructuring declarations, which match variables to object properties by name instead of by position. This approach reduces the brittleness of position-dependent destructuring when data shapes change, and makes intent clearer by associating extracted variables with specific property identifiers. The article explains the motivation for moving beyond positional patterns, outlines the practical benefits for readability and maintainability, and positions name-based mapping as a way to align destructuring with property semantics. The feature is presented as a complementary alternative to existing destructuring mechanisms; readers are directed to the full post for concrete syntax, examples, and migration considerations. Overall, name-based destructuring aims to make unpacking objects safer and more expressive by tying variables directly to property names.

超越位置：Kotlin 的基于名称的新解构方式

Kotlin 2.3.20 引入了基于名称的解构声明，它将变量匹配到属性而不是依赖位置顺序。

重點摘要

在 Kotlin 2.3.20 中新增基于名称的解构

根据属性名称绑定变量，取代位置索引绑定

有助于提高可读性并减少因顺序变化引发的问题

Kotlin 在 2.3.20 版本引入了基于名称的解构声明，此特性通过属性名称将变量与对象属性匹配，而非依赖位置顺序。名称绑定可以降低因数据结构顺序变更带来的脆弱性，使解构语句的意图更清晰，提升代码的可读性与可维护性。文章讨论了从按位置解构向按名称解构转变的动机与潜在优势，并将其视为可与现有解构机制并存的替代方式；有关具体语法、示例和迁移建议则在原文中有详细说明。总体而言，基于名称的解构旨在通过将变量直接与属性名关联，提供更安全、更具表意性的对象拆解方案。

超越位置：Kotlin 的新一代基於名稱的解構

在 Kotlin 2.3.20 中引入了基於名稱的解構宣告，它將變數對應至屬性名稱，而非依賴位置順序。

重點摘要

Kotlin 2.3.20 引入基於名稱的解構

根據屬性名稱綁定變數，而非位置索引

可提升可讀性並降低因順序變動造成的錯誤

Kotlin 在 2.3.20 版本新增了基於名稱的解構宣告，這種做法以屬性名稱來對應解構後的變數，而非傳統依序的位次（position）。透過名稱對應，可以降低資料結構順序變動時導致的脆弱性，並讓程式碼意圖更明確，增進可讀性與可維護性。文章說明了從位置導向解構轉向名稱導向的理由與實際好處，並指出此功能可與既有解構機制並存；有關語法範例與遷移建議請參閱原文。總體而言，基於名稱的解構透過將變數直接與屬性名稱連結，提供更安全且表意性更強的物件展開方式。

17

Android 17 for Developers: New APIs, Breaking Changes, and What to Migrate Now

Medium Kotlin 作者：Prakash Sharma 發布：03-18 02:01

Android 17 for Developers: New APIs, Breaking Changes, and What to Migrate Now

API level 37 introduces adaptive layouts, lock-free messaging, and granular privacy controls that affect app behavior and migration priorities.

重點摘要

Adaptive layouts to improve UI responsiveness across devices

Lock-free messaging primitives aimed at safer, higher‑performance concurrency

Granular privacy controls that may require API and permission updates

Android 17 (API level 37) focuses on three broad areas relevant to developers: adaptive layout capabilities to better handle diverse screens, lock‑free messaging features intended to improve concurrency and performance, and more granular privacy controls that change how apps request and manage access to user data. The release also includes breaking changes and behavior updates that can affect compatibility, so developers should audit affected APIs, review permission and privacy flows, and test apps on devices or emulators running API level 37. Prioritize migration steps that touch UI layout handling, inter‑thread messaging or synchronization, and any privacy‑sensitive functionality. Careful testing and incremental updates will reduce user impact and help take advantage of the new platform improvements.

Android 17 开发者须知：新 API、破坏性变更与应尽快迁移的事项

API 等级 37 带来自适应布局、无锁消息和更细粒度的隐私控制，影响应用行为与迁移优先级。

重點摘要

自适应布局提升不同设备上的界面适配

无锁消息机制改善并发性能与稳定性

细粒度隐私控制需更新权限与数据访问逻辑

Android 17（API 等级 37）主要强调三方面：用于多屏幕和不同配置的自适应布局、旨在提升并发与性能的无锁消息机制，以及引入更细粒度的隐私控制，可能改变应用对用户数据和权限的处理方式。该版本还包含若干可能导致兼容性问题的破坏性变更，开发者应检查受影响的 API、调整权限与隐私流程，并使用真机或模拟器进行全面测试。优先迁移 UI 适配、消息/同步相关代码和隐私敏感功能，以减少用户影响并利用平台新特性。

Android 17 開發者須知：新 API、破壞性變更與必要遷移項目

API 等級 37 引入自適應佈局、無鎖訊息機制與更細緻的隱私控管，將影響應用行為與遷移優先順序。

重點摘要

自適應佈局改善不同裝置的介面呈現

無鎖訊息提高並發與效能穩定性

細緻隱私控管需檢視權限與資料存取流程

Android 17（API 等級 37）帶來三大開發重點：能更彈性應對多種螢幕與配置的自適應佈局、旨在提升並發與效能的無鎖訊息機制，以及改變應用資料存取模式的細緻隱私控管。此版本亦包含可能影響相容性的破壞性變更，建議開發者檢視受影響的 API、審核權限與隱私流程，並在實機或模擬器上測試應用。優先處理 UI 佈局、訊息/同步機制與隱私相關功能的遷移，以降低對使用者的影響並善用平台改進。

18

What are extension functions in Kotlin, and how do they work internally?

Medium Kotlin 作者：Satnam Singh 發布：03-18 04:04

What Are Kotlin Extension Functions and How They Work

Extension functions let you add functionality to existing classes without modifying their source code, and under the hood they are compiled into static functions that take the receiver as a parameter.

重點摘要

Add methods to existing types without changing their source.

Compiled as static functions with the receiver passed explicitly.

Resolution is static—extensions do not alter class dispatch or access private members.

Extension functions in Kotlin provide a way to add callable members to existing classes without modifying their source code or inheriting from them. They improve API ergonomics by allowing functions to be invoked with receiver syntax (obj.extension()), while internally the compiler turns them into ordinary static functions that accept the receiver as a parameter. Because of this compilation strategy, extension resolution is static (determined by the compile-time type), extensions cannot override member functions or access a class's private internals, and extension properties are implemented via generated accessor methods. This approach offers convenient syntax and modularity while keeping runtime class behavior and binary compatibility unchanged.

Kotlin 的扩展函数是什么及其内部工作原理

扩展函数允许在不修改原始类代码的情况下为现有类添加功能；在内部它们被编译为将接收者作为参数的静态函数。

重點摘要

无需改动类源代码即可为类型添加方法调用语法。

被编译为带接收者参数的静态函数或合成方法。

解析在编译时确定，无法覆盖成员或访问 private 成员。

Kotlin 的扩展函数提供了一种在不修改类源代码或继承类的前提下，为已有类型添加可调用成员的方式，使用接收者语法（obj.extension()）使 API 更加直观。编译器会将扩展函数转译为普通的静态函数，接收者作为第一个参数传入；因此扩展的解析是静态的（以编译期类型为准），扩展函数不能覆盖类本身的方法，也不能访问类的私有成员，扩展属性通过生成的访问器方法实现。该机制在提升语法便利性的同时，保持运行时类行为和二进制兼容性不变。

Kotlin 的延伸函式是什麼，以及其內部運作方式

延伸函式可在不修改原始類別程式碼的情況下為現有類別新增功能；內部上會編譯成接受接收者作為參數的靜態函式。

重點摘要

在不變更類別原始碼下新增方法呼叫語法。

編譯為帶有接收者參數的靜態函式（synthetic 靜態方法）。

解析於編譯期決定，無法覆寫類別成員或存取 private 成員。

Kotlin 的延伸函式允許開發者在不更改類別原始碼也不繼承的情況下，為既有型別新增可呼叫的成員，並以接收者語法（obj.extension()）直覺地使用。編譯器會把延伸函式轉換成接受接收者物件作為第一個參數的靜態函式，因此解析是靜態的（取決於編譯期型別），延伸函式無法覆寫類別的成員方法，也不能直接存取類別的 private 成員；延伸屬性則透過產生的存取器方法實作。此設計兼顧語法便利性與不改變執行時類別行為及二進位相容性。

今日總結

MyBatis-Flex 使用指南

重點摘要

Java 中的 TOON 格式入門

重點摘要

在 Android 中用 RecyclerView 實作 Room 資料庫 CRUD（Kotlin 步驟指南）

重點摘要

Kotlin 基礎第17篇 — 類別：普通 class 與 data class 的比較

重點摘要

Android 開發者仍會犯的 9 個 Kotlin Coroutine 錯誤（即使在 Compose 中也會）

重點摘要

德里 Android 應用程式開發訓練 | 適合初學者與開發者的最佳 Android 課程

重點摘要

Jetpack Compose 狀態存活指南：從 remember 到 rememberNavBackStack

重點摘要

GraalVM Native Image：能克服反射限制嗎？

重點摘要

Kotlin 協程 — 完整深入參考

重點摘要

在不發生 ANR 的情況下處理可及性事件

重點摘要

Virtual Threads 會取代 Reactive 嗎？

重點摘要

Koin 教學系列：使用註解與新版編譯器的生產環境設定

重點摘要

Android 中的 Coroutine Dispatchers：完整指南

重點摘要

Google Summer of Code 2026：為 Kotlin 做出貢獻

重點摘要

我如何將從任務到發佈的例行程序整合為單一 Android 工作流程

重點摘要

超越位置：Kotlin 的新一代基於名稱的解構

重點摘要

Android 17 開發者須知：新 API、破壞性變更與必要遷移項目

重點摘要

Kotlin 的延伸函式是什麼，以及其內部運作方式

重點摘要