La diferencia entre pruebas de ios y pruebas web

1. Idioma

Como programa orientado al cliente, el front-end y el terminal tienen las mismas características: deben confiar en ellos. el entorno de ejecución de la máquina del usuario, por lo que durante el desarrollo Básicamente no hay elección de idioma. A diferencia de lo que se requiere en el backend, iOS solo puede usar object-c y el front-end solo puede usar javascript. Por supuesto, iOS también puede usar RubyMotion y el front-end también puede usar GWT/CoffieScript, pero. No es común y pocas personas lo usan. En el uso real, causará muchos problemas. IOS también puede usar el nuevo lenguaje rápido de Apple, que puede usarse para reemplazar object-c en el futuro. Todavía está en su infancia, por lo que no lo discutiré todavía.

Existe un contraste interesante entre objc y js: el estilo de denominación de variables/métodos es exactamente lo contrario. Apple siempre ha abogado por la experiencia del usuario y escribir código no es una excepción. Todos los nombres de los programas están en inglés y deben ser lo más detallados posible, para que pueda saber lo que está haciendo al observar los nombres de las variables y los métodos, como aplicación: didfinishlaunching con Opciones: Pero debido a que js se descarga del Internet cada vez, intente poner la abreviatura de los métodos variables. De hecho, existen herramientas de compresión de código y el efecto es el mismo sin importar cuán largo sea el nombre de la variable, pero todos están acostumbrados a usar nombres cortos. Por ejemplo, la aplicación objc: terminó de iniciarse con Opciones: el método mencionado anteriormente se llama $() en js.

Objc y js son lenguajes dinámicos y su uso es bastante similar. Sin embargo, objc se compila y se pueden encontrar muchos errores durante el proceso de compilación. js se interpreta y su rendimiento depende del motor de interpretación. Incluso con el potente motor v8, el rendimiento no puede seguir el ritmo de los lenguajes compilados. El lenguaje es demasiado dinámico y las variables no están escritas en absoluto. Es divertido de escribir, pero un poco difícil de depurar. Siempre siento que js es ligero, flexible, bohemio y está lleno de todo tipo de habilidades extrañas. objc no es tan serio como c++ java, ni tan flexible como js.

En segundo lugar, los subprocesos

El desarrollo front-end apenas requiere el concepto de subprocesos. En la implementación del navegador, el análisis y la representación HTML y CSS de la página pueden no estar en el mismo hilo que js, pero todo el código js solo se ejecuta en un hilo y no se ejecutará al mismo tiempo, por lo que no es necesario considerar varios. problemas de programación concurrentes. Entre las nuevas características de JS, puede crear una tarea de trabajo que otro hilo puede ejecutar en paralelo. Sin embargo, debido a que no todos los navegadores lo admiten y los estándares para la transmisión de datos en diferentes subprocesos también son diferentes, existen pocos escenarios de uso, por lo que parece que no se ha utilizado a gran escala. Las tareas como las operaciones de la base de datos/el envío de solicitudes de red son diferentes de los subprocesos de ejecución del código js, ​​pero estas tareas son administradas por el navegador no necesita preocuparse por estos subprocesos ni afectarlos. Solo necesita recibir devoluciones de llamadas de eventos y no. Es necesario abordar cualquier problema de concurrencia.

El desarrollo de terminales requiere muchos subprocesos múltiples. iOS tiene un hilo principal y la representación de la interfaz de usuario se encuentra en este hilo. Otras solicitudes de red/IO de base de datos o lógica que consumen mucho tiempo deben ser ejecutadas por otro subproceso; de lo contrario, consumirá el tiempo del subproceso principal, lo que provocará que la interfaz no pueda responder a los eventos de interacción del usuario o que el procesamiento sea lento, lo que provocará un bloqueo. desplazándose. La lógica del programa se distribuye en múltiples subprocesos y es necesario abordar problemas como la inconsistencia de datos/confusión de tiempo que pueden ser causados ​​por la ejecución concurrente de varios códigos. Concurrencia, algunos errores son difíciles de solucionar y caerá en una trampa si no tiene cuidado. Es necesario utilizar algunas colas/bloqueos para garantizar el orden de ejecución del programa. IOS proporciona un método de administración de subprocesos múltiples, GCD, que encapsula subprocesos y colas de una manera muy simple y poderosa. Es mucho mejor que otros terminales o fondos, pero aún requiere mucho esfuerzo para manejar problemas de subprocesos múltiples.

En tercer lugar, el almacenamiento

El desarrollo de terminales requiere mucha lógica de almacenamiento de datos. Las aplicaciones móviles no son como los navegadores. Cuando los usuarios abren un navegador, deben estar conectados a Internet, pero cuando abren una APLICACIÓN, es probable que estén fuera de línea o en GPRS móvil con condiciones de red extremadamente pobres, por lo que deben guardar los datos que solicitaron antes. Una vez guardados los datos, es necesario sincronizarlos con los datos más recientes del servidor. Si la cantidad total de datos sincronizados es demasiado grande y el consumo de tráfico es lento, se requiere una sincronización incremental. Necesita desarrollar un plan para la devolución incremental de datos con el servidor y debe abordar los problemas de coherencia de los datos entre el cliente y el servidor. Cuando la capacidad de almacenamiento de datos es grande y la estructura es compleja, es necesario hacer un buen uso de la memoria limitada como caché para optimizar el rendimiento de varias consultas de almacenamiento.

Las interfaces rara vez necesitan vivir en el escritorio. A menos que sea una aplicación de una página, naturalmente no es necesario realizar una serie de trabajos para actualizar los datos. Los datos se extraen del fondo y se muestran directamente en la página. Incluso si Weibo puede continuar cargando más datos en la página, los datos solo existen en la memoria y no se almacenarán permanentemente, debido a que la velocidad de la red de escritorio es estable, independientemente del tráfico, todos los datos se pueden recuperar directamente desde el backend. No es necesario que el cliente cree otro conjunto de almacenamiento. Aplicaciones web que se parecen mucho a las aplicaciones nativas móviles, al igual que el desarrollo de terminales. Los datos también se guardan en SQLite y la lógica de almacenamiento y los problemas a resolver son similares.

Cuatro.

Estructura

En marcos de terceros, el front-end web es completamente opuesto al desarrollo de iOS. La web es inherentemente débil y abierta, lo que permite que una gran cantidad de marcos y bibliotecas de clases de terceros ejerzan su poder, mientras que iOS es inherentemente poderoso y cerrado, lo que deja poco espacio para los marcos de terceros.

Al principio, los navegadores solo estaban diseñados para páginas web basadas en contenido, y js era solo un lenguaje de programación que podía agregar algunos efectos especiales a esta página web. En la era de las aplicaciones web, no pueden seguir el ritmo del desarrollo y requieren la ayuda de muchas bibliotecas y marcos de terceros. Además, el desarrollo front-end es completamente abierto, lo que da como resultado muchas bibliotecas y marcos. Al principio, la mayoría de las bibliotecas se centraban en encapsular las operaciones DOM y todo el mundo estaba constantemente construyendo ruedas para las bibliotecas de operaciones DOM básicas. Después de un período de lucha, jQuery fue la única biblioteca utilizada por el sitio web. Más tarde, la gente ya no repitió la rueda de esta biblioteca básica, sino que agregó algunos marcos de organización de código y arquitectura front-end, como el marco require.js, el marco MVC backbone/angular.js, etc.

Desarrollo de IOS Apple proporciona un marco de desarrollo completo cacao, y este marco se ha actualizado y optimizado en cada generación de sistemas, y el modelo de desarrollo se ha finalizado. No hay mucho espacio para marcos de terceros. Una gran cantidad de proyectos populares de código abierto son componentes y bibliotecas de uso común, como la biblioteca de solicitudes de red AFNetworking y la biblioteca de operaciones de bases de datos FMDB. Sin embargo, es difícil que los marcos grandes como el marco de carne de res/cacao reactivo se vuelvan populares.

Los verbos (abreviatura de verbo) conviven en armonía

El desarrollo front-end debe ser compatible con una gran cantidad de navegadores, navegadores de escritorio como chrome, safari, ie6-ie10, Firefox, varios navegadores como Cheetah 360 y navegadores móviles como iOS/Android tienen tamaños de pantalla infinitamente diferentes. Parece aterrador, pero no es tan difícil. Sólo para asustar a la gente. Chrome/Safari en el escritorio y varios modos de velocidad del shell usan webkit, y no hay mucha diferencia. Firefox se implementa básicamente según estándares y no es muy diferente de WebKit. El antiguo IE6/7 necesita cuidados especiales, pero muchos sitios web no son compatibles con IE6. Los terminales móviles son todos de la misma familia y todos son WebKit. No hay mucha diferencia excepto que admiten nuevas funciones. Para diferentes tamaños de pantalla, los sitios de alta gama utilizarán diseños receptivos para adaptarse a diferentes diseños según los diferentes tamaños de pantalla. Normalmente, el lado del escritorio del punto será fijo y el lado móvil se estirará hasta el ancho adaptable.

El desarrollo de terminales también debe ser compatible con diferentes versiones del sistema y tamaños de teléfonos móviles. No hace falta decir que Android también tiene tamaños de 3,5/4/4,7/5,5/9,7 pulgadas, pero es tan fácil de ser compatible como la web, es decir, ancho adaptable. UIKit de iOS ya se ha ocupado de todo esto y tiene funciones avanzadas como diseño automático y sizeClass, por lo que no tiene que dedicar demasiado esfuerzo al tamaño. En términos de versión del sistema, iOS7 es un punto de inflexión. La interfaz de usuario de las versiones anteriores y posteriores a iOS7 es muy diferente y se necesitan algunos esfuerzos para hacerlas compatibles. Sin embargo, los usuarios de iOS se actualizarán muy rápidamente y se espera que los usuarios inferiores a iOS 7 sean ignorados en uno o dos años más.

Rendimiento del verbo intransitivo

Tanto el terminal como el front-end están orientados al usuario. El propósito de la optimización del rendimiento es presentar el contenido lo más rápido posible y permitir que el programa se ejecute. sin problemas bajo la operación del usuario. El terminal se ocupa principalmente del rendimiento de almacenamiento/renderizado. Cuando una aplicación almacena una gran cantidad de datos y las relaciones de datos son complejas, la consulta de datos puede convertirse fácilmente en un cuello de botella en el rendimiento. Es necesario optimizar continuamente la eficiencia del acceso a los datos, planificar subprocesos de E/S de datos, diseñar cachés de memoria, hacer un buen uso de la memoria limitada de los dispositivos terminales, evitar la renderización repetida, reutilizar las vistas tanto como sea posible y encontrar la solución de renderización más eficiente.

El front-end se centra en la velocidad de carga de la página. Debido a que todas las imágenes de estructura/estilo/programa/recursos de la página web se solicitan en tiempo real, para que la página represente el contenido más rápido, es necesario optimizar estas solicitudes para que estos recursos se puedan cargar a la velocidad más rápida. incluida la combinación de imágenes/código para reducir la cantidad de solicitudes, código comprimido, solicitudes paralelas, solicitudes de código en caché basadas en el número de versión, compresión gzip, carga diferida de módulos/imágenes. Además, al igual que la terminal, también nos centramos en el rendimiento de renderizado, seguimos algunas reglas para evitar el reflujo de la página, evitamos el uso de sombras CSS y usamos animaciones CSS3 en lugar de js.

Siete. Ensamblador

Se requiere compilación para el desarrollo del terminal. El programa se compila en lenguaje de máquina y luego se vincula con varias bibliotecas para generar un archivo ejecutable correspondiente a la plataforma. Finalmente, es programado y ejecutado por el sistema operativo. Las reglas de compilación y vinculación en el desarrollo de terminales iOS se han encapsulado en la herramienta de desarrollo xcode. Generalmente, no necesita preocuparse por eso, pero cuando tiene necesidades profundas, aún tiene que lidiar con muchos asuntos de compilación, como usar el front-end del compilador Clang, personalizar las reglas de detección de código estático, escribir scripts de compilación para compilación automática e integración continua, empaquetado y generación de bibliotecas estáticas y vinculación La composición del archivo ejecutable optimiza el tamaño de la aplicación.

Los programas de desarrollo front-end no requieren un proceso de compilación. Solo necesita enviar el código al navegador, y el navegador analizará el código y lo ejecutará. Aunque el navegador puede analizar y ejecutar el código js/css sin hacer nada, para optimizar el rendimiento mencionado anteriormente, todo el código y los archivos de recursos se procesarán antes de que el código de front-end esté en línea.

Estos procesos incluyen: comprimir y fusionar js/css, fusionar gráficos de sprites css, procesar dependencias de módulos, procesar números de versión de recursos de código y procesar posicionamiento de recursos. Este proceso es muy similar a la compilación de programas tradicionales. Al optimizar el código que se muestra a las personas y resolver algunas dependencias, puede considerarse como un proceso de compilación front-end. Herramientas como grunt.js/fis pueden ayudar con este proceso de compilación. Normalmente, la compilación front-end se combina con la implementación en línea como parte del sistema en línea.

Ocho. Seguridad

Aunque la seguridad del front-end y del terminal no necesita considerarse tanto como la del back-end, todavía hay algunas cosas a las que se debe prestar atención. La terminal y la interfaz son iguales cuando se trata de solicitar seguridad. Las solicitudes enviadas por los usuarios al backend deben pasar por capas de enrutamiento y son interceptadas, manipuladas o reproducidas sin saber dónde. Por lo tanto, es necesario tomar algunas medidas para prevenir estas situaciones. La más común es la autenticación de identidad, que utiliza principalmente tokens caducados en lugar de nombres de usuario y contraseñas para evitar que los piratas informáticos inicien sesión permanentemente en la cuenta después de ser descubiertos. Aquellos con altos requisitos de seguridad de datos utilizarán transmisión cifrada o https. Además, algunas cuestiones, como el secuestro de DNS y la colocación de anuncios del operador, deben abordarse según la situación.

Las terminales rara vez consideran otras cuestiones de seguridad. Este sistema ha ayudado a garantizar la seguridad de todo el entorno de ejecución de la aplicación en máquinas iOS sin jailbreak. Pero en una máquina con jailbreak, los programas maliciosos pueden hacer cualquier cosa con privilegios de root, y es difícil protegerse de las aplicaciones. En el front-end, las características del navegador hacen que el desarrollo del front-end tenga varios riesgos de seguridad. Primero, el código js se puede insertar dinámicamente en cualquier lugar de la página web y el navegador ejecutará estos códigos indiscriminadamente. En segundo lugar, la información de autenticación se almacena de manera uniforme en las cookies. En tercer lugar, puedes incrustar libremente páginas de otros sitios web a través de iframes. Estos ataques son causados ​​por XSS, CSRF y secuestro de cookies, por lo que el front-end debe considerar estos problemas de seguridad al escribir código y tomar las medidas preventivas correspondientes. La medida preventiva más simple e importante es filtrar completamente todas las entradas y salidas del usuario para evitar que se incruste código malicioso en la página.

Nueve. Interacción/desarrollo

Finalmente, permítanme hablar sobre mis sentimientos personales sobre el desarrollo interactivo de los dos campos. Cuando trabajaba en el front-end web en el pasado, sentí que la web había retrasado diez años la interacción entre humanos y computadoras, y todas las interacciones eran clics duros: el resultado era desplazarse y actualizarse uno por uno. Si bien muchas personas defienden lo maravilloso que puede ser HTML5, FLASH en realidad se desarrolló hace diez años y es más fluido que los navegadores más modernos. Después de que el iPhone se hizo popular, la interacción persona-computadora finalmente volvió a su nivel adecuado y la experiencia fue mucho más fluida que en la web. Interacción con la punta de los dedos/animación suave/gestos de deslizamiento convenientes/realización infinita, la corriente principal finalmente ha regresado o superado el nivel de Flash hace diez años.

Sin embargo, la interacción persona-computadora ha mejorado, pero los métodos de desarrollo han retrocedido. El método de desarrollo web es muy avanzado y los usuarios utilizan la última versión. Cuando se descubren errores, se pueden reparar en línea en segundos, lo que es especialmente adecuado para una iteración rápida en el entorno de Internet. Sin embargo, la aplicación del terminal no funciona. Aparte de las revisiones de iPhone, Android no puede garantizar que los usuarios tengan los programas más recientes y utilizan el método tradicional de actualizaciones del cliente. La versión corregida de errores no se puede proporcionar a los usuarios a tiempo y no puede estar en línea docenas de veces al día, por lo que es necesario mantener muchas versiones antiguas. Todo esto se debe a que la red móvil es inestable y el tráfico es limitado. El terminal móvil no puede depender completamente de Internet como los navegadores de escritorio, por lo que hasta que el tráfico de la red móvil sea estable y libre, el método de desarrollo no cambiará mucho.

Además, no soy optimista sobre HTML5. Se ha dicho en Internet que puede reemplazar a APP durante tres o cuatro años, pero hasta el momento no hay constancia. No le veo el mérito. La aplicación nativa puede obtener más recursos del sistema y una experiencia de interacción persona-computadora más fluida. HTML5 nunca será comparable en este sentido. Debido a las limitaciones del tráfico y las redes móviles, no puede aprovechar el desarrollo web, por lo que no se generalizará y solo es adecuado para fabricar algunos dispositivos livianos.