Experiencia en diseño de interfaces.

De la independencia empresarial

Si el negocio A está estrechamente relacionado con el negocio B, el negocio A y el negocio B son negocios completamente independientes. En este momento, se deben diseñar interfaces separadas para el servicio A y el servicio B. En lugar de proporcionar solo una interfaz para vincular los servicios A y B.

Por ejemplo, los dos negocios siguientes:
1. Detección de vida de rostros
2. Comparación de rostros

Los dos están estrechamente relacionados: en muchos escenarios, la detección de vida se realiza primero para garantizar la autenticidad del rostro y luego se realiza la comparación de rostros.

Pero la "detección de seres vivos" y la "comparación de rostros" son negocios que pueden existir de forma independiente. Es decir, sólo puede haber "detección en vivo" o "comparación de rostros" (por ejemplo, cargar una foto personal para consultar la información de identidad de la persona).

Aunque solo esté diseñado como una interfaz.

/**
*识别人脸
*/
void identifyFace() {
        先活体检测,
        再人脸比对
}

Lo anterior está diseñado así, aunque la mayoría de los escenarios son aplicables. Sin embargo, la "detección en vivo" y la "comparación de rostros" están unidas. Si desea realizar una "comparación de rostros", primero debe realizar la "detección en vivo". Ya no es posible hacer una "comparación de rostros" solo.

Un mejor enfoque debería ser configurar interfaces para los dos servicios por separado.

/**
*活体检测
*/
void detectFace();

/**
*人脸比对
*/
void matchFace ()

Confirmar que los parámetros tienen sentido

Los más comunes son los números de pedido internos y los números de pedido externos. En algunos proyectos, el número de pedido interno se genera de acuerdo con reglas y los registros especificados se pueden encontrar rápidamente siguiendo esta regla al realizar consultas. El número de orden externo también tiene tales reglas, pero es diferente de las reglas del número de orden interno, por lo que se debe mantener la relación de mapeo entre el número de orden interno y el número de orden externo.

Pero si no existe tal regla para el número de pedido interno o el número de pedido externo, de hecho, solo debe haber un número de pedido.

Las interfaces deben ser atómicas.

Una interfaz solo es responsable de una única función. Si una empresa solo requiere el diseño de una interfaz pero llama a múltiples funciones, entonces la interfaz atómica debe encapsularse dos veces y empaquetarse en una interfaz.

Entonces, hay dos tipos de interfaces, una es una interfaz comercial y la otra es una interfaz de función única. Se puede realizar una interfaz empresarial combinando múltiples interfaces funcionales.

Si hay una superposición funcional entre las dos interfaces, significa que las dos interfaces están diseñadas incorrectamente.

Considere el rendimiento de la interfaz empresarial.

Si la interfaz empresarial se compone de una única interfaz funcional, el rendimiento es bajo. Es necesario considerar ampliar la interfaz funcional.
Por ejemplo, la siguiente situación:
la interfaz funcional es importar una sola imagen, y la interfaz comercial requiere importar imágenes en un directorio determinado, y puede haber más de 1000 imágenes en el directorio.

Suponiendo que la siguiente interfaz es una interfaz AIDL, el cliente de Android necesita leer más de 1000 imágenes en la memoria y luego llamar a la siguiente interfaz más de 1000 veces en un bucle. Además, se transmiten más de 1000 imágenes al servidor a través de procesos y el rendimiento es obviamente demasiado bajo.

/**
* 导入单张图片
*/
void importBitmap(Bitmap bmp);

En este momento, se debe ampliar la siguiente interfaz funcional:

/**
* 批量导入图片
* @param bmpDir 图片所在的目录路径
*/
void batchImportBitmaps(String bmpDir);

De esta manera, el cliente de Android solo necesita llamar una vez y el servidor de Android puede leer la imagen, evitando 1000 transmisiones entre procesos.

Supongo que te gusta

Origin blog.csdn.net/jiejingguo/article/details/124197372
Recomendado
Clasificación