Android++: Native development and debugging extension for Visual Studio • Hacker News Board

Re: Android++: Native development and debugging extension for Visual Studio

#41

Post by fidotron » Mon, Jan 27, 2014, 8:12 PM UTC

acemarke wrote: post #32

kevingadd wrote: post #28

Earlier quoted context omitted.

It's my understanding that this counter-intuitive performance problem with Dalvik is what crippled the original UI for Android Firefox - they were using their native C++ UI stack (the one used on Windows, Mac and Linux) to implement the whole browser UI, but they found that in practice a UI stack written in Java running on Dalvik performed better because it wasn't subject to all the weird performance penalties from i…

I don't think that's entirely correct (yes, XKCD #386 applies): First, I'd hesitate to use the phrase "native C++ UI stack". Mozilla's UI framework is XUL, which is a mixture of JS and XML. Presumably there's C++ underneath, but based on my reading it's a mixture of web-based technologies. Second, because the original Firefox for Android UI was written in XUL, they had to load the entire Gecko architecture in order t…

This is intriguing - I had no idea that the Mozilla experience so closely mirrored my own.

The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.

Re: Android++: Native development and debugging extension for Visual Studio

#42

Post by fidotron » Mon, Jan 27, 2014, 8:28 PM UTC

nly wrote: post #31

fidotron wrote: post #27

This is certainly good for games and similar multimedia heavy type apps. However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious…

> if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles Maybe if you're starting from absolutely nothing. If I had non-trivial functionality already written in native code then I suspect I'd rather write JNI bindings than do a complete rewrite in Java. I'm also skeptical of 'use more memory' and 'load less quickly'. Even the GNU C++ standard library on an x86-64 desktop is a…

You're making the precise mistake we're talking about: don't project from your experience of desktop Linux to Android. This equally applies for any Java platform too as the VM performance characteristics don't resemble any from the Sun/Oracle family.

The key thing is to understand what is involved to get an Android app to start up. This is terrifying when considering just the Dalvik case, but what most C++ types don't realise is that even if your app is using NativeActivity it means you are really subclassing this: https://github.com/android/platform_frameworks_base/blob/mas...

This means in order to load the native lib you first have to load Dalvik, a whole load of classes relevant to the app, allocate the whole Dalvik heap for the app, and then you rely on the Dalvik code to initiate loading of the native lib. As a result this only becomes worth doing if the gains you're going to make exceed those losses, but I find it's quite common for people to ignore the downside, as a few comments here indicate.

Storage to RAM bandwidth on these things is not exactly stellar, so as a consequence loading takes a while. To make things worse if you want to deploy all supported native architectures you're multiplying the native code size by four, since you will want two ARM builds (v5 and v7), one MIPS, and an x86. As a consequence I'm unaware of anyone that habitually includes all of them, and just putting ARMv7 libs in is the norm.

Re: Android++: Native development and debugging extension for Visual Studio

#43

Post by lstamour » Mon, Jan 27, 2014, 9:00 PM UTC

fidotron wrote: post #42

nly wrote: post #31

Earlier quoted context omitted.

> if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles Maybe if you're starting from absolutely nothing. If I had non-trivial functionality already written in native code then I suspect I'd rather write JNI bindings than do a complete rewrite in Java. I'm also skeptical of 'use more memory' and 'load less quickly'. Even the GNU C++ standard library on an x86-64 desktop is a…

You're making the precise mistake we're talking about: don't project from your experience of desktop Linux to Android. This equally applies for any Java platform too as the VM performance characteristics don't resemble any from the Sun/Oracle family. The key thing is to understand what is involved to get an Android app to start up. This is terrifying when considering just the Dalvik case, but what most C++ types don'…

The Google Play store will accept multiple build types and will deliver the correct builds to the correct phones automatically, no need for a fat binary.

While NativeActivity is interesting, for LOB apps we're much more likely to stick to native Android UI components, which means Android/Java activities. However, Loaders might then in turn use JNI as a model layer. I'm still working out the details myself, but I feel there should be a way for shared, cross-platform C or C++ code even if it relies on platform-specific UI and localization. The alternative, rather than JS, is probably Java2objc, used by Google for new developments.

Re: Android++: Native development and debugging extension for Visual Studio

#44

Post by lstamour » Mon, Jan 27, 2014, 9:02 PM UTC

fidotron wrote: post #41

acemarke wrote: post #32

Earlier quoted context omitted.

I don't think that's entirely correct (yes, XKCD #386 applies): First, I'd hesitate to use the phrase "native C++ UI stack". Mozilla's UI framework is XUL, which is a mixture of JS and XML. Presumably there's C++ underneath, but based on my reading it's a mixture of web-based technologies. Second, because the original Firefox for Android UI was written in XUL, they had to load the entire Gecko architecture in order t…

This is intriguing - I had no idea that the Mozilla experience so closely mirrored my own. The fun thing about Android is you can often spot when apps load the native code library since it generally leads to mysterious black screens during the loading of activities for exactly the kind of reasons mentioned there.

I would point out to all the above commenters, that Chrome is still largely native code, with simple wrappers on iOS and Android. http://www.chromium.org/developers/design-documents/android-...

Re: Android++: Native development and debugging extension for Visual Studio

#45

Post by lstamour » Mon, Jan 27, 2014, 9:05 PM UTC

pjmlp wrote: post #35

Maarten88 wrote: post #11

Earlier quoted context omitted.

> C++ is the one language that can work on both iOS and Android (and Windows phone?) C# can do that too, using Xamarin.

C++'s benefit is that it is common to all SDKs. With Xamarin you must buy it, which may not be an option for hobby developers.

Xamarin does have a nice UI for working with Xcode/iOS, though I too fall on the cheap side of the fence. :)

Re: Android++: Native development and debugging extension for Visual Studio

#46

Post by corresation » Mon, Jan 27, 2014, 9:21 PM UTC

fidotron wrote: post #42

nly wrote: post #31

Earlier quoted context omitted.

> if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles Maybe if you're starting from absolutely nothing. If I had non-trivial functionality already written in native code then I suspect I'd rather write JNI bindings than do a complete rewrite in Java. I'm also skeptical of 'use more memory' and 'load less quickly'. Even the GNU C++ standard library on an x86-64 desktop is a…

You're making the precise mistake we're talking about: don't project from your experience of desktop Linux to Android. This equally applies for any Java platform too as the VM performance characteristics don't resemble any from the Sun/Oracle family. The key thing is to understand what is involved to get an Android app to start up. This is terrifying when considering just the Dalvik case, but what most C++ types don'…

The load time and memory consumption of a minimalist NativeActivity is so minuscule that it isn't worth discussion. Your argument beyond there seems to be of the good investment after bad variety -- that if you've made a marginal bad investment, you'd better keep making it just because. That is not good advice in any endeavor.

No one in this thread "ignore the downsides", and your point seems actually very undeveloped: After you've paid that unavoidable, very small initial price (that of course a fully managed app pays as well), you then have 100% minimal native app, using that legacy or cross platform code at full, 100% native speed, with no GC taxes, etc. There is no magical overhead just because you originally started with a native activity.

This is certainly not to say that native is the way to go, because if you're going to make heavy use of the Android API outside of the pure native elements like OpenGL, you're going to just cause yourself a lot of hassle, but most of the anti-native argument seems to derive from nothing at all.

And the ARMv7/v5/MIPS/x86 thing is just strange. Yes, it might be a consideration in some cases (although if it matters 9 times out of 10 you can set a flag and there you go), it is quite a departure from the claims about C++.

Re: Android++: Native development and debugging extension for Visual Studio

#47

Post by RayDonnelly » Mon, Jan 27, 2014, 9:30 PM UTC

This is an interesting project for sure. WinGDB is quite similar.

From the rationale page:

"Large numbers of these developers world-wide use Visual Studio as their primary IDE. Either by preference, or other external factors."

I wonder if having fairly good tooling is one of those factors? And if so, will this encourage people to stick to Visual Studio?

I'd recommend developers to try Qt Creator for Android (there's no requirement to use Qt with it if you don't want to). IMHO, for native development it is already good, improving rapidly and has the advantage of being cross platform and Open Source, though it's build system (qmake .pro/.pri) is arguably worse than MSBuild. Once Qbs support is finished I'll happily retract that statement.

Re: Android++: Native development and debugging extension for Visual Studio

#48

Post by ivank » Mon, Jan 27, 2014, 9:53 PM UTC

realharo wrote: post #29

fidotron wrote: post #27

This is certainly good for games and similar multimedia heavy type apps. However, if you're using C++ for portability for any sort of non-realtime needs you've lost your marbles, and would be better off with JavaScript (no, really) and/or platform specific code to leverage the class libraries of the respective platforms. C++ heavy apps on Android are larger, use more memory, and load less quickly. This isn't obvious…

If by JavaScript you mean making a webview-based app with something like Cordova/PhoneGap, then that's not a great option either. Pre-4.4 WebView on android is notoriously bad, and things as trivial as smooth scrolling are a huge issue. The same app performs fine on iOS and on Android 4.4 which uses Chrome's engine, but unfortunately it will be a while before older versions go the way of IE6. I agree that C++ is not…

https://crosswalk-project.org/ is a Chromium-based runtime that works on Android 4.0+

Re: Android++: Native development and debugging extension for Visual Studio

#49

Post by pjmlp » Mon, Jan 27, 2014, 10:27 PM UTC

lstamour wrote: post #45

pjmlp wrote: post #35

Earlier quoted context omitted.

C++'s benefit is that it is common to all SDKs. With Xamarin you must buy it, which may not be an option for hobby developers.

Xamarin does have a nice UI for working with Xcode/iOS, though I too fall on the cheap side of the fence. :)

I have played around with all three, Java, C++, C#.

For business I would surely advise Xamarin, as their prices are quite reasonable.

But if you are just hacking some stuff every now and then, it might not be worth it.

And on that case, there is also the possibility to compile Java to native code in iOS (RoboVM) or use any other language that either has an AOT compiler, or has a compiler available that compiles via C.

It is always a matter how much time vs money, one wants to invest.

Re: Android++: Native development and debugging extension for Visual Studio

#50

Post by corresation » Mon, Jan 27, 2014, 10:40 PM UTC

pjmlp wrote: post #36

Pxtl wrote: post #21

Earlier quoted context omitted.

Yeah, nobody wants to have a GC pause just as they're about to do something tricky.

So maybe AAA studios shouldn't be using Unity. Oh wait...

The overwhelming bulk of a Unity game on Android runs in purely native code (the Unity shared library). Of course the game orchestration and such runs in a managed runtime (mono), but the garbage created by simple orchestration/management running in a GC is minuscule compared to the garbage created by an entire game engine running in a GC.