把一个新闻应用装进折叠屏，打开来应该是什么样子？如果还是手机那套全屏列表跳全屏详情，屏幕展开之后宽出来的那一半空间等于白费了。这就是平行视界（Navigation Split 模式）真正要解决的问题：在大屏上把列表和详情并排显示，在手机上自动退回普通的栈式导航，一套代码，两种体验。Navigation 的 Auto 模式是实现平行视界的核心，不需要手动判断设备类型，阈值 600vp 是系统默认值。

折叠屏上的相机页面，最容易出现的问题不是功能报错，而是看起来没崩、但预览画面完全不对。展开设备后预览区域拉伸变形，或者出现明显黑边，甚至方向和实际持机方向不符。这类问题单看日志发现不了，单看布局代码也找不到原因，因为根源往往在"窗口尺寸变了，但相机预览没有随之重建"这个环节。这篇文章从窗口变化这个切入点，梳理折叠屏上相机预览适配的核心逻辑。折叠屏相机适配的核心矛盾不在布局，而在"UI 容器尺寸"和

折叠屏上的相机页面，最容易出现的问题不是功能报错，而是看起来没崩、但预览画面完全不对。展开设备后预览区域拉伸变形，或者出现明显黑边，甚至方向和实际持机方向不符。这类问题单看日志发现不了，单看布局代码也找不到原因，因为根源往往在"窗口尺寸变了，但相机预览没有随之重建"这个环节。这篇文章从窗口变化这个切入点，梳理折叠屏上相机预览适配的核心逻辑。折叠屏相机适配的核心矛盾不在布局，而在"UI 容器尺寸"和

做图文阅读、视频播放或图片浏览这类页面时，横竖屏切换几乎是绕不开的问题。旋转设备后，封面图、操作按钮、进度条的位置突然错乱，或者内容区宽度没有随窗口变化——这类问题的根源通常不是 ArkUI 的布局 bug，而是开发者对"窗口尺寸变化时页面到底发生了什么"这件事理解得不够准确。这篇文章用一个最小化的图文详情页，走完横竖屏切换、全屏进入和退出、业务状态保持这一整条路。横竖屏切换的本质是窗口尺寸变化，

做图文阅读、视频播放或图片浏览这类页面时，横竖屏切换几乎是绕不开的问题。旋转设备后，封面图、操作按钮、进度条的位置突然错乱，或者内容区宽度没有随窗口变化——这类问题的根源通常不是 ArkUI 的布局 bug，而是开发者对"窗口尺寸变化时页面到底发生了什么"这件事理解得不够准确。这篇文章用一个最小化的图文详情页，走完横竖屏切换、全屏进入和退出、业务状态保持这一整条路。横竖屏切换的本质是窗口尺寸变化，

用户把应用退到后台，任务还在跑——这时候怎么让他感知到进度，又不强迫他回到应用？这正是闪控球和闪控窗要解决的问题。一个是常驻屏幕边缘的小球，承担最简进度提示；另一个是点击小球后弹出的展开面板，展示更多信息并提供操作按钮。两者分工明确，配合使用，形成一套完整的后台任务可见性方案。本文围绕官方文档提供的接口，用一个下载任务场景，把从创建控制器到状态切换、再到退出清理的完整开发流程串联起来。这两个组件将

用户把应用退到后台，任务还在跑——这时候怎么让他感知到进度，又不强迫他回到应用？这正是闪控球和闪控窗要解决的问题。一个是常驻屏幕边缘的小球，承担最简进度提示；另一个是点击小球后弹出的展开面板，展示更多信息并提供操作按钮。两者分工明确，配合使用，形成一套完整的后台任务可见性方案。本文围绕官方文档提供的接口，用一个下载任务场景，把从创建控制器到状态切换、再到退出清理的完整开发流程串联起来。这两个组件将

第一次接触闪控窗（Flash Control Window）的开发者，很容易把它理解成一个"可以自由摆放内容的小悬浮窗"。但只要真正动手配置过，就会发现系统对窗口尺寸、内容密度、按钮数量都有明确的规格上限，而且超出范围时系统会静默修正，不会直接报错——这意味着你的代码可以正常运行，但效果和预期完全不一样。这篇文章围绕闪控窗的窗口约束做一次系统性的梳理：官方规格是什么、哪些配置会被系统截断、边缘停靠

第一次接触闪控窗（Flash Control Window）的开发者，很容易把它理解成一个"可以自由摆放内容的小悬浮窗"。但只要真正动手配置过，就会发现系统对窗口尺寸、内容密度、按钮数量都有明确的规格上限，而且超出范围时系统会静默修正，不会直接报错——这意味着你的代码可以正常运行，但效果和预期完全不一样。这篇文章围绕闪控窗的窗口约束做一次系统性的梳理：官方规格是什么、哪些配置会被系统截断、边缘停靠

聊天页、评论框、表单页，这类页面有一个共同特征：底部常驻一个输入栏，左边是输入框，右边是发送按钮。软键盘弹出来的那一刻，问题出现了——输入框还在，发送按钮消失了，或者整条底部栏都被键盘压进了屏幕底部看不见的位置。系统的自动避让只保证焦点输入组件可见，并不关心"输入框旁边的按钮"。这是自动避让机制的设计边界，不是 bug。要让整个底部输入栏都随键盘上浮，需要切换到手动避让模式。这篇文章围绕这个具体场