三个iOS WebKit陷阱，让我的AR游戏黑屏了。这不是标题党，是真实发生的事——一个跑在浏览器里的AR游戏，在iOS上打开就是一片黑，连报错都没有。
问题不在AR本身，也不在渲染逻辑。坑全在WebKit这个iOS上所有浏览器都必须用的内核里。桌面端跑得好好的代码，到了iPhone和iPad上就集体失灵。更麻烦的是，这些陷阱不会给你明确的错误提示，只会让画面安静地黑掉。
陷阱一：看不见的权限墙
摄像头权限是第一道坎。iOS对摄像头的管控比桌面严格得多，而且触发时机很讲究。如果权限请求的调用栈不是直接来自用户手势，WebKit会直接拒绝，连弹窗都不给。开发者看到的现象就是：代码执行了，回调没来，画面黑的。
这类问题的隐蔽性在于，它不抛异常。你只能通过日志一层层往回查，才能定位到是权限请求的触发方式出了问题。
陷阱二：视频纹理的静默失败
AR游戏要把摄像头画面当作纹理贴到3D场景里。在iOS上，视频元素要真正开始播放、并且有可用的帧数据之后，才能被当作纹理源。如果这一步的时序没对上，纹理就是空的。
空纹理不会让程序崩溃，它只是渲染出黑色。于是你看到的是一个逻辑完全正常、但什么都看不见的游戏。排查这种问题，靠的是把视频元素的状态一步步打出来，确认它到底有没有进入可播放状态。
陷阱三：上下文丢失后的沉默
WebGL上下文在iOS上更容易丢失，尤其是在切后台、内存吃紧的时候。上下文一丢，之前创建的所有纹理、缓冲区全部失效。如果代码里没有监听上下文丢失事件并重建资源，恢复前台后就是一片黑。
这个陷阱最容易被忽略，因为它在开发阶段不一定复现。只有真机、真实使用场景下切来切去，问题才会冒出来。
怎么抓住它们
三个陷阱的共同点是：不报错、不崩溃、只是黑屏。所以排查思路也得换——不能等错误，要主动验证每一个环节的状态。
- 权限：确认请求是否由用户手势直接触发
- 视频纹理：确认视频元素是否真正进入可播放状态
- WebGL上下文：监听丢失事件，重建全部资源
把这三步做成检查清单，黑屏问题基本就能定位到具体是哪一环断的。AR在浏览器里跑，难点往往不在AR，而在这些平台差异带来的沉默故障。
热门跟贴