首页里常见的推荐/关注/我的，或者概览/统计/设置，本质上都是同级页面切换。本文用一个三栏首页示例讲 ArkUI Tabs 的写法：父组件只管 tab 切换，每个 tab 自己维护状态；再对照 Android View 的 TabLayout + ViewPager2 和 Compose 的 TabRow / NavigationBar。

栅格解决的是“同一组卡片排几列”，动态布局解决的是“页面结构什么时候改变”。本文用一个设置面板示例，把 ArkUI 的 onAreaChange、条件渲染和布局模式表串起来：窄屏纵向堆叠，宽屏切成主设置区 + 右侧状态栏；再对照 Android View/Compose 的资源限定符、WindowSizeClass 与 BoxWithConstraints。

同一个“入口宫格/卡片墙”，在手机要两列、平板要三列、横屏要四列：如果你靠 if/else 手写一堆宽高，很快就会失控。本文用一个最小可复用的“功能入口栅格”示例，对照 ArkUI 的 GridRow/GridCol 与 Android（Compose 的 LazyVerticalGrid / View 的 GridLayoutManager），把“列数、间距、span/offset、断点”这套规则落到具体写法。

Row/Column 解决“沿一条轴排”，Stack 解决“覆盖叠放”，Flex 解决“放不下就换行”。但当你要把角标、播放按钮、标题、副标题、操作区同时放进同一张卡片时，真正的难点变成了：控件之间到底怎么互相对齐、互相约束？本文用一个封面卡片示例，对照 ArkUI RelativeContainer 与 Android ConstraintLayout（含 Compose 约束思路），把“约束关系”这件事从心智到写法一次讲清楚。

从 Android 迁移到 HarmonyOS，最容易犯的错是把 UIAbility 当成 Activity 的同名替换。真正的差异在更底层：HarmonyOS Stage 模型强调“一个 ArkTS 引擎实例服务一个 UIAbility”，而 Android 的运行时与 UI 组织方式更偏向“组件实例 + 任务栈 + 进程边界”。把运行时心智先对齐，后面的路由（Intent/Want）、页面栈、资源管理才不会越写越乱。

从 Android 迁移到 HarmonyOS，很多人会先问 Intent 对应什么。但真正决定迁移成本的，是“系统如何匹配并分发一次跳转”。这篇用一套路由契约的视角，对齐 Android 的 intent-filter 与 HarmonyOS 的 skills + Want，顺手把安全边界和排查路径一起带上。