Vinegar Tasters wrote: > But you gotta understand that there is a major problem > with interpreted applications. They are too damn slow!
That depends on what sort of app you want to create. You seem fixated on games. Android is not necessarily designed to be a gaming platform. And, it's possible those Android devices that *are* gaming platforms will offer their own binary SDK alongside the stock Android one, if they feel it necessary or useful. Since this is [android-developers], not [android-discuss], please post some sample code that demonstrates how you are unable to achieve adequate performance using Dalvik. It may be that we can offer some suggestions to help improve performance. > If you put a java layer on top of it, you are > going to make apps 5-10 times slower! And your proof of this assertion is...what exactly? Please provide peer-reviewed scientific analyses if possible. And then bear in mind that those analyses are probably for a desktop Java implementation running on arbitrary hardware, versus Dalvik run on Android-optimized hardware. More on this point below. > Before I start a flame war, lets get the main point: I am asking for > another sdk for programming to the metal, not get rid of the java sdk > that is android now. Soon, you can use the open source firmware. We believe it will be released in or around the general availability of the first phones on October 22nd. Since Android is Linux-based, one would imagine developing binary modules is simply a matter of getting the appropriate cross-compiling toolchain going. Then, all you need to do is either: 1. Convince people to download your modified Android distro and install it on their phones. 2. Submit patches for potential inclusion in Android that expose APIs to the Dalvik-based SDK (or updated drivers or whatever) that perform better to get around any specific bottlenecks you encounter when using the existing SDK. I suspect this has a better chance of success than #3 below, because the improvements will benefit a wider audience. 3. Submit patches for potential inclusion in Android that enable platform-specific machine-code programs. Be prepared to answer lots and lots of questions regarding security, battery life, and long term support of this option. I realize this isn't the answer you want to hear. There is also a decent chance that something resembling JNI support (whether the real JNI spec or something similar) will be added and supported long-term by the Android team. In that case, specific bits that need optimization can be written in assembler and loaded as binary modules. However, this is not officially available as of Android 1.0. > While normal programs will be able to run at the speed of > the chip directly without going through interpretation. Just because Java is a VM, and Dalvik is a VM in the emulator, does not mean that Dalvik is a VM (= *virtual* machine) in an Android-specific phone. There could be a Dalvik chip. Hence, Dalvik might not be interpreted, any more than machine code is interpreted. And, again, you haven't demonstrated that anything you want to write cannot be written using Dalvik. -- Mark Murphy (a Commons Guy) http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
