devgo.cn苹果秋季发布会刚过，最大的新闻不是芯片参数，而是那台折叠设备。折叠屏终于从安卓和鸿蒙的专属玩具变成了主流移动设备的新形态——但这对开发者来说，恐怕是个头痛的转折点。想象一下：你的App现在要在小屏和展开的大屏之间无缝切换，单栏变双栏，列表与详情同屏出现，导航从整页跳转变成区域切换，手势返回的逻辑要重写，动画节奏还得保持一致……如果只适配一个平台，咬咬牙也就做了，但Android、iOS、HarmonyOS三端都要各来一遍，维护成本直接翻三倍。腾讯开源的跨端框架Kuikly给出的答案是：把折叠屏适配这事从“逐端开发”抽离成“共享Kotlin层的一次适配”，让同一套页面逻辑在多端复用。
Kuikly基于Kotlin Multiplatform（一种让Kotlin代码在多个平台共享的技术）构建，覆盖Android、iOS、HarmonyOS、H5、微信小程序、Mac六大平台，支撑日活超5亿的业务。它的核心思路不是简单抹平平台差异，而是把折叠屏适配的复杂度拆解成三层：平台数量、窗口形态、交互模式。传统方案里，这三层每增加一项都要产生新的开发和验证组合，而Kuikly把可复用能力逐层沉淀——尺寸模型、状态模型、布局策略、导航语义、交互原则全部统一定义在共享层，平台侧只承接必要的容器和系统能力。比如布局断点（响应式设计中页面布局切换的临界尺寸）在共享代码里声明一次，三端都遵循同一套切换规则；选中项和页面层级不依赖具体平台容器，折叠展开后状态恢复也成了框架的默认行为。
最让我意外的是它对路由和动画的处理。小屏页面通常靠Android Activity、iOS ViewController这类系统载体做整页跳转，但大屏后列表和详情同屏出现，原来的“打开新页面”变成区域内的内容切换，系统路由根本帮不上忙。Kuikly的做法是在自适应页面或组件内部建立统一的导航状态：业务只表达“进入详情”“返回上一级”，组件根据当前窗口形态自动映射成小屏跳转或大屏区域切换。动画同样如此——小屏保留系统转场，大屏在局部区域执行内容转场，从单栏切到双栏时还能同步编排列表宽度和详情位置，让内容关系在窗口变化中保持连续。手势方面，大屏右侧区域可能多层内容，一次返回是关整个页面还是只回上一级？Kuikly把返回栈和手势作用域关联起来，大屏优先回退当前区域内部层级，栈清空后再由外层处理，避免点击穿透。
这些能力不是只服务折叠屏。Kuikly把窗口变化驱动页面响应式刷新做成框架基础能力，同套布局断点、状态管理和策略可以复用到平板、分屏、小窗甚至未来大屏场景——当新设备形态出现，业务只需调整断点和策略，不用重建适配体系。平台差异也收敛在原生渲染架构内部：iOS的Liquid Glass等平台特性可以自然融入，状态栏、刘海、挖孔、圆角这些物理限制被抽象成统一的安全距离，一次布局在各端自动避让。目前示例代码已开源在GitHub（Tencent-TDS/KuiklyUI，feat/kuikly_fold分支），值得开发者直接拿来参照。
对正在做多端App的团队，这套思路最直接的启发是：折叠屏适配不该按“新设备”来做，而应视为应用持续适应空间变化的能力。与其每个平台各写一套逻辑，不如把尺寸响应、状态管理、导航语义这类高频重复的部分抽到共享层沉淀为可复用资产。当然坑也明显——框架的成熟度、社区生态、是否适合你团队的技术栈（尤其是否接受Kotlin作为跨端语言）都需要前置评估。但方向很清晰：折叠的屏幕越来越多，打磨“多形态体验复用”的能力，迟早是刚需。
内容与图片版权归原作者所有 · 原文: https://mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649804073&idx=1&sn=cb50dfd70925eaa04a791e9a1b03b382