This question already has answers here:
Stresstest Memory on Android
(2 answers)
Closed 3 years ago.
I've been reading up on the Android dalvik, and I was curious as to how one would go about stress testing the Dalvik to evaluate its stability. I understand the Dalvik is meant for memory an processor constrained devices. So would allocating a lot of memory/increasing frequency of some CPU cores and then launching multiple applications be a way to test the stability?
I also understand that each independent process gets itsown instance of the Dalvik. So another possibility to stress the Dalvik would be to launch multiple applications that share a single process and a single instance of the Dalvik and see how stable the Dalvik is.
I would like to to know if either of these are good ways to measure the stability of the Dalvik. If both of them are good ways, which one would be a better test?
Thanks!
It's difficult to stress every part of a VM all at once.
You can write memory stress tests that exercise the heap and the garbage collector, synchronization stress tests (like the JSR-166 java.util.concurrent test suite), CPU stress tests that do lots of integer and floating-point computations on different cores simultaneously. And so on.
The trick is to write a test that does what you think it does -- a surprising number of "multi-core" tests end up single-threaded because of unexpected dependencies -- and whose results can be evaluated for correctness. A test that successfully causes instability isn't useful unless that fact is communicated to the user in some way. Making the VM crash is a pretty good way. :-)
Running multiple apps and services in the same process is theoretically possible but rare in practice. I don't think you'd actually be able to stress the system out any better this way, since only one app is in the foreground at a time, and if you're making requests of a service one thread will wait for the response while the other runs. You're better off just have one app with multiple threads, so you can control exactly what each does and how they interact.
Before you can do any of this, you need to define the scope of "stability". Simply running many apps isn't going to turn up anything, since there are hundreds of millions of devices running billions of instances of Dalvik with essentially no failures due to the VM itself (but any number due to bugs in apps, the framework, 3rd-party libraries, etc). Dalvik hasn't changed much since Android 4.0 (Ice Cream Sandwich) shipped two years back.
Related
I work at a phone manufacturer (OEM).
One of our preloaded third-party apps has been complained about by our users that the performance is very bad on our mid-to-low end devices.
Without having access to the app's source code, how do I determine whether the performance problem is caused mostly by how the app was written or by the limitation of the device (e.g. CPU)?
This is an interesting question. Even though it should require code.
My take;
When it comes to performance especially when it comes to Android, the issue always has to do with application development.
If an application is struggling, regardless of its capabilities, it is trying to do too much at once. There are many ways to improve performance with asynchronous background threads, and with modern development Croutines.
People complain about performance for one reason. The application is showing the user it is struggling. If you are working on low end devices, your views should be very simple and clean, and data/views should be asynchronous to prevent too too much from happening at one time.
The next version of my app has roughly 70K methods.
Knowing the exact implications of using Multidex (which usually means using the Multidex support library to support API<21) is important to me to make this decision:
Should I put a lot of effort (i.e. by fine tuning my Proguard configuration to shrink more aggressively, dumping some 3rd party libs etc.) to comply with the 64K methods limit, or should I just enable Multidex?
The documentation suggests that the Multidex support library may have some serious side effects (see Limitations of the multidex support library).
What should I really expect?
Failed installs on some devices?
Slow startup of the app (on 1st startup or always)?
New crashes or ANRs on some devices?
Overall performance degradation?
Feedback from your own migrations to Multidex would be greatly appreciated.
I'm not a specialist in Dalvik but I've worked on several projects that at some point required MultiDex and these are some of the lessons I learned:
Failed installs on some devices?
Some devices, specially old Gingerbread phones (but also ICS), use a very small LinearAlloc buffer which might cause errors while installing or cold-starting an app that has too many classes or whose class hierarchy is too complex. Enabling MultiDex doesn't contribute directly to this problem but allows developers to continue the "code bloat" up to the point where the app becomes too big to run on those devices... which sometimes only gets noticed when hundreds of very sad users start calling your customer support.
Slow startup of the app (on 1st startup or always)?
The first start after installing or upgrading is definitely slower, mainly due to the expensive I/O operations required to extract the secondary dex files from the APK into the file system. Subsequent starts are also affected proportionally to the size and complexity of classes that have to be loaded in order to bring up your first Activity, so it's good to keep the main components of the app (specially activities) in the primary dex to minimize startup time, although it's not always possible to do so.
New crashes or ANRs on some devices?
We've seen ANRs in Alcatel OneTouch (2.3.3) and Google Nexus One (2.3.6) phones that were caused by the dex extraction taking too long. In more modern devices, upgrading and cold starting multidex apps might take a bit longer but usually not long enough to cause ANRs.
Overall performance degradation?
Class loading becomes much slower and that affects the app in unpredictable ways. If you use a DI system, Protobuf or some other framework that generates hundreds of classes then you might find some of your application workflows becoming 20-25% slower after enabling multidex. One way to mitigate this is to load classes ahead of time via, for example, a background thread or a BroadcastReceiver but these, of course, will increate the memory footprint of the app and potentially slow down the device.
Also, some install-time dex optimizations might also be skipped if dexopts finds classes missing from the primary dex, so there might be a considerable penalty in terms of CPU and memory usage even if only a couple of classes end up in secondary dex files.
Should I put a lot of effort (i.e. by fine tuning my Proguard configuration to shrink more aggressively, dumping some 3rd party libs etc.) to comply with the 64K methods limit, or should I just enable Multidex?
MultiDex solves the 64K method limit but it's not a silver bullet and IMHO shouldn't be used as an excuse to avoid optimizing the size of the APK but if
You're only targeting modern devices (e.g. API 16+)
Performance/cold-start times are not critical
You have no time to optimize the app further
then MultiDex might be suitable, otherwise stripping unnecessary code is the way to go.
I ended up going with multidex, essentially because the roadmap of my app would have forced me to do so eventually (as I'm planning to integrate big libraries in a near future).
It's been more than a month and hundreds of thousands of installs/updates of the multidexed APK, so I can now say with decent confidence that the move to multidex did not have any significant side effect, in my specific case.
(note: the update only targetted API 11+, so I cannot speak of potential problems with Android 2.x).
So I am developing an application, which has a 'strong' parallel structure, and since time is important for me, I thought about creating 4 threads for each 'subwork' (assuming running on 4 cores device). If the 4 subworks are executed sequentially it will be a great loss of potential.
The OS will handle which threads run on which cores. All you need to do is use AsyncTasks or threads to set it up for parallel processing and it will take advantage of it if it can. You can find a more information on the topic in this qualcomm blog post.
I do not believe that you have access to the individual cores - this is handled by the Android kernel. However, as long as you implement your 4 "threads" as Java Thread you should be fine, seeing as they can execute concurrently independant of your main Android Activity. You can find additional information on using a Thread in Android here: http://developer.android.com/reference/java/lang/Thread.html
You cannot control the kernel yourself (without root) i belive, but android should use all the threads itself, so you dont need to do anything at your end.
This might help, if you want to run many activityes at the same time - Can you have two activities running at the same time?
Does single thread application use all the 4 core in a Quad-core phone.
I searched this a lot and found some articles that says yes and some saying no. some articles even say the android OS doesn't utilize the 4 core.
Is android capable of using all 4 cores in an Quad core processor?
Does single thread application utilize multi core?
The answer is YES.
Android is basically built upon Linux kernel which does utilize mulit-core.
As far as single-threaded-application is concerned, remember that a thread can not be executed in-parts on different cores simultaneously. So although your single-thread can be executed by different cores at different point in times, it can not be sub-divided and executed by different cores at the same time.
Having said that, please be aware that chipset manufacturers like Qualcomm are developing intelligent processors capable of sub-dividing your single-threaded app code (if and only if there are mutually exclusive parts) into multiple threads and have it run on different cores. Here again, the basic principle remains same - in order to utilize multi-core, the single thread was sub-divided into multiple threads.
To get the most out of your multi-core chip, you would rather create a multi-threaded app, with maximum possible asynchronous threads, so as to have optimum utilization of maximum number of cores. Hope this clears.
EDIT:
This also translates to - An app that does not make use of multiple asynchronous threads (or any other parallelism construct) will NOT use more than one core.
Yes. Android 3.0 is the first version of the platform designed to run on either single or multicore processor architectures.
Even a single-threaded application can benefit from parallel processing on different cores.
For example, if your application uses a media server, then the media processing and your UI rendering application logic can run on different cores at the same time. Also, the garbage collector can run on a different core.
Say your using graphics. To render the same your app can use multi cores. You can check the same at the link below.
https://youtu.be/vQZFaec9NpA?t=459 (Graphics and performance)
http://android-developers.blogspot.in/2010/07/multithreading-for-performance.html
Check this pdf. Scroll down to slide 22. Might be useful
http://elinux.org/images/1/11/Application-Parallelization-Android-KlaasVanGend.pdf
The same code for Android (1Ghz Snapdragon) executes 2 time faster, than on my PC (in desktop application) with 3.3 Ghz Core 2 Duo (class from PC was copied to Android project). Tested with Win7 and Debian. Time mesured by System.currentTimeMillis() for only one (main) calculating method. Why it's happend and what can I do to fix it?
UPD1. First application running on real android device, second - in JRE
UPD2. In that part of applications, that I try to compare, used only simple math and operations with BigDecimal (multiply, sqrt, divide and so on). Idea - calculate pi by gauss-legendre algorithm
You're going to need to be more specific about what you're doing to monitor this. There are a large number of factors at play that could influence this. If you're running on the emulator, forget it -- it's incredibly slow, there's really no comparison there. However, I get the feeling you're talking about one application running in the JVM as a standard Java application and another application running on Dalvik, but there, you really can't compare either. Different frameworks have different libraries and different calls that are implemented in different ways. Not to mention Dalvik is optimized differently than the standard JVM and so on.
You'll need to give us more information in order for us to attempt to give you an explanation, but I suspect you're trying to compare two things that really can't be compared.
I think because the Android device has a different processor architecture than your PC, so the CPU on your PC needs to emulate the Android, so it would do much more processing.