Portada
mis comunidades
otras secciones
#11:
Lo siento, pero vaya tonterías que dice, se nota que no entiende ni lo que es un scheduler o un thread (que traduce del original en inglés como "código principal").
En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso. Desde que empezaron con Android (que no fue Google, sino la empresa que compró, http://en.wikipedia.org/wiki/Android_(operating_system) ) se pensó en pantalla táctil, y no tiene que vr con eso. El iOS es un derivado del Mac OS X/Darwin, que además de no estar pensado originalmente para pantallas táctil está basado en Unix, que tampoco estuvo diseñado para pantallas táctiles.
El problema de la latencia en Android es fundamentalmente un problema del scheduler. Android funciona mucho mejor con el "multitask" (en realidad "multiprogramación") porque es un Linux y no han tocado prácticamente la gestión de procesos. Para arreglar este problema sólo tienen que mejorar el scheduler. Seguramente están trabajando en ello, y de hecho se ha mejorado mucho.
El otro problema que tiene Android es que cada proceso es una máquina virtual de Java separada al que han optimizado haciendo que se comparta la memoria de las librerías comunes (como hace naturalmente el Linux/UNIX) y código muy optimizado: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
Los programas en Android están en ese código intermedio que es interpretado por la máquina vitual, en cambio en iOS es nativo del procesador (que da ventajas de velocidad, pero desventajas de portabilidad y diversidad, lo que solucionan con un sólo tipo de hardware). Seguramente hay cosas que se pueden mejorar, pero esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché.
Lo peor, acaba con:
El verdadero problema viene cuando nos enteramos que esto va a seguir siendo así por algún tiempo más.
¿De dónde saca eso? En Linux hubo el mismo problema durante años, porque Linus Torvalds no aceptaba chapuzas en el scheduler (cosas que sí hacía Windows, como dar mayor prioridad a la "aplicación activa"), pero se solucionó hace años con el scheduler de Ingo Molnar, el Completely Fair Scheduler (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
Los schedulers no son una ciencia exacta, es algo bastante quisquilloso, con montón de "casos exremos" (corner cases) al que ir detectactando y agregando heurísticas que se aprenden con la experiencia.
Es más que probable que el problema desaparezca (por tres razones fundamentalas, las mejoras en el scheduler, la gestión de la máquina vrtuale de Java y la mejora del hardware), lo que no se puede decir, a estas alturas, es que siempre será así, y que es un problema de diseño original. ¿Es que no leyó nada de la historia reciente de la informática?
En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso. Desde que empezaron con Android (que no fue Google, sino la empresa que compró, http://en.wikipedia.org/wiki/Android_(operating_system) ) se pensó en pantalla táctil, y no tiene que vr con eso. El iOS es un derivado del Mac OS X/Darwin, que además de no estar pensado originalmente para pantallas táctil está basado en Unix, que tampoco estuvo diseñado para pantallas táctiles.
El problema de la latencia en Android es fundamentalmente un problema del scheduler. Android funciona mucho mejor con el "multitask" (en realidad "multiprogramación") porque es un Linux y no han tocado prácticamente la gestión de procesos. Para arreglar este problema sólo tienen que mejorar el scheduler. Seguramente están trabajando en ello, y de hecho se ha mejorado mucho.
El otro problema que tiene Android es que cada proceso es una máquina virtual de Java separada al que han optimizado haciendo que se comparta la memoria de las librerías comunes (como hace naturalmente el Linux/UNIX) y código muy optimizado: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
Los programas en Android están en ese código intermedio que es interpretado por la máquina vitual, en cambio en iOS es nativo del procesador (que da ventajas de velocidad, pero desventajas de portabilidad y diversidad, lo que solucionan con un sólo tipo de hardware). Seguramente hay cosas que se pueden mejorar, pero esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché.
Lo peor, acaba con:
El verdadero problema viene cuando nos enteramos que esto va a seguir siendo así por algún tiempo más.
¿De dónde saca eso? En Linux hubo el mismo problema durante años, porque Linus Torvalds no aceptaba chapuzas en el scheduler (cosas que sí hacía Windows, como dar mayor prioridad a la "aplicación activa"), pero se solucionó hace años con el scheduler de Ingo Molnar, el Completely Fair Scheduler (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
Los schedulers no son una ciencia exacta, es algo bastante quisquilloso, con montón de "casos exremos" (corner cases) al que ir detectactando y agregando heurísticas que se aprenden con la experiencia.
Es más que probable que el problema desaparezca (por tres razones fundamentalas, las mejoras en el scheduler, la gestión de la máquina vrtuale de Java y la mejora del hardware), lo que no se puede decir, a estas alturas, es que siempre será así, y que es un problema de diseño original. ¿Es que no leyó nada de la historia reciente de la informática?
#5:
¿Es más fluído? ¿Se puede ser más fluído que un Android en un Galaxy SII o en un ASUS Transformer eee Pad? Me cuesta creer, que se pueda ser más fluído que la "fluidez total".
Igual lo que tendríamos que decir, para hacer una comparación aceptable sería:
¿Por qué un Samsung Galaxy mini es menos fluído que un iPhone? Pero entonces nos daríamos cuenta, solo de formular la pregunta, lo tonta que es esta.
Igual lo que tendríamos que decir, para hacer una comparación aceptable sería:
¿Por qué un Samsung Galaxy mini es menos fluído que un iPhone? Pero entonces nos daríamos cuenta, solo de formular la pregunta, lo tonta que es esta.
#22:
#16 ¿Copia de Blackberry?
Qué fácil que decís barbaridades, la arquitectura de Android no tiene nada que ver con la de BB, ni con casi ningún otro sistema operativo. Es una obra maestra de ingeniería.
No sé de dónde sacas que es "copia", no sé si has visto alguna demo previa al primer Android comercial (que no tiene nada que ver con la interfaz de BB), pero estás confundiendo "aspecto visual" con "copiar el sistema". O que se usen los dispositivos que hay en el mercado para demostrar tus prototipos (no puedes gastar tanto dinero en diseñar y fabricar el dispositivo de hardware desde el principio).
Insisto, decís muy fácil lo de "copiar", sin conocer nada de cómo está construido.
Qué fácil que decís barbaridades, la arquitectura de Android no tiene nada que ver con la de BB, ni con casi ningún otro sistema operativo. Es una obra maestra de ingeniería.
No sé de dónde sacas que es "copia", no sé si has visto alguna demo previa al primer Android comercial (que no tiene nada que ver con la interfaz de BB), pero estás confundiendo "aspecto visual" con "copiar el sistema". O que se usen los dispositivos que hay en el mercado para demostrar tus prototipos (no puedes gastar tanto dinero en diseñar y fabricar el dispositivo de hardware desde el principio).
Insisto, decís muy fácil lo de "copiar", sin conocer nada de cómo está construido.
#52:
#40 #51 En el iPhone tienes BT, pero SOLO para usar un manos libres para llamadas o como auriculares. El resto de usos que puedas imaginar están restringidos.
Y no solo eso. Pilla un iPhone y que alguien te pase una canción. Estás jodido. La única forma de poder escucharla es que la tengas en tu ordenador y la pases con el iTunes.
¿Seguimos con la lista?
Vale que el iPhone es fluido. Pero con un móvil medio bueno y un Adroid que no esté secuestrado por la operadora (muy recomendables las ROM de Cyanogen) va como un tiro. Y haces con él lo que quieras, no solo lo que Apple te deje. Y es mil veces más configurable. Y más barato!
Y no solo eso. Pilla un iPhone y que alguien te pase una canción. Estás jodido. La única forma de poder escucharla es que la tengas en tu ordenador y la pases con el iTunes.
¿Seguimos con la lista?
Vale que el iPhone es fluido. Pero con un móvil medio bueno y un Adroid que no esté secuestrado por la operadora (muy recomendables las ROM de Cyanogen) va como un tiro. Y haces con él lo que quieras, no solo lo que Apple te deje. Y es mil veces más configurable. Y más barato!
#4:
iOS es un sistema cerrado y desarrollado para un HW concreto. Está especializado en dicho HW y ambos se desarrollan conjuntamente.
Android no es cerrado (desde luego no tanto) ni se desarrolla para un HW concreto. Android está mucho menos especializado.
La pregunta es ¿ese extra de fluidez es realmente relevante? ¿Es razonable pagar por un coche deportivo cuando un monovolumen es lo que necesitamos, velocidad a costa de flexibilidad?
Android no es cerrado (desde luego no tanto) ni se desarrolla para un HW concreto. Android está mucho menos especializado.
La pregunta es ¿ese extra de fluidez es realmente relevante? ¿Es razonable pagar por un coche deportivo cuando un monovolumen es lo que necesitamos, velocidad a costa de flexibilidad?
Comentarios
Lo siento, pero vaya tonterías que dice, se nota que no entiende ni lo que es un scheduler o un thread (que traduce del original en inglés como "código principal").
En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso. Desde que empezaron con Android (que no fue Google, sino la empresa que compró, http://en.wikipedia.org/wiki/Android_(operating_system) ) se pensó en pantalla táctil, y no tiene que vr con eso. El iOS es un derivado del Mac OS X/Darwin, que además de no estar pensado originalmente para pantallas táctil está basado en Unix, que tampoco estuvo diseñado para pantallas táctiles.
El problema de la latencia en Android es fundamentalmente un problema del scheduler. Android funciona mucho mejor con el "multitask" (en realidad "multiprogramación") porque es un Linux y no han tocado prácticamente la gestión de procesos. Para arreglar este problema sólo tienen que mejorar el scheduler. Seguramente están trabajando en ello, y de hecho se ha mejorado mucho.
El otro problema que tiene Android es que cada proceso es una máquina virtual de Java separada al que han optimizado haciendo que se comparta la memoria de las librerías comunes (como hace naturalmente el Linux/UNIX) y código muy optimizado: http://en.wikipedia.org/wiki/Dalvik_virtual_machine
Los programas en Android están en ese código intermedio que es interpretado por la máquina vitual, en cambio en iOS es nativo del procesador (que da ventajas de velocidad, pero desventajas de portabilidad y diversidad, lo que solucionan con un sólo tipo de hardware). Seguramente hay cosas que se pueden mejorar, pero esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché.
Lo peor, acaba con:
El verdadero problema viene cuando nos enteramos que esto va a seguir siendo así por algún tiempo más.
¿De dónde saca eso? En Linux hubo el mismo problema durante años, porque Linus Torvalds no aceptaba chapuzas en el scheduler (cosas que sí hacía Windows, como dar mayor prioridad a la "aplicación activa"), pero se solucionó hace años con el scheduler de Ingo Molnar, el Completely Fair Scheduler (http://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
Los schedulers no son una ciencia exacta, es algo bastante quisquilloso, con montón de "casos exremos" (corner cases) al que ir detectactando y agregando heurísticas que se aprenden con la experiencia.
Es más que probable que el problema desaparezca (por tres razones fundamentalas, las mejoras en el scheduler, la gestión de la máquina vrtuale de Java y la mejora del hardware), lo que no se puede decir, a estas alturas, es que siempre será así, y que es un problema de diseño original. ¿Es que no leyó nada de la historia reciente de la informática?
¿Es más fluído? ¿Se puede ser más fluído que un Android en un Galaxy SII o en un ASUS Transformer eee Pad? Me cuesta creer, que se pueda ser más fluído que la "fluidez total".
Igual lo que tendríamos que decir, para hacer una comparación aceptable sería:
¿Por qué un Samsung Galaxy mini es menos fluído que un iPhone? Pero entonces nos daríamos cuenta, solo de formular la pregunta, lo tonta que es esta.
#0 ¿¿Pero qué haces insensato??
#16 ¿Copia de Blackberry?
Qué fácil que decís barbaridades, la arquitectura de Android no tiene nada que ver con la de BB, ni con casi ningún otro sistema operativo. Es una obra maestra de ingeniería.
No sé de dónde sacas que es "copia", no sé si has visto alguna demo previa al primer Android comercial (que no tiene nada que ver con la interfaz de BB), pero estás confundiendo "aspecto visual" con "copiar el sistema". O que se usen los dispositivos que hay en el mercado para demostrar tus prototipos (no puedes gastar tanto dinero en diseñar y fabricar el dispositivo de hardware desde el principio).
Insisto, decís muy fácil lo de "copiar", sin conocer nada de cómo está construido.
#24 El primer móvil Android era el HTC G1, que era táctil con teclado deslizante. Lo del teléfono estilo blackberry era un prototipo que se mostró junto a otro prototipo de pantalla táctil.
iOS es un sistema cerrado y desarrollado para un HW concreto. Está especializado en dicho HW y ambos se desarrollan conjuntamente.
Android no es cerrado (desde luego no tanto) ni se desarrolla para un HW concreto. Android está mucho menos especializado.
La pregunta es ¿ese extra de fluidez es realmente relevante? ¿Es razonable pagar por un coche deportivo cuando un monovolumen es lo que necesitamos, velocidad a costa de flexibilidad?
#2
Si le adjuntas una power balance, la fluided, la agilidad y los reflejos aumentan de forma exponencial
El artículo tiene su interés pero no se, no prefiero una pantalla más fluida (que tampoco es tanto más) a costa de no poder, por ejemplo, usar el bluetooth en el coche y muchas cosas más. Me quedo con mi HTC.
" ¿Por qué un dispositivo con Android se siente menos fluido que uno con el sistema iOS?"
O sea, no es que sea resultado de una medición producto de una comparativa, ni de ningún análisis serio. Simplemente se siente, como el que dice que con un Peugeot se siente más seguro que con un Renault.
Pero bueno, será por el puente, sera porque se siente la navidad, pero me ahorro el negativo de sensacionalista por ver otro flame navideño.
#16 Cuando presentaron por primera vez Android se hizo con dos móviles, uno como dices al estilo Blackberry y otro táctil para mostrar la versatilidad del nuevo sistema operativo Android para los diferentes tipos de móviles.
Al final por cosas del mercado y evolución al final todos los Android llevan pantalla táctil pudiendo llevar o no teclado físico.
#40 #51 En el iPhone tienes BT, pero SOLO para usar un manos libres para llamadas o como auriculares. El resto de usos que puedas imaginar están restringidos.
Y no solo eso. Pilla un iPhone y que alguien te pase una canción. Estás jodido. La única forma de poder escucharla es que la tengas en tu ordenador y la pases con el iTunes.
¿Seguimos con la lista?
Vale que el iPhone es fluido. Pero con un móvil medio bueno y un Adroid que no esté secuestrado por la operadora (muy recomendables las ROM de Cyanogen) va como un tiro. Y haces con él lo que quieras, no solo lo que Apple te deje. Y es mil veces más configurable. Y más barato!
Yo tengo un sony ericson xperia neo V para uso particular y del trabajo tengo un iphone 4.
Tienen un harware similar, mismo tamaño de pantalla, misma velocidad procesador y misma memoria, uno usa android 3.2 y el iphone ios 5.
La velocidad de respuesta del iphone le saca años luz de ventaja en cualquier tarea, y en dictados y traducciones y navegación...también.
Yo creo que android abarca muchisimo hardware, de todas formas cada cosa es para lo que es.
#5 En mi iPhone 3GS, desde que le puse el iOS 5, la fluidez se ha ido a tomar viento...
#6 En los dos ejemplos que he puesto en #5 no. Con el Samsung Galaxy mini puede que si. Pero vamos, es un hardware muy inferior al de un iPhone.
#22 Yo, desde luego, no entiendo de esto ni el 0,001% de lo que entiendes tú, pero hay una cosa que me sorprende. La gente que dice que Android es una copia de iOS solo por el aspecto gráfico (que ya es discutible).
Vamos que un SO se me antoja que son mil cosas y que el aspecto gráfico es solo la punta del iceberg. Que lo complejo está debajo y que no tiene porque tener nada que ver, incluso aunque el aspecto gráfico fuera una copia 100% igual.
#11 Normalmente el planificador (scheduler) de procesos , hilos, etc, se encuentra en el kernel del SO. Esto es mejorable simplemente tratando de optimizar el código. De hecho, existen multitud de páginas web donde puedes descargarte varias versiones de kernel's de android, realizada por programadores informáticos, conocidos como "cocineros" porque además realizan ROM's personalizados de varias versiones de android.
Supongo que todo esto lo sabrá, ya que intuyo que ha estudiado informática. Yo también. Soy licenciado y no me apetece meterme ahora mismo en pleno debate porque estoy en la oficina programando para un banco en código COBOL (hágase una idea de como tengo la cabeza ahora). Aparte, que estoy de acuerdo con usted en un 95%. Por otra parte no considero que este diciendo una barbaridad. Es bastante lógico lo que afirma en su comentario.
Sin embargo no he podido evitar cuestionarme un comentario suyo. En concreto es el siguiente:
"El otro problema que tiene Android es que cada proceso es una máquina virtual de Java separada al que han optimizado haciendo que se comparta la memoria de las librerías comunes (como hace naturalmente el Linux/UNIX) y código muy optimizado: en.wikipedia.org/wiki/Dalvik_virtual_machine"
Cabe decir, repito, que estoy de acuerdo con usted en casi todo. Y afirma bien diciendo que cada proceso en android es una máquina virtual de Java. Sin embargo, ¿realmente usted cree que esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché?. Yo considero que esto también beneficia también a las aplicaciones en Apple iOS. Por tanto es de suponer que Apple siempre estará un paso por delante en este aspecto, ya que como bien afirma, en iOS los programas son nativos en procesador y esto supone más "eficiencia y rapidez" que los programas cargados en una máquina virtual. Creo que mientras esto siga así, Apple siempre estará por delante, ¿no cree?.
Además esa máquina virtual es de Java. Y sí, una de las mejores cosas que tiene Java es su máquina virtual por cuestiones de su sencilla portabilidad. Sin embargo como lenguaje... quizás no es tan bueno como aparenta en un principio. Aunque este es otro tema de debate que ahora mismo no viene al caso.
Es evidente que, en lo que refiere al tema de portabilidad y tal, android sale ganando frente a Apple y por goleada. Pero Apple a esto no le importa mucho porque para ellos iOS siempre correrá en un iPhone y no en un HTC, Sambung, LG, etc. Obviamente, si un día esto tuviese que cambiar, Apple se vería en un serio aprieto. ¿Me equivoco?
Un saludo.
Cuando iOS recibe una pulsación del usuario, detiene cualquier otro proceso que estuviera realizando para “escuchar” e interpretar lo que la persona está haciendo sobre la pantalla, la interfaz de usuario tiene prioridad absoluta. En cambio cuando un tablet o smartphone del robot verde reciben un toque por pantalla el procedimiento a seguir es distinto. Se entiende que la acción es una más como cualquier otra en el código principal que se está ejecutando con lo que la interfaz de usuario sufre ciertos retardos, en especial cuantos más procesos se estén llevando a cabo en ese momento.
O sea, que no es más fluido, solo parece que es más fluido. En iOS tocas el teléfono y ves como te responde en el acto, pero lo que no ves el atasque de aplicaciones en segundo plano que has provocado.
#4 ¿ese extra de fluidez es realmente relevante?
Depende de para quien. Yo acabo de comprar un Xperia Neo con gingerbread y lo primero que he hecho es calzarme la mitad de los programas preinstalados en el smartphone puesto que tarda casi 1 min en arrancar.
Ahora va mucho mejor . Para mi, si es importante que el dispositivo sea rapido (tb aplicable a pc´s y demas), otra cosa es ¿cuanto estoy dispuesto a pagar de mas?
"No se trata de simples conclusiones subjetivas, es algo que ocurre de verdad"
Ah claro, si ocurre de verdad entonces vale.
Alguien puede decir si es así?
#30 Por tanto es de suponer que Apple siempre estará un paso por delante en este aspecto, ya que como bien afirma, en iOS los programas son nativos en procesador y esto supone más "eficiencia y rapidez"
Una cosa es la eficiencia en ejecución, y otra el problema de falta de respuesta que se plantea en el artículo. La primera no suele ser un problema en el mundo Java desde hace tiempo puesto que el término cache de #11, asociado a Java, hace referencia a los atajos y optimizaciones para la ejecución de bytecodes/optcodes. El cacheado sería, por decirlo de alguna manera, una versión binaria cuasinativa que evita muchos procesos de 'traducción' cuando se trabaja en modo JIT. Es decir, Java podría tener en memoria una imagen ejecutable nativa tan eficiente como la del compilado iOS; virtualmente, porque nunca será perfecta y siempre habrá más overheading al trabajar en dos capas. Hoy en día la diferencia es poco apreciable. Empieza a ser frecuente ver aplicaciones Java casi tan eficientes como otras realizadas en C++, esto tiene truco: una aplicación C++ será siempre más eficiente si está muy bien afinada, pero no todas lo están. Y aquí volvemos a iOS: viendo el nivel de muchas de sus aplicaciones, no creo que los que llegan ahora al mundo de Objective-C sean expertos 'pulidores' de aplicaciones.
De todos modos, y como solución futurible a favor de Java, está la posibilidad de incorporar una VM por hardware (algo que ya viene de la era de Sun). Aunque no creo que sea necesario con las CPUs cada vez más potentes y de 2/4 núcleos.
El asunto de la 'falta de respuesta' es otro, y en mi opinión está desvinculado de las VMs de Java. Puede que el artículo haya acertado, de casualidad, en una cosa. iOS puede despachar hardIRQs (lo que llama 'prioridad absoluta') directamente a las aplicaciones (convertidas en eventos listos para ser manejados). iOS se lo puede permitir porque podría (hipotéticamente; lo desconozco) incorporar por hardware el propio controlador gestual. En Android esto se convierte en una casacada de interrupciones que van desde el hardware, pasando por el controlador, relanzamiento de softIRQs, despachado en la VM con interrupción de su hilo(s) de ejecución y delegación de eventos al manejador de la app... ¿Y para qué sirve todo esto? Para que podamos elegir libremente el teléfono que te apetezca sin depender de un solo terminal (iPhone). Este es el coste a pagar y es algo que hereda del mundo GNU/Linux (modularidad y kernel desacoplado del hardware).
Flame ON
Por si alguno no lo noto aun, el articulo cuestionador del rendimiento de ANDROID esta en un blog que se llama APPLEweblog.com.
#30
> Supongo que todo esto lo sabrá, ya que intuyo que ha estudiado informática
No sé, quizás, sólo soy ingeniero y doctor en informática... lo que no asegura que lo sepa. Bueno, también uso firmwares alternativos en mis Androids (ahora tengo el Cyanogen 7 en uno, y uno más antiguo en el Magic)... supngo que esto da más credibilidad. Bueno, también que doy clases de sistemas operativos, y explico estos temas.
> ¿realmente usted cree que esta desventaja es cada vez menor con la ampliación de velocidad de procesadores, y sobre todo de caché?
Sí, será cada vez menor por las mejoras en hardware que están haciendo (como el multicore, supongo que vienen mejoras también en TLBs y caché). Por otro lado iOS tendrá que hacerse más complejo, lo que hará que las distancias sean cada vez más pequeñas. Cuando el usuario no perciba la diferencia, el problema ya no existirá (de hecho es casi imperceptible con el 4.0, diría yo).
Bueno, no me lío, que ya estoy escribiendo un apunte sobre este tema.
¡Upsss! Se me olvidó poner que el comentario #35 era en respuesta a #33 . Fallos de novato
De nuevo, un saludo.
Bueno, es otra de las ventajas de ser un sistema abierto, no espera.
#18 Algo que es fluido, además de parecerlo lo es, si no dejaría de ser fluido.
#4 Hombre, un jailbreak y te va igual de fluido con la parte de software "liberada" al menos.
#30 #34
Lo escribí más largo: http://gallir.wordpress.com/2011/12/07/android-ios-tiempos-de-respuestas-y-por-que-nada-es-gratis-en-sistemas-informaticos/
#14 ¿Cómo has echo eso? A mi tambien me arranca en un minuto y me gustaria reducirlo.
Al parecer aqui (https://plus.google.com/100838276097451809262/posts) hay una mejor respuesta de un ex-ingeniero de Google del equipo Android
#50 Tengo un auricular manos libres por bluetooth y no tuve que hacer nada especial para conectarme. Lo mismo con el bluetooth del coche, uno que va a la toma del mechero, y lo mismo con el Astra de un amigo, que tiene el bluetooth incorporado.
#11 Por comentarios como el suyo suelo pasar más tiempo leyendo opiniones de noticias que las propias noticias en sí.
Gracias. Ha comentado muchos detalles técnicos interesantes que desconocía.
#8 ¿No poder usar el bluetooth en el coche? Que yo sepa, sí se puede.
Por cierto, ¿por qué es errónea esta noticia, si incluso un ingeniero de Android lo reconoce?:
"Roman Guy, un ingeniero de software del equipo de Android, ha admitido estos problemas pero también ha dicho que estén trabajando en nuevos modos de implementar las animaciones para solucionar los problemas de la respuesta. De todos modos, también ha comentado que no son pocos los inconvenientes para crear un nuevo kit de interfaz gráfica para los desarrolladores."
Sacado de http://www.genbeta.com/movil/un-ex-empleado-de-google-describe-los-motivos-por-los-que-las-animaciones-son-menos-fluidas-en-android
PD: El enlace del meneo ya no existe, por lo que parece.
#5
Tengo un SG2 y un iPad 2, y te aseguro que lo del SG2 no es "fluidez total"
#19 Si que lo vieron, pero eso no importa, un fanboy siempre lo vera objetivo o sensacionalista.
Lo que dice el artículo en inglés, del cual la traducción al español es pésima es bastante cierto.
No obstante, se puede mejorar bastante la respuesta de cualquier Android rooteado, usando comandos básicos de UNIX sobre los procesos que queremos optimizar. Un ejemplo: renice 5 `pidof com.google.process.gapps` && renice -15 `pidof com.android.phone` && renice -15 `pidof com.android.inputmethod.latin` && renice -18 `busybox pidof com.android.systemui`
#4 No. El sistema de prioridades para los hilos es dinámico y en tiempo real en iOS y Windows Phone7 mientrás que en Android la gestión de hilos se realiza mediante un sistema estático de prioridades similar al de los PCs.
#40 Pues yo tengo amigos fanboys appeleros y no hubo narices de conectar el iphone al bluetooth para oir canciones o recibir llamadas, en cambio mi htc a la primera. Yo tengo entendido que el BT está capado, pero eso sólo lo ponía como ejemplo.De todos modos tTe hablo de hace un par de años, supongo que ya se haya solucionado según tu comentario.
#9 " harware similar, mismo tamaño de pantalla, misma velocidad procesador y misma memoria"
No te lo crees tú ni harto de vino, chaval. Anda, anda. El iphone tiene dos núcleos y el xperia uno.
Que manía de hablar sin tener ni puta idea.
#14 Es de coña que las operadoras nos metan tantas tonterías en el móvil que tengamos que rootearlo para poder utilizarlo a nuestro gusto.
Lo que me recuerda que tengo que rootear mi HTC...
#5 bonito ejemplo.. curiosamente tengo un asus transformer, y fluidez total lo que es fluidez total no tiene pese a los trucos que hacen para optimizar el display:
Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 -- that GPU can touch every pixel of a 1280x800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window... and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU
estoy mezclando un par de todas las cosas que he leido ultimamente sobre este tema, pero hay una cosa que leí que me parece que da en el clavo, a mi me ha pasado, que si estoy instalando alguna aplicación en background, el teclado deja de responder y lo mismo tarda medio segundo en registrar la pulsación de la tecla, quedando una experiencia de usuario desastrosa. En cambio comentaban que en iOS detenia la instalación en segundo plano mientras estuvieses interactuando en la pantalla.
Bien.. ¿que es mas optimo? por supuesto en android la instalación de la aplicación terminara antes, porque no la detienes.
Francamente, me importa 0 que la instalación que he dejado en segundo plano para hacer otra cosa termine 1s o 10s despues, yo quiero que el teclado reaccione al instante de apretar la pantalla y muestre en el textbox la tecla pulsada de manera inmediata. Eso es fluidez, y no hay que mezclarlo con el rendimiento.
#31 Poco a poco, la verdad es que llevo muy poco con el, seguro que mas de uno aquí podrá ayudarte mas.
Yo saque el tlfno con Vodafone, así que venía muchas aplicaciones de fabrica con el. Utilice el Advanced Task Manager creo recordar para quitar muchas de ellas.
Ahora estoy intentando dar un paso mas, cuando tenga tiempo investigar en logearme como root y seguir calzandome cosas que no use.
Aun así, no creas que es la panacea. Yo me asuste puesto que al principio llego a sobrepasar el minuto. Ahora no llega pero sigue siendo lento en mi opinión y por eso voy a seguir investigando.
Yo estoy trasteando por aquí (http://www.htcmania.com/foro.php)
Espero que te ayude
> No sé, quizás, sólo soy ingeniero y doctor en informática... lo que no asegura que lo sepa. Bueno, también uso firmwares alternativos en mis Androids (ahora tengo el Cyanogen 7 en uno, y uno más antiguo en el Magic)... supngo que esto da más credibilidad. Bueno, también que doy clases de sistemas operativos, y explico estos temas.
Por favor, no me malinterprete. En ningún momento he puesto en duda su posible conocimiento sobre el tema. Únicamente lo he supuesto a juzgar que escribía con cierta propiedad sobre el tema. Ser ingeniero y doctorado en informática sí le asegura conocer "algo" sobre el tema. Por tanto no me equivocaba suponiendo que ha estudiado informática . Y sobre firmwares, yo actualmente estoy usando el CyanogenMod 9 con ICS en un Nexus S y un kernel alternativo al que venía de stock.
> Sí, será cada vez menor por las mejoras en hardware que están haciendo (como el multicore, supongo que vienen mejoras también en TLBs y caché). Por otro lado iOS tendrá que hacerse más complejo, lo que hará que las distancias sean cada vez más pequeñas. Cuando el usuario no perciba la diferencia, el problema ya no existirá (de hecho es casi imperceptible con el 4.0, diría yo).
Buena observación. Y francamente, eso espero. Una mejora en las TLB's y por tanto en el manejo de las tablas de paginación, así como en las cachés, mejorarían considerablemente el SO. Sin embargo creo que hasta que no este bien afianzado Ice Cream Sandwich en nuestros android's no podremos estar plenamente seguro de ello. Aún no ha salido la versión para Nexus S (aunque está a punto de salir) y únicamente lleva poco tiempo en el mercado con el Galaxy Nexus. No obstante he de admitir que actualmente la versión alpha que tengo instalado en mi Nexus S va bastante bien y fluido.
Un saludo. Espero ansiosamente su apunte sobre este tema.
#43 Largo, pero... largo
Gracias por el enlace y la exposición. Ahora mismo estaba comentando sobre el tema con un commiter de Lucene al hilo de Dalvik. Si saco algo en claro, lo comento en el blog.
#43 Muy buen artículo.
Gracias por tomarse la molestia y el tiempo en redactarlo. Me ha gustado especialmente el apartado de "El lenguaje y plataforma", en la que he podido encontrar respuesta a mi duda de "código nativo vs. máquina virtual". No conocía el mecanismo copy-on-write por el cual se sustenta la idea y el proceso inicial zygote (el cual tampoco tenía conocimiento). Eso respondió a mis anteriores dudas.
Entre otras conclusiones que he sacado al respecto, creo que hay que quitarse el sombrero ante la gente de Google por diseñar un sistema operativo a la altura del iOS de Apple y que además (a diferencia del iOS) Android corra con una máquina virtual por debajo.
¡Chapeau!
Un saludo.
¿Qué hace en pendientes un enlace a una noticia que ya no existe?
#55 Hola accorn, el que demuestra que no tiene ni puta idea eres tu.
Yo he nombrado el iphone 4, que, si miras es sus especificaciones, tiene un procesaror A4 de un solo nucleo a 800mhz,512 megas de ram y pantalla de 3.5 pulgadas.
El sony xperia neo V tiene un procesador arm a 1ghz, 512 mb ram y pantalla de 3.5 pulgadas,¿Por qué no los voy a comparar si tengo los dos?
AMÉN maese Gallir!
#32 Gracias, miraré por ahí.
#30 En qué cárnica trabajas? Accenture, everis, indra?
He llegado tarde
La página que estás buscando no se ha encontrado
Puede que la página cambiase de dirección o nunca existiera. Si crees que se trata de un problema ponte en contacto con nosotros o revisa el archivo.
¿ Alguien me puede decir de cuantos segundos de diferencia estamos hablando para asumir que uno es mas fluido que otro ? Vamos, un dato concreto para situarme y saber de que estamos discutiendo.
Porque salió de la mente de un genio. Porque es mejor en todo a Android: más capacidad de memoria, más versatilidad, mejor diseño, con ABS y elevaluna eléctrica. Además, si compras dos, te regalan un imán para la nevera. ¿Qué más se puede pedir?
#11 Dices que:
En primer lugar afirma que Android fue diseñado para "joystick y teclado", lo que es falso.
Debes tener poca memoria porque cuando se empezaba a oir eso de "Android", los prototipos eran burdas copias de las balackberries de entonces:
http://gadgetsteria.com/wp-content/uploads/2009/11/google-phone.jpg
También hay que destacar que Android no lo empezó Google, sino Android Inc., una firma comprada por Google en 2005. Y ellos nunca pensaron en una pantalla táctil.
#23 Está claro que en fluidez no es una copia
#22 Eso fue un rumor que circuló por ciertos prototipos iniciales. http://www.osnews.com/story/25264
#22 No quiero menospreciar las obras de ingeniería, pero en el contexto con el que se compara, android no es tan obra maestra de ingeniería en fluidez en comparación a iOS.
Por otro lado, ¿si en Android creían tanto en el táctil, y es tan obra maestra, porque su primera versión comercial no era táctil, y se ve claramente que estaban inspirados en blackberry?
Para mi una obra maestra de la ingeniería es aquella que mantiene sus ideas iniciales, fija y no distrae sus prioridades y da resultados excelentes. Android no entra en ninguna de las tres. Es buena ingeniería, pero no maestra. Los maestros en fluidez de interfaz gráfica está claro que son otros. Yo lo llamaría ingeniería discípula. No menosprecio, que ya sabemos que muchas veces el discípulo supera al maestro, pero no en esto.
#11 Si el equipo original de Android estaba pensado en táctil, ¿por qué su primer modelo fue una copia de blackberry? A ver si ahora la culpa va a ser de blackberry, o de palm o de windows mobile por ser muy malos y no poder copiarlos bien...
#4 Windows Phone no está hecho para un hardware concreto y es más fluido que android. En realidad cualquier cosa es más fluida que android. Y del malware mejor no hablamos.