Tamaño de las aplicaciones para Android
 

Alguno habéis probado a crear alguna aplicacion para android con el XE5?
cuanto ocupa por ejemplo el APK de un simple Hello World?

no se por qué me da que ocupará muchos megas como para ser usable para crear aplicaciones para Android,
siendo que la mayoría de gente tiene móviles android de gamas bajas con muy pocos megas libres para instalar cosas.

A mi con un label y un button, me sale 5MB el APK y 25MB en memoria al instalarlo en el mobil :(

Pero 25mb consume de RAM o 25mb de memoria interna para aplicaciones?
si es 25mb de memoria interna lo veo totalmente inviable hacer aplicaciones con él,
a no se que dispongamos de un buen terminal y queramos hacer aplicaciones para uso personal.

Hola,

yo también he creado una aplicación con cuatro radiobutton y un botón y me ocupa lo que estais comentando, supongo que tendrá alguna opción para configurar algo y que no ocupen tanto. Digo yo.

Saludos.

De momento y según lo que he visto, una opción es inhabilitar los paquetes que no se estén usando en el proyecto.

El tamaño es 5Mb para todos segun veo, aunque habra que esperar a una guia para ver como reducir el tamaño.

El tamaño en ram, probando con la prueba de "LowLevel3D" y "PhotoEditorDemo" me saca un uso de memoria de 12 a 15Mb, lo normal en una aplicacion de android.

A seguir investigando como reducir el tamaño del apk XD

Hola,

Si no me equivoco un archivo APK es un archivo Zip con diferente extensión. Dicho esto, tal vez una forma de reducir el tamaño del APK sea comprimirlo nosotros mismos usando el mayor nivel de compresión posible. Creo que lo que digo tiene sentido, aunque, ignoro si podría hacerse sin más y las posibles consecuencias. ;)

Bueno, si son 5Mb aprox. aunque metas un button o crees una aplicacion compleja, no esta mal, asi no hay que meter librerías.
Supongo que todas las librerias y framewoks de audio, video, db, etc van metidas ya. Aunque tendrian que dejar elegir las que queremos y no...

la mejor solución sería que el sistema Android incluyese esas librerias nativamente y no tener que incluirlas repetidamente en cada programa.
Porque lo de instalarlas por separado como un runtime sería un poco engorroso para el que instala tu aplicación.

https://forums.embarcadero.com/threa...ssageID=595298

No se si tenga que ver o aporte

Saludos,

Se ha creado el siguiente hilo de conversación en los foros de Embarcadero Delphi XE5 Android Heap size problem para que lo estemos monitoreando.

Destacar que el clásico "Hello World" consume 23MB de RAM usando Delphi XE5 y poco más de 300KB con Eclipse...



Basic4Android (VB to Android), genera 600KB... Embarcadero, algo estas haciendo mal :confused:

http://www.youtube.com/watch?v=p4wh0IksOfg

Con las aplicaciones para Iphone e ipad creo que es lo mismo,
De todos modos por algo se empieza, imagino que esto lo iran puliendo en nuevas versiones.
Aunque como sea como en Windows, cada nueva verisión de delphi han ido incrementado el tamaño de los ejecutables compilados.
Así que no parece que sea una cosa que les preocupe mucho, los programadores de Embarcadero deben de tener todos iphone's 5 y Samsung's S4

OK, La respuesta es los foros es que XE5 genera código nativo para Android y por ello consume más espacio. En cambio, al usar entornos como Eclipse, se esta compilando bajo JAVA y por ende requiere menos espacio (archivo comprimido APK de 5.000KB en nativo vs 300KB en JAVA).

¿Y el código nativo de android no es java?, ¿a qué se refieren exactamente?

Pues no Casimiro. El código nativo de Android no es JAVA aunque comúnmente las aplicaciones se programen en este lenguaje usando el SDK, se puede programar nativamente (lenguaje C...) usando el NDK, lo que elimina una muy importante capa, mejorando el rendimiento, etc.

Si genera código nativo para Android, a regañadientes se puede aceptar que consuma más espacio en disco,
pero que sentido tiene que consuma tanta RAM?
¿Entonces cual es la ventaja de que sea código nativo?
Lo único que se me ocurre es que consuma menos CPU, pero me da a mi que no será así tampoco

Creo que no he entendido: sí, seguramente android está desarrollado en lenguaje C, como cualquier sistema operativo, digamos que es lo normal. Pero se creó para que corriesen programas hechos en java. Lo que no acabo de entender es que (según tu comentario de antes) ocupe más el programa (app) en código nativo (C) que en java, salvo que no se cuente con que necesita un runtime.
Resumiendo, que no me ha quedado muy claro ni me ha parecido muy lógico.

Desde la web original de Android :rolleyes:

He probado a compilar algún ejemplo de los que vienen con el XE5 y por ejemplo
MobileControls.apk el tamaño vale que son 5,7mb
pero es que al abrirlo en mi móvil Sony Xperia P, que no es de los malillos (dualcore de 1ghz y 1gb de ram),
le cuesta 7 segundos desde que pincho el icono hasta que se abre el programa.
Para ser que dicen que crea código nativo y que es mejor que java vaya ruina.

Seria bueno comparar con:

http://docs.xamarin.com/guides/andro..._package_sizes

Echadle un vistazo a este artículo. Es otra forma de ver el tema.

De todas formas, yo creo que este "problema" y muchos otros que trae esta versión son "solucionables" o "mejorables". Esta no deja de ser una primera versión y como tal tiene muchas cosas a mejorar.
Ahora que la base está puesta (que creo que es lo más difícil) las sucesivas versiones vayan añadiendo más funcionalidades, aportando más información ayuda y ejemplos, y mejorando las existentes.

Me quedo con este comentario que esta sin responder:

"What is about memory size limitation on mobile device and memory usage strategy, when OS unload not active application to free memory for you "size is not my care" app?" ;)

El problema es que están cobrando un valor premium por una funcionalidad que no equipara*. Contraste con XCode. Cuando hay algo nuevo, el beta dura hasta meses. Cada mes/2 meses hay nuevas versiones. Nunca he visto un problema grave (en las versiones estables) y cada vez hay cosas mejores.

He incluso, la compilacion y/o el manejo del codigo y/o las apps son cada dia mas rapidas (con el salto a 64 bits por ejemplo, se ha avanzado todo un resto).

No entiendo porque a estas alturas embarcadero no hace betas publicas de sus productos...

* Mi problema no es tanto con el tamaño de la app en si. Aunque es importante en moviles, es un precio que se puede pagar si la funcionalidad lo compensa.

¿Con XCode puedo compilar aplicativos, con las mismas lineas de código para Windows 32 y 64 Bits, OSX, iOS y Android?. Por otro lado ¿Has notado que este es el foro de Android?, además veo que si vas a refutar el precio hablas de XCode, pero sí vas a hablar de algo en la funcionalidad hablas es de Xamarin. Osea, ninguna de las herramientas que mencionas ofrecen ambas cosas.

[modo broma]
El foro de iOS/apple todavía no se ha estrenado, ¿por qué será? ;)
Venga, mamcx, que no se diga... :D
[/modo broma]

De poderse se puede, pero no esta tan facil (para Win/OSX/iOS si pero Android requiere algo como http://www.apportable.com/ - no lo he probado-).

Si que lo he notado. El robocito todo chulo del foro me lo recuerda ;).

Hago el contraste con Xcode/Xamarin porque son las ppales competencias. Xcode, porque es una herramienta de código nativo (cosa diferente a lo normal en Java), aspecto que Embarcadero enfatiza para delphi, pero la diferencia de la experiencia y expectativas no cuadra. El aspecto del precio afecta, porque en iOS, la ventaja de xcode sobre Delphi es muy alta y la de Delphi sobre iOS es solo la promesa de la multiplataforma (que en la practica, como se ha demostrado su eficacia?).

Y xamarin es lo que compite en términos del tipo de desarrollador (que busca una herramienta mas productiva y multiplataforma) la cual es tecnicamente y en ejecución mejor.

En el mundo de win32, delphi tiene su nicho porque con todas las metidas de pata en estrategia y posicionamiento, tecnicamente es insuperable. Pero en móviles no se ve ni lo uno ni lo otro. Y me duele la idea que no logren, rapidamente, posicionarse bien en este mercado, porque eso seria un puntillazo definitivo que relegaria a Delphi aun mas.

Y *todavia* sueño con programador con Delphi en móviles. Como lenguaje, Delphi & python son mis favoritos. Pero como producto, Delphi no esta ni en las 5 alternativas que considero viables a corto y largo plazo.

P.D: Que alternativas han *PROBADO* su eficacia:

- MonoTouch, Xamarin
- Lua con CoronaSDK
- Varios engine de juegos, como Unity, Coccos2D con obj-c y/o C++, Sparrow, etc.

Por *probado* implica apps exitosas y suficientes que han demostrado que es algo real. Tambien su documentación, soporte, etc

Otras alternativas que son a medias, pero que consideraria antes que Delphi (como esta):

- Python con Kivy. Si le dan soporte a la GUI nativa de iOS me le tiro en voladora
- Lua
- PhoneGap

He de decir que quizas he probado y medido mas opciones en el mundo de móviles que muchos aqui, y mi experiencia con esas alternativas es positiva desde el inicio, osea, uno hace su "hello world" y no hay grandes sorpresas y las cosas andan bien. Con todo, solo MonoTouch, Corona tienen algo completo que tambien pudiera servir para apps en general.

No hay una solución completa con la promesa de Delphi. Delphi es una cosa unica, incluso en Win32. Pero lo que me preocupa es que están chapuzeros con su ejecución en móviles, y para REMATAR cobran como *si fueran* el producto premium en este mundo.

Listo, esas herramientas puede que funcionen muy bien y las hayas probado muchísimo, pero Delphi XE5 acabó de salir ¿Como puedes deir que que no se pueden hacer proyectos serios en él?... osea, ¿has al menos tratado de hacer algo serio en XE5 y has visto que funciona demasiado mal como para decir que delphi no puede competir?

Pues ya que estamos en clubdelphi y en el foro de delphi para android, critiquemos constructivamente para que embarcadero vaya mejorando todo lo que critiquemos :)
Pero no promocionemos productos de otra índole.

¿Ya leiste esta nota ?

http://www.embarcadero.com/es/press-...dental-clinics

¿Eso responderá a tu pregunta? Tal vez no, puedes decir que es una nada más, pero que me enseñe alguien que haya utilizado su mismo código para desarrollar una aplicación en otra plataforma, uno sólo me gustaría ver.

Lo de precios y demás, no me interesa discutirlo, EMBT se lo tendrá que comer sólo, a mi sólo me interesa poder crear mis aplicaciones para cualquier plataforma sin tener que pelearme con otros lenguajes y eso me va a costar dinero, lo demás pues cada quien que busque lo que le funcione.

Cómo debaten por el asunto de los precios, caray!!!! de todos modos siguen usando Delphi 5,6 y 7. :rolleyes:

Va

Me sumo a tu comentario, esa me parece una apreciación acertada.

Embarcadero no va a hacer nada de nada por lo que hablemos aqui. Ni siquiera lo que se habla en sus propios foros (eso es un punto que cientos de veces se ha dicho una y otra vez).

Lo que *supuestamente* sirve es reportar bugs y hablar directamente con soporte. Durante los *años* que he estado monitoreando y visitando los foros de Borland/EMB he atestiguado que eso funciona muy poco, y que incluso el trabajo gratuito y los fixes/sugerencias de la comunidad se empolvan.

Lo que hablemos en este y otros foros es solo para ayuda entre nosotros, dar opiniones y que hayan diferentes perspectivas y experiencias, pero eso de que afecte a EMB si es todo un sueño.

jajajaj y a eso sumale que algunos de quienes debanten los precios nunca han comprando una licencia... :P

Ui, y yo pensando que este hilo era sobre el tamaño de las aplicaciones de Android echas con XE5 y no sobre embarcadero, su soporte, precio, iphone, mac, windows o similares...

Creo que esto este subforo es sobre ANDROID, xcode no pinta nada porque no puede compilar para android, en todo caso, sobre eclipse o similares aun me cabria :confused:.

El foro de iphone esta impoluto para que soltéis mil desprecios sobre xe5 para ios ;)

Volviendo al tema, ¿alguien ha conseguido eliminar los paquetes que no son necesarios?

Alguien sabe algo mas sobre este tema?

Me temo que es lo que hay por ahora,
quizás en XE6 vengan las librerías por separado para incluir sólo las que necesitas.
Alguna mejora tienen que guardar para justificar nuevas versiones.

Sólo comentar que al igual que con los ejecutables en Windows, no es lo mismo (o no debería serlo) la versión de Debug, que la versión de despliegue.
¿Os habéis asegurado de eliminar toda la información no imprescindible?

Gracias mancx

Tengo tiempo buscando algo así. Ya lo pruebo.