64 comentarios

  1. Israel Gonzalez Moreno dice:
    16 de Abril, 2014 a las 18:54

    no entendi ni madres

    • gabboman dice:
      16 de Abril, 2014 a las 19:34

      Es un tema complejo, pero creo que te puedo "resumir": en C un programa hay que traducirlo para cada CPU, esto se llama compilar (cosas de GCC y CLANG en la tabla). En java (usa davilk y art) el programa se compila una vez y vale para todas las demás. Lo que pasa es que si abarcas mucho... pues te irá más lento, pues no aprovecharas los detalles especiales de cada cpu

  2. d14gvn dice:
    16 de Abril, 2014 a las 18:56

    Y si inventasen un lenguaje para basar a android, que esté basado en C pero que sea mucho más simple de utilizar? :O Ok, no, estoy soñando.

    • Luis Centeno dice:
      16 de Abril, 2014 a las 19:09

      Dirán que eres un soñador, pero no eres el unico -Johh Lennon

    • Joel Pichardo dice:
      16 de Abril, 2014 a las 19:18

      Entonces sera lento igual o peor que Java al inicio.

    • gabboman dice:
      16 de Abril, 2014 a las 19:34

      Ya está java. El problema de java es implementar una máquina virtual decente, que es lo que se está haciendo con ART. Si mejoras ART mejoras el rendimiento de todo android

      • Juan Carlos Alpizar Chinchilla dice:
        17 de Abril, 2014 a las 04:46

        El problema es que un código que tenga que pasar por una máquina virtual nunca va a ser tan rápido como uno que no tenga que pasar por la misma, aún así el rendimiento actual de android no es para nada deplorable

    • IvánD3 dice:
      16 de Abril, 2014 a las 19:35

      Si quieres la eficiencia de C, tienes que lidiar con punteros. Si quieres hacer subfunciones que simplifiquen ese trabajo acabas recogiendo ineficiencia por todos lados. Algo así sucede con objetive C (el lenguaje que se utiliza en IOS) que no es tan tedioso como C, pero a cambio de ello sacrifica rendimiento (aunque no tanto como java, pero sacrificar, sacrifica) Otro tema sería que los desarrolladores aprendieran a programar decentemente, pero por desgracia eso no está al alcance de todos ya que lleva bastante trabajo y tiempo. Todo es ver como evoluciona ART, desde dalvik JIT en Android 2.2 han evolucionado una barbaridad en esos temas donde flaquea Java. De todos modos, viendo lo fácil que evoluciona el HW es normal que no se centren tanto en la optimización. Al final optimizar te sale más caro que mejorar el HW

      • Raúl Alexander Mendoza Muñoz dice:
        17 de Abril, 2014 a las 07:29

        En Java sigues usando punteros, no me vas a decir que todos los datos de una instancia de clase la guardas en la stack, guardas en el stack la dirección del objeto que creas (cuando usas el operador new) y en la memoria guardas el objeto completo. Siguen siendo punteros, disfrazados, pero al fin y al cabo son punteros.

        • IvánD3 dice:
          17 de Abril, 2014 a las 16:14

          De hecho, ahi está el problema. En java practicamente todo son punteros, pero no tienes un control real y eficiente como en C/C++ ¿Más intuitivo para el programador estándar? Si ¿Más eficiente? Ni de coña

          • errepunto dice:
            25 de Abril, 2014 a las 12:10

            La gracia está en que la máquina virtual es la que controla los punteros. Eso permite, por ejemplo, utilizar un recolector de basura, que libera memoria cuando los punteros dejan de estar usados. Eso evita muchos problemas como te olvides hacer un free después de un malloc, y evita corrupción de memoria por desbortamiento de punteros. El problema es que se usa más memoria y cuando el recolector de basura se pone en marcha, hay un pequeño parón. No obstante, para móviles sería un infierno hacer las cosas en C/C++, habría que compilarlo para cada procesador diferente y cada partición de memoria distinta, y probablemente para cada versión de Android, para que las shared library fueran correctas (seguro que no usan el mismo glibc en android 2.3 que en 4.4.2). Eso implicaría tener que subir a la tienda 20 o 30 versiones distintas, y con nuevos modelos de móvil, recompilar y subir las nuevas versiones. ¡Un infierno!

    • Astur dice:
      16 de Abril, 2014 a las 19:36

      Pues no habría beneficio de ningún tipo..absolutamente ninguno

  3. Alfredo Figueroa dice:
    16 de Abril, 2014 a las 18:59

    Hagan un tema sobre Art y las apps que tienen o no conflicto con este, sería muy interesante yo queria cambiar a Art pero dicen que son varias las apps que no funcionan y no hay mucha información sobre ello

    • mani dice:
      16 de Abril, 2014 a las 19:24

      En el primer mes había muchas, pero yo lo tengo activado y hace muchos meses que no me da absolutamente ningún fallo.

      • Alfredo Figueroa dice:
        16 de Abril, 2014 a las 19:25

        Amigo pero con la app de Whatsapp no te dio problemas ¿? la verdad esta app fue la que no me dejo cambiar porque lo haría pero la mayoría de mis contactos se comunican por esta y según después ya no se podía ni instalar.

        • Razagar dice:
          16 de Abril, 2014 a las 20:00

          Eso fue hace tiempo, cuando acabó de salir art las aplicaciones no eran compatibles, entre ellas WhatsApp, pero ahora es raro que alguna sea incompatible. Yo lo tengo activado hace un mes en mi nexus 5 y no me falla ninguna aplicación.

          • Andres dice:
            17 de Abril, 2014 a las 04:43

            En que te mejoro al cambiar a ART? Ahora te dura más la batería? Más rapidez?

            • Razagar dice:
              17 de Abril, 2014 a las 05:07

              Pues la verdad que no he notado mucho, un amigo mio con el nexus 4 sí le va más rápido, pero el nexus 5 va más rápido de por sí. La batería también me dura lo mismo. Quizás me va más rápido la aplicación de Twitter (talon), por lo demás no he notado nada.

  4. Daniel Merchán Cáceres dice:
    16 de Abril, 2014 a las 19:02

    como dicen que en las pruebas Java en mejor que C y al final dicen que android con C seria mas fluido?? no entendi ni madres

    • bear spirit dice:
      16 de Abril, 2014 a las 19:12

      lamentablemente no eso eso, es que no sabes leer. si supieses leer verias que hablan de que C en las pruebas es mejor que java

      • extremekhaos dice:
        16 de Abril, 2014 a las 23:55

        Y, si lo leyese todavía mejor, vería que es cierto lo que dice. A pesar de ser más lento, Java es mejor que C (que no C++). ¿Por qué? Porque la diferencia entre los tiempos de respuesta (7,99 microsegundos en Java sin optimizar, frente a 1 de C) no compensan la complejidad de programar en uno u otro lenguaje. A parte de que no congeniaría con la filosofía de Android, que es la de ser compatible con multitud de hardware diferente. El cuento de C le iría genial a los iPhone porque todos, absolutamente todos los terminales, los fabrica Apple con los mismos procesadores y no Samsung, LG, HTC, Sony, Acer, Xiomi y un larguísimo etc con otro enorme etc de versiones y subversiones. Por lo que ART es la alternativa perfecta a Dalvik y no "reprogramar" un SO completo y todas sus APPs en C.

        • Juan Carlos Alpizar Chinchilla dice:
          17 de Abril, 2014 a las 04:44

          No es que le iría genial, le va. Bueno en sí es Objective-C y no C puro, pero sigue siendo un hijo de C y aún así te apuesto que rinde mejor que los sabores de java. Por favor no me ataquen de apple fanboy porque tengo un S4 y me voy a comprar un HTC One M8, pero los hechos son lo que son :p Ahora bien una relación 1:7 yo sí la veo considerable, mucho más en términos de consumo de energía, pero el hecho es que esto no lo vas a notar sino en aplicaciones que demanden demasiado poder computacional, y las únicas que se me ocurren son escasamente los juegos o editores de video, así que como dice extremekhaos no creo que valga la pena re crear todo el código del OS sólo por eso

          • extremekhaos dice:
            21 de Abril, 2014 a las 12:54

            Perdón. Le va... jejejej

    • Carlos Javier dice:
      28 de Abril, 2014 a las 15:10

      Para que un lenguaje sea mejor que otro para desarrollar aplicaciones, no influye sólo el rendimiento del programa generado, sino la facilidad para desarrollar esos programas. Y luego, si resulta que en las aplicaciones la mayor parte del tiempo se lo pasa interactuando con el usuario en lugar de hacer un montón de cálculos complejos, ahí tiene que no salga a cuenta desarrollarla en el lenguaje más rápido, sino en el más sencillo de programar. ¿O me vas a decir que preferirías invertir 1000 horas en desarrollar un programa para obtener una ligerísima mejora en el rendimiento percibido por el usuario, en lugar de invertir 100 horas en ese mismo programa? Si el programa desarrollado en Java es suficientemente rápido, no es necesario complicar el desarrollo haciéndolo en otro lenguaje más complejo de usar.

  5. unsleep dice:
    16 de Abril, 2014 a las 19:19

    Y por eso y mil cosas mas es por lo que no me gusta Java...

    • Astur dice:
      16 de Abril, 2014 a las 19:35

      Pero su curva de aprendizaje es facilisima, las cosas como son

      • unsleep dice:
        16 de Abril, 2014 a las 19:55

        java tiene un monton de jeroglificos y versiones, c, no los tiene

        • Jesús Martínez dice:
          16 de Abril, 2014 a las 21:01

          Para jeroglíficos php D; Y como dice Astur, Java es fácil... "verbouse", pero fácil.

          • unsleep dice:
            16 de Abril, 2014 a las 21:41

            jeroglificos php por favor??? java prima pelada, java moviles, java tu culo, java bragas, java semana santa, java iphone, java android, java tu ano, java pedo... igual que un lenguaje no compilado pero encima peor... C es c en cualquier plataforma, igual que php, java no.

            • Jesús Martínez dice:
              16 de Abril, 2014 a las 21:51

              uy perdón......... pues que triste que te tomes tan personal un lenguaje de programación.

          • errepunto dice:
            25 de Abril, 2014 a las 12:01

            Para jeroglíficos, usa Perl XD

  6. Joshua dice:
    16 de Abril, 2014 a las 19:43

    "La razón es práctica, al ser un lenguaje de programación de bajo nivel la dificultad para crear apps en C es enorme" ¿Peeeeeeeeeeerdona? C y Java son ambos de alto nivel, lo que cambia es el paradigma de programación

    • Manuel Echeverry dice:
      16 de Abril, 2014 a las 21:23

      pueda se que el autor se referia a C y no a C++ que es la versión orientada a objetos, asi como java. por que C puro, si es muy complejo en comparacion con java

  7. Patricio Bosio dice:
    16 de Abril, 2014 a las 19:54

    Asumo que el tiempo esta medido en milisegundos... la diferencia entre 1 y 17 es casi imperceptible. Como programador y siendo C++ el lenguague que mas he utilizado en mi vida profesional (y el que mas me gusta) y aparte de ser toda la vida muy critico sobre el lenguague Java, creo que tiene valor que diga que la diferencia en rendimiento entre una aplicacion en C++ o Java en los dispositivos de hoy en dia es practicamente imperceptible y el esfuerzo que implica usar el NDK de Android no lo vale ya que la ganancia en rendimiento seria minima.

    • jenen dice:
      16 de Abril, 2014 a las 20:13

      Pero es tiempo relativo, en milisegundos no te das cuenta pero si es un juego cuyo codigo en java tarda para ejecutarse 18 segundos, en c sería 1 segundo, ahí si que se notaría la diferencia, solo que en c llevaría mucho mas tiempo programar. En los celulares de gama baja seguro que se notaría la diferencia, donde todas la aplicaciones pesadas tardan unos 5 segundo aproximadamente en abrir

      • Patricio Bosio dice:
        16 de Abril, 2014 a las 20:23

        Honestamente en los tiempos de carga dudo que encuentres mucha diferencia entre C++ y Java, no se si Andrioid a la hora de cargar los recursos de la App lo hace a traves de APIs nativas. La diferencia principal se encuentra en la logica de la aplicacion en si. En las mayorias de las apps al no tener logicas demasiadas complicadas la diferencia seria casi nula, en el unico escenario donde se me ocurre que podria llegar a notarse es en aplicaciones con logica mas compleja como los juegos. Pero hay que ser realistas, nadie desarrolla para dispositivos de gama baja ni les interesa, la diferencia de tiempos de desarrollo entre Java y C++ es gigante y en los dispositivos de hoy en dia, la diferencia de rendimiento seria casi imperceptible para el usuario. No creo que haya mucho que discutir sobre el tema, existen en internet un monton de pruebas de rendimiento entre C++ y Java, es una discusion frecuente entre programadores, la unica diferencia es que esta vez se hizo bajo un environment que no es una PC sino un Android

      • Astur dice:
        16 de Abril, 2014 a las 20:26

        No, una cosa es la optimización y otra cosa son los buses de datos, eso solo es inherente al hardware

  8. Ricardo dice:
    16 de Abril, 2014 a las 20:14

    A ver, una cosa es el lenguaje y otra muy diferente es el compilador y la máquina virtual sobre la que se ejecuta el programa compilado (para el caso de Java). Android utiliza Java COMO LENGUAJE DE PROGRAMACIÓN porque es de lo más utilizado por los desarrolladores y podrían envolverse rápidamente al mundo de Android, pero sin embargo no es Java de Sun MicroSystems como tal, de hecho los archivos que traduce la máquina virtual son optimizados para móviles comparados con los clásicos .java La gran idea de Java, cuando surgió, fue que se podría ejecutar en cualquier computadora sin tener que volver a compilar para diferentes procesadores o arquitecturas ya que la máquina virtual lo hacía por nosotros, esta idea se llevó después al mundo del desarrollo web y ahora con los dispositivos móviles. Por lo que el tiempo en ejecutar una aplicación va a depender más de la máquina virtual y su optimización que del lenguaje en sí. Ahora, ¿Porqué funciona con C? Pues porque se utiliza el gcc. Que es un conjunto de compiladores (entre ellos C) para GNU, y Android dentro de sus más profundos secretos tiene un kernel de Linux, el cuál ejecuta la máquina virtual y esta ejecuta nuestras aplicaciones. Entonces en teoría, va a ser más rápido ejecutar una aplicación en C porque estas ejecutando directamente sobre el Kernel y no pasa por la máquina virtual que a la vez va a traducir tu código al Kernel. Resumen, ¿Porqué usar Java en lugar de C? Porqué más desarrolladores están acostumbrados a utilizarlos aunado a que es un lenguaje orientado a objetos contra un lenguaje estructural como C. ¿Porqué ejecutar una máquina virtual y no trabajar directo sobre el kernel? Pues es una de las ventajas de Android, olvidarte del hardware, las direcciones de memoria y las limitantes del dispositivo para programar una aplicación que va a funcionar en todos los dispositivos que corran dicha máquina virtual.

    • Raúl Alexander Mendoza Muñoz dice:
      17 de Abril, 2014 a las 07:21

      Por eso prefiero .Net, ya viene integrada la maquina virtual en el sistema operativo, lo cual hace una ejecución mas rápida, ademas parte del binario se compila durante la ejecución para el procesador. Microsoft tendrá sus puntos débiles, pero debo admitir que en una pelea de Java vs C# apuesto hacia C#.

      • Javier C dice:
        18 de Abril, 2014 a las 05:18

        si claro, y corre en linux, mac Os, solaris

        • Raúl Alexander Mendoza Muñoz dice:
          23 de Abril, 2014 a las 18:54

          ¿Has escuchado el proyecto de Mono? (Project Mono)

          • Javier C dice:
            23 de Abril, 2014 a las 21:18

            si, y ¿por lo menos has corrido algún programa de .net fuera de windows y de forma correcta?, ¿sin usar Wine u otro similar? para no ir tan lejos has usado moonlight, que es el equivalente a silverlight, y que fue un fracaso total

            • Raúl Alexander Mendoza Muñoz dice:
              23 de Abril, 2014 a las 22:46

              Hasta el Framework 3.5 de .Net si, ya en versiones posteriores no me toco trabajar con Mono.

      • errepunto dice:
        25 de Abril, 2014 a las 12:57

        Java no es más lenta que C#, es más, en ningún benchmark que haya visto supera la plataforma .net a hotspot en velocidad. Otra cosa es que C# tenga una muy buena integración con entornos windows y, por qué no decirlo, las interfaces gráficas hechas en .Net funcionan bastante mejor que el apestoso swing (y lo digo como programador Java :D)

        • Raúl Alexander Mendoza Muñoz dice:
          25 de Abril, 2014 a las 18:01

          Y eso que no te toco trabajar con la AWT, pero problema viene al querer visualizar de manera similar en diferentes plataformas un mismo ejecutable. Por eso las librerías de gráficos de .Net son mejores, ya que solo se preocupan en Windows.

          • errepunto dice:
            28 de Abril, 2014 a las 10:07

            ¡AWT es el horrooooor!

    • suponzio dice:
      03 de Abril, 2015 a las 02:17

      No tienes ni idea de lo que estás hablando. Cuando se programa en C no se trabaja directamente sobre el kernel. Se trabaja con las librerías del sistema y estas son las que tocan el kernel. Si tocásemos directamente el kernel corromperíamos el sistema. Además de que no se puede, no se tiene ese permiso sobre la memoria. Aunque tal vez si es un microkernel se puedan tocar los módulos de este...

      • Ricardo dice:
        01 de Mayo, 2015 a las 17:45

        Tienes razon, exagere sobre el trabajar directamente sobre el kernel; sin embargo no quiere decir que no tenga idea de lo que estoy hablando, lo que queria resaltar es que trabajando en C te evitas el tener que pasar por una maquina virtual, que mucho o poco pero va a afectar en el rendimiento a costa de un ambiente de desarrollo mas seguro, bonito y facil de usar.

  9. Bruno Alcalde dice:
    16 de Abril, 2014 a las 20:15

    En mi.moto g sale la opción de vambiar a ART, pero cuando reinicia y veo, sigue en Dalvik

    • Astur dice:
      16 de Abril, 2014 a las 20:25

      Tienes instalado Xposed?

      • nacaballero dice:
        16 de Abril, 2014 a las 20:36

        Me pasa exactamente lo mismo, y tengo instalado Xposed.. Será ese el problema?

        • Gera dice:
          16 de Abril, 2014 a las 21:07

          Pues sí, Xposed no es compatible con ART, sólo con Dalvik.

        • Carlos dice:
          16 de Abril, 2014 a las 22:02

          Si, ese es el problema, Xposed aún no puede trabajar con ART sino que solo con dalvik, en el caso del moto g si compraste el de 8 gb esta mejor en dalvik ya que en ART ocupan mas espacio las aplicaciones

      • Bruno Alcalde dice:
        16 de Abril, 2014 a las 21:18

        Sí. Tengo Xposed y cwm de recovery

        • Astur dice:
          17 de Abril, 2014 a las 14:20

          Pues ahí tienes la razón, shur

    • Manuel Echeverry dice:
      16 de Abril, 2014 a las 21:24

      igual metrerse con ART a estas alturas que esta en beta es un juego de suerte. algunas apps funcionaran bien, y otras daran muchos problemas o errores inesperados.

  10. Miguel Méndez dice:
    16 de Abril, 2014 a las 20:31

    Personalmente prefiero C#, su desventaja sería en cuanto a la dependencia de .NET Framework y Microsoft, o sea, la ausencia de soporte multiplataforma.

    • Manuel Echeverry dice:
      16 de Abril, 2014 a las 21:21

      osea una total mier.... lo único bueno de C# es un interoperatividad con otros lenguajes gracias al código intermedio MSIL, pero como dices, eso solo es posible con el Framework de .NET

    • miguelpedregosa dice:
      16 de Abril, 2014 a las 21:34

      De guatemala a guatepeor ...

  11. Andrés Blasco dice:
    16 de Abril, 2014 a las 23:54

    Si por lo menos optimizasen...

  12. Elvin dice:
    17 de Abril, 2014 a las 00:24

    C alto nivel? Q diablos estas hablando...

    • Raúl Alexander Mendoza Muñoz dice:
      17 de Abril, 2014 a las 07:24

      Es de alto nivel C, si quieres bajo nivel usa Ensamblador.

      • Jorge Martín dice:
        17 de Abril, 2014 a las 15:57

        Qué coño ensamblador, ¡usa binario! O eso es demasiado moderno, mejor por pulsos electromagnéticos. Eso sí que es bajo nivel.

    • errepunto dice:
      25 de Abril, 2014 a las 12:01

      Cualquier lenguaje que en vez de "compara estos registros y si el resultado es cero salta a esta dirección de memoria y decrementa el contador" tenga un "haz esto 10 veces" ES de alto nivel :D

Login