每日新聞摘要

This article continues from an earlier piece that argued testing is non‑negotiable in modern Android engineering. It focuses on unit testing while placing it within the broader landscape of test types, and aims to bridge first principles — why tests matter and how to think about them — with pragmatic, production‑grade practices developers can adopt. The author emphasizes understanding test scope, designing maintainable and reliable tests, and integrating testing into development workflows so teams can reduce regressions and increase release confidence. Combining conceptual grounding with actionable recommendations, the article is intended to help Android engineers move unit testing from a theoretical ideal to a robust part of their production process.

本文延续前文观点，强调在现代 Android 工程中测试不可或缺，並將單元測試置於其他測試類型的脈絡中，旨在把基本原理（為何要測試、如何思考測試）與可用於生產環境的實務做法相連接。作者強調明確測試範圍、設計可維護且可靠的測試，並將測試納入開發流程，以降低回歸風險並提升發佈信心。文章兼具概念說明與可操作的建議，適合希望將單元測試從理論落實到生產流程的 Android 開發者參考。

This guide explains how LaunchedEffect functions within Jetpack Compose, focusing on its lifecycle and how it runs coroutines tied to composables. It discusses the interaction between LaunchedEffect and recomposition so you can understand when effects are launched, cancelled, or restarted. The article also addresses patterns for safely managing coroutines that are driven by state changes, helping avoid leaks or unexpected behavior when state updates trigger new effects. Overall, it aims to give developers a clear, practical understanding of using LaunchedEffect correctly in Compose-based applications.

本文介绍了 LaunchedEffect 在 Jetpack Compose 中的工作机制，说明它如何在可组合函数的生命周期内启动、取消或重启协程，并分析在重组过程中效果的触发时机。文章还讨论了由状态变化驱动的协程的安全管理方法，以避免资源泄漏或因状态更新导致的意外行为，旨在帮助开发者在 Compose 项目中正确且稳健地使用 LaunchedEffect。

The author describes a common experience: using Kotlin every day without fully understanding the language's inner workings. Although productive with Kotlin code, they felt unsure about what the compiler, runtime, and abstractions were doing behind the scenes. This led to a deliberate effort to probe and learn the mechanics that power everyday Kotlin code. The article reflects on how routine usage can mask gaps in deeper knowledge and why bridging that gap matters for more confident, effective development. By recounting the realization and the ensuing investigation, the author aims to encourage readers who write Kotlin regularly to question assumptions and seek a clearer mental model of what the language actually does.

作者讲述了一种普遍的经历：尽管每天都在写 Kotlin，并能产出可用代码，却并不清楚语言在底层究竟如何运作。面对编译器、运行时与各种抽象的内部机制，作者感到迷惑，进而主动去学习和调查这些底层细节。文章反思了日常使用如何掩盖理解上的空白，以及弥补这些空白为何能提升开发的信心与效率。通过记录这一觉醒与探索的过程，作者希望激励同样经常使用 Kotlin 的读者检视既有假设，建立更清晰的语言运作认知。

This Medium article, titled "Android System Design: Complete Facebook News Feed Architecture" by Abi Farhan, is linked but not included in full here. The provided excerpt contains only a "Table of Contents" line and a "Continue reading on Medium" prompt; no substantive content or section details are present in the supplied text. To read the full analysis, architectural diagrams, or implementation discussion implied by the title, the reader must follow the original Medium link. Based solely on the title, the article likely aims to examine system-design aspects of Facebook's News Feed as implemented on Android — such as component responsibilities, data flow, caching, offline support, scalability, and performance considerations — but those specifics are not present in the excerpt. This summary reflects only the available snippet and how to access the complete article.

这篇 Medium 文章标题为「Android System Design: Complete Facebook News Feed Architecture」，作者为 Abi Farhan。所提供的文本片段仅包含一行「Table of Contents」和「Continue reading on Medium »」的提示，没有包含任何章节内容或技术细节。若要查看完整分析、架构图或实现讨论，需要访问原始链接。仅从标题可以推测文章聚焦于 Facebook News Feed 在 Android 上的系统设计，但本摘要仅基于可获得的片段说明如何获取全文，不对原文内部的具体技术细节作实质性引述或推测。

The article explains how sockets enable real-time, two-way communication for Android apps and contrasts HTTP requests with persistent connections. It outlines three socket types—WebSockets for standardized low-latency streaming, Socket.IO as a library that adds fallbacks, reconnection and event handling, and raw TCP/UDP for low-level binary transfers. A practical Jetpack Compose example uses io.socket:socket.io-client:2.1.0: define a DashBoardMessage data class, a DashBoardViewModel exposing latestMessage via mutable state, and a SocketManager that connects to a server, listens for "message" events, parses JSON into the data model, posts updates to the main looper, and disconnects cleanly. The Compose DashboardScreen starts the socket in LaunchedEffect and displays Var1–Var3. A GitHub repository with the full example is provided.

文章介绍了在 Android 中使用 sockets 实现实时更新的原理与实践，区分 WebSocket、Socket.IO 与原始 TCP/UDP 的用途与特性。强调 Socket.IO 为移动端处理断线重连、消息缓冲、事件命名和广播等常见网络问题提供便利。并给出一个基于 Jetpack Compose 的实作示例：添加 io.socket:socket.io-client:2.1.0 依赖及网络权限，定义 DashBoardMessage 数据类，DashBoardViewModel 通过 SocketManager 建立连接并以 mutableStateOf 暴露最新消息；SocketManager 在接收 "message" 事件时解析 JSONObject，切换到主线程回调以更新 UI，disconnect 时正常断开与移除监听。示例通过 DashboardScreen 在 LaunchedEffect 中启动连接并显示 Var1–Var3，文末附上 GitHub 演示仓库链接。

Soft assertions allow tests to continue after an assertion fails, collecting multiple failures to be reported as a group rather than stopping at the first error. With AssertJ, developers working in Java and Kotlin can adopt soft assertions to obtain consolidated failure reports and clearer diagnostics, which reduces the need for repeated test runs and shortens debugging time. Unlike hard assertions that halt execution immediately, soft assertions gather errors during a test and throw a combined exception at the end, giving a fuller picture of regressions in one run. AssertJ’s fluent API and compatibility with common testing frameworks make it straightforward to integrate soft assertions into existing test suites, improving efficiency when validating multiple independent expectations.

软断言允许测试在遇到断言失败后继续执行，将多个失败汇总后一次性报告。使用 AssertJ，在 Java 与 Kotlin 中可以方便地采用这种方式，获得集中化的失败报告与更清晰的诊断信息，从而减少反复运行测试并缩短调试时间。与在首次失败即停止的硬断言不同，软断言会在测试结束时抛出合并异常，让开发者一次性看到所有回归点，有助于更快定位与修复问题。AssertJ 的流式 API 与主流测试框架兼容，使其容易整合到现有测验套件中。

This article warns Android developers that Android 15 (API level 35) makes edge-to-edge layouts mandatory, which can cause existing apps to break if they don’t adapt. It offers a concise three-step survival guide aimed at helping developers assess impact and implement practical fixes. Rather than diving into exhaustive API references, the guide focuses on actionable adaptation: understanding the implications of mandatory edge-to-edge, handling system window insets and display cutouts, and validating layouts and interactive elements across devices. The piece emphasizes proactive testing and incremental updates—adjusting themes and layout margins, ensuring content isn’t obscured by system bars or notches, and verifying touch targets and readability—so apps remain functional and visually correct under API 35’s edge-to-edge requirement.

本文提醒 Android 开发者，Android 15（API 35）强制采用 edge-to-edge 布局，可能导致现有应用出现问题。文章提供一份简明的三步求生指南，帮助开发者应对新规：了解强制 edge-to-edge 的影响、处理系统窗口 inset 与屏幕刘海或圆角、并在多设备上验证布局与交互组件。指南重点在于实现与测试：检查布局边界、更新主题与间距，确保内容不被系统栏或凹槽遮挡，并维持触控目标与可读性，让应用在 API 35 下仍能正常显示与运行。

The article contends that Swift’s emergence was not simply a technical successor to Objective‑C but a strategic move by Apple with career consequences for developers. It highlights that Apple spent four years developing the language in secret and argues that Swift’s design and rollout reflect broader goals: enforcing safer patterns, raising platform standards, and shaping how code is written for Apple ecosystems. Rather than viewing Swift as just another tool, the piece frames it as a force that changes who can succeed in the ecosystem — rewarding those who adapt and risking obsolescence for those who don’t. Developers are encouraged to see learning Swift as more than a skill upgrade: it’s a necessary response to shifting platform priorities and a signal of wider industry change.

文章认为 Swift 的出现并非仅仅是技术上取代 Objective‑C，而是 Apple 的一项战略举措，对开发者职业产生深远影响。作者指出 Apple 秘密投入四年时间开发该语言，并强调 Swift 的设计与发布反映了更广泛的目标：推动更安全的编码实践、提高平台标准并改变开发方式。与其把 Swift 当作单纯工具升级，文章提醒开发者它更可能重新定义谁能在生态中胜出——适应者受益，拒绝改变者可能被边缘化。学习 Swift 应被视为回应平台与行业优先级转变的必要行动。

Following Part 1’s conceptual introduction to MVI, this article focuses on practical guidance for shipping production Android apps with MVI. It examines how to manage side effects safely, design pagination flows, maintain an offline cache, and apply production-ready patterns that improve reliability and maintainability. The author outlines trade-offs and integration points—how effects are isolated from state, how paged data and network boundaries interact with local caches, and which architectural conventions help testing and debugging at scale. The piece aims to bridge theory and practice, giving teams actionable patterns and considerations for moving an MVI-based app from prototype to production while preserving unidirectional flow and predictable state management.

延续第一部分对 MVI 概念的介绍，本文侧重于如何用 MVI 在 Android 上交付生产级应用。文章说明如何在 MVI 架构中安全地处理副作用、设计分页流程、维护离线缓存，并采用适合生产环境的架构模式以提升可靠性与可维护性。作者讨论这些机制与状态流的整合与权衡，指出有助于测试、调试与扩展的实践要点，旨在将 MVI 理论与实践衔接，帮助团队将基于 MVI 的应用从原型推进到可部署的产品，同时保持单向数据流与可预测的状态管理。