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

01

97% of My App's Code Is in commonMain — A Field Report on Shipping 100% Compose Multiplatform

Dev.to Kotlin 作者：wang jack 發布：06-18 09:42

97% of My App's Code Lives in commonMain: A Field Report on Shipping 100% Compose Multiplatform

For a content/list/detail app, CMP is comfortably production-ready on Android.

重點摘要

96.9% of the shared module is in commonMain; 17 screens are written once.

The remaining native work is concentrated in about 10 expect/actual seams.

iOS compiles and renders, but still has polish and toolchain issues.

This field report describes shipping a small dev-news reader to Google Play with a single Compose Multiplatform codebase. Nearly all shared code lives in commonMain, including 17 screens, while the native surface is limited to about 10 expect/actual seams for platform info, sharing, URL handling, analytics, and WebView. The author says CMP is production-ready for a content/list/detail app on Android, but iOS remains WIP: it compiles and renders in the simulator, yet still has crashes, missing analytics, and toolchain friction. WebView is the ugliest boundary, and fixed platform primitives are handled with expect/actual rather than DI.

我应用 97% 的代码都在 commonMain：100% Compose Multiplatform 上线实录

对于内容／列表／详情类应用，CMP 在 Android 上已经相当适合投入生产环境。

重點摘要

共享模块 96.9% 位于 commonMain，17 个界面一次编写即可。

原生成本集中在约 10 个 expect/actual 接口。

iOS 已能编译并渲染，但仍存在打磨不足与工具链问题。

作者以一款小型开发新闻阅读器为例，介绍如何使用单一 Compose Multiplatform 代码库发布到 Google Play。共享代码几乎全部放在 commonMain，17 个界面全部共用；原生差异则集中在约 10 个 expect/actual 接口，覆盖平台信息、系统交互、埋点和 WebView。作者认为，这种方案对内容／列表／详情类应用来说，在 Android 上已足够生产可用；但 iOS 仍处于 WIP，虽然能在模拟器中编译并渲染界面，却仍有崩溃、缺少分析接入，以及 Xcode 和构建速度带来的工具链摩擦。

我應用程式 97% 的程式碼都在 commonMain：100% Compose Multiplatform 上線實錄

對於內容／列表／詳情型應用，CMP 在 Android 上已相當適合投入正式環境。

重點摘要

共用模組 96.9% 位於 commonMain，17 個畫面只寫一次。

原生差異集中在約 10 個 expect/actual 接點。

iOS 可編譯並顯示畫面，但仍有打磨與工具鏈問題。

作者以一個小型開發新聞閱讀器為例，說明如何用單一 Compose Multiplatform 程式碼庫上架 Google Play。共享程式碼幾乎都放在 commonMain，17 個畫面皆共用，原生差異則集中在約 10 個 expect/actual 接點，涵蓋平台資訊、分享、網址開啟、分析與 WebView。作者認為這種做法對內容／列表／詳情型應用而言，在 Android 上已足夠進入正式環境；但 iOS 仍在進行中，雖可於模擬器編譯與渲染，仍有崩潰、缺少分析以及 Xcode 與建置速度等工具鏈成本。

02

SavedStateHandle in the Navigation 3 Era: It’s Time to Rethink Your ViewModel

Medium Kotlin 作者：chanzmao 發布：06-18 09:30

SavedStateHandle in the Navigation 3 Era: It’s Time to Rethink Your ViewModel

If you’ve been developing Android apps with Jetpack Compose for a while, you’ve probably written something like this.

重點摘要

Jetpack Compose developers often rely on familiar ViewModel patterns.

The article points to SavedStateHandle in the Navigation 3 era.

It suggests it may be time to rethink how ViewModels are structured.

The article opens by noting that Android developers using Jetpack Compose have likely written code following a familiar ViewModel pattern. Its title indicates a shift in thinking around SavedStateHandle as Navigation 3 changes how state and navigation are approached. Although the provided excerpt is brief, the central message is clear: developers should reconsider whether their current ViewModel design still fits the newer navigation era.

Navigation 3 时代的 SavedStateHandle：是时候重新思考你的 ViewModel 了

如果你已经用 Jetpack Compose 开发 Android 应用一段时间，很可能写过类似的代码。

重點摘要

Jetpack Compose 开发者常采用熟悉的 ViewModel 模式。

文章聚焦 Navigation 3 时代下的 SavedStateHandle。

作者认为有必要重新审视 ViewModel 的设计方式。

文章开头指出，熟悉 Jetpack Compose 的 Android 开发者很可能写过类似的 ViewModel 代码。从标题可以看出，作者关注的是 Navigation 3 带来的变化，以及 SavedStateHandle 在新的状态与导航体系下是否仍然合适。尽管目前提供的正文很短，但主旨已经很明确：开发者应重新思考现有的 ViewModel 设计是否还适合新的导航时代。

Navigation 3 時代的 SavedStateHandle：是時候重新思考你的 ViewModel 了

如果你已經使用 Jetpack Compose 開發 Android 應用一段時間，很可能寫過類似的程式碼。

重點摘要

Jetpack Compose 開發者常沿用熟悉的 ViewModel 寫法。

文章聚焦 Navigation 3 時代下的 SavedStateHandle。

作者認為應重新檢視 ViewModel 的設計方式。

文章一開始指出，熟悉 Jetpack Compose 的 Android 開發者多半寫過類似的 ViewModel 程式碼。從標題可看出，內容聚焦於 Navigation 3 帶來的變化，以及 SavedStateHandle 在新的狀態與導覽架構下是否仍適用。雖然目前提供的內文很短，但核心訊息相當明確：開發者應重新思考現有的 ViewModel 設計是否還符合新的導覽時代。

03

When Postgres is the wrong place to traverse the graph

Medium Kotlin 作者：Andrey Minogin 發布：06-18 10:18

When Postgres Is the Wrong Place to Traverse the Graph

Some performance problems are not query-optimization problems.

重點摘要

Graph traversal can be the wrong workload for Postgres.

Not every slowdown can be solved with indexes or parameter tuning.

Sometimes the real fix is choosing a different approach or system.

The article argues that some database performance issues are not simply a matter of query optimization. Even with indexes, rewritten queries, tuned parameters, and additional hardware, certain workloads may still remain slow if they are a poor fit for Postgres. In particular, graph traversal can be one of those cases where the database is being used beyond what it handles efficiently. The core message is that performance tuning has limits, and the right solution may be to rethink the data access pattern or use a better-suited system.

当 Postgres 不是遍历图的合适场所

有些性能问题并不是单靠查询优化就能解决的。

重點摘要

图遍历可能并不适合交给 Postgres 处理。

索引、改写查询和调参未必能解决所有性能问题。

有时真正的办法是换一种方案或系统。

文章指出，有些数据库性能问题并不只是查询优化不足。即使已经使用索引、重写查询、调整参数，甚至增加硬件，如果工作负载本身并不适合 Postgres，性能仍可能无法改善。作者以图遍历为例，说明某些场景下 Postgres 可能并不是合适的工具。核心观点是，性能调优有边界，真正的解决方式可能是重新设计访问模式，或选择更匹配需求的系统。

當 Postgres 不是遍歷圖的最佳場域

有些效能問題不是單靠查詢最佳化就能解決的。

重點摘要

圖遍歷可能不是 Postgres 擅長的工作負載。

索引、改寫查詢與調參未必能解決所有延遲。

有時真正的解法是改變方法或改用更合適的系統。

本文指出，有些資料庫效能問題並不只是查詢最佳化不足。即使已經加上索引、改寫 SQL、調整參數，甚至升級硬體，若工作負載本身不適合 Postgres，效能仍可能無法改善。作者以圖遍歷為例，說明某些情境下 Postgres 可能不是最佳選擇。重點在於，調校有其極限，必要時應重新思考資料存取方式，或選用更契合需求的系統。

04

Your App Will Be Resizable on Tablets Whether You Like It or Not

Medium Kotlin 作者：Christophy Barth 發布：06-18 11:01

Your App Will Be Resizable on Tablets Whether You Like It or Not

For most of an Android side project I shipped a couple of years ago, I never once thought about tablets.

重點摘要

The article recounts an Android side project that originally ignored tablets.

The app was designed for portrait use and did not account for tablet behavior.

The headline suggests Android apps must adapt to tablet resizing requirements.

The piece reflects on an Android side project that was built without ever considering tablets, since the app was designed primarily for portrait use. It points to a broader Android reality: apps may be expected to handle tablet form factors and resizable behavior even if that was never part of the original plan. Based on the available text, the article’s central theme is the unavoidable need for tablet compatibility in Android app development.

无论你是否喜欢，你的应用都将在平板上可调整大小

在我几年前发布的一个 Android side project 中，我从未想过平板电脑。

重點摘要

文章回顾了一个最初完全没有考虑平板的 Android side project。

这个应用以竖屏为主，没有将平板使用场景纳入设计。

标题强调 Android 应用最终仍要面对平板可调整大小的要求。

本文回顾作者几年前发布的一个 Android side project，当时几乎没有考虑过平板，因为应用主要以竖屏模式设计。标题传达的重点是：即使开发者最初没有将平板纳入规划，Android 应用仍可能必须支持平板上的可调整窗口和不同尺寸场景。就目前可见内容来看，文章主旨在于说明平板兼容性已成为 Android 开发中无法回避的现实。

無論你喜不喜歡，你的 App 都將可在平板上調整大小

在我幾年前推出的一個 Android side project 大多數時間裡，我從未想過平板電腦。

重點摘要

文章回顧一個原本未考慮平板的 Android side project。

這個 App 以直向為主，沒有把平板情境納入設計。

標題強調 Android App 最終仍必須面對平板可調整大小的要求。

本文回顧作者幾年前推出的一個 Android side project，當時幾乎沒有想到平板裝置，因為應用程式主要以直向模式設計。文章標題點出一個現實：即使開發者原本未將平板納入規劃，Android App 仍可能被要求支援平板上的可調整視窗與不同尺寸情境。從目前可見內容來看，核心訊息是平板相容性已成為 Android 開發中難以迴避的一環。

05

What No One Tells You About Android Development in 2026

Medium Kotlin 作者：AndroidLab by Andre 發布：06-18 13:14

What No One Tells You About Android Development in 2026

The ecosystem has matured — but the hidden complexity has only gotten deeper.

重點摘要

Android’s ecosystem is now more mature than before.

Hidden complexity has increased rather than disappeared.

The article points to concerns senior Android developers are discussing.

The article argues that Android development in 2026 is no longer defined by a young, rapidly changing ecosystem alone. Instead, maturity has brought a different kind of challenge: deeper hidden complexity. Rather than listing concrete technical trends, the post frames the topic around what experienced Android developers are actually talking about and implies that the day-to-day realities of building for Android remain more complicated than they may first appear.

关于 2026 年 Android 开发，没人会告诉你的事

生态系统已经成熟，但隐藏的复杂性只会更深。

重點摘要

Android 生态系统如今比以往更成熟。

隐藏的复杂性并没有减少，反而更深。

文章聚焦资深 Android 开发者正在讨论的问题。

文章指出，到 2026 年，Android 开发不再只是面对一个尚未成熟、快速变化的生态系统；相反，成熟也带来了更深层的隐藏复杂性。原文并未展开具体技术细节，而是以资深 Android 开发者正在讨论的话题作为切入点，暗示实际开发中的难题并没有因为生态成熟而消失，反而可能变得更隐蔽、更难处理。

關於 2026 年 Android 開發，沒有人會告訴你的事

生態系統已經成熟，但隱藏的複雜度卻變得更深了。

重點摘要

Android 生態系統比以往更成熟。

隱藏的複雜度並未減少，反而更深。

文章聚焦資深 Android 開發者正在討論的問題。

這篇文章指出，到了 2026 年，Android 開發不再只是面對一個尚未成熟、快速變動的生態系統；相反地，成熟也帶來了更深層的隱藏複雜度。文章本身沒有展開具體技術細節，而是以資深 Android 開發者正在談論的議題作為切入，暗示在實際開發中，Android 的挑戰並沒有因生態成熟而消失，反而可能變得更難察覺、更難處理。

06

Server-Driven UI Is Back And This Time, It’s Smarter Than Ever

Medium Kotlin 作者：AndroidLab by Andre 發布：06-18 13:22

Server-Driven UI Is Back, and It’s Smarter Than Ever

The future of Android apps might not live on your device at all.

重點摘要

Android apps may rely more on server-controlled UI.

Server-driven UI is being positioned as a scalable approach.

The article argues the model is now smarter than before.

The article argues that server-driven UI is making a comeback in Android development, with a stronger value proposition than before. It suggests that the next generation of apps may not keep all interface logic on the device, but instead let the server control parts of the experience. The piece frames this as a scalable strategy that appeals to teams building larger, more adaptable products.

Server-Driven UI 回来了，而且这次更聪明了

Android 应用的未来，甚至可能根本不在你的设备上。

重點摘要

Android 应用可能更多依赖服务器控制的 UI。

Server-driven UI 被视为可扩展的方案。

文章认为这种模式比过去更成熟。

文章认为，Server-driven UI 正在 Android 开发中重新流行起来，而且这一次的价值主张比以往更强。文中指出，未来的应用可能不会把所有界面逻辑都放在设备端，而是由服务器主导部分体验。作者将其视为一种更具可扩展性的方式，尤其适合需要快速迭代、面向规模化增长的团队。

Server-Driven UI 回來了，而且這次更聰明了

Android 應用的未來，甚至可能根本不在你的裝置上。

重點摘要

Android 應用可能更依賴伺服器控制的 UI。

Server-driven UI 被視為可擴展的解決方案。

文章認為這種模式比以往更成熟。

文章主張，Server-driven UI 正在 Android 開發中重新受到關注，而且這次的價值主張比以往更強。它指出，未來的 App 可能不會把所有介面邏輯都放在裝置端，而是讓伺服器主導部分體驗。作者將這視為一種更具擴展性的做法，特別適合需要快速調整、規模化成長的團隊。

07

“Grokking” Kotlin Coroutines: Why suspend exists

Medium Kotlin 作者：Yevhenii Krykun 發布：06-18 14:46

“Grokking” Kotlin Coroutines: Why Suspend Exists

A practical mental model for understanding async work, threads, callbacks, Rx, and why Kotlin suspend exists.

重點摘要

Explains async work with a practical mental model

Connects threads, callbacks, and Rx to coroutines

Clarifies the purpose of Kotlin's suspend keyword

This article sets out to explain Kotlin coroutines through a practical mental model. Rather than treating async programming as a collection of unrelated tools, it aims to relate threads, callbacks, Rx, and coroutines in a way that makes the role of Kotlin’s suspend keyword easier to understand. The piece is framed as an introduction to why suspend exists and how it helps developers reason about asynchronous work more naturally.

“领会” Kotlin 协程：为什么会有 suspend

用一个实用的心智模型来理解异步工作、线程、回调、Rx，以及 Kotlin 为什么需要 suspend。

重點摘要

以实用心智模型解释异步工作

串联线程、回调与 Rx 和协程

说明 Kotlin suspend 关键字的作用

本文以一个实用的心智模型来帮助读者理解 Kotlin 协程与异步编程。作者不是把 async、线程、回调和 Rx 当作彼此独立的技术，而是试图建立一套连贯的认知框架，说明它们与协程之间的关系，并进一步解释 Kotlin 的 suspend 为什么存在，以及它如何帮助开发者更自然地理解和组织异步工作。

「領會」Kotlin 協程：為什麼會有 suspend

用一個實用的心智模型來理解非同步工作、執行緒、回呼、Rx，以及 Kotlin 為何需要 suspend。

重點摘要

以實用心智模型說明非同步工作

串連執行緒、回呼與 Rx 和協程

釐清 Kotlin suspend 關鍵字的用途

本文以實用的心智模型切入，幫助讀者理解 Kotlin 協程與非同步程式設計。作者不把 async、執行緒、回呼與 Rx 視為彼此孤立的概念，而是試著建立一個連貫的理解框架，說明它們與協程之間的關係，並進一步解釋 Kotlin 的 suspend 為何存在，以及它如何協助開發者更自然地思考非同步工作。

08

Mastering Design Principles: Dependency Inversion in Kotlin

Dev.to Kotlin 作者：Renzo Fernando LOYOLA VILCA CHOQUE 發布：06-17 23:35

Mastering Design Principles: Dependency Inversion in Kotlin

This shift dramatically improves our codebase, facilitates unit testing, and prepares our applications for future growth.

重點摘要

Tight coupling makes systems fragile and hard to change.

DIP requires high-level and low-level modules to depend on abstractions.

Using interfaces and dependency injection improves testability and flexibility.

This article explains the Dependency Inversion Principle (DIP), the last of the SOLID principles, through a Kotlin e-commerce payment example. It first shows a tightly coupled OrderProcessor that directly depends on PayPalService, making the code brittle, hard to test, and difficult to change when payment providers switch. It then refactors the design by introducing a PaymentGateway interface, with PayPalProvider and StripeProvider implementing it. By injecting the dependency into OrderProcessor, the code becomes more modular, easier to test with mocks, and ready to support future payment options without changing business logic.

掌握设计原则：Kotlin 中的依赖倒置原则

这一转变能显著提升代码库质量，便于单元测试，并为应用未来扩展做好准备。

重點摘要

紧耦合会让系统脆弱且难以维护。

DIP 要求高层和底层模块都依赖抽象。

通过接口与依赖注入，可提升可测试性和灵活性。

本文以 Kotlin 电商支付流程为例讲解依赖倒置原则（DIP），这是 SOLID 的最后一项原则。文章先展示 OrderProcessor 直接依赖 PayPalService 的紧耦合设计，说明这种写法会导致难以单元测试、修改成本高，并且在更换支付服务时容易牵连其他代码。随后通过引入 PaymentGateway 接口，让 PayPalProvider 与 StripeProvider 共同实现该抽象，再将其注入到 OrderProcessor 中。这样一来，系统更模块化、依赖更解耦，也能更方便地用 mock 测试业务逻辑，并支持未来新增支付方式。

掌握設計原則：Kotlin 中的依賴反轉原則

這種轉變大幅提升程式碼品質、方便單元測試，也讓應用程式更能迎接未來成長。

重點摘要

緊耦合會讓系統脆弱且難以變更。

DIP 要求高階與低階模組都依賴抽象。

透過介面與依賴注入，可提升可測試性與彈性。

本文以 Kotlin 的電商付款流程示範依賴反轉原則（DIP），這也是 SOLID 的最後一項原則。文章先展示 OrderProcessor 直接依賴 PayPalService 的緊耦合設計，指出這會造成難以測試、修改成本高，以及更換付款服務時牽一髮動全身。接著引入 PaymentGateway 介面，讓 PayPalProvider 與 StripeProvider 實作同一抽象，並透過建構子注入到 OrderProcessor。如此一來，架構更模組化、更易於使用 mock 進行單元測試，也更方便未來擴充新的付款方式。

09

I reverse-engineered my motorcycle's Bluetooth protocol to put Google Maps on the dashboard

Dev.to Kotlin 作者：Arjun 發布：06-18 03:41

I reverse-engineered my motorcycle's Bluetooth protocol to put Google Maps on the dashboard

A weekend experiment turned into a working app that routes Google Maps directions to a motorcycle instrument cluster.

重點摘要

The bike’s Bluetooth protocol was proprietary and undocumented.

The author reverse-engineered it by inspecting traffic, decompiling the app, and hooking runtime calls.

He built REDLINE, an Android app that sends Google Maps navigation to the dashboard and adds ride telemetry features.

The author describes how he reverse-engineered a motorcycle’s proprietary Bluetooth instrument-cluster protocol and built his own Android app, REDLINE, to display Google Maps turn-by-turn directions on the dashboard. With no documentation available, he examined live Bluetooth traffic, decompiled the manufacturer’s app, and used tools like Frida to map message formats and checksum logic. He also documents the assumptions he got wrong along the way, including misidentified Bluetooth characteristics and an incorrect belief that the bike had its own SIM. The finished app runs entirely on the phone, replaces the stock navigation experience, and adds telemetry, ride logging, exports, and a clock display when navigation is idle.

我逆向分析了摩托车的 Bluetooth 协议，把 Google Maps 放到仪表盘上

一个周末的实验，最终做出了能把 Google Maps 导航送上摩托车仪表盘的应用。

重點摘要

这台摩托车的 Bluetooth 协议是专有的，而且没有文档。

作者通过抓包、反编译原厂应用和运行时 Hook 还原了协议。

他开发了 REDLINE，把 Google Maps 导航写入仪表盘，并加入行程遥测功能。

作者讲述了自己如何逆向分析摩托车专有的 Bluetooth 仪表盘协议，并开发出 Android 应用 REDLINE，将 Google Maps 的逐向导航显示到仪表盘上。由于没有任何文档，他先观察真实 Bluetooth 流量，再反编译厂商应用，并借助 Frida 跟踪函数调用，逐步弄清消息格式和校验逻辑。文章也记录了多次误判，例如把某些特征值误认成数字钥匙规格，以及误以为车辆内置 SIM 卡。最终应用完全运行在手机上，不依赖账号或云端，还提供遥测、骑行记录、导出以及导航空闲时的时钟显示。

我逆向分析了機車的 Bluetooth 協定，把 Google Maps 放上儀表板

一個週末的實驗，最後做出能把 Google Maps 導航送到機車儀表板的 App。

重點摘要

這台機車的 Bluetooth 協定是專有且沒有文件可參考。

作者透過封包觀察、反編譯原廠 App 與執行期攔截完成逆向。

他做出 REDLINE，將 Google Maps 導航寫入儀表板，並加入行車遙測功能。

作者分享自己如何逆向分析機車專有的 Bluetooth 儀表板協定，並開發 Android 應用 REDLINE，把 Google Maps 的逐步導航顯示到儀表板上。由於沒有文件，他先觀察實際 Bluetooth 流量，再反編譯原廠 App，並透過 Frida 追蹤函式呼叫，逐步釐清訊息格式與校驗碼。文中也誠實記錄多次判斷失誤，例如誤把特徵值當成數位鑰匙規格，以及誤以為車輛內建 SIM 卡。最終成品完全在手機上運作，不需帳號或雲端，還提供遙測、騎乘紀錄、匯出與待機時鐘等功能。

10

Demystifying Compare-And-Swap (CAS): The Secret Engine Behind Lock-Free Concurrency

Medium Kotlin 作者：Avik Sharma Chowdhury 發布：06-17 23:17

Demystifying Compare-And-Swap (CAS): The Secret Engine Behind Lock-Free Concurrency

The hardware primitive behind StateFlow.update {}, AtomicInteger, and every lock-free data structure you’ve ever used.

重點摘要

Explains CAS as a core hardware primitive.

Connects CAS to StateFlow.update {} and AtomicInteger.

Frames CAS as the foundation of lock-free concurrency.

This article introduces compare-and-swap (CAS) as the low-level hardware primitive that powers many modern concurrent programming tools. It highlights how CAS underlies Kotlin’s StateFlow.update {}, AtomicInteger, and other lock-free data structures, making it a key mechanism for building concurrency without traditional locks. The piece focuses on CAS as the hidden engine behind these abstractions and emphasizes its importance in understanding lock-free design.

解密 Compare-And-Swap（CAS）：无锁并发背后的秘密引擎

StateFlow.update {}、AtomicInteger，以及你用过的每一种无锁数据结构背后的硬件原语。

重點摘要

说明 CAS 是核心硬件原语。

关联 CAS 与 StateFlow.update {}、AtomicInteger。

指出 CAS 是无锁并发的基础。

本文将 compare-and-swap（CAS）介绍为支撑现代并发编程的底层硬件原语，说明它如何成为 Kotlin 的 StateFlow.update {}、AtomicInteger 以及各种无锁数据结构的基础。文章强调，CAS 是实现不依赖传统锁机制的关键，并将其视为这些抽象背后的隐藏引擎，帮助读者理解无锁设计的核心概念。

破解 Compare-And-Swap（CAS）：無鎖並行背後的秘密引擎

StateFlow.update {}、AtomicInteger，以及你用過的每一個無鎖資料結構，背後的硬體原語。

重點摘要

說明 CAS 是核心硬體原語。

連結 CAS 與 StateFlow.update {}、AtomicInteger。

指出 CAS 是無鎖並行的基礎。

本文將 compare-and-swap（CAS）介紹為支撐現代並行程式設計的底層硬體原語，說明它如何成為 Kotlin 的 StateFlow.update {}、AtomicInteger 以及各種無鎖資料結構的基礎。文章強調，CAS 是實現不依賴傳統鎖機制的關鍵，並將其視為這些抽象背後的隱藏引擎，幫助讀者理解無鎖設計的核心概念。

11

Android Interview Questions & Answers Part:2 (Kotlin & Jetpack Compose)

Medium Kotlin 作者：Arindam Ghosh 發布：06-18 06:42

Kotlin: Understanding val vs const val

Explain the difference between val and const val in Kotlin with examples.

重點摘要

Both are used for read-only values in Kotlin

const val is limited to compile-time constants

Choose based on whether the value is known at compile time

This article focuses on the Kotlin distinction between val and const val, using interview-style questions and examples. It explains that both are read-only, but const val is restricted to compile-time constants and can only be used for primitive types and Strings at the top level or inside objects. By contrast, val can hold values assigned at runtime. The piece helps readers decide which keyword to use depending on whether a value is fixed at compile time or computed during execution.

Kotlin：理解 val 与 const val 的区别

Explain the difference between val and const val in Kotlin with examples.

重點摘要

两者都用于声明只读值

const val 仅适用于编译期常量

是否在编译期已知，决定选择哪个

本文以面试题形式讲解 Kotlin 中 val 与 const val 的区别。两者都表示值不可再次赋值，但 const val 只能用于编译期即可确定的常量，通常限制为原始类型和字符串，并且多用于顶层或 object 中；val 则可以在运行时初始化。文章帮助读者根据值是否在编译期已知，选择合适的声明方式。

Kotlin：理解 val 與 const val 的差異

Explain the difference between val and const val in Kotlin with examples.

重點摘要

兩者都可用來宣告唯讀值

const val 只能用於編譯期常數

是否在編譯期已知，是選擇依據

本文以面試題的方式說明 Kotlin 中 val 與 const val 的差異。兩者都代表不可重新指定的值，但 const val 只能用於編譯期就已確定的常數，且通常限於原始型別與字串，並需宣告在頂層或 object 內；val 則可在執行期才完成初始化。文章也提醒讀者，應依值是否在編譯時已知來選擇合適的關鍵字。

12

Android Security in 2025 (Part 2): Fixing Inadequate Supply Chain Security in Android

Medium Kotlin 作者：Mohit Damke 發布：06-18 06:46

Android Security in 2025 (Part 2): Fixing Inadequate Supply Chain Security in Android

Third-party SDKs, dependency auditing, Gradle security

重點摘要

Focuses on Android supply chain security risks

Highlights third-party SDKs and dependency auditing

Mentions Gradle security as a key area

This article is the second part of a series on Android security in 2025 and focuses on supply chain security concerns. From the available excerpt, it specifically points to third-party SDKs, dependency auditing, and Gradle security as the main topics. The piece appears to continue a discussion on how Android developers can reduce risk by better managing external dependencies and strengthening build-time security practices.

2025 年 Android 安全性（第 2 部分）：修复 Android 中不足的供应链安全

第三方 SDK、依赖审计、Gradle 安全性

重點摘要

聚焦 Android 供应链安全风险

提到第三方 SDK 与依赖审计

将 Gradle 安全性列为重点

本文是 2025 年 Android 安全性系列的第二部分，主题集中在供应链安全不足的问题。根据当前可见内容，文章主要涉及第三方 SDK、依赖审计以及 Gradle 安全性等议题。整体来看，作者延续前文讨论，说明 Android 开发者可通过更严格地管理外部依赖，并强化构建阶段的安全实践，来降低供应链带来的风险。

2025 年 Android 安全性（第 2 部分）：修補 Android 供應鏈安全不足問題

第三方 SDK、依賴項稽核、Gradle 安全性

重點摘要

聚焦 Android 供應鏈安全風險

提到第三方 SDK 與依賴項稽核

將 Gradle 安全性列為重點

本文為 2025 年 Android 安全性系列的第二部分，主題聚焦在供應鏈安全不足的問題。從目前可取得的內容可知，文章主要談到第三方 SDK、依賴項稽核與 Gradle 安全性等議題。整體看來，作者延續前文脈絡，說明 Android 開發者如何透過更嚴謹地管理外部依賴與強化建置流程，降低供應鏈帶來的風險。

今日總結

我應用程式 97% 的程式碼都在 commonMain：100% Compose Multiplatform 上線實錄

重點摘要

Navigation 3 時代的 SavedStateHandle：是時候重新思考你的 ViewModel 了

重點摘要

當 Postgres 不是遍歷圖的最佳場域

重點摘要

無論你喜不喜歡，你的 App 都將可在平板上調整大小

重點摘要

關於 2026 年 Android 開發，沒有人會告訴你的事

重點摘要

Server-Driven UI 回來了，而且這次更聰明了

重點摘要

「領會」Kotlin 協程：為什麼會有 suspend

重點摘要

掌握設計原則：Kotlin 中的依賴反轉原則

重點摘要

我逆向分析了機車的 Bluetooth 協定，把 Google Maps 放上儀表板

重點摘要

破解 Compare-And-Swap（CAS）：無鎖並行背後的秘密引擎

重點摘要

Kotlin：理解 val 與 const val 的差異

重點摘要

2025 年 Android 安全性（第 2 部分）：修補 Android 供應鏈安全不足問題

重點摘要