I have an application that requires data from a list in more than one classes extending Context. Sometimes I can pass the reference of the list to these classes and sometimes I cannot. So, I was wondering if putting the list to R.array.mylist and then continually calling from them in different classes might be a better idea? I specifically want to know if there is "high/low/acceptable"(in terms of memory & CPU) overhead to calling Resources continually.
Any suggestions/answers is appreciated. Thank you.
The "R" (resources) file is a static reference to XML defined objects. Creating a reference in XML allows you to reference those objects using objects that extend Context. It uses the Resources class to reference these objects.
If you inspect the source code (http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/content/res/Resources.java#Resources) you will see it is essentially a handler for these XML defined classes. If you have access to Context then there are few steps you can take to improve upon a the short reference path that Context and Resources provide.
You can build your own mechanism for storing and/or referencing this array or you can use the one provided for you by the framework. Most likely you will find that the framework offers acceptable performance in terms of speed, memory allocation, etc. Since Context and Resources are loaded with your Application object, there is little overhead involved in using these tools. You will notice the source code attempts to optimize caching of XML objects, etc. That means the accessing and caching mechanism may not be optimized for some use-cases.
You may have situations where you can beat the effectiveness of the framework, but for most situations it is just fine. If you have a special use-case (like an array of 100,000 elements) then you might be able to optimize better than the framework. Most likely you will find that it is both convenient and effective to store your array as an XML defined object.
Related
I am making Android app, I have to use multidimensional data, either in String [][] or in Xml resource file. Please suggest which one is better from performance perspective and memory used in both cases.
As Jack stated, the operations on a String[][] would probably have better performance than working with an XML file. It would also likely have a smaller memory footprint. Depending on what sort of data you are dealing with, a String[][] might be cumbersome to deal with. If the data is hierarchical, I would go with an XML file for simplicity.
If you thing an XML file is the way to go, take a look at this article on parsing XML in Android. The article claims that an XmlPullParser is "efficient."
You may want to consider using a JSON format as third option :)
If you only care about the performance and memory footprint, String[][] would be better.
But place your data into xml and access them as resource has its advantages.
Following is quoted from Android developer's document.
Using app resources makes it easy to update various characteristics of your app without modifying code and—by providing sets of alternative resources—enables you to optimize your app for a variety of device configurations (such as different languages and screen sizes).
In addition, by zip aligning the resources, the resource can be mapped to memory which makes the speed to access them also very fast.
I'm thinking about using singleton patterns for adapters and helpers in an Android app that I'm building, but I'm not too familiar with Java's garbage collecting and how static attributes (eg static FooBar instance) impact memory usage.
Will it have a big enough impact in Android apps that I should avoid using it?
Depends on what you mean by "impact memory usage". An object isn't larger or smaller just because there is one instance of it enforced by a singleton pattern. In that sense there's no difference.
If it means you definitely have at most one copy of an object in memory instead of several, yes it could help.
Usually what people mean though, is, how long does the singleton live? does it stick around taking up memory when the app is in the background?
A static member is attached to an instance of its Class which is in turn attached to its ClassLoader. So the singleton lives as long as the ClassLoader. It turns out in Android that the app's ClassLoader goes away in onDestroy, not onPause, so a singleton implies you hold on to the memory even when the app is in the background.
As others have said, it depends. The case where it could be bad is if the singleton is holding references to objects that could otherwise be garbage collected. If there are a lot of references in the object, or references to large objects, you could be using memory you don't need. You could work around it by using weak references, but then you have to have code to recreate the objects when needed if they get garbage collected. You could not use the singleton pattern, which would allow things to get garbage collected (at least potentially), but at the expense of creating and throwing away objects. The best solution depends on the details of the object and its usage. One thing to always avoid is holding on to a reference to a UI object, such as a View.
I am not sure about one particular android optimization tip, that suggests to avoid unnecesary object creations. I'm unsure about thet "creation" part. In my application i started to assign several objects (context, resources etc) to activity fields with the intention to avoid calling the same get functions (getBaseContext(), getResources()) multiple times in each lifecycle.
So my question would be, when i assign those objects to activity fields, do i create new objects (and use extra space) or am i making a new reference to already created object?
When calling getBaseContext(), getResouces() you are not creating any new objects. You are obtaining objects that the Android OS has created whenever your application's process is first created.
And in regards to watching how many objects you create, I wouldn't worry about that at all unless you are creating a huge amount of objects (and I mean magnitude orders above 100s). 100s may even be too low.
A good practice would be too always keep your heap size in mind, if it you seeing it growing larger as you build your application, do your best to manage it. You can find out information about your heap size by looking at the DDMS (Dalvik Debug Monitor Server) view in your IDE.
I have a doubt which will be better - using getter, setter methods or direct field access ?
In android site Performance Tips - its given as "Avoid Internal Getters/Setters".
My choice is to use direct field access, but my friends are telling to use getter setter methods in Android. Is that right if so then what is the use of using getter setter methods? How the performance will be improved?
To add to the answer from Ed, what the link you send refers to is to avoid internal getter/setter. Within the same class, using the getter/setter to access a field will cost you for nothing...
Does not mean you should not use getter/setter from other classes. The cost you may pay in performance is worth it in maintainability and code design / structure.
The choice between using getters and setters and allowing for direct field access is not typically one of performance, but instead one of maintainability and encapsulation of data. Typically you will use getters and setters to have tighter control over your data.
Unless you are running in a tight loop that needs to go as fast as the hardware will allow it and the function call is actually proven to be cosnuming a relatively significant amount of CPU time you don't have to worry about the performance.
How to Improve app performance
Performance is most important for user fulfillment
Some technique to improve app performance
1) Avoid Unnecessary variables and package
create only needed variables and import used package remove unused package
2) Create Setter getter to store and access data
3) Replace array to List or any java collection
4) Data reuse
I find myself using the Application class a lot to persist user data. These are application wide resources, though I cheat by storing an integer or two sometimes. Are there any drawbacks of doing this? I could not find any documentation which puts a limit on the amount of data that can be stored here.
Well, the documentation to Application says :
There is normally no need to subclass
Application. In most situation, static
singletons can provide the same
functionality in a more modular way.
Also the stuff you put in there goes to the heap(*), which is size constrained (e.g. to 24 MB). If you want to store more data, you should put it in a database or on file system.
*) Technically Android's Dalvik vm may not have a heap, but other ways to store stuff in main memory.