Evilom
83 lines
7.2 KiB
Markdown
83 lines
7.2 KiB
Markdown
# Y42iwXAsXigSyfkF6bXc5UkLnyb
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/Y42iwXAsXigSyfkF6bXc5UkLnyb
|
||
|
||
|
||
# 一.工作内容概述
|
||
- 产出剩余系统所需美术资源，并完成项目内替换
|
||
- 学习 Cocos 多分辨率适配方法，理解 Canvas、Widget、UITransform 等相关组件的作用，并初步对部分界面尝试进行适配调整。
|
||
# 二.多分辨率适配知识梳理
|
||
## 多分辨率适配原理思路
|
||
多分辨率适配并不是单纯地把 UI 等比例缩放到不同屏幕上，而是要在不同设备宽高比下，保证核心内容可见、界面布局稳定、交互区域合理，并尽量避免 UI 被裁切、留黑边或位置错乱的问题。
|
||
Cocos 中多分辨率适配的核心，可以理解为**“以设计分辨率为基准，在真实设备屏幕上重新映射显示区域”。**
|
||
设计分辨率相当于开发时使用的一套标准画布尺寸，例如按照1080×1920来搭建界面。但在不同的设备下，屏幕分辨率和宽高比并不总会保持统一，因此运行时需要根据设备屏幕尺寸，对 UI 进行缩放与布局调整。
|
||
Cocos 的 Canvas 会基于设计分辨率和当前设备屏幕尺寸，计算 UI 在真实屏幕中的显示区域与缩放关系。
|
||
|
||
适配中比较关键的是 Fit Width 和 Fit Height。它们本质上决定了设计分辨率如何映射到真实屏幕，不同组合会影响 UI 的缩放比例和最终可视区域。
|
||
- Fit Width：优先保证设计宽度与屏幕宽度匹配，适合宽度方向布局较敏感的界面。
|
||
- Fit Height：优先保证设计高度与屏幕高度匹配，适合高度方向内容较重要的界面。
|
||
- 组合使用时，需要结合实际设备比例进行验证，避免出现内容过度缩放、边缘留白或局部裁切。
|
||
因此，实际项目中不能对所有界面使用同一种适配策略。背景类资源更关注铺满屏幕，必要时允许边缘裁切；核心玩法区域、按钮和交互内容则更关注完整可见和布局稳定。而且不能只看某一种分辨率下的表现，而是需要同时考虑窄屏、宽屏、全面屏、平板等不同设备比例下的显示效果。
|
||
|
||
|
||
|
||
## 相关节点与组件理解
|
||
### Canvas
|
||
Canvas 是 UI 适配的基础节点，主要负责整体显示区域和缩放策略。通常 UI 节点都会放在 Canvas 下，由 Canvas 统一管理它们在不同分辨率下的显示。
|
||
在项目中，Canvas 更适合处理“整体层级”的适配问题，例如：
|
||
- 当前界面以什么设计分辨率为基准；
|
||
- 整个 UI 是按宽度适配还是按高度适配；
|
||
- 屏幕比例变化时，可视区域如何变化；
|
||
- 根节点下的 UI 元素整体如何跟随缩放。
|
||
可以把 Canvas 理解为“统一画布”和“整体适配规则”的承载者。
|
||
### Widget
|
||
Widget 更偏向处理单个 UI 节点相对于父节点或屏幕边缘的位置关系。它可以让节点固定在上、下、左、右、中间等位置，也可以设置距离边缘的偏移值。
|
||
例如：
|
||
- 顶部资源栏固定在屏幕顶部；
|
||
- 返回按钮固定在左上角；
|
||
- 设置按钮固定在右上角；
|
||
- 底部操作按钮固定在屏幕底部；
|
||
- 中间弹窗保持居中显示。
|
||
|
||
|
||
|
||
需要注意的是，如果 Widget 的 Align Mode 设置为 Always，它会在运行时持续按照对齐规则刷新节点位置，因此节点的 position、width、height 可能会受到限制，不适合同时由动画或脚本频繁控制。
|
||
因此在实际使用时，需要区分：
|
||
- 静态 UI：可以使用 Widget 持续对齐；
|
||
- 动画 UI：要谨慎使用 Always，避免和脚本动画控制冲突；
|
||
- 弹窗类 UI：通常适合使用居中对齐；
|
||
- 边缘按钮：适合使用上下左右边距对齐。
|
||
### UITransform
|
||
除了 Canvas 和 Widget，UITransform 中的宽高、锚点、节点坐标也会直接影响适配效果。
|
||
比如一个按钮虽然通过 Widget 固定到了右上角，但如果锚点设置不合理，实际位置可能会出现偏移；一个背景图虽然铺满了设计分辨率，但在宽屏设备下可能无法覆盖完整屏幕。因此，适配时需要同时关注节点尺寸、锚点、父子层级和 Widget 约束。
|
||
## 具体应用理解
|
||
今日也初步在部分界面中尝试使用 Canvas 和 Widget 进行适配调整，重点观察了背景铺满、顶部栏固定、底部按钮对齐以及弹窗居中等场景在不同屏幕比例下的表现。
|
||
结合项目中的 UI 使用场景，后续可以按不同类型节点采用不同的适配方式。
|
||
### 背景图适配
|
||
背景通常应该优先保证铺满屏幕。对于背景图，可以采用覆盖式思路，让其在不同屏幕比例下尽量填满画面，必要时允许边缘区域被裁切。
|
||
这样可以避免宽屏或长屏设备上出现黑边。背景设计时也要尽量把重要内容放在中间区域，边缘只放可裁切的装饰内容。
|
||
### 主内容区域适配
|
||
主玩法区域、棋盘、关卡区域等核心内容，一般需要保证完整可见。它们可以放在 Canvas 中央，通过居中布局或适当缩放来适配不同屏幕。
|
||
对于这类区域，不能简单铺满屏幕，否则在极端比例设备上可能导致内容被裁切或操作区域过小。更合理的方式是保持主体比例稳定，再根据屏幕剩余空间调整周边 UI。
|
||
### 顶部和底部 UI 适配
|
||
顶部资源栏、头像、货币栏、返回按钮等，可以通过 Widget 固定到顶部或左右两侧。
|
||
底部按钮、模式切换、操作栏等，则可以固定到底部区域。这样在不同设备上，UI 能够跟随屏幕边缘变化，不会因为整体缩放导致位置偏移。
|
||
这种方式比较适合手游界面中常见的“顶部状态栏 + 中间内容 + 底部操作区”结构。
|
||
### 弹窗界面适配
|
||
弹窗通常应保持居中显示，背景遮罩铺满全屏，弹窗主体保持固定比例或在一定范围内缩放。
|
||
例如体力恢复弹窗、奖励弹窗、确认弹窗等，可以采用：
|
||
- 遮罩节点铺满 Canvas；
|
||
- 弹窗主体居中；
|
||
- 关闭按钮绑定弹窗右上角；
|
||
- 弹窗内部元素相对于弹窗面板布局，而不是直接相对于屏幕布局。
|
||
这样可以保证弹窗在不同分辨率下结构稳定，不会因为屏幕变化导致按钮错位。
|
||
# 三.后续计划
|
||
**界面适配与美术完善：**
|
||
- 逐步完成各面板的分辨率适配；
|
||
- 补充遗漏美术资源，并优化已有资源表现；
|
||
- 持续加入 UI 动效、特效等交互表现。
|
||
**关卡与玩法体验：**
|
||
- 体验《佛系消消消》，总结其关卡设计、节奏控制与投放思路；
|
||
- 基于体验结果重新生成并配置关卡，必要时扩充关卡编辑器功能。
|
||
**平台测试：**
|
||
- 持续进行真机测试，排查不同设备和平台环境下的适配问题。 |