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

01

expect/actual — KMP's Secret Weapon for Platform-Specific Code

Medium Kotlin 作者：Mohammed Rampurawala 發布：03-27 07:22

expect/actual — KMP's Secret Weapon for Platform-Specific Code

This final lesson explains how Kotlin Multiplatform's expect/actual mechanism enables clean platform-specific implementations when shipping production apps.

重點摘要

Final lesson of a three-part series on shipping production apps with Kotlin Multiplatform

Explains the expect/actual mechanism for separating common APIs and platform-specific implementations

Positions expect/actual as a practical tool for managing platform differences in production code

The article "expect/actual — KMP's Secret Weapon for Platform-Specific Code" is Lesson 3 of 3 in a series about shipping a production app with Kotlin Multiplatform. It focuses on the expect/actual mechanism as the primary way to declare platform-agnostic APIs in common code (expect) and provide platform-specific implementations (actual) for targets like JVM, Android, iOS, and JavaScript. The piece frames expect/actual as a practical technique to keep shared logic clean while accommodating native platform behavior, helping teams produce maintainable, testable, and production-ready cross-platform code. As the concluding installment, it ties earlier lessons to real-world delivery considerations and encourages readers to consult the Medium post for concrete examples, code patterns, and implementation details that illustrate the approach in production contexts.

expect/actual — KMP 的平台特定代码秘密武器

本文作为系列的第 3 篇，介绍了 Kotlin Multiplatform 的 expect/actual 机制，如何处理平台特定实现。

重點摘要

系列共三篇，本文为第 3 篇（收官篇）

介绍 Kotlin Multiplatform 的 expect/actual 机制

说明如何在共享代码中管理平台特定实现

本文《expect/actual — KMP 的平台特定代码秘密武器》是作者关于用 Kotlin Multiplatform 上线生产应用的系列中的第 3 篇（共 3 篇），重点介绍 expect/actual 机制。文章指出可在共享代码中用 expect 声明跨平台 API，再在各平台用 actual 提供本地实现，从而处理平台差异并保持共享逻辑清晰，提升可维护性与生产就绪性。作为系列收尾篇，文章将前两篇的概念与实际交付需求对接，并建议读者前往 Medium 原文查看具体示例与实现细节。

expect/actual — KMP 的平台特定程式碼祕密武器

這篇系列的第 3 篇說明了 Kotlin Multiplatform 的 expect/actual 機制，如何處理平台特定的實作。

重點摘要

系列共三篇，本文為第 3 篇（收官篇）

介紹 Kotlin Multiplatform 的 expect/actual 機制

說明如何在共用程式碼中管理平台特定實作

本文《expect/actual — KMP 的平台特定程式碼祕密武器》為作者 Kotlin Multiplatform 實務系列的第 3 篇（共 3 篇），聚焦於 expect/actual 機制。文章說明如何在共用代碼中以 expect 宣告跨平台 API，並在各平台以 actual 提供本地實作，作為管理平台差異、保持共享邏輯乾淨並維持生產環境可用性的實用工具。作為系列收官之作，文章將前兩篇的觀念與實際上線需求連結，並建議讀者前往 Medium 原文閱讀具體範例與實作細節。

02

Advanced Kotlin Part 3: Visibility Modifiers in Kotlin — Controlling Access

Medium Kotlin 作者：Kishor Ramani 發布：03-27 08:31

Advanced Kotlin Part 3: Visibility Modifiers in Kotlin — Controlling Access

Visibility modifiers control where your code can be accessed. Let's master the four types in Kotlin!

重點摘要

Visibility modifiers determine where code can be accessed

Kotlin provides four visibility modifiers to control exposure

The article guides mastering these modifiers for safer code

Visibility modifiers determine where code elements such as classes, functions, and properties can be accessed. Kotlin provides four primary modifiers—public, private, protected, and internal—that let you restrict or expose members across different scopes (within a class, a file, a package, or a module). Mastering these modifiers helps you design clearer APIs, encapsulate implementation details, reduce accidental misuse, and enforce sensible boundaries between components. This installment of Advanced Kotlin explains the concepts and practical considerations for choosing appropriate visibility levels, discusses how those choices affect testing and extension, and offers guidance to balance encapsulation with usability. Understanding visibility modifiers enables developers to control access, minimize unintended coupling, and build more maintainable, robust Kotlin codebases.

高级 Kotlin 第三篇：Kotlin 的可见性修饰符 — 控制访问

可见性修饰符决定你的代码可以在哪儿被访问；让我们掌握 Kotlin 中的四种修饰符！

重點摘要

可见性修饰符决定代码的访问范围

Kotlin 提供四种主要修饰符来控制暴露程度

文章指导如何掌握这些修饰符以提升代码安全

可见性修饰符决定类、函数和属性等代码元素可以在哪些范围内被访问。Kotlin 提供四种主要修饰符：public、private、protected 和 internal，可以在类、文件、包或模块等不同层级限制或开放成员。掌握这些修饰符有助于设计更清晰的 API、封装实现细节、减少误用并在组件间建立合理边界。本文（高级 Kotlin 第三篇）讲解选择适当可见性时的概念与实务考量，并讨论这些选择如何影响测试、扩展与 API 演进。理解可见性有助于降低不必要的耦合，构建更易维护且更稳健的 Kotlin 代码。

進階 Kotlin 第三篇：Kotlin 的可見性修飾子 — 控制存取

可見性修飾子決定程式碼可以在哪裡被存取；讓我們掌握 Kotlin 中的四種修飾子！

重點摘要

可見性修飾子決定程式碼的存取範圍

Kotlin 有四種主要修飾子來控制暴露程度

文章說明如何掌握這些修飾子以提升程式安全性

可見性修飾子決定類別、函式與屬性等程式碼元素可以在哪些範圍內被存取。Kotlin 提供四種主要修飾子：public、private、protected 與 internal，藉此在類別、檔案、套件或模組等不同層級限制或開放成員。掌握這些修飾子有助於設計清晰的 API、封裝實作細節、減少誤用，以及在元件間建立合理的界限。本文（進階 Kotlin 第三篇）說明選擇適當可見性時的概念與實務考量，並討論這些選擇如何影響測試、擴充與 API 演進。理解可見性有助於降低不必要的耦合，打造更易維護的 Kotlin 程式碼。

03

Kotlin Flows: A Complete Deep Dive for Android Interviews

Medium Kotlin 作者：Mahendra Sutar 發布：03-27 10:37

Kotlin Flows: A Complete Deep Dive for Android Interviews

Flows are one of the most powerful — and most misunderstood — parts of modern Android development.

重點摘要

Flows are powerful yet often misunderstood in Android development

The article covers topics from cold flows to StateFlow

Aimed as an in-depth resource for Android interview preparation

Mahendra Sutar’s article presents a comprehensive deep dive into Kotlin Flows aimed at developers preparing for Android interviews. It frames Flows as among the most powerful yet frequently misunderstood features in modern Android development, and indicates coverage ranging from cold flows to StateFlow. The piece seeks to clarify core concepts, reduce confusion around different Flow types and behaviors, and consolidate knowledge useful for technical interviews. Rather than serving as a brief introduction, the article positions itself as an in-depth resource that explains why Flows matter in reactive Kotlin programming and how their different kinds fit into app architecture and state management. Readers can expect focused explanations intended to build conceptual clarity and confidence when discussing Flows in interview settings, and practical implications.

Kotlin Flows：面试用的完整深入解析

Flows 是现代 Android 开发中既强大又常被误解的部分。

重點摘要

Flows 在 Android 开发中功能强大但常被误解

内容涵盖从 cold flows 到 StateFlow

定位为 Android 面试准备的深入资源

Mahendra Sutar 的文章对 Kotlin Flows 提供完整的深度解析，目标为准备 Android 面试的开发者。文章指出 Flows 是现代 Android 开发中既强大又常被误解的功能，内容涵盖从 cold flows 到 StateFlow，旨在澄清核心概念、消除不同 Flow 类型与行为的误解，并整合对面试有用的知识与要点。读者可以从中获得重点说明，建立概念性理解并在面试中更有信心地阐述，同时理解 Flows 在应用架构与状态管理上的实际意义。

Kotlin Flows：面試用的完整深入解析

Flows 是現代 Android 開發中既強大又常被誤解的部分。

重點摘要

Flows 在 Android 開發中功能強大但常被誤解

內容涵蓋從 cold flows 到 StateFlow

定位為為 Android 面試準備的深入資源

Mahendra Sutar 的文章對 Kotlin Flows 提供完整的深度解析，目標為準備 Android 面試的開發者。文章指出 Flows 是現代 Android 開發中既強大又常被誤解的功能，內容涵蓋從 cold flows 到 StateFlow，旨在釐清核心概念、消除不同 Flow 類型與行為的迷思，並整合對面試有用的知識與要點。讀者可從中獲得有重點的說明，建立概念性理解與在面試中自信表達的能力，同時理解 Flows 在應用架構與狀態管理上的實務意義。

04

Android UI in 2026: Adaptive Layouts, Foldables & Desktop Mode

Medium Kotlin 作者：Sixtin - Android Developer 發布：03-27 14:47

Android UI in 2026: Adaptive Layouts, Foldables & Desktop Mode

The Android canvas is bigger, stranger, and more powerful than ever.

重點摘要

Broader range of Android form factors, including foldables and desktop modes.

Apps must adopt adaptive, responsive layouts and handle multiple windows.

Developers need improved tooling and testing for dynamic screen states.

By 2026 Android's UI landscape has expanded to accommodate a wider range of hardware and interaction models. The article argues that the Android "canvas" is larger and more varied, driven by foldable phones, tablets, convertible laptops, and desktop modes that change how apps present content and respond to input. Designers and engineers must prioritize adaptive layouts, responsive components, and continuity across contexts—supporting multiple windows, varying aspect ratios, and shifts between touch, keyboard, and pointer. The piece emphasizes practical implications for layout systems, testing strategies, and developer tooling to handle dynamic screen states and novel form factors. Rather than one-size-fits-all interfaces, successful Android apps will embrace flexible UI surfaces, graceful resizing, and user-centric transitions so experiences remain coherent across devices and modes.

2026 年的 Android UI：自适应布局、折叠设备与桌面模式

Android 的画布比以往更大、更奇特，也更强大。

重點摘要

设备形态更多元：折叠机、平板与桌面模式。

应用需采用自适应与响应式布局，支持多窗口。

开发者需强化测试与工具以应对动态屏幕状态。

文章指出，到 2026 年 Android 的界面范围更广且更复杂，随着折叠设备、平板、二合一笔记本与桌面模式等形态增加，应用需要在多种屏幕尺寸與交互方式之间自适应。設計与开发应聚焦弹性布局、响应式组件、窗口与状态的平滑切换，以及在测试与开发工具上支持动态屏幕状态。成功的 Android 应用不是单一固定界面，而是能优雅地调整与延续使用体验，确保在不同设备与模式下保持一致性与可用性。

2026 年的 Android UI：自適應佈局、摺疊裝置與桌面模式

Android 的畫布比以往更大、更奇特，也更強大。

重點摘要

裝置形態更多元：摺疊機、平板與桌面模式。

應用需採用自適應與響應式佈局，支援多視窗。

開發者需強化測試與工具以應對動態螢幕狀態。

文章指出，到 2026 年 Android 的介面範圍更廣更複雜，因摺疊裝置、平板、二合一筆電與桌面模式等形態增加，應用需能在多種螢幕尺寸與互動方式間自適應。設計與開發應聚焦彈性佈局、響應式元件、視窗與狀態的平滑切換，以及在測試和開發工具上支援動態螢幕狀態。成功的 Android 應用不是單一固定介面，而是能優雅地調整與延續使用體驗，確保在不同裝置與模式下維持一致性與可用性。

05

Stop Fighting Compose: The State Management Patterns That Actually Scale in 2026

Medium Kotlin 作者：Sixtin - Android Developer 發布：03-27 14:48

Stop Fighting Compose: The State Management Patterns That Actually Scale in 2026

Most Compose bugs aren't Compose bugs — they're state bugs, and senior Android devs structure state to ship faster and break less.

重點摘要

Most Compose bugs are state bugs, not toolkit bugs.

Senior Android devs structure state to ship faster and break less.

Adopt scalable state-management patterns in 2026 to reduce regressions.

The article argues that most issues attributed to Jetpack Compose are actually caused by faulty state management rather than the UI toolkit itself. It explains that senior Android engineers emphasize clear state ownership and structure so components remain predictable, testable, and simple. By applying scalable state-management practices—such as keeping state as the source of truth, separating UI from business logic, and enforcing consistent ownership boundaries—teams can ship features faster and avoid chasing UI symptoms instead of root causes. The piece recommends aligning architecture and team practices around state flow so Compose serves as a declarative rendering layer reflecting a well-managed state model, which becomes increasingly important as app complexity grows in 2026.

别再与 Compose 对抗：在 2026 年真正能扩展的状态管理模式

大多数被归咎为 Compose 的错误，其实是状态管理的问题；资深 Android 开发者通过结构化状态来更快交付、减少故障。

重點摘要

多数 Compose 问题源自状态管理，而非 Compose 本身。

资深开发者会将状态明确界定并结构化以降低风险。

在 2026 年采用可扩展的状态管理模式可加速交付并减少回归。

文章指出，多数被归咎于 Jetpack Compose 的问题，其实源自状态管理失误，而非 Compose 本身。资深 Android 开发者会把状态明确界定与结构化，分离 UI 与数据/业务逻辑，使组件可预测、易测试并降低回归风险。作者主张采纳可扩展的状态管理模式（在 2026 年应对更高复杂度时尤为重要），通过一致的状态拥有边界与单向数据流，能够加速上线并减少处理 UI 症状的浪费。与其与 Compose 对抗，不如调整架构与团队实践，让 Compose 成为反映良好状态模型的声明式呈现层。

別再跟 Compose 對抗：在 2026 年真正能擴展的狀態管理模式

大多數被歸咎為 Compose 的錯誤，其實是狀態管理的錯誤；資深 Android 開發者透過結構化狀態來更快交付、減少故障。

重點摘要

多數 Compose 問題源自狀態管理，而非 Compose 本身。

資深開發者會將狀態明確界定並結構化以降低風險。

在 2026 年採用可擴展的狀態管理模式可加速交付並減少回歸。

文章指出，多數被歸咎於 Jetpack Compose 的問題，其實源自狀態管理失誤，而非 Compose 本身。資深 Android 開發者會把狀態明確界定與結構化，將 UI 與資料/商業邏輯分離，讓元件可預測、易測試並降低回歸風險。作者主張採用可擴展的狀態管理模式（在 2026 年面對複雜度提高時尤其重要），透過一致的狀態擁有邊界與單向資料流，能加速上線並減少處理 UI 症狀的浪費。與其與 Compose 對抗，不如調整架構與團隊實務，讓 Compose 作為反映良好狀態模型的宣告式呈現層。

06

Things You’ll Regret Ignoring in Android 17 — The Features That Actually Matter

Medium Kotlin 作者：AndroidLab by Andre 發布：03-27 14:50

Things You’ll Regret Ignoring in Android 17 — The Features That Actually Matter

Android 17 isn't just an incremental update; every Android developer needs to stop sleeping on it before it's too late.

重點摘要

Android 17 is more than a minor release.

Developers should review and test their apps against Android 17 now.

Ignoring the release risks missed improvements and compatibility issues.

The article warns that Android 17 is more than an incremental release and urges every Android developer to pay attention now rather than later. It frames the release as a set of changes and opportunities that can affect app behavior, compatibility, and developer workflows; ignoring them risks degraded user experience, missed performance or security improvements, and falling behind on platform conventions. Developers are encouraged to audit their codebases, test against Android 17 behavior, adopt recommended platform APIs and patterns where appropriate, and schedule updates to take advantage of improvements. The piece is a call to action: review the platform changes, prioritize testing and migration, and treat Android 17 as a meaningful step rather than a minor point release to avoid avoidable technical debt and lost opportunities.

别忽视 Android 17：你会后悔错过的重要功能

Android 17 不只是小幅更新；每位 Android 开发者都应尽早关注，别等到为时已晚。

重點摘要

Android 17 并非简单的小版本迭代。

开发者应尽早检查并在 Android 17 上测试应用。

忽视它可能带来兼容性和机会损失。

本文提醒开发者不要将 Android 17 视为小幅更新，应尽早重视。作者强调此次发布包含可能影响应用行为、兼容性和开发流程的重要变化与机会；如若忽略，可能造成用户体验下降、错失性能或安全改进，并增加技术负担。建议团队尽快评估并测试代码、采用平台推荐的做法与 API，规划迁移与更新节奏，将 Android 17 视为重要里程碑以避免错过提升与修正的机会。

別錯過 Android 17：你會後悔忽視的重要功能

Android 17 並非小幅更新；每位 Android 開發者都該盡早重視，別等到為時已晚。

重點摘要

Android 17 不只是例行性小改版。

開發者應立即檢視並測試應用在 Android 17 的行為。

忽視可能導致相容性問題與錯失改善機會。

本文提醒開發者別把 Android 17 當成小幅更新，應盡早重視。文章指出此次釋出包含可能影響應用行為、相容性與開發流程的重要變更與機會；若忽視，可能導致使用者體驗衰退、錯失效能或安全改進，並累積技術債。建議團隊盡快評估並測試程式碼、採用平台建議的做法，規劃遷移與更新時程，將 Android 17 視為重要里程碑以免錯過機會。

07

Is Remote Compose Finally Replacing Traditional Android UI Development?

Medium Kotlin 作者：AndroidLab by Andre 發布：03-27 14:51

Is Remote Compose Finally Replacing Traditional Android UI Development?

The way we build Android UIs is quietly being rewritten and most developers haven't noticed yet.

重點摘要

Remote Compose may supplant traditional Android UI approaches

Android UI development is undergoing a quiet rewrite

Many developers remain unaware of this shift

This Medium piece from AndroidLab (Andre) argues that the way we build Android UIs is being quietly rewritten and poses the question of whether Remote Compose is finally replacing traditional Android UI development. The excerpt emphasizes that the change is happening subtly and that many developers have not yet noticed. While the short excerpt here does not include technical specifics, it frames Remote Compose as a potential inflection point for Android UI patterns and tooling. The article encourages readers to explore the full post on Medium to see the author’s full arguments, examples and implications, and it prompts developers and teams to consider how this gradual evolution might affect workflows, compatibility and learning priorities as the ecosystem evolves.

Remote Compose 是否最终在取代传统 Android UI 开发？

我们构建 Android UI 的方式正被悄然改写，多数开发者尚未注意到。

重點摘要

Remote Compose 可能取代传统 Android UI 方法

Android UI 开发正在悄然重写

许多开发者尚未察觉这一变化

AndroidLab（Andre）在 Medium 的文章指出，Android UI 的构建方式正被悄然改写，并提出 Remote Compose 是否已经在取代传统 Android UI 开发的疑问。摘录强调这一变动发生得较为低调，多数开发者尚未察觉。虽然此处仅为短摘录并未提供技术细节，但文章以此引发对工具、开发流程与兼容性等議題的關注，並邀請讀者到 Medium 閱讀完整內容，以了解作者的完整論點、示例及該趨勢對開發實務的潛在影響。

Remote Compose 是否終於在取代傳統 Android UI 開發？

我們構建 Android UI 的方式正被悄悄改寫，而多數開發者尚未注意到。

重點摘要

Remote Compose 可能取代傳統 Android UI 方法

Android UI 開發正在悄然改變

許多開發者尚未察覺這項變動

AndroidLab（Andre）在 Medium 的文章指出，Android UI 的構建方式正被悄悄改寫，並提出 Remote Compose 是否已經在取代傳統 Android UI 開發的問題。摘錄強調這是個不太顯眼的轉變，多數開發者還沒有注意到。雖然此處只是一段短摘錄，未包含技術細節，但文章以此為起點，提示讀者關注這一變化可能帶來的工具、流程與相容性議題，並邀請有興趣的讀者到 Medium 閱讀完整論述與範例，以理解對開發實務的具體影響。

08

Descomplicando o Componente Activity no Android: Uma Jornada Didática

Medium Kotlin 作者：fefe_dev 發布：03-26 23:58

Demystifying the Activity Component in Android: A Didactic Journey

When we start exploring Android development, one of the first concepts we encounter is the 'Activity' component.

重點摘要

The Activity component is one of the first concepts encountered in Android development.

The article aims to demystify the Activity through a didactic, guided approach.

It focuses on clarifying what an Activity is and its role within Android apps.

This piece introduces the Android Activity as a foundational concept newcomers meet early in their learning. Framed as a didactic journey, the article seeks to simplify and clarify the Activity component—explaining its nature and why it matters in app development—so readers can build a practical understanding without being overwhelmed by jargon. Rather than diving into exhaustive technical detail, the intent is pedagogical: to guide learners step by step toward a clear mental model of what an Activity represents and how it fits into the broader structure of an Android application. The tone and structure are designed to make the topic approachable for those beginning Android development.

解构 Android 的 Activity 组件：一段教学式之旅

当我们开始探索 Android 开发时，最先遇到的概念之一就是所谓的“Activity”组件。

重點摘要

Activity 是 Android 开发中最早接触的核心概念之一。

文章以教学式的方式解构并简化 Activity 的概念。

重点说明 Activity 是什么以及它在应用程序中的角色。

本文以教学式的笔调带领读者认识 Android 中的 Activity 组件，指出它是初学者在学习 Android 时首先会碰到的重要概念。文章旨在化繁为简，阐明 Activity 的本质及其在应用结构中的作用，帮助读者建立清晰且实用的概念框架。通过循序渐进的说明，读者能在不被过多术语干扰的情况下，逐步理解 Activity 的意义与用途，从而更顺利地进入 Android 开发的学习路径。

解構 Android 的 Activity 元件：一段教學式的旅程

當我們開始探索 Android 開發時，最先遇到的概念之一就是所謂的「Activity」元件。

重點摘要

Activity 是 Android 開發中最早接觸的核心概念之一。

文章以教學式的方式拆解並簡化 Activity 的概念。

重點在說明 Activity 是什麼以及它在應用程式中的角色。

本文以教學式的敘述帶領讀者認識 Android 中的 Activity 元件，強調這是初學者在學習 Android 時會先遇到的重要概念。文章目的在於去除複雜感，釐清 Activity 的本質與在應用程式架構中的角色，幫助讀者建立實用且清晰的概念模型。語氣與結構偏向入門導向，透過循序說明讓初學者能在不被過多術語干擾下，逐步理解 Activity 的意義與用途。

09

We Killed JSON in SDUI Framework. It’s 10x Smaller. Here’s What Replaced It.

Medium Kotlin 作者：Developer Chunk 發布：03-27 01:43

We Killed JSON in SDUI Framework. It’s 10x Smaller. Here’s What Replaced It.

Your Server-Driven UI is bleeding bandwidth, stalling renders, and burning CPU and you don't even know it yet.

重點摘要

Server-driven UI JSON payloads can inflate bandwidth and CPU usage

The author replaced JSON with a format that is 10× smaller

The article explains the replacement and its performance benefits

This article highlights a common performance problem in Server-Driven UI (SDUI) architectures: large JSON payloads that consume bandwidth, slow rendering, and increase CPU work. The author reports that they removed JSON from their SDUI framework and replaced it with a much more compact representation that reduces payload size by about tenfold. The piece outlines the motivation for abandoning verbose JSON, emphasizes the user-facing impacts of heavy payloads (network latency, render stalls, CPU overhead), and presents the compact replacement as a practical solution to improve performance and resource usage. Readers learn why payload size matters in SDUI and are pointed toward an alternative approach that yields substantially smaller transfers and better runtime behavior.

我们在 SDUI 框架中淘汰了 JSON：体积缩小 10 倍，这是替代方案

你的 Server-Driven UI 正在流失带宽、导致渲染停滞并消耗大量 CPU，而你还没有察觉。

重點摘要

SDUI 使用的 JSON 可能导致带宽与 CPU 负担增大

作者用一种体积约 10 倍更小的格式替代了 JSON

文章介绍了替代方案及其带来的性能改善

本文指出 Server-Driven UI 的一个常见性能问题：冗长的 JSON 会占用大量带宽、增加网络延迟并导致渲染与 CPU 负载上升。作者在其 SDUI 框架中弃用 JSON，采用一种更紧凑的表示，使传输体积约为原来的十分之一。文章说明了放弃 JSON 的原因，强调了大体积负载对用户体验（网络延迟、渲染停滞、计算开销）的负面影响，并展示了更小格式在传输效率和运行时表现上的实际益处，为希望改善 SDUI 性能的读者提供了替代思路。

我們在 SDUI 框架中淘汰了 JSON：體積縮小 10 倍，這是替代方案

你的 Server-Driven UI 正在流失頻寬、造成渲染停滯並燒掉 CPU，而你還沒察覺。

重點摘要

SDUI 使用的 JSON 可能導致頻寬與 CPU 負擔增加

作者以一種體積約 10 倍更小的格式取代了 JSON

文章說明替代方案與其帶來的效能改善

本文指出 Server-Driven UI 常見的效能痛點：大量且冗長的 JSON 會佔用頻寬、延長網路等待並造成渲染與 CPU 負擔。作者在其 SDUI 框架中移除 JSON，採用一種更為精簡的表示方式，讓傳輸資料約為原先的十分之一。文章說明採取此變更的動機、JSON 對使用者體驗（網路延遲、渲染停滯、運算負載）的負面影響，以及採用更小格式後在傳輸與執行時能帶來的實際效益，提供讀者一個改善 SDUI 效能的可行方向。

10

Advanced Kotlin Part 2: Getters and Setters in Kotlin — Custom Property Access

Medium Kotlin 作者：Kishor Ramani 發布：03-27 02:31

Advanced Kotlin Part 2: Getters and Setters in Kotlin — Custom Property Access

Kotlin provides default getters and setters for class properties, but sometimes you need custom behavior.

重點摘要

Kotlin supplies default property accessors

Custom getters and setters let you alter property behavior

The article demonstrates how to define custom accessors

Kotlin supplies default getters and setters for class properties, but developers often need custom behavior for reasons such as validation, computed values, or side effects when a property is read or written. This article focuses on that capability: it explains that while basic properties work out of the box, you can override the default accessors to implement tailored logic. By defining custom getters and setters, you control how values are produced and assigned, enabling checks, transformations, or additional actions tied to property access. The piece serves as a practical guide to understand when default accessors are sufficient and when to introduce custom ones, and it walks through the approach for implementing those custom property accessors in Kotlin.

进阶 Kotlin（第二部分）：Kotlin 的 getter 与 setter — 自定义属性访问

Kotlin 为类属性提供默认的 getter 与 setter，但有时需要自定义行为。

重點摘要

Kotlin 为属性提供默认访问器

自定义 getter/setter 可调整属性行为

文章示范如何定义自定义访问器

Kotlin 会为类属性自动生成默认的 getter 和 setter，但在实际开发中常常需要自定义行为，比如在读取或写入时进行验证、计算派生值或触发其它副作用。本文聚焦于这一能力：说明何时默认访问器不够用，并介绍通过定义自定义 getter 与 setter 来掌控属性的取值与赋值过程。通过自定义访问器，开发者可以在属性访问时加入检查或转换，从而实现更符合需求的属性行为与逻辑。

進階 Kotlin（第二部）：Kotlin 的 getter 與 setter — 自訂屬性存取

Kotlin 為類別屬性提供預設的 getter 與 setter，但有時需要自訂行為。

重點摘要

Kotlin 對屬性提供預設存取器

自訂 getter/setter 可改變屬性行為

文章示範如何定義自訂存取器

Kotlin 會為類別屬性自動產生預設的 getter 與 setter，但在實務上經常會遇到需要自訂行為的情況，例如在讀取或寫入時加入驗證、計算衍生值或觸發其他副作用。本文說明了在何種情況下預設存取器不足，並說明可以透過定義自訂的 getter 與 setter 來控制屬性的取值與賦值流程。透過自訂存取器，開發者能夠在屬性存取時加入檢查或轉換，實作更符合需求的屬性行為。

今日總結

expect/actual — KMP 的平台特定程式碼祕密武器

重點摘要

進階 Kotlin 第三篇：Kotlin 的可見性修飾子 — 控制存取

重點摘要

Kotlin Flows：面試用的完整深入解析

重點摘要

2026 年的 Android UI：自適應佈局、摺疊裝置與桌面模式

重點摘要

別再跟 Compose 對抗：在 2026 年真正能擴展的狀態管理模式

重點摘要

別錯過 Android 17：你會後悔忽視的重要功能

重點摘要

Remote Compose 是否終於在取代傳統 Android UI 開發？

重點摘要

解構 Android 的 Activity 元件：一段教學式的旅程

重點摘要

我們在 SDUI 框架中淘汰了 JSON：體積縮小 10 倍，這是替代方案

重點摘要

進階 Kotlin（第二部）：Kotlin 的 getter 與 setter — 自訂屬性存取

重點摘要