I am currently working on a mini game using libgdx 1.0 + box2d with no more than 4 screens.
My base virtual screen resolution is 854x480 and texturepacker i being used.
The apk file after compiled has about 2.2mb. After a closer look, I just noticed that there 3 folders in the lib folder with the "same" files totaling 1.2mb:
android
lib
armeabi
libgdx.so
libgdx-box2d.so
armeabi-v7a
libgdx.so
libgdx-box2d.so
x86
libgdx.so
libgdx-box2d.so
Well, I need the files libgdx.so and libgdx-box2d.so, but is it safe to get rid off some of them or they are there to support different target devices?
They are not the same files.. check their sizes.Every version is for a different platform and its not really safe to remove any of them.
armeabi: compatible with all the devices,kinda like a compatibility mode ,much slower cause does not offer platform specific optimizations.
armeabi v7a:offers hardware float operations and other things that improve performance.
x86:same as v7a but for x86 architectures.
Most of the devices will probably be able to run on just armeabi but much slower than on v7a or X86.
Related
I want to create a very small (in apk size) Android game, I hope is not more than 3mb, so anyone with low avaiable space in the phone can play it.
I can do it with libgdx but I want to use cocos2d-x.
The problem is that I built the start template project that only has the cocos logo image, using Android Studio in release mode and the APK built is 3.2Mb. Is too big. I run the analysis and the .so file size is 2.4mb.
I'm missing some optimizations or something? I'm new in cocos2d-x so maybe there is something I don't know.
Here are the things you can try:
Comment out physics engine, particle engine, any 3D libraries and other unused file formats from CCConfig.h
Check if you are loading any TTF fonts (they can take around 600kb each)
Build only for 1 arch at a time (not arm and x86 mixed)
If you do all that you can probably get down to around 1mb theoreticaly.
What would be my best bet for trying to roll my own libraries when I want to launch Minecraft on an ARM device? Standard Mojang repositories only have x86 versions of LWJGL in particular, and trying to overwrite the copies in .minecraft/libraries with armhf version triggered a corrupt file error and a redownload cycle with the x86 version.
I think you are wanting to run Minecraft on mobile? Correct me if this is incorrect, Because LWJGL is already compatible with ARM, it doesn't even care which CPU it is running on (e.g AMD CPUs are ARM) because the two main APIs it is using (Java and OpenGL) both don't either - It even supports all OSs because of this too, it's just preferred that you use 64-bit libraries on 64-bit systems for speed purposes, you can always just use 32-bit even.
I would also like to clear up that Mojang did not make LWJGL so searching their repositories isn't the place to look. Plus if it were possible to simply change the natives they would have done that instead of make it again..
Is there any way which can be adopted, to create cross platform responsive mobile apps using Flash Builder ?
We are using our custom written Resigning Engine for this purpose right now, but we tend to replace it with any generic Resigning tool or to cater responsiveness for all kind of devices/platforms.
Being on the same cross platform development, i.e. Flex, Action Script and MXML, is there any solution for this?
Thanks
It's possible deploy Flex-apps on Mobile devices, see Mobile app development
at Adobe Devnet more details
You definitely can develop Android and iOS apps using Adobe Air, Flex, AS3, MXML and publish them on Apple App Store and Google Play Store. But it's limited to these platforms, and Adobe is very unlikely to add any new platform to this list.
Pros:
it's really cross-platform. Once your application works on one, it's really easy to get it working on the other; so the development cost compared to native applications is much lower;
you may have some OS specific features/design; using by example OS specific CSS directives;
You perfectly may create an app with a responsive design, all tools are provided, but like for HTML/CSS, it requires a lot of work;
you may access all phone features (sensors, camera, etc...) using Adobe Native Extensions
Cons:
the size of the generated application: as it includes the AIR runtime, even a very simple app will weight around 12 Mb (9 for the runtime + 2.5 for Flex);
the performances are correct but not as good as those of native apps; one of the reasons is that Flex does not allow to use GPU for rendering (but Flex is not a framework for creating games);
it would be costly to get an app looking like a native one, as you would have to mimic all of native components. There was a project to do this (Eskimo), but it looks dead, and the components were not polished enough to be used in production when they stopped the development;
Adobe Native Extensions offer is rather limited, and they are quite tricky to write; (these drawbacks are not strong ones: you can write extensions, assuming you know to write native code; and most of the common features are available as ANE);
like with any other cross-platform technology, there are a few issues that you can't fix by yourself; you just can wait for Adobe to fix them when it's a problem in the compiler or the AIR runtime; hopefully they follow a 3 months release cycle since they launched AIR on mobile;
it runs on Android 2.3+ devices only; and only devices that are matching the minimal requirements defined for the AIR runtime; that is to say, most of the smartphones and tablets, except cheap ones like ZTE products. When a device is not considered as powerful enough by adobe, the AIR based apps are not displayed in the stores.
Some recommendations:
The best way to organize your code is to create a project for each OS, with specifics assets (icons by example) and a specific manifest file (app.xml), and put all of your application code in a library used by these two projects. It will allow you to test your code (Flex mobile project can't be unit tested), and will avoid you permanent modifications of the manifest.
Worflow: it's usually faster to develop for Android, and then adapt you app for iOS, because it's faster to deploy and test on Android device (although you may use the Adobe Simulator most of the time).
Use the latest release of Apache Flex; it handles the high resolution devices. Forget Adobe's release (4.7 and lower)
Test quickly and often on mobile, especially for the responsive aspects.
Use FXG instead of bitmap graphics each time it's possible (i.e. if they arent animated); it's lighter and very easy to scale.
Mad Components
Alternatively, you may consider using Mad Components instead of Flex.
Flex was not designed for mobile at first; MC was. So it's faster (looks like native), and much lighter (although you still need the embedded AIR runtime which weights 9 Mb).
I'm trying to make a HTML5 word-game that should eventually be wrapped into an app for Android and iOS.
For now, I only tried Phonegap / Cordova to build the app, but it is VERY slow on my 2-year old Android 2.3.3 phone. Operations (like indexing the dictionary file or finding all words that start with a certain prefix) that take only 100ms in Chrome on my desktop, take up to 2 SECONDS on my phone. I know this is because Phonegap uses the Android Browser, which is very slow on 2.3.3.
So, what are my options now? I want this app to be able to run smoothly on Android 2.3.3.
I read about CocoonJS, Trigger.io and appMobi (now Intel SDK).
I know these techniques can improve canvas performance, but will they let my Javascript run faster too ?
Maybe there are other solutions that really compile the Javascript into native code?
Or some HTML5 wrapper that I'm unaware of that includes a version of Chromium instead of using the Android Browser?
With CocoonJS your app will run under a optimized engine so your app will run significantly faster, still they recommend some Javascript good practises for performance optimizing that you should take care of them. The point is to help JavaScript compiler following some coding rules.
Here you have some slides done by #mortimergoro of the engineering team of Ludei that explain the behavior of JavaScript compiler:
http://goo.gl/0RdhIY
This month I started to play with Flash Builder because I don't have a mac to create native iPhone apps.
I have made a Flex Mobile Project and an AS3 Mobile project. Both do mostly exact the same and I see great differences in operation speed (AS3 version is much faster). Also the size of the AS3 version is less than the size of the Flex version when I deploy the project.
But one thing disappoints me, the size of a deployed AS3 app (Android) is still about 8MB. I think that is quite huge for a simple app, or is it normal? I did not test the iOS version because I am not an Apple Developer member (is there a trick to deploy an iOS app with fake certificates)?
Resources I have used in the apps:
Two images approx. 35kb in size
A StageWebView
I want to know:
What is the average size of a simple app when it is a native app (apk file)?
What is the difference between an AS3 app and a Flex app except the libraries that re used?
Is the AS3 app converted to C or another language?
Why is the apk so huge (IMO)?
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
Thanks for the answer(s).
What is the average size of a simple app when it is native app (apk file)?
I have no idea. When you were comparing sizes; did you export a release build or a debug version? The full version of my app; using Captive Runtime is 12MB. That includes all the embedded images. I thought that roughly 8MB is the size of the embedded runtime. Of course, if you don't use Captive Runtime then the app will be smaller; but it will have a depency on the user having the runtime installed.
What is the difference between an AS3 app and a Flex app except the libraries that are used?
For all intents and purposes nothing. The Flex Framework will need to execute code to setup the framework and such. In theory this 'impact' is offset by the value that the framework brings.
- Is the AS3 app converted to C or other language?
Not for Android or Playbook. It relies on the Mobile AIR Runtime--which I assume is written as a native app somehow. For iOS there is a more in depth conversion taking place; but no on knows the exact magic sauce; but it the process is much more intensive than Android or Playbook and people believe that your code and the AIR Runtime is converted to Objective C somehow in a way that is not in violation of the Apple licensing agreement.
Why is the apk so huge (IMO)?
Huge is open to interpretation. Without seeing your full app code; it's tough to judge.
Is there a trick to deploy an iOS app with fake certificates? (just for testing)
I don't think so; although there may be possibilities on unlocked devices.
You would like to use Mobile AS3 Project if you want you apps to be smaller and your GUI mainly contains vector graphics and Mobile Flex Project if you prefer to use standart GUI Controls that comes together with Flex framework but adds overhead in size because of controls that come with it.
As of the other questions:
the size of the apps is different on mobile platforms. Typical iOS app is about 2MB - 20MB. It really depends on resources you store with your app. What might be important to you is not to overcome 20MB if not needed because 20MB+ apps require Wi-Fi connection to be downloaded.
(However you should export release build version only as mentioned by www.Flextras.com)
there is no fundamental difference between AS3 and Flex apps - they both compile to the same instructions that executes on targeted mobile platform.
as far as I know (being iOS developer myself) there is no workaround to deploy an iOS apps. You need to use Mac and become Apple Developer to deploy with valid certificate.
to make your app smaller try to pai special attention to the resources you add to the project. Although I believe the size is so big because of framework itself, you would like to use more vector graphics vs. bitmaps when compiling apps with Flash/Flex.
When you export for Android you have an option of embedding the air framework in the application, that way your users don't have to download air. you can export your application without air embed which will result in a much lighter application, however your users will need to download air runtime. http://cookbooks.adobe.com/post_How_do_I_create_an_AIR_application_for_Android_tha-19299.html