Un contenedor SDK de dispositivo debería estandarizar las convenciones de llamadas y al mismo tiempo preservar las diferencias reales entre dispositivos. Los nombres de API coincidentes no definen la semántica de los parámetros, la propiedad del búfer ni los estados de error. Lo siguiente es un método de diseño de adaptador, no una afirmación de que ya se hayan integrado dispositivos arbitrarios.
Primero defina la semántica de los parámetros
| Campo | Información requerida | Problema a evitar |
|---|---|---|
| Identificador | Nombre de la aplicación, asignación de dispositivos y modo aplicable | Nombres idénticos con diferentes significados. |
| Tipo y unidad | Unidades enteras, de punto flotante, enumeración, booleanas y explícitas | Copiar números con unidades incompatibles |
| Capacidad de acceso | Dependencias de estado y rango dinámico de solo lectura o escritura | Escribir parámetros que no pueden cambiar durante la captura de imágenes |
| Enumeraciones y valores predeterminados | Valores reales admitidos y lectura | Informar configuraciones no compatibles como exitosas |
| Condiciones de activación | Si es necesario detenerlo, reiniciarlo o volver a conectarlo | Suponiendo que los marcos usan una nueva configuración inmediatamente después de que regresa una llamada |
Haga más que cambiar el nombre de los campos. Devuelve estados identificables para funciones no compatibles. Defina conversión y redondeo para unidades compatibles. Verifique la lectura, el estado del dispositivo y los cambios de imagen de acuerdo con las capacidades del SDK de destino.
Vida útil de los datos del cuadro
Documente si el SDK, el adaptador o la persona que llama del proveedor asigna un búfer, cuánto tiempo permanece legible, cuándo debe liberarse o devolverse, si se permite el uso entre subprocesos y si se produce la copia. Las dimensiones, el formato, el paso de la fila y la longitud válida describen juntos los datos de la imagen; no asuma filas muy apretadas.
No pase un puntero de devolución de llamada asincrónica a una tarea posterior de ejecución prolongada sin confirmar su duración. El apagado, la desconexión y la destrucción del dispositivo de captura de imágenes también requieren una orden de fotogramas pendientes, devoluciones de llamadas en cola y liberación de recursos.
Estados y orígenes de errores.
Considere estados separados de desconexión, conexión, configuración, adquisición, detención y falla, con llamadas permitidas y condiciones de transición. Exprese los tiempos de espera, la desconexión, los parámetros no admitidos, la escasez de búfer y las fallas de análisis por separado. Conserve el código de error del proveedor y el contexto junto con el código de error del contenedor.
Verifica más que un ejemplo
Para dispositivos y versiones específicos, pruebe los límites de los parámetros, inicios y paradas repetidos, tiempos de espera de fotogramas, retorno del búfer, llamadas simultáneas y reconexión. Registre por qué no se pudo inyectar una falla o no fue compatible. Entregue documentación de API, tablas de errores, instrucciones de compilación, ejemplos y registros de pruebas acordados.
Servicios relacionados: SDK de dispositivos de visión y captura de imagen de imagen incrustada.