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.
Related
I'm trying to build a limited-functionality Android system for our device, which needs to boot quickly, but everything we do seems to slow it down.
For example, our device has no camera, no bluetooth, no wifi, but turning them off wholesale in various /system/etc/init/*.rc files seems to actually slow it down, due to the interdependencies of Android. The services that are turned off end up restarting, or causing timeouts in Settings, for example.
(Android is on the device for its' UI, not for its connectivity abilities.)
Do you have any suggestions for how to do this? Surely Android for cars, TVs and tablets have had to deal with these issues before.
You did not specify what you did exactly, but if you tried to not start HAL services on startup they might just be started dynamically later. If you are using Android 8 or newer you could merge multiple HALs in one process. But I doubt that this will give you any significant speed-up.
Android does provide a guide on how to optimize boot times: https://source.android.com/devices/tech/perf/boot-times. However, you will notice that they focus on the bootloader, kernel, file system, SELinux, and parallelizing init. The elephant in the room is Zygote. It takes forever to start because it preloads the whole Android SDK.
From its history, Android did not care too much about startup times, because you typically do not restart Android. Instead, they rely on Suspend-to-RAM.
You should think about what you want to have your user experience early. Example: for Automotive Android, Google needs to support a rear-view camera that is available within two seconds after boot. They achieve that by a second, faster stack that provides first images before the application SDK is started and takes over. See https://source.android.com/devices/automotive/camera-hal
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.
I've developed an application which seems to work on most tablets/phones I've tested it on (S2/S3/S4/Xoom/some emulator configurations etc)
However, I've noticed a few complaints around a "Pantech Burst" - I can't seem to find any of these phones to pick one up (possibly it's specific to the US) and thought perhaps I could simulate one.
I know its 480 x 800 pixels, and has 1GB of memory
http://www.gsmarena.com/pantech_burst-4429.php
Is it possibly to simulate this kind of phone?
Or are some phones inherently different based on hardward that you could never simulate?
(I have a gut feeling it might be related to mp3's and Soundpools, but I'd rather prove it)
Short answer: no. In my experience if you have device-specific problems really the best way to debug them is to get your hands on the specific device.
Failing that, I can recommend integrating some kind of crash-reporting framework into your app, if you haven't already. These really help in capturing, tracking, and sending errors (with stacktraces) to you and have helped me fix problems on devices I can't get my hands on.
One I use is bugsense, there is also ACRA and others.
http://www.bugsense.com/
https://github.com/ACRA/acra
If you're having a problem on one particular device, then it is likely a hardware + software bug, and simply simulating the hardware configuration will not solve your problem.
That said, you can always duplicate the hardware by setting the RAM, screen size, storage etc. to its specifications. You probably won't get the same processing speed due to the fact that you're on an emulator.
If getting device is not really an option for you, you might want to consider using the Apkudo service, assuming they have the device your app is having trouble with.
You submit your app, and they run it on their set of devices using Monkey, returning to you a logcat and a stack trace when the application crashes on a particular device.
I'm curious about efficient strategies for porting simple iOS apps to Android. In this case "simple" means an app with one full-screen UITableViewController that's populated with an XML file downloaded from a server. The XML file will be identical for both iOS and Android apps.
I have zero experience with Android development. So I've considered various approaches:
Invest time and resources into learning Android developement
Hire a free-lancer to port the app
Just make a crappy Android port myself w/o investing much time and resources
These approaches have upsides and downsides:
Learning Android development is a decent investment and will most likely pay off in the future.
Dealing with device fragmentation isn't something I want to invest too much into since I don't want to be an Android specialist.
A decent free-lancer could have a grip on the fragmentation issue. However that route could make the app harder to maintain. I won't know the codebase. If that same free-lancer isn't available to make updates then I might have to pay another person to get up-to-speed on the codebase.
Quickly creating a version of the app for a single handset that I purchase would work for that device. However I'm not sure if any one device covers a majority of the market.
The app is free hence running perfectly on the majority of devices isn't a huge issue for me. If enough users complain I can fix problems on specific devices.
In this situation what are some strategies for efficiently porting a simple iOS app to Android?
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.