```
***
### 图形
为你说明 Toss 提供的图形资源及其正确使用方法。
{% hint style="info" %}
**图形版权说明**
Toss 的所有图形资产，以及通过 Toast 生成的图形，均为 ㈜비바리퍼블리카 受《著作权法》及相关法规保护的知识产权。
提供的图形只能用于 AppinToss 合作环境内的服务运营和宣传目的，禁止在其他服务或媒体中通过复制、修改、分发、传送、向公众传送等方式使用。
{% endhint %}
***
**Toss 提供的图形资源**
**1. 图标 & 表情**
Toss 提供约 7,000 个以上的图标和表情套件。在 App Builder 和 Figma 中进行设计时，可以查看图标和表情列表。App Builder 可以在工作区中 [注册应用后](https://appsintoss.gitbook.io/appsintoss-docs/guide/operation/console-workspace) 从“设计”菜单开始。若需要自行制作图标， [AppinToss 图标制作指南](https://www.notion.so/21b714bbfde780fb84bac2acfbb4a6b9?pvs=21)请参考并按照标准制作。
**\[使用时注意事项]**
* 请在屏幕上以 24\~40px 大小使用图标。
* 不建议将两个或以上图标或表情并联组合使用。请一次只使用一个。
* Toss 提供的图形资源只能用于服务界面内的 UI 设计，不能用于应用 logo、缩略图等应用信息中。
**2. 智能手机模型文件**
用智能手机模型制作资源时，请直接使用上述提供的文件。图标已按尺寸提供，请不要随意裁剪、调整颜色或扭曲形状。
为反映设计更新，开发时也建议使用下面的 URL。
* **Full**
*
* **Large**
* Top:
* Bottom:
* **Medium**
* Top:
* Bottom:
* **Small**
* Top:
* Bottom:
**3. Toast（AI 图像生成工具）**
基于第 1 项提供的图标和表情，可以生成 3D 图像。生成的图形在实际画面使用前，需要获得 Toss 图形设计团队的使用许可。许可通常会在 1 天内完成。
**4. 其他**
3D 图形或动画只能使用 Toss 提供的模块中包含的资源。\
提供范围今后会逐步扩大。
***
**图形的正确使用方法**
**1. 请使用与语境相符的图形。**
图形不是装饰，而是帮助用户更轻松理解屏幕含义的角色。
**2. 请按信息密度使用合适的尺寸。**
简单图形请用小一点，细节较多的图形请用足够大的尺寸。
**3. 不要在同一屏幕上使用太多图形。**
相似尺寸的图形越多，视线越分散。\
请只使用最核心的一个图形，其余请用辅助图形或图标替代。
**4. 请避免遮挡核心信息。**
请调整尺寸和位置，避免重要内容被推到下方而产生不必要的滚动。
**5. 请避免负面或乞求式的情绪表达。**
让用户感到不快，或者像是在乞求、恳求的表达，都属于暗黑模式。\
请不要使用这类情绪表达。
**6. 不要使用装饰性效果或特效。**
无意义的描绘、粒子、过度渐变等元素会让画面变得复杂，并妨碍信息传达。
**7. 请使用能够准确传达情境的图形。**
在并非错误的情况下使用感叹号图标，或者\
在不需要等待时使用加载动画，用户可能会误解情境。
***
**合作方自行制作图形时的注意事项**
**1. 请保持 Toss 风格的一致性。**
Toss 倾向于简洁、明快、干净的数字图形风格。\
手绘感、抒情画风、漫画式表现可能会在界面中显得格格不入。
**Toss 的图形风格示例**
**2. 请使用高画质图形。**
请制作清晰、干净的高画质图形。若分辨率过低或粒子类细碎效果过多，可能会显得品质较低。
**3. 深色模式和浅色模式下都要清晰可见。**
Toss 应用中使用的图形需要同时考虑深色模式和浅色模式。\
过亮或过暗的颜色在某些模式下可能不够清晰，请使用中等明度的色彩。
**4. 请与整个界面协调构成。**
请平衡整个画面的颜色和布局，避免图形比文字或 CTA 按钮等其他元素更抢眼。
**5. 请带来积极且整洁的印象。**
图形在营造服务的稳定感和信赖感方面起着重要作用。\
请避免过多单色、朦胧和暗淡的印象，设计成明亮、整洁的感觉。
***
### 分辨率
本指南说明在开发 AppinToss 迷你应用时，应以什么分辨率为基准进行界面设计和优化，并解释推荐标准及如何在各种设备环境下稳定运行的设计方向。
AppinToss 迷你应用会运行在多种分辨率和屏幕比例的设备上。为减少因这些环境差异带来的混乱，本指南建议采用“以基准分辨率为中心的设计”方式，而非按设备分别适配。
{% hint style="info" %}
**请务必确认**
以一个逻辑分辨率为基准进行设计，并准备 1x·2x 资源，就能稳定覆盖 AppinToss 实际流量中的大部分。
{% endhint %}
***
**AppinToss 迷你应用全屏设计标准**
AppinToss 的游戏迷你应用必须实现全屏。在全屏环境下，必须考虑以下内容。
* 内容必须完全填满屏幕。
* 不能留下 WebView 边距或半透明区域。
* 不能因设备旋转而出现比例错乱或信箱模式（黑边）。
* 刘海、摄像头孔、Dynamic Island 应按 Safe Area 处理。
* 由于缩放导致资源质量不能明显下降。
因此，与其按设备分别设定分辨率，不如先确定一个基准分辨率，再通过缩放来应对。
***
**看待分辨率的两种标准**
在 AppinToss 迷你应用中，建议将分辨率分为以下两类来考虑。
**① 逻辑分辨率（Logical Resolution）**
这是 UI 布局、坐标计算和游戏逻辑的基准分辨率。
* 这与实际设备像素分辨率是不同的概念。
* 建议只选择一个逻辑分辨率。
* 应在所有设备上保持相同的游玩手感和界面构成。
**② 资源分辨率（Asset Resolution）**
指图片、背景、角色、UI 资源的像素密度。
* 不需要为每台设备单独准备资源。
* 用少数几个分辨率组来管理会更高效。
***
**AppinToss 推荐分辨率标准**
**① 逻辑分辨率推荐范围**
请在以下范围中选择一个作为基准分辨率。
* **纵向迷你应用：** 约 360 × 640 \~ 420 × 740
* **横向迷你应用：** 约 640 × 360 \~ 740 × 420
建议在此范围内确定一个基准分辨率，并以缩放方式应对设备间差异。
**② 资源分辨率推荐标准**
资源最好按组准备。
* **1x 资源**：对应基础分辨率
* **2x 资源**：对应高分辨率设备
只有在图形品质特别重要时，才选择性增加 3x 资源。
{% hint style="info" %}
**请务必确认**
大多数迷你应用仅用 1x + 2x 组合就足够了。如果过度细分资源分辨率，可能会导致内存占用增加、加载延迟和维护成本上升。
{% endhint %}
***
**基于数据的参考说明**
本指南是 **基于在 AppinToss 实际服务环境中收集的设备分辨率数据**整理而成。
* 约占全部迷你应用流量的 **70\~80%** 集中在横向约 **800\~900**，纵向约 **360\~420** 范围的 viewport 分辨率上。
* 其余流量则以分散到各种分辨率的长尾形式存在。
因此，与其逐一对应所有分辨率，不如以代表性的分辨率区间为基准进行设计，这样最有效率。
***
**测试设备指南**
不需要在所有设备上测试。只要满足以下条件的 **3\~5 台代表性设备**就足够了。
* 屏幕比例不同的 2\~3 台设备
* 1 台大范围应用 Safe Area 的设备
* 1 台屏幕尺寸相对较小的设备
***
**不推荐的方式**
请避免以下方式。
* 按不同设备型号使用不同逻辑分辨率的方式
* 以实际像素分辨率为基准计算 UI 或坐标的方式
* 运营过多不同的资源分辨率组的方式
* 在不同分辨率下维持不同 UI 布局的方式
这些做法可能会导致 UI 错位、出现黑边，以及维护成本增加。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://developers-apps-in-toss.toss.im/landing-page/landing-page-zh/design/consumer-ux-guide.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
