Well i have read a lot of answers of similar questions (even if they are old from like 2013-2014) and i understood that it is not possible to know it exactly since android doesnt count the hardware usage as usage of the app, and some other possible problems like services etc.
At the moment I'm trying to test the perfomance of an App using a protocol to reach a goal and the perfomance of the same App using another protocol (not well known by everyone) to reach the same goal, the default android battery analyzer is good for me since both cases are like 90% the same and i know how the protocols work
My problem is that i'm not sure which one is the best to measure the mAph consumed by my App, i know that there are some external apps that shows it but i would prefer using the one of default, I believe this is something important not only for me but for other people who might have to compare different protocols.
I know that i can measure it programmatically and I've done it too, i save the percentage when the app is opened and how much has been consumed until it gets closed, but it isnt an exact measure since while the app is opened some other apps can do heavy work and add some kind of noise of what i'm measuring so i would prefer to use the android's battery analyzer.
Get a spare device. Load it completely, then run the protocol until shutdown without other interaction (no youtube or anything), note the time it lasted. Repeat with the other protocol. Imho that is a fair way to compare. Note that every device behaves differently and it may or may not be possible to transfer this result to other devices e.g. with different network chips, processors or even firmware versions.
For a more fair comparison I think you should compare how the protocols work. I.e. number of interactions, payload size etc. because the power consumption can only ever be an estimate.
Related
I'm writing an app that requires frequent location checks using GPS. It needs to get the current location every 10-15 seconds and then write it to a database (the database part is mostly irrelevant for this question, just wanted to throw it out there). The issue I'm facing is that I can't find a decent way to accomplish this. I've tried several things:
Using LocationManager.getBackgroundLocationListener() never seems to work. I've tried it on both Android and iOS and nothing ever seems to happen. Might be something I'm doing wrong but regardless, I've read that on iOS, it will only get hit when moving to a different cell tower, so that doesn't meet my needs.
I've tried using Background Fetch, but it's only reliable on Android. The frequency is completely random on iOS and so this won't meet my needs either.
I've tried just starting a new thread that will fetch the current location every 10-15 seconds, but this only works when the screen is on and the app is being used. This won't meet my needs because I need to make sure it continues getting location updates when switching to other apps.
Does anyone have any suggestions on alternative methods to solve this problem? Note that I don't have a background in objective-c, so a cross-platform solution like Codename One is really my only option here.
Background fetch isn't the right choice in this case as iOS expects you to declare what you are actually doing. What you are trying to do is prohibited in iOS and might be problematic in Android too.
Fetching location data in the background (especially at this resolution) has serious privacy implications so I doubt it will work. Doing this in the foreground should work fine to allow use cases such as navigation but in the background it might be an issue.
This is further compounded by the fact that location and networking are big battery draining activities. So there are limits to the resolution you can apply with these API's. One of the more common use cases for background is geo-fencing which allows you to track when a user approaches an important point of interest. The reason this API exists is to reduce polling costs and keep location usage to a minimum.
Notice that both Android & iOS provide tools to detect battery usage for the user and these might impact misbehaving apps.
With respect to mobile development, I'd like to know whether the rate at which something is downloaded from the internet can be affected by the app making the http request. I assume that download speed is most affected by hardware. If code can affect download speed, what are some performance tips to download something as fast as possible most of the time?
In all communications, you are limited by your bandwidth. Mobile platforms tend to be much slower than wired connection. So the solution is simple, make the download amount as small as possible.
This is, of course, easier said than done. It tends to take some creativity to get a network bound application unbound. However when you are able to, you can see very impressive/unbelievable gains in performance.
I'm your case, it is good to think about it up front, but also consider it as the app is developed.
Ps: some general rules of thumb
Network accesses: on the order of 10 millisecond
Disk access: on the order of 10 microseconds
Memory access: on the order of 10 nanoseconds
Cpu cache: on the order of 100 picosec
This is a little bit more than you asked for, but you can clearly see why it would be faster to compress data, send it and uncmpress it then to just send it.
As Robert said, it's more likely than not the network that's limiting you, rather than the code itself. It IS possible to intentionally throttle download speed in multiple languages, but I doubt the code is the cause.
Think instead about how you might cut down your application's size. Think hard about reusing assets, pulling some data from a webserver if possible, etc etc.
So I am working with a quiz game in android where you are supposed to be two players playing against each other on different devices.
I am trying to figure out how the correct way is to set up the server communication to the devices. I want both devices to know when both players has given their answers to a question so they can receive the game result.
My first thought was that both devices will repeatedly ask the server if the other device is finished so they can have the game result. But I start thinking this is a bad idea as it will cause a lot of unnecessary traffic and probably some background performance.
So what is the correct way of doing this?
The Google Android way of doing this would be using Google Cloud Messaging (GCM.) This approach is battery & processor efficient, supports broadcasting up to 1000 users at once and has built in functionality for outdated/expired messages.
http://developer.android.com/training/cloudsync/gcm.html
Of course there are other ways of communicating that may be correct/right/valid but this approach is the best for your specified requirement.
I'm developing an app that it functionality very similar to Facebook Android native app: social network that most of the time the user will spend in an endless ListView displaying lot's of images, entering an image gallery, and so on.
let's say for the discussion that I'm doing all the right things and best android practices to achieve smooth scroll (recycling views as it should, using different view types when needed, loading to memory only scaled bitmaps in the needed size, caching bitmaps, using ViewHolder design pattern, not blocking th UI thread when its possible and so on...)
let's say also that every thing else in my app written in the best way and following best practices (for the discussion... :->)
my app working not bad at all in that stage, but when
turning on the hardware acceleration, as described and promised in Android Developers documentation it making my app much much more smooth and fast.
let's say that it does not affect in any nagative way on the UI as can happened, and I'm not performing any of the Unsupported Operations
according to Google's document on the subject, only reason I can see not to use this feature (besides all other reasons I already mentioned above) is that it can cause my app to use more RAM. but how much RAM? a lot more? I know that when my app consumes lot's of RAM - it becoming good candidate to be destroyed by the OS when it need to free some memory.
my question is basically -
is it "ok" under my circumstances to use this feature?
what other problems can raise from using it?
TIA
To use or not to use
It is advised to use hardware acceleration only if you have complex custom computations for scaling, rotating and translating of images, but do not use it for drawing lines or curves (and other trivial operations) (source).
If you plan on having common transitions and also given that you have already considered scaling, recycling, caching etc, than it may not make sense to burden your project anymore. Also, any efforts spent reworking your code to support hardware acceleration will not effect users on versions below 3.0, which are ~36% of the market as of May 8, 2013.
Memory
Regarding memory usage (according to this article), by including Android Hardware the application loads up the OpenGL drivers for each process, takes memory usage of roughly 2MB, and boosts it to 8MB.
Other issues
Apart from API versions, I presume it will also affect battery life. Unfortunately there aren't any benchmarks on different use cases online in order to draw a line on this one. Some argue that in given cases because of multiple gpu cores, using acceleration may save battery life. Overall, I think it would be safe that the effect won't be too dramatic (or Google would have made this a major point).
UPDATE
Hardware acceleration is enabled by default if your Target API level
is >=14
I would say yes in your situation, use hardware acceleration.
Seeing that you aren't using any resource intensive controls in your app it should not be a problem to enable Hardware acceleration. As you said your app is working quite well without hardware acceleration.
When you enable hardware acceleration Android will start using your GPU and because of the increased resources required to enable hardware acceleration, your app will consume more RAM.
A frequently asked question is Will the amount of ram increase by a really big amount?
The answer to that will all be determined by :
1. Your programming ability ie. management of the recycling list, scaling of the Images ect.
2. The Device
I wrote a app a while ago that was used to edit really high res bitmaps. I ran into the same problem. I found that on different devices the max amount of ram allocated by the OS when hardware acceleration is enabled varies by device. If your device has more ram the OS will allocate more ram to your app, so you will never find a consistent amount of ram used for your app. The bigger more expensive devices will always run your app on a larger amount of ram.
What other problems can raise by using hardware acceleration?
Hardware acceleration might cause problems for some 2D drawing operations. If you experience this you can enable Hardware Acceleration for only specific activities in your app like stated on the Hardware Acceleration post in the android Developer Docs
The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware acceleration at the following levels:
Application,
Activity,
Window,
View
This way you can also limit the hardware acceleration in your app but by the sound of it you will need it for most of your apps functions.
Hope this helps
I'm interested in using Android for a E-Ink
based platform. I know it has been demonstrated once by MOTO, but I'm interested in using it for a commercial grade product and not 'just' a technology demo. I have got a question on the ability to change the platform to cope with specific display effect caused by E-Ink. I'm asking this question from the role of system architect and have no prior experience with Android.
E-ink has several characteristics which are very different than the common LCD displays:
time to update display (50-700ms)
it costs power to change the display (none to maintain)
display life time is determined by number of display updates!
tradeoffs can be made between quality, performance and display lifetime
grayscale versions available
The great thing: it costs no power to retain display information and they can be read in bright sunlight with no backlight. Also the display can be literally as thin as paper...
This means that the platform software needs to have a degree of control over the number of display updates and the type of display updates to get the best performance. Otherwise, an application which is unaware of the display characteristics could quickly drain the battery, or worse, shorten display life time to months instead of years. Conceptually I'd be interested in replacing a display driver, but I'm not sure if this part is open. I know it is hard to get info on the Qualcomm chipsets....
My question: can this be done? Can the Android platform be modified to support a drastically different display effect? Any pointers to an android roadmap?
The reason I find Android interesting for this application is because there is a significant overlap in functionality (from cell phone to browser).
Thanks!
I cannot agree more and started to lobby with app and OS developers on improving readability on e-ink:
Make scrolling and page turns e-ink friendly http://github.com/aarddict/android/issues/28#issuecomment-3512595
Looking around on the web I find a recurring theme "we had to rebuild WebView from scratch to adapt it to the e-ink display"
There are already coding solutions which reduce flicker and page refreshes. Most of them are kept by those who market the e-ink readers who prefer to keep them as frontends to their shops.
I contacted the author(s) of cool reader on their implementation of
smooth scrolling on e-ink devices and got the following reply:
Hello, Look at N2EpdController.java Author
is DairyKnight from xda-developers. At least you can use it under GPL.
For use in closed project I would recommend to contact him.
Ideally, display components for e-ink devices should be part of the Webkit's WebView framework. I've submitted a feature request via
http://bugs.webkit.org/show_bug.cgi?id=76429
fyi, E-Ink has an Android on E-Ink development kit, AM350 that's being sold now. http://www.eink.com/sell_sheets/AM350_Kit_Sell_Sheet.pdf
http://www.linuxworld.com/news/2007/112707-kernel.html
In this case the application domain is e-reading, in which case the advantages of E-ink are more imporant than the disadvantages (slow display updates).
I've done some further studies of Android. I believe the trick is to perform display updates asynchronously; to provide applications with an environment which mimicks immediate display updates, whilst detecting the relevant updates (i.e. by using graphics processor and/or MMU) to have an intelligent display update. Not all types of applications would be suitable; i.e. games and video playback require immediate display updates.
Making such a platform will be less than trivial; however, with the growing number of different hardware platforms, abstractions are becoming better all the time.
I know this is an old question, but I have found it through Google - others might want to know this too.
PocketBook Pro 902/903 are based on Android and feature e-ink screen. You might want to check them out. There might be other models too - I am interested in these because of their 10" screen. YMMV.