Un cargador transaccional en TypeScript para cambiar de avatar 3D sin cortar la sesión
Un patrón de dos fases prepara y valida el avatar candidato antes de activarlo, para que el usuario nunca vea un fotograma roto en la sesión en vivo.
Un desarrollador propone un patrón de dos fases para cambiar de avatar 3D en una sesión en vivo sin que nadie llegue a ver el fotograma roto. El candidato se prepara y se valida en segundo plano, y solo entonces se activa, de golpe y de forma síncrona. El ejemplo está escrito en TypeScript y se apoya en el SDK Beauty AR de Tencent RTC, aunque el patrón vale para cualquier integración que permita preparar recursos antes de mostrarlos.
El problema no es generar el avatar
Un modelo produce en minutos un concepto de avatar, un manifiesto de recursos o un esqueleto de integración. Lo incómodo viene después: decidir si ese candidato aguanta en producción. Que se vea bien no significa que cargue en el dispositivo objetivo, que el seguimiento funcione, que quepa en el presupuesto de render o que sobreviva a un cambio de ropa fallido. La implementación que sale primero encadena carga y muestra, y deja sin respuesta qué se ve mientras carga, qué pasa si el recurso carga pero genera fotogramas inválidos, o qué ocurre si llega otra selección antes de terminar la primera.
La regla que propone el tutorial es más estricta: el avatar activo sigue visible hasta que un candidato nuevo pase la validación de política y la calificación en tiempo de ejecución. Si todavía no hay ninguno activo, se muestra un marcador de posición explícito, nunca la cámara, que requiere su propia decisión de producto y su propio consentimiento.
Un puerto transaccional y una política por tramos
El núcleo es una interfaz, AvatarPort, con cinco operaciones: preparar el manifiesto, sondear el candidato, activarlo, restaurar el anterior y liberar recursos. La activación es síncrona a propósito. JavaScript no puede intercalar otra selección en medio de un commit síncrono, así que una carga antigua que termine tarde no puede ganar la carrera. Si la API de la plataforma es asíncrona, el adaptador tiene que aportar la serialización equivalente.
La validación se apoya en una política por tramos de dispositivo. El ejemplo desactiva los avatares 3D directamente en equipos de gama baja y, para gama media y alta, fija límites de bytes declarados, número de fotogramas de calificación, fotogramas defectuosos tolerados y tiempo máximo por fotograma. En el caso medio: 8.000.000 de bytes, 12 fotogramas de calificación, dos fallos permitidos y 40 ms por fotograma; en el alto, 16.000.000 de bytes, un solo fallo y 32 ms. El propio autor avisa de que son valores de ejemplo y no referencias de producto: los umbrales salen de medir tu propia matriz de dispositivos. Tencent RTC publica además una guía de optimización para equipos de gama baja que recomienda ajustar los efectos por tramo y descartar cargas como el 3D o la segmentación cuando el dispositivo no las sostiene.
Que la pieza no tenga dependencia de ninguna biblioteca de render es lo que la hace interesante para quien tiene que mantenerla: el comportamiento de estado y de fallo se prueba sin cámara, sin GPU y sin sala en vivo. Y hay una decisión de producto debajo de todo esto que conviene leer bien: desactivar el indicador de avatar 3D por tramo significa no intentar esa carga en ese dispositivo, no probar a ver si el usuario lo tolera.
