Stress Testing Android Dalvik
Solution 1:
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.
Post a Comment for "Stress Testing Android Dalvik"