Si alguna vez te habías preguntado cómo se mide la sensibilidad y el tiempo de respuesta de las pantallas de dispositivos móviles, Google utiliza para sus smartphones y tablets Android y ordenadores Chrome OS este robot bautizado como Chrome TouchBot, fabricado por la empresa finlandesa OptoFidelity. Así lo ha revelado el empleado de Google, François Beaufort, en un post de Google + con vídeo adjunto en el que se observa el trabajo realizado a cabo por el robot en cuestión.
Comentarios
Titular (sensacionalista) alternativo: "El robot que Google ha diseñado para hacer tocamientos"
He leído lactancia
#1 En qué estarías tú pechando, digo pensando.
no costaba nada ponerle dos ojos y una boca o algo...
¿Robot? Que ganas de matar moscas a cañonazos. El puto java es el problema.
#7 Ni me imagino el montón de capas de abstracción que tendrá Android.
Sólo hagan la prueba, tomen un equipo Android y desactiven el Wifi por un día entero, pasado el día activenlo y que se conecte a la red, ahora vaya tranquilo a almorzar, a echarse una buena siesta, disfrute una fiesta, vaya a la playa, medite seriamente sobre la existencia humana y cuando vuelva, todavía el Android no ha reaccionado de todo la mierda que tiene que bajar de Internet.
#10 Las actualizaciones automáticas se pueden desactivar...
Debería de probarlos después de dos actualizaciones del sistema...
#5 o después de instalar algunas apps
Google no fabrica dispositivos, hace el software...
Lo que medirá el robot es la latencia del software en los diferentes dispositivos.
Pues a mi me ha parecido más sabrosa esta otra:
http://www.malavida.com/noticias/como-espiar-un-ordenador-con-un-pan-de-pita-y-una-radio-005353
Poner a un humano ahí sería una tortura, tener que aguantar tanto lag.
Bua, yo pensaba que se pondría a jugar al Candy Crush
Dicen que el robot en vez de utilizar un cronómetro utiliza un calendario para medir el tiempo de reacción
Menos garbage collector y menos robot
Latencia, bonito palabro.
¿Y tú me lo preguntas?...latencia eres tú.
#18 Maquina virtual y SO emulado son cosas MUY distintas y a mi me parecía que las estabas confundiendo. Si no es así, mis disculpas.
#19 No hace falta que te disculpes. Y tienes razon. Son 2 conceptos distintos aunque parecidos.
Al entender la maquina virtual como un traductor de datos que necesita mas procesador.
Entonces en la maquina virtual la emulacion aqui estaria entre el SO y los programas, o sea despues del SO, y en un SO emulado seria al reves, estando la emulacion antes del SO porque esta dentro de otro SO. Queria decir que pasa por 2 traducciones de datos (un mame dentro de android).
Son cuellos de botella igualmente porque hasta llegar a ejecutar el programa es lento en cualquiera de los 2 casos (mas ineficiente emular todo, pero incluso los virtualbox y compañia usan algunos recursos directos de la maquina host. O sea, el SO emulado haria las veces de programa emulado mediante maquina virtual.
Perdon por el rollo.
- Señor, hemos detectado que nuestro nuevo móvil tiene demasiado lag.
- No pasa nada, ponedle de nombre Galaxy loquesea y se venderá bien.
- Es usted un genio!
Lo importante es que tengan un robot para corregirla
Es java, es lento (que tendra que ver que un robot manosea la pantalla?)
Usa una maquina virtual (dalvik), es un sistema operativo EMULADO. Si utilizas un juego de una maquina recreativa emulada como los de mame, estarias emulando dos veces.
#16 Java es lento pero Android ya no usa Dalvik sino ART, y el sistema operativo no es emulado.
Igualmente Android es una mierda y hacer un SO en Java es de ser MUUU tonto.
#17 Yo sigo usando Dalvik porque ART me va mas lento todavia (en mi caso con un procesador 801 de qualcomm).
El bytecode generado, primero es transformado al bytecode de Java y posteriormente se transforma en el usado por Android. Es decir, primero son generados los .class típicos de JAVA, y posteriormente se transforman al tipo de archivo .dex (dalvik executable). Estos archivos dex son comprimidos en los conocidos APK (Android Package).
La principal diferencia entre la antigua Dalvik y la nueva ART, reside en que la antigua ejecuta una maquina virtual interpretando el código al tiempo que se inicia la aplicación. En cambio, ART es AOT (Ahead-Of-Time), es decir, comienza una pre-compilación al instalar la aplicación y, por tanto, al ejecutarla esta ya no requiere tanta carga de datos como antes y hace que iniciar una aplicación se produzca en menos tiempo.
En resumen, si es una maquina virtual, aunque como ha precompilado lo es un poco menos en la practica (para lo cual cambia el tipo de archivos .dex a .aot) , pero que lo haga antes no significa que no tenga que hacerlo. Por lo tanto era emulado y sigue siendo emulado aunque un poco mas rapido.