夏忆昔做Unity抖音小游戏这条路，最近问的人真的很多。很多人手上已经有一套Unity游戏，想往抖音小游戏平台搬，但卡在“打包”和“上架”这两个环节。要么不知道用什么工具链转，要么转出来了上传又报错，要么提审被拒了不知道哪里改。这篇我直接按自己踩过的流程，把从Unity工程到抖音小游戏上架的完整链路捋一遍，包括环境适配、侧边栏接入、资源优化、广告位参数、提审注意事项这些，尽量一次讲透。
先说清楚这篇适合谁。如果你是想把已有的Unity 2D或3D游戏改造成抖音小游戏，或者公司接了外包项目要做抖音小游戏，又或者是个人开发者想试试小游戏流量收益，这篇文章都可以直接当操作手册用。我会尽量少贴大段代码，多讲流程和取舍逻辑，因为小游戏开发比起写功能，更难的往往是“为什么这一步要这么做”。
1. 整体流程梳理与关键技术路线
1.1 抖音小游戏与微信小游戏在技术路线上的差异
很多做Unity的人第一反应是：“我做的是Unity游戏，抖音小游戏又不是用Unity跑的，怎么上？”这个理解没有错，抖音小游戏运行环境是字节系自有的容器，和微信小游戏本质上是类似的，都不能直接跑Unity的IL2CPP原生包。所以核心思路是：用Unity把游戏导出成WebGL工程，再用官方转换工具把WebGL产物转换成抖音小游戏能识别和加载的格式。
我之前做过微信小游戏适配，再转抖音时发现一个有意思的事：Unity官方其实提供了微信小游戏适配方案（Instant Game），抖音侧则是字节自己搞了一套转换工具。两者的共同点都是基于WebGL做桥接，区别在于初始化SDK、API命名、账号体系、支付内购这些平台层的能力不相同。所以如果你已经适配过微信小游戏，切抖音时会省不少事，但千万别以为是复制粘贴就行。
1.2 整体流程分几步走
我把完整的流程拆成六个阶段：开发准备、打包适配、平台能力接入、本地调试、版本提审、上线运营。每一个阶段都有它对应的“坑”，下面我按实际操作的顺序讲。
开发准备阶段，你需要确认Unity版本、目标平台、是否安装了WebGL模块。打包适配阶段，要做的事包括调整API Level（如果你是同时发安卓原生包）、做包体瘦身、处理UI适配和资源加载方式。平台能力接入阶段，需要把抖音小游戏的初始化SDK、侧边栏、激励视频、登录等能力接到Unity挂载的宿主脚本里。本地调试阶段，用抖音开发者工具加载转换后的小游戏目录，逐项核验功能。提审阶段，要准备好图标、截图、隐私协议这些资质材料。上线运营阶段，关注崩溃率、ecpm和用户反馈。
这条链路最核心的一点是：从Unity到抖音小游戏的转换，不是一次点击就结束的。首次转换完成后，你还需要处理一堆兼容性问题，我后面会专门展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 打包前必须处理的适配项
2.1 Android API Level与构建目标的关系
在热搜词里看到“unity 提高 minimum api level target api level 到api35”，这个恰恰是很多人在打包阶段最容易忽略的一项。抖音小游戏本身是WebGL产物，理论上不直接涉及Android Target API Level，但很多Unity团队的现状是同一套代码既发抖音小游戏，又发安卓原生包。如果你同时走这两条线，那原生包的Target API Level必须往高了提。
原因很简单：安卓应用市场在持续收紧targetSdkVersion要求，如果你的Target API Level还停留在很低的老版本，上架时会直接被应用市场打回。我实际遇到的情况是，Unity默认的Target API Level偏低，需要手动在Player Settings里调高到34或35（具体看当前主流市场要求）。调完之后还需要把Gradle版本、Android SDK Build-Tools一并升级，否则构建会报错。
但这里要注意，调整API Level只是针对安卓原生包。如果你的项目只做抖音小游戏，那精力更应该放在WebGL平台的压缩格式和内存占用上，小游戏容器对性能和包体的敏感度远高于原生APK。
2.2 包体瘦身与首包加载速度
抖音小游戏对包体有硬性限制，首包（主包）一般控制在20MB以内最稳，超出后必须走分包加载。Unity转换出来的WebGL包经常动辄几十甚至上百MB，如果不处理直接传上去，轻则加载慢到让用户流失，重则审核直接不通过。
包体瘦身我常用的方案有几层。第一层是资源层面的，UITexture和Sprite图集要压缩，音频尽量用低码率，模型网格能合并就合并，纹理格式尽可能选择ASTC或ETC2这类GPU能直接采样的格式。第二层是代码层面的，用代码裁剪（Strip Engine Code）配合IL2CPP的裁剪机制，把没用的Unity模块减掉。第三层是加载层面的，一定要做AssetBundle分包，把首屏必需的核心资源打进主包，其余关卡、道具、音效统统走AB包按需加载。
有一个容易被忽略的点是，抖音小游戏里的“首包”概念跟Unity里的StreamingAssets不完全一样。转换工具会把你的WebGL数据目录重新组织，所以你在Unity工程里放StreamingAssets路径下的文件，转换后要确认是否被正确归类到了首包还是资源包中。如果发现某些文件没有跟着打包进产物，优先检查Unity侧的文件放置路径是否合规。
2.3 UI适配与竖屏横屏安全区
小游戏运行在手机环境，不可避免地要处理各种异形屏、刘海屏、不同宽高比。如果你原来做的是移动端App，到了小游戏容器里，UI适配逻辑基本沿用，但有几个地方不同。
抖音小游戏的运行容器里是可以控制横屏还是竖屏的，这个在开发者平台创建小游戏时就能选。选定横竖屏之后，Unity工程里的Game视图宽高比最好保持一致，否则转换后会出现整体拉伸或黑边。更稳妥的做法是，在Unity里就用Screen.safeArea判断安全区，把关键按钮、弹窗避让开刘海和底部横条。我见过有团队在PC上测得好好的，一上手机发现顶部按钮被刘海挡住，就是忽略了安全区。
此外，小游戏默认会有一个加载进度条和胶囊菜单按钮，这个胶囊按钮是抖音容器自带的，会悬浮在游戏界面上。你在做UI布局时要假设屏幕右上角存在一个不可控的悬浮元素，尽量别把高频点击的按钮放在那个区域。这个胶囊按钮能不能隐藏或者移位置，取决于最新版SDK能力，建议开发前查一下当前平台的接口文档，以官方规定为准。
3. 抖音侧边栏接入与其他平台能力
3.1 什么是抖音侧边栏，为什么要接
“侧边栏”这个说法在抖音小游戏里指的是用户从抖音App的侧边栏入口直接拉起小游戏的能力，用户可以在抖音首页右滑或者通过侧边栏卡片快速进入游戏场景。很多做小游戏的同学只关注抖音内的信息流和搜索入口，忽略了侧边栏也是一个真实存在的流量来源。
接入侧边栏的核心操作是在小游戏初始化后，调用抖音开放能力的接口，把当前游戏注册为可被侧边栏拉起的实例。注册成功后，侧边栏会展示小游戏图标，点击后直接唤起游戏。接入过程并不复杂，关键是在Unity侧正确拿到初始化SDK的引用，并在合适的生命周期节点做注册，比如在启动场景加载完成后调用。
有一个我需要特别提醒的是：官网SDK的能力和API是持续更新的，早期版本的侧边栏接入方式可能在最新基础库下已经废弃。建议在接入前先看一遍“抖音开放平台”提供的接入文档，以文档里最新的方法名为准。网上搜到的教程可能会有时间差，照搬容易踩版本兼容的坑。
3.2 激励视频广告与ecpm的逻辑
做小游戏的人都很关心ecpm（千次曝光收益）。抖音小游戏的主流变现方式是激励视频，也就是用户看一段广告，游戏给钻石、复活机会、双倍奖励这类激励。ecpm并不是一个固定值，它受广告填充、用户地区、广告主出价、曝光频次等因素影响。你可以通过后台的数据看板实时看到不同广告位的ecpm表现。
从接入逻辑上讲，Unity工程里一般是写一个广告管理器脚本，将抖音平台的激励视频API封装成Unity可调用的C#接口。用户点击“看视频复活”按钮时，Unity调用这个接口，动态创建并加载广告实例，然后监听加载成功、播放完成、关闭等回调。注意，广告实例不要反复创建，最好在场景启动时就预加载，否则播放前临时加载会出现拉取失败或长时间无回调。
ecpm想提升，除了广告位位置设计得自然一点，还有一个容易被忽略的点：新用户和沉默用户的广告价值完全不同。如果做活动把老用户唤回来看广告，和让新用户第一次接触激励视频，ecpm差距可能挺大。建议在后台观察不同用户群体下的广告收益，把激励视频入口设计得更贴近游戏内刚需。
3.3 登录、分享、录屏等能力接入
小游戏不只靠广告赚钱，社交裂变也是重要流量来源。抖音小游戏里有分享能力、录屏能力、登录能力，这些都需要在前置阶段接入。最常见的做法是做一个C#侧的宿主脚本，把抖音SDK的能力封装成方法，然后在Unity的游戏逻辑中调用。
登录能力相对简单，主要是获取用户授权与openid，用于存档绑定。分享就得注意平台规则，严禁诱导分享或者强制分享后才能继续游戏，这类违规会直接导致审核被拒。录屏能力更多用于竞技类游戏，让用户把高光时刻录下来发布，这种天然的内容传播属性在小游戏平台往往能带来额外流量。
无论接什么能力，都要在工程里处理好“未初始化完成”的状态。抖音SDK的初始化是异步的，而Unity的Awake/Start是同步的。我习惯在启动场景做一个登录界面，等SDK初始化回调到达后再跳转主场景，这样能规避一大半“调用SDK时报错未初始化”的问题。
4. 打包实操：从Unity构建到转换工具
4.1 Unity侧构建WebGL前的参数配置
在Unity里做抖音小游戏打包，第一步虽然有点违反直觉，但确实如此——你先要在Build Settings里把平台切到WebGL。这一步很多人会卡住，因为Unity没有“抖音小游戏”这个平台选项，它只有WebGL、Android、iOS这些。抖音的转换工具和微信小游戏适配类似，都是建立在WebGL产物之上的。
切到WebGL后，有几个参数是必调的：
- Player Settings里Company Name、Product Name建议改成游戏的真实名称，避免产出物里的默认名导致后续配置文件读取异常。
- Publishing Settings里压缩格式建议选Brotli或Gzip，虽然运行时容器能解压，但压缩率直接影响资源加载速度。
- Code Optimization建议选Speed，对首屏加载更友好。
- 如果项目用了较新的C#特性，要确认当前Unity版本对WebGL的IL2CPP编译支持情况，有时候某些API在WebGL下是不存在的，编译时会直接报错。
构建时长取决于工程大小，但注意Unity侧构建出来的目录是一个WebGL文件夹，里面包含Build、TemplateData等子目录。你不需要对这个目录做任何手动的内部修改，直接整个交给转换工具即可。
4.2 转换工具的正确使用顺序
拿到Unity的WebGL产物后，打开抖音开发者工具，选择“小游戏项目”，导入方式选择“从WebGL转换”。工具会自动解析WebGL产物并生成一个摇一摇加载兼容层的小游戏目录。转换完成后，最好先别急着上传，先在开发者工具里把整个流程跑一遍。
转换之后你会看到一个新增目录，一般包含game.js、game.json、src目录等。game.json是小游戏的核心配置文件，包含页面路径、设备方向、分包结构等。Unity转换工具会帮你把大部分配置自动填好，但转完要检查一下game.json里的“deviceOrientation”字段是不是你期望的横竖屏，这个字段直接决定游戏在小程序里以什么方向展示。
还有一个常见情况是，转换工具提示“资源过大”或者“某些文件不在允许列表内”。出现这类提示时，优先检查是不是把不必要的编辑器资源、调试日志文件放进了Build目录。有同事遇到转换后小游戏包比WebGL原始目录还大的案例，排查发现是Texture没走压缩，原始PNG全部被塞进去了。
4.3 本地联调与真机预览
转换产物在模拟器能跑，不代表真机没问题。抖音开发者工具里的模拟器对WebGL的还原度整体不错，但性能表现和资源加载时序跟真机有差异。我习惯的做法是，先用开发者工具过一遍功能、接口、广告位的冒烟测试，确认无逻辑报错后，再到手机上用抖音扫码预览真机环境。
真机预览时重点看三个维度：首屏加载时长、运行帧率、内存占用。首屏加载如果超过3秒，用户流失会很严重，需要回到资源分包和压缩环节做优化。运行帧率如果时常抖动明显，可以从阴影、实时灯光、粒子数量入手做减负。内存占用异常上涨时，要审查是不是有纹理或音频没有正确释放。
联调阶段的日志查看方式也要单独说一句。Unity里的Debug.Log在小游戏容器里并不直接显示在开发者工具的控制台，通常需要通过转换工具提供的日志桥接层来输出，或者在game.js里做一层日志转发。如果没有提前处理，你将面临“游戏真机表现异常但完全看不到报错”的窘境。
5. 上架提审流程与资质准备
5.1 注册开发者账号与创建应用
上架抖音小游戏，第一步是注册抖音开放平台的开发者账号。个人开发者和企业开发者能创建的应用类型不同，企业主体可以开通虚拟支付和更多流量入口，个人主体在部分能力上会有限制。如果你只是测试玩一下，个人号足够；如果要认真做发行和变现，建议直接用企业主体。
创建小游戏时，需要填写游戏名称、简介、分类、图标，这里有几个细微要求：名称不能与已有知名游戏太相似，简介里不能出现“首充”“返利”等敏感词，图标需要清晰且在较小尺寸下仍能认出内容。审核人员是按照平台规则逐项核对的，任何一项不合规都会被拒。
5.2 提审时需要准备哪些材料
抖音小游戏提审阶段要提交的材料比想象中多。除了基础的游戏包，还需要软著证明（如果你是自主研发的原创游戏）、游戏自审自查报告、隐私政策说明。软著这个东西周期比较长，我的建议是立项后马上准备，等游戏做完的时候软著差不多也下来了，否则会卡在资质环节白白浪费时间。
隐私政策不要随便网上找一个模板填。小游戏涉及登录授权、广告标识、用户行为数据统计，这些都在隐私政策的涵盖范围内。抖音侧现在对个人信息收集的合规性审查很严，隐私政策里写了什么，代码里就必须真的做了什么。如果你在隐私政策里声明不收集用户信息，但代码里却又调用了获取用户手机号的接口，这种矛盾很可能会导致审核被拒甚至下架。
5.3 审核常见被拒原因与修改方向
我实际遇到和听到的审核被拒原因，排在前几位的是：
- 游戏内容或素材涉及诱导分享、诱导关注、赌博擦边等违规元素。
- 隐私政策不完善或与线上功能不符。
- 游戏包/首包超限，提审时上传失败或加载过慢。
- 广告位设置不合法，比如在游戏开始前直接强插广告。
- 没有明确退款入口（如果接入虚拟支付的话）。
每一类都有对应的修改方向。比如诱导分享，修改文案并取消分享后的强制奖励；隐私政策不完善，就对照平台模板补齐用户权利说明和第三方SDK目录；包超限就继续分包；广告位置不合法就调整到游戏自然暂停或死亡结算等节点。审核被拒并不可怕，只要不是内容违规严重，大部分情况下修改后重新提交就能通过。
需要注意的是，抖音审核团队的工作时间并不是24小时的，有时候周五下午提交的版本，可能要等到下周一才有审核结果。做好了时间预期能减少很多焦虑，我第一次提审等了两天多，还以为出事了，其实就是在排队。
6. 常见问题与排查技巧实录
6.1 DllNotFoundException与代码裁剪冲突
“unity dllnotfoundexception: unable to load dll 'slua'” 这类的报错，在小游戏转换场景里尤其常见。原因是项目里用了第三方原生插件或热更脚本，比如SLua、XLua这类Lua桥接库，它们在WebGL/小游戏环境下没有对应的原生实现。小游戏容器不是操作系统级的运行环境，不能像原生App那样加载so或dll，所以这类报错基本无解。
遇到这类情况，第一件事是检查代码裁剪设置。当Unity开启Strip Engine Code后，反射调用和部分动态加载的代码可能被误裁剪，导致运行时找不到类型或方法，表现上和DllNotFoundException很相似。如果确认不是代码裁剪问题，那基本就是插件不兼容了，需要替换方案。比如把SLua替换为纯C#的配置表方案，或者把逻辑用Unity自身支持的脚本方式重写。
6.2 缓存更新与版本兼容问题
小游戏的更新机制很特殊。用户首次进入后会下载包体并在本地缓存，后续再进时如果服务端没变化，可能直接走缓存资源，不会拉取新版本。这对发版影响很大——你修完bug提审通过后，用户手机上的缓存还没更新，老版本一直在跑。
处理方式是在小游戏启动阶段调用更新检查接口，如果发现远端有新版本，主动触发缓存清理或重启时重新拉取。也建议在后台做好版本灰度策略，不要一次性全量发布，万一新版本有线上问题，你还能及时回滚。
6.3 性能与帧率如何压线达标
小游戏审核对性能没有特别硬性的指标线，但上线后平台会根据性能数据和用户体验做流量调控。低端机上如果帧率一直在20帧以下，用户反馈差，平台给你的流量就会减少。这是一个比提审更长期的运维课题。
性能排查我常用Unity Profiler跑一遍WebGL模式，看看CPU耗时大头在哪。如果卡在UI重建，就检查Canvas的动静分离；如果是粒子系统，就调低Max Particles或改用Shader模拟；如果是Draw Call过高，就做图集和批处理。测试机建议拿一台2GB内存、性能偏低的老安卓机跑，这种机器能过基本就能覆盖大多数用户的真机表现。
6.4 如何获取ecpm并优化收益
后台查看ecpm是实时的，但只看单日数据波动会很大，更建议拉一周或一个月维度的均值。ecpm优化一方面靠广告位触发时机的设计，另一方面靠留存。小游戏广告收益本质是“用户量乘以人均广告展示次数再乘以ecpm”，三者缺一不可。
如果你的游戏人均广告展示次数已经很高但ecpm偏低，很可能是广告填充率上出了问题，可以尝试在非高峰时段测试一下是否频繁出现“广告拉取失败”的提示。如果确实频繁失败，排查一下广告位ID是否配置正确、是否因为测试包被限流、或者SDK版本过旧导致接口不兼容。把广告SDK升级到最新版，很多时候能直接解决填充率问题。
7. 上架后的运营与数据观察
小游戏上架不是终点，上线后才是真正面对用户的时候。我上架后的第一周会密集观察三个指标：次留、人均使用时长、加载成功率。次留能看出游戏第一印象好不好；人均使用时长能看出数值玩法和关卡设计的黏性；加载成功率能反映出包体大小、资源压缩和服务器带宽是否匹配。
如果加载成功率偏低，最优先排查的是资源加载并发问题。Unity WebGL产物在慢网环境下，如果一次性加载的AB包数量过多，或单个资源文件过大，很容易导致卡死或超时。解决方式是拉长加载顺序，优先加载核心场景，边玩边加载后续资源。
另外，抖音小游戏平台的用户群体和传统应用市场用户画像差异挺大，游戏新手占比更高。所以如果原来做的是硬核向端游移植，一定要在前期加新手引导和难度平滑过渡。我见过不止一个项目在App端数据不错，上小游戏后直接滑铁卢，原因就是忽略了平台用户属性。
运营层面，还可以利用抖音的内容生态做联动，鼓励玩家录屏分享精彩操作。录屏分享在小游戏平台上有天然优势，用户录制内容会直接关联小游戏信息，其他用户刷到视频后可以一键进入游戏。相比买量投放，这种自然内容流量的成本低很多，但上限也取决于游戏本身的节目效果。
根据我自己试过几次的经验，给小游戏预留一些全局事件埋点非常关键。有了埋点，你后续做AB测试、调广告位位置、优化关卡难度，才有数据支撑，不然每次改动都只能靠感觉。埋点尽量在首次开发时就做好，后期补埋点容易漏，数据对比也不连续。
从Unity打包、抖音侧边栏接入到上架审核，整套流程第一次走需要一周左右，第二三次就会快很多。最花时间的往往不是框架性的大问题，而是那些单个看起来很小、却非常耗时的兼容性细节。如果你当前正卡在某一步，先别急着改代码，列一个流程图，把当前步骤的输入、输出、依赖项理清楚，再动手。很多“玄学报错”本质上都是前置条件没满足引发的连锁反应。
最后再分享一个小技巧：抖音小游戏平台的基础库是会持续更新的，建议每次官方发布新版本后，及时用开发者工具升级基础库并回归一遍广告和登录功能。平台能力更新往往不只是加新接口，还可能调整老接口的行为，早发现比用户骂街了再修要轻松得多。