企业官网建设流程全解析

Unity项目怎么接入抖音小游戏？这个问题我最近被问了好几次，尤其是做微信小游戏做到一半想多平台分发的团队，以及刚开始接触小游戏赛道的Unity开发者。其实抖音小游戏和微信小游戏虽然同为“小程序容器”思路，但底层的适配方案、构建流程、调试链路差异都不小。这篇文章我就把Unity项目接入抖音小游戏的完整路径、我踩过的坑、以及上线前容易忽略的细节一次说清楚，希望能帮你少走几天弯路。

先说结论：Unity接抖音小游戏，核心思路是借助字节跳动官方的Unity适配插件，把Unity项目导出为一个“抖音小游戏工程”，然后在抖音开发者工具里打开、调试、预览、真机测试，最后提交审核上线。整个链路不需要你把游戏用Laya或Cocos重写一遍，还是以Unity为主力开发环境，最终产物是一个能在抖音App内运行的小型WebGL应用。

Mac/Windows上都能操作，Unity版本建议用2021 LTS或更新的稳定版，配合Node环境做打包预处理。这里需要强调一个认知：Unity导出到抖音小游戏，本质还是WebGL那套东西，只是外面套了一层抖音小游戏的适配框架。所以你在Unity里做的渲染、UI、动画、物理等大部分工作，都会保留下来，但涉及平台能力的部分——比如原生插件、直接读写文件、某些系统API——就要走字节提供的转换接口去适配。

这篇文章适合的人群很明确：会Unity基础、想把手上的Unity项目变成抖音小游戏、但对字节这套打包链路不太熟的开发者。就算你完全没接触过小游戏，照着下面的步骤走一遍，也能跑通第一个Demo。

1. 整体接入思路拆解：为什么Unity能进抖音小游戏

1.1 底层本质：不是原生输出，而是“WebGL”换壳

很多人第一次接触Unity转小游戏时会困惑：Unity不是编译成原生代码吗？为什么能塞进一个小程序容器里？答案在于，抖音小游戏对Unity的接入方案，本质上是一个基于WebGL的运行时容器。Unity官方很久以前就支持WebGL构建目标，能把你的游戏构建成一套跑在浏览器里的JavaScript + WebAssembly + 纹理/音频资源包。字节的适配层做的事情，就是把Unity WebGL产物“翻译”成抖音小游戏能识别的工程结构，比如补上game.json、project.config.json、适配插件模板文件，同时把原生浏览器相关的API映射到小游戏环境提供的API上。

所以你在Unity里看到的“扩展”或者“适配插件”，做的事情并不是把你所有代码变成C#之外的什么新语言，而是完成三件小事：一是调整Unity引擎在WebGL下的启动初始化流程，让它适配小游戏的生命周期（比如onShow、onHide）；二是将Unity的输入事件（触摸、键盘、加速度计等）桥接到小游戏的事件体系；三是处理资源加载方式，因为小游戏包体通常限制在4MB或12MB（具体以平台最新公告为准），超出的部分要走远程资源、子包等功能。

1.2 为什么选择官方插件而不是自己魔改

早期有人自己改Unity导出的WebGL模板，把UnityLoader改成自己的加载器，再手写一套字节API桥接层。这种“手搓方案”在技术上可行，但维护成本和踩坑成本极高。官方适配插件已经处理好了大量边缘情况，比如WebGL context丢失时的恢复、触摸事件坐标的偏移处理、音频播放兼容性等。非官方方案你每升级一次Unity版本，可能就要重新做一遍适配，非常消耗时间。

字节的Unity适配插件也已经迭代了几代。它不只是打包工具，还提供了运行时兼容层，比如taa（音频）、SDK（登录、分享、支付、广告等）相关的Unity C#接口封装。这意味着你在Unity C#代码里可以调一句DTSGameSDK.Login(...)就完成抖音账号登录，不需要自己解析JSSDK的JSCall。插件升级也和Unity版本、抖音小游戏基础库版本绑定，尽量跟随官方更新而不是固定在某个旧插件版本上，否则会碰到基础库升级后API被废弃的问题。

1.3 抖音小游戏和微信小游戏的主要差别

如果你之前做过微信小游戏，转抖音时最需要注意的是API差异，而不是Unity本身。字节小游戏的基础库命名空间、初始化方式、广告组件、支付方式都和微信不同。Unity部分的操作流程类似，但插件对应的菜单和配置项不同，发布产物也不同（game.json的字段体系区别于微信的game.json）。音频处理上两边也不同，抖音需要你用字节插件提供的音频接口初始化Unity的音频输出，限制比微信更严格一点。如果项目里用了微信小游戏SDK，迁移到抖音时必须替换成字节的SDK，不是光改包名就行。

还有分包策略：微信支持的分包目录和抖音支持的子包字段不完全一样。Unity的远程资源加载，两边都会要求“域名白名单”“下载校验”，但配置入口和游戏内校验方式有差异，这部分放到后面的实操章节细说。

2. 环境准备与工具链选型

2.1 Unity版本、Node环境、抖音开发者工具怎么搭

这一部分容易出问题，很多人一上来就安装最新版Unity或最新版开发者工具，结果遇到插件不兼容。先说我的建议组合：Unity 2021.3 LTS（或者2022.3 LTS），Node 16以上（用nvm管理更好），抖音开发者工具用官方稳定版、保持更新即可。不是越新越好，因为Unity WebGL的压缩方案在小游戏环境里支持有限，Brotli压缩在部分基础库版本下反而会拖慢启动；用LTS版本至少可以保证插件的匹配度更高。

Node环境主要用来跑构建脚本和字节提供的命令行工具。你不需要深入Node开发，但要保证node -v和npm -v能正常输出。如果你电脑上已经有其他Node项目，避免全局版本冲突，推荐用nvm为小游戏打包单独设置一个Node版本。

抖音开发者工具就是你的“浏览器+调试台+模拟器”，类似微信开发者工具，但界面和功能差异不小。它会模拟抖音App内的运行环境，显示console日志、网络请求、性能面板。真机预览时需要扫码，开发者需要注册为抖音开发者。这个环节需要企业认证还是个人认证，取决于你发布的游戏类型和是否涉及支付，建议提前查看平台规则。

2.2 官方适配插件的获取与版本匹配

字节官方提供Unity SDK/适配插件，一般在抖音开放平台上能下载，是一个Unity Package，可以用Window -> Package Manager -> Add package from tarball或直接把com.bytedance.unity.minigame整个目录丢进项目的Packages目录下导入。导入后Unity菜单栏会出现字节相关菜单，比如抖音小游戏之类的入口，具体菜单位置会随插件版本略有不同。

版本匹配的优先级是：插件文档中标注支持的Unity版本范围 > 你的Unity版本 > 插件功能是否覆盖你想要的基础库。不要直接用最低版本插件强行配最新Unity，日志里会报出各种编译错误或生命周期不触发的问题。每升级一次插件，建议先在空场景打包一次Demo测试，确认渲染、点击、音频、SDK登录都正常，再放到真实项目里。

2.3 一个最简单的验证项目建议

第一次接入时，不要直接拿公司几GB的大项目试，先用官方Demo或一个空场景（一个Cube、一个Button、一段UI）跑通全流程。因为Unity WebGL构建本身就涉及很多坑，叠加小游戏适配后问题更多。用小项目验证时，把构建耗时、产物结构、启动流程都记录下来，作为后续大项目的基准。这一步很有价值，后续排查问题时能区分“Unity WebGL的问题”和“小游戏适配的问题”。

我在早期接入时，就是偷懒直接打包大项目，结果报错一堆，完全分不清是哪里出的问题。后来老老实实用Demo跑通，再逐步迁移业务代码，效率反而高很多。

3. 核心操作流程：Unity构建到抖音小游戏全步骤

3.1 Unity工程中的关键配置

接入插件之前，先调整Unity工程的WebGL构建配置。流程：打开File -> Build Settings，平台切换到WebGL，点Player Settings。重点看以下几项：

• Publishing Settings里的Compression Format：建议选Disabled或Brotli。选Disabled后产物体积会更大，但兼容性最好；选Brotli后产物体积小，但需要抖音基础库支持br解码。如果你发现真机加载后白屏且console报解压错误，先改成Disabled试试。
• Other Settings里的Color Space建议保持Linear或Gamma与项目原设定一致，大部分Unity项目是Linear，移动设备上能用，但注意真机颜色与你本地编辑器有差异。
• Other Settings -> Enable Exceptions不要全开，会显著影响WASM性能；关闭时出错信息少，调试阶段可以开Expose Enabled Checks。
• Browser Compatibility里WebGL版本选好，部分插件要求WebGL 2.0，但如果遇到兼容问题退回WebGL 1.0。
• Strip Engine Code开启与否影响包体大小，但开启后有些反射或动态创建资源的逻辑会报错。第一个可跑版本建议关闭，优化阶段再打开并配合link.xml做裁剪。

还要确认Architecture用的是WASM。虽然理论上也能用Asm.js，但性能差很多，抖音侧也更推荐WASM。

3.2 构建WebGL产物

Unity构建时，未安装适配插件时直接Build，产物是一个标准的WebGL包，包含index.html、Build文件夹、TemplateData等。安装适配插件后，构建菜单会把“Unity项目”转成“小游戏项目”的目录结构。

我的习惯是新建一个独立目录如DyttMiniGame作为构建输出目录，方便每次Build后对比。构建参数中Development Build建议第一轮开启，这样能看到更详细的日志；正式提审包关闭。

构建过程中如果出现emscripten相关的报错，大概率是Unity版本和插件内置的emscripten版本冲突，优先检查Unity版本是否在插件支持范围内。另一个常见构建问题是内存不足，Unity WebGL构建时会把所有C#程序集转成C++再到WASM，非常吃内存，建议关闭其他大型软件，且保证硬盘空间充足。

3.3 生成抖音小游戏工程结构

构建完成后，输出目录里会出现抖音小游戏的核心文件：game.json、project.config.json、game.js、unity.data等。game.js是整个小游戏的适配入口，它会启动Unity的WASM运行时、加载数据文件、初始化渲染Canvas。你在Unity里写的C#逻辑编译后成为WASM代码，数据和场景资源则被序列化到unity.data这类文件中。

这里面有几个文件需要重点关注：

• game.json：小游戏的配置，包含页面、子包、设备方向（比如deviceOrientation为portrait或landscape）、交互设置等。遇到屏幕方向不对、留海屏适配问题，大概率要调整这里。
• project.config.json：开发者工具的项目配置，类似微信的project.config.json，包含appid、编译设置等。
• game.js：适配层的入口逻辑，不要手动大改，但可以在里面调整加载进度、初始化的优先级等。早期联调时有些人会在game.js里加console日志，我建议临时加没问题，提审前要还原。

3.4 导入抖音开发者工具并预览

打开抖音开发者工具，选择“小游戏”项目类型，导入构建输出目录。此时工具会提示缺少appid之类的信息，没有就注册一个测试小游戏获取appid，不能随便填一个。

导入后如果一切正常，你会看到一个“模拟器”窗口，能在里面看到Unity游戏画面渲染。这一步大概率会遇到tt.mini.game相关报错，提示某个接口未定义、某个API已废弃等。别慌，先看console里是Unity内部报错还是适配插件报错。Unity内部报错通常是C#异常或资源加载失败；适配层报错则和插件版本、基础库版本相关。开发者工具的右上角可以选择基础库版本，建议先用“最新稳定版”，如果遇到兼容问题再降级。

点击“预览”后生成二维码，用抖音App扫码就能在手机上跑真机。真机预览是必须做的一步，因为模拟器里渲染和真机差异很大，尤其是音频、触控多点、设备性能。

3.5 提审前的基础自检清单

很多刚接触的开发者，功能跑通就提交审核，结果被打回。我整理一份自查清单，提审前过一遍能省不少时间：

• 项目能通过“真机预览”启动，且加载进度条正常，不会卡在0%或闪退。
• 手机无网络时（或弱网环境）能进入游戏，或给出友好提示；很多游戏提审时被要求“不可直接白屏”。
• 游戏内的UI在小屏、留海屏、全面屏上布局正常，不会因为系统状态栏或底部小黑条遮挡关键按钮。
• 抖音登录、分享、支付等能力在测试模式下调通，不会在审核环境下因code换取openid的配置缺失而报错。
• 游戏包体大小符合平台要求，超出的部分要么开启远程资源配置，要么拆分主包和子包，要么压缩资源。

这只是一份最基础的检查，平台侧审核标准是动态变化的，还是建议以最新发布规范为准。

4. 常见问题排查与避坑技巧

4.1 白屏、启动卡在Loading界面

这是Unity转抖音小游戏最最最常见的头号问题。白屏原因一般有这几类：

第一，Compression Format不兼容。Brotli解码在小游戏基础库中曾经存在过兼容性问题，如果WebGL产物用了Brotli而小游戏环境没有对应的解码逻辑，数据文件加载不出来，就会一直卡loading。排查方式很简单：改成Disabled重新构建，若问题消失即定位到压缩格式。

第二，WASM启动失败。WebAssembly.instantiate失败，多与基础库版本、编译目标有关。可以先试降低基础库版本，如果仍失败，检查Unity的Browser设置是否启用了WebGL 2.0，有些机型对WebGL 2.0支持弱，降为1.0能解决。

第三，入口脚本报错。打开开发者工具的Console，找是否有ReferenceError或TypeError，比如某个变量未定义。这种要重点看适配层插件版本和基础库版本是否匹配，特别是从旧版升级插件后，game.js和模板文件没有重新生成，会出现旧模板调用新接口的情况。重建输出目录能解决大部分此类问题。

我现在排查白屏的思路是：先看开发者工具的Console，看有无JS报错；若无报错则看Network面板，看data文件是否加载完成；若无问题再看WebGL context是否创建成功；最后看Unity内部日志。按顺序排查，效率比乱改配置高很多。

4.2 触摸事件偏移、点击不准确

Unity WebGL在小游戏中的触摸坐标，需要把抖音小游戏的触摸位置映射到Unity的屏幕坐标。如果你发现点击按钮没反应，点A处触发B处，问题基本出在坐标转换或者Canvas尺寸没同步。

适配插件一般会自动处理canvas的宽高和CSS像素比例。但如果你在Unity Player Settings里设置了Resolution为固定值，比如1280x720，而手机上屏幕比例不是16:9，那么引擎会自动缩放或裁剪，这时触摸映射就要有缩放系数。常见坑是编辑器里正常，真机变形。建议检查game.js或适配层代码里是否有对window.innerWidth/innerHeight的监听和画布尺寸同步逻辑。

还有一个隐蔽问题：如果页面里开启过tt.setKeepScreenOn或ad隐藏时页面resize，Canvas尺寸变化后Unity的DPI没有刷新，会导致触摸位置偏移。遇到时试试在C#端主循环里延迟一帧重新获取屏幕尺寸，或者在小游戏的onResize回调中主动重置Unity的viewport。

4.3 音频无声、音效异常、音频延迟

音频是Unity转小游戏的重灾区。Unity内置的WebGL音频输出在抖音小游戏环境可能不生效，字节适配插件会利用小游戏的音频API实现一套音频桥接。出现无声问题时，首先检查Unity的音频初始化是否被插件接管——有些版本需要你在C#脚本里显式调用适配层的InitAudio。

第二个原因是音频文件格式和加载方式。小游戏环境对音频格式的支持有限，如果你的音频是平台不支持的格式但Unity编辑器里播放正常，真机上就会静音。建议统一转为常见的mp3格式并开启Force To Mono。长音频和短音效也要区分处理，长音频用AudioClip加载并预下载，短音效可以在Unity的AudioSource里预加载并播放。

还有音频延迟：真机上如果存在播放延迟几十毫秒，特别是在点击音效场景，适配插件可能会做一次预解码，延迟依然存在时可以在C#侧将音效预加载到内存。如果延迟超过可接受范围，建议在Unity里用OnAudioFilterRead之外的方式单独去调小游戏的音频接口播放音效。

4.4 内存过高、闪退、频繁GC

Unity WebGL构建运行在小游戏环境时，内存管理是个大问题。手机上内存有限，Unity引擎的WASM又要占用一块线性内存，如果场景资源很大，很容易触发崩溃。首要原则是管好包体和运行时资源加载，不要在启动时一次性加载全场景。

WASM线性内存和GC的内存是不完全相同的。你会在Unity Profiler看到Managed Heap涨到一个值之后就不释放，这在小游戏环境会导致整体内存上涨。排查有几招：减少场景里动态生成的GameObject数量；使用对象池；把项目从Mono切换成IL2CPP后，GC策略调整下；对于临时的Texture2D或AudioClip，用完及时Destroy并调用Resources.UnloadUnusedAssets。

我在真机调试时喜欢在开发者工具的性能面板里抓内存快照，对比不同基础库版本下的内存峰值。同一份代码在不同基础库版本下，内存可能差出两三百兆，这部分差异只能靠测试后选定一个基础库版本固定下来。

4.5 API差异、SDK无法初始化

如果你直接用微信小游戏的SDK或代码，拿到抖音上运行肯定是不行的。字节的初始化方式与微信完全不同，需要单独下载字节的Unity SDK。此外，登录、支付、广告等接口都需要在抖音开放平台申请对应的AppID和权限。SDK初始化失败有个典型报错是tt.init is not a function或GameSDK is not defined，一般是SDK资源未加载完就调用了初始化接口，或者Unity侧引用的SDK静态库版本与插件内置版本冲突。

处理方法是：在C#里正确检查SDK初始化状态后再发起初始化；如果项目同时做了微信和抖音双端，最好在项目里做一层平台抽象，避免两边SDK代码互相污染。不要在一个工程里同时初始化两套SDK，可能会造成资源抢占和游戏卡顿。

4.6 包体限制与资源远程加载

抖音小游戏对包体大小有明确限制，超出后需要资源上传到CDN，运行时从远程下载。Unity WebGL构建产物中包含的大头是unity.data，也就是场景、纹理、动画等资源的总和。如果超限，优先做以下几步：

第一，检查Unity的Texture Compression设置，所有纹理尽量用ASTC或ETC2，不要在WebGL里保留未压缩的RGBA。第二，把大型美术资源从Resources目录中移除，改为AssetBundle，构建后用工具上传至CDN。第三，利用Unity的Addressables或AssetBundle做按需加载，主包只保留首屏必要资源。

这里需要特别提醒：远程资源加载在抖音小游戏里要走字节的tt.downloadFile或适配层提供的下载接口，不能在Unity C#里直接用UnityWebRequest拉公网资源。即使能通，也没有校验和缓存机制，可能导致资源更新后用户却加载到旧缓存。

5. 性能优化与上线前细节打磨

5.1 启动性能优化：从加载到首帧的时间

小游戏的启动体验非常影响留存，加载越慢，玩家流失越严重。Unity WebGL产物的启动链路比较重：下载WASM和data文件 → WASM编译 → 初始化引擎 → 加载首个场景 → 渲染首帧。你要从下载体积、WASM编译、引擎初始化这三方面分别压时间。

下载体积方面，使用CDN + 压缩 + 分片加载，WASM文件本身用gzip或br压缩。WASM编译方面，小游戏运行时有缓存机制，但如果你给WASM文件加了版本参数导致每次变化，缓存就失效。让WASM文件名保持唯一且稳定，场景和逻辑更新时只更新data文件。引擎初始化方面，减少启动场景的GameObject数量，不要在Awake里做大量同步计算，把需要异步加载的内容延后。

另外，Unity 2020以上WebGL默认支持“代码分段”，把引擎初始化代码分离出一部分，能加速首帧。抖音小游戏适配插件如果支持该特性，尽量开启，能明显减少启动时间。

5.2 帧率、DrawCall与Shader兼容

WebGL和原生渲染管线有很大区别。Unity项目原先是移动端或PC端，转到WebGL后要重新审核DrawCall数量和Shader兼容性。小游戏的渲染性能上限远低于原生应用，特别是在低端安卓机上，如果DrawCall超过300，帧率会掉得怀疑人生。

Shader方面，最先检查你有没有使用依赖Compute Shader或复杂后处理的渲染效果。抖音小游戏环境基于WebGL，不一定支持完整的URP/HDRP管线。如果你的项目是URP，建议在WebGL目标下把质量等级调低、关闭体积光、泛光、SSAO等后处理。如果还在用内置渲染管线，SRP Batcher可能无效，所以要尽量手动合并材质和网格。

我踩过的具体坑：项目里用了一个屏幕后处理特效，用了OnRenderImage里多次Blit，在WebGL下帧率直接砍半。后来改成全屏Shader只Blit一次，性能立刻回到60帧。遇到这类问题，用Unity Profiler或在开发者工具里看WASM CPU耗时，定位消耗最大的Shader Pass。

5.3 安全区适配与刘海屏、全面屏

抖音小游戏运行在手机App内，页面顶部有状态栏、底部可能有HomeIndicator。如果Unity场景里UI和按钮固定了坐标，这些区域可能被遮挡或触发误触。为适配安全区，你需要在小游戏侧读取屏幕的安全区信息，比如tt.getSystemInfoSync()里提供的safeArea字段，然后把数据传给Unity的C#代码，动态调整Canvas里的UI布局。

避免把最高频的操作按钮放在屏幕底部中间，因为全面屏手势冲突的概率最大。我的做法是在启动时通过JSSDK把safeArea的top、bottom传给Unity，再用一个全局偏移函数处理所有UI面板的定位。如果UI是用uGUI的CanvasScaler做的，计算偏移时要分参照分辨率和实际屏幕分辨率一致。

5.4 资源管理：避免重复下载和内存泄漏

远程资源的缓存和版本管理值得单独处理。每次资源包更新时不要更换目录，而是在下载环节通过请求头或文件名版本号标记，做好版本对比。小游戏的缓存空间有限，远程资源文件太大时，需要程序内控制缓存淘汰策略。

Unity侧要特别注意场景切换后的资源卸载。小游戏运行环境内存紧张，全屏场景加载多次后，旧资源如果不清理，最终会内存溢出。我的方法是在场景加载前强制Resources.UnloadUnusedAssets()，并降低QualitySettings的纹理尺寸限制来减少内存占用。

还有一点容易被忽略：Unity的AssetBundle在WebGL下如果用LZMA压缩，解压时会占用额外内存；改用LZ4或未压缩会更快更省内存，代价是包体更大，但远程加载可以接受。真机上用LZ4的加载速度和内存占用明显优于LZMA，提审前测一下再做决定。

5.5 动态更新与灰度发布

小游戏不像原生App每次迭代都要发版，你的Unity逻辑和资源有一部分可以通过远程资源更新，而不是每次都重新提审。动态更新的做法一般是将逻辑和资源配置为远程方式，启动时检查版本号，下载新资源覆盖本地。

这里有一个Trick：Unity的C#逻辑编译进WASM后，如果你改了C#代码就要重新构建WASM，WASM通常在主包中，还是要提审。所以想走远程更新，需要尽量把可变的“配置、数值、剧情、皮肤”等都放在AssetBundle或JSON/Addressables资源里，C#只作为引擎壳。这样的架构一开始就要设计好，后期再改会非常痛苦。

灰度发布是指先在少量用户中发布新版本，观察崩溃率和性能数据后再全量。抖音侧有领班测试、分阶段发布等机制，具体以平台工具为准。我在实际发布中体会到，灰度发布远比你自己测试几十台真机更能发现问题，特别是低端机器上的内存崩溃和兼容性崩溃，灰度数据比什么都靠谱。

6. 我的几点实战心得

做到这里，Unity接入抖音小游戏的流程已经比较完整了。最后分享几条只有实际做项目才会体会到的经验。

第一，永远保持“一个可运行版本”。做Unity小游戏时，很容易因为一个很小的配置项导致整个构建链崩掉。我建议你每调整一次配置、每升级一次插件，都重新构建并跑通最小Demo，再继续往下改。别连续调十个配置再构建，一旦出问题，定位成本极高。

第二，抖音小游戏的调试信息链路比微信复杂一些。Unity C#侧的Debug.Log不会直接出现在开发者工具console里，需要看适配插件的日志桥接有没有开启。有些版本需要用#if UNITY_WEBGL宏包裹对应日志代码，或者通过桥接把日志输出到小游戏console，否则线上问题很难排查。遇到“线上出问题但本地复现不了”时，先检查日志链路通不通。

第三，插件版本不要长期不升。抖音基础库演进很快，一些接口会标注deprecated并在后续版本中移除。如果你长期停留在旧插件上，短期内很稳，但某一天基础库强制升级后可能直接无法启动。建议每个季度安排一次插件升级测试，并记录每次升级对包体、性能、启动耗时的影响。

Unity转抖音小游戏这条路，时间成本主要集中在第一次跑通和性能优化阶段。工具链虽然还谈不上完美，但已经把过去需要手写适配层的工作大幅简化了。按上面这些步骤走，你大概率能在一到两天内跑通第一个可交互小游戏。做出一版能稳定运行的项目后，再谈包体优化、远程更新、精细性能调优，思路会清晰很多。