I'm using Android Room and combination of LiveData in my app successfully, but I notice it has a significant delay between query and presenting the data to the UI. It is not the end of the world, not unsustainable at all, but when opening other messaging Apps (like WhatsApp) the difference is monumental. When I open such an app the conversations and messages are already available, there isn't even time to play the fade in default animation that is typically available in RecyclerView lists.
On the other hand in my app I can clearly see the delay the data takes until it is presented to the UI.
I understand that attaching the viewmodel to a fragment means that same viewmodel is reconstructed every time the associated fragment is rebuilt, so in theory attaching that viewmodel to the activity's would mean that data would survive even longer in memory, thus saving loading times when rebuilding the fragment, but the very first time it loads it still will show that significant delay, so this isn't an ideal solution nor do I know if this would be an ill advised modification (attach the fragment's viewmodel to the activity lifecycle instead of fragment's).
Are there any ways that I can improve this? Is perhaps WhatsApp using a completely different SQLite library that is marginally faster than Room so I will never be able to achieve this performance with Room?
I think, you have to investigate the issue before try to fix, possible bottle necks:
slow database queries
reasons:
huge amount of data
not optimized queries
middleware converts (if you use it)
Just calculate a middle time for 5-10 calls.
slow UI drawing
check your RecyclerView or other UI.
Use AndroidStudio profiler to find out potential slow code.
I am new to Android SDK/API environment. It's the first I am trying to draw a plot/chart. I tried running different kinds of sample codes on the emulator using 3 different free libraries, nothing is showing on the layout screen. The logcat is repeating the following message:
W/Trace(1378): Unexpected value from nativeGetEnabledTags: 0
I/Choreographer(1378): Skipped 55 frames! The application may be doing too much work on its main thread.
The problem didn't persist and the chart worked when I ran a sample code pertaining to an evaluation copy of a licensed library.
taken from : Android UI : Fixing skipped frames
Anyone who begins developing android application sees this message on
logcat “Choreographer(abc): Skipped xx frames! The application may be
doing too much work on its main thread.” So what does it actually
means, why should you be concerned and how to solve it.
What this means is that your code is taking long to process and frames
are being skipped because of it, It maybe because of some heavy
processing that you are doing at the heart of your application or DB
access or any other thing which causes the thread to stop for a while.
Here is a more detailed explanation:
Choreographer lets apps to connect themselves to the vsync, and
properly time things to improve performance.
Android view animations internally uses Choreographer for the same
purpose: to properly time the animations and possibly improve
performance.
Since Choreographer is told about every vsync events, I can tell if
one of the Runnables passed along by the Choreographer.post* apis
doesnt finish in one frame’s time, causing frames to be skipped.
In my understanding Choreographer can only detect the frame skipping.
It has no way of telling why this happens.
The message “The application may be doing too much work on its main
thread.” could be misleading.
source :
Meaning of Choreographer messages in Logcat
Why you should be concerned
When this message pops up on android
emulator and the number of frames skipped are fairly small (<100) then
you can take a safe bet of the emulator being slow – which happens
almost all the times. But if the number of frames skipped and large
and in the order of 300+ then there can be some serious trouble with
your code. Android devices come in a vast array of hardware unlike ios
and windows devices. The RAM and CPU varies and if you want a
reasonable performance and user experience on all the devices then you
need to fix this thing. When frames are skipped the UI is slow and
laggy, which is not a desirable user experience.
How to fix it
Fixing this requires identifying nodes where there is or
possibly can happen long duration of processing. The best way is to do
all the processing no matter how small or big in a thread separate
from main UI thread. So be it accessing data form SQLite Database or
doing some hardcore maths or simply sorting an array – Do it in a
different thread
Now there is a catch here, You will create a new Thread for doing
these operations and when you run your application, it will crash
saying “Only the original thread that created a view hierarchy can
touch its views“. You need to know this fact that UI in android can be
changed by the main thread or the UI thread only. Any other thread
which attempts to do so, fails and crashes with this error. What you
need to do is create a new Runnable inside runOnUiThread and inside
this runnable you should do all the operations involving the UI. Find
an example here.
So we have Thread and Runnable for processing data out of main Thread,
what else? There is AsyncTask in android which enables doing long time
processes on the UI thread. This is the most useful when you
applications are data driven or web api driven or use complex UI’s
like those build using Canvas. The power of AsyncTask is that is
allows doing things in background and once you are done doing the
processing, you can simply do the required actions on UI without
causing any lagging effect. This is possible because the AsyncTask
derives itself from Activity’s UI thread – all the operations you do
on UI via AsyncTask are done is a different thread from the main UI
thread, No hindrance to user interaction.
So this is what you need to know for making smooth android
applications and as far I know every beginner gets this message on his
console.
As others answered above, "Skipped 55 frames!" means some heavy processing is in your application.
For my case, there is no heavy process in my application. I double and triple checked everything and removed those process I think was a bit heavy.
I removed Fragments, Activities, Libraries until only the skeleton was left. But still the problem did not go away. I decided to check the resources and found some icons and background I use are pretty big as I forgot to check the size of those resources.
So, my suggestion is if none of the above answers help, you may also check your resource files size.
I too had the same problem.
Mine was a case where i was using a background image which was in drawables.That particular image was of approx 130kB and was used during splash screen and home page in my android app.
Solution - I just shifted that particular image to drawables-xxx folder from drawables and was able free a lot of memory occupied in background and the skipping frames were no longer skipping.
Update Use 'nodp' drawable resource folder for storing background drawables
files.
Will a density qualified drawable folder or drawable-nodpi take precedence?
Another common cause of delays on UI thread is SharedPreferences access. When you call a PreferenceManager.getSharedPreferences and other similar methods for the first time, the associated .xml file is immediately loaded and parsed in the same thread.
One of good ways to combat this issue is triggering first SharedPreference load from the background thread, started as early as possible (e.g. from onCreate of your Application class). This way the preference object may be already constructed by the time you'd want to use it.
Unfortunately, sometimes reading a preference files is necessary during early phases of startup (e.g. in the initial Activity or even Application itself). In such cases it is still possible to avoid stalling UI by using MessageQueue.IdleHandler. Do everything else you need to perform on the main thread, then install the IdleHandler to execute code once your Activity have been fully drawn. In that Runnable you should be able to access SharedPreferences without delaying too many drawing operations and making Choreographer unhappy.
I had the same problem. Android Emulator worked perfectly on Android < 6.0. When I used emulator Nexus 5 (Android 6.0), the app worked very slow with I/Choreographer: Skipped frames in the logs.
So, I solved this problem by changing in Manifest file hardwareAccelerated option to true like this:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapplication">
<application android:hardwareAccelerated="true">
...
</application>
</manifest>
Update Jan 2022. According to the comment from #M.Ed: Hardware acceleration is enabled by default if you're targeting APIs >= 14.
Try to use the following strategies in order to improve your app performance:
Use multi-threading programming if possible. The performance benefits are huge, even if your smart phone has one core (threads can run in different cores, if the processor has two or more). It's useful to make your app logic separated from the UI. Use Java threads, AsyncTask or IntentService. Check this.
Read and follow the misc performance tips of Android development website. Check here.
I am not an expert, but I got this debug message when I wanted to send data from my android application to a web server. Though I used AsyncTask class and did the data transfer in background, for getting the result data back from server I used get() method of the AsyncTask class which makes the UI synchronous which means that your UI will be waiting for too long. So my advice is to make your app do every network oriented tasks on a separate thread.
I had the same problem. In my case I had 2 nested Relative Layouts. RelativeLayout always has to do two measure passes. If you nest RelativeLayouts, you get an exponential measurement algorithm.
Optimize your images ... Dont use images larger than 100KB ... Image loading takes too much CPU and cause your app hangs .
this usually happens when you are executing huge processes in main thread. it's OK to skip frames less than 200. but if you have more than 200 skipped frames, it can slow down your application UI thread. what you can do is to do these processes in a new thread called worker thread and after that, when you want to access and do something with UI thread(ex: do something with views, findView etc...) you can use handler or runOnUiThread(I like this more) in order to display the processing results.
this absolutely solves the problem. using worker threads are very useful or even must be used when it comes to this cases.
https://stacklearn.ir
I had the same problem. When I ran the code on another computer, it worked fine. On mine, however, it displayed "The application may be doing too much work on its main thread".
I solved my problem by restarting Android studio [File -> Invalidated caches / Restart -> click on "Invalidate and Restart"].
My app had same problem. But it was not doing other than displaying list of cards and text on it. Nothing running in background. But then after some investigation found that the image set for card background was causing this, even though it was small(350kb). Then I converted the image to 9patch images using
http://romannurik.github.io/AndroidAssetStudio/index.html.
This worked for me.
In my case, it was because I had accidentally set a breakpoint on a method. Once I cleared it, the message went away and performance improved a lot.
As I did first preferably use SVG images instead of all other types, If not possible compress all of your PNG and JPG resources using some image processing tools such as Adobe Photoshop or Fotosizer. one of the easiest ways is online image compressing tools like this which helped me to decrease all my image files to almost 50% of their initial size.
This is actually not a problem. This happens when you have the debugger for a long time. Remove the brake point and check again.
I got same issue while developing an app which uses a lot of drawable png files on grid layout. I also tried to optimize my code as far as possible.. but it didn't work out for me.. Then i tried to reduce the size of those png.. and guess its working absolutely fine.. So my suggestion is to reduce size of drawable resources if any..
After doing much R&D on this issue I got the Solution,
In my case I am using Service that will run every 2 second and with the runonUIThread, I was wondering the problem was there but not at all.
The next issue that I found is that I am using large Image in may App and thats the problem.
I removed the Images and set new Images.
Conclusion :- Look into your code is there any raw file that you are using is of big size.
First read the warning. It says more load on main thread. So what you have to do is just run functions with more work in a thread.
Have not resolved yet but will do. For my tiny project with one composable function (button) and logic to check if "com.whatsapp" packages exists on device (emulator) i have the following in the same log while starting simulator:
I/Choreographer: Skipped 34 frames! The application may be doing too much work on its main thread.
For me that was RoundedBackgroundColorSpan ! in textview, I remove it so (burn my brain to find it because It doesn't appear in real smartphones like Pixel 4 Xl or Samsung note 10+ also in emulator but in chip device this slow a view).
This is normal if you are using async/await functionalities in your application.
I am working on an application that Looks similar to the Google Play App (swipe view with gridviews inside the fragments, in addition data in the gridview [image + text] is retrieved from a remote server).
My problem is with background tasks. I can’t decide what to use for retrieval of data from the internet. Mainly I am trying to decide whether to use AsyncTask or manual threading.
Of course it would be easier to implement AsyncTask, but after some research I noticed that many people find it limiting.
In my particular case, I want to download data from the internet as Json Objects, parse them and display the data in the gridview. The gridview would have up to 30 items, each item contains a thumbnail and 3 textviews. In Android documentation, they say that AsyncTask is suitable for short operations (few seconds at most). Would filling up to 30 items be considered as a short operation?
I want the data to be fetched concurrently. Also I want to support Android phones from API 8 and above. I read that for different APIs AsyncTask behaves differently (serially or concurrently)
My question is: Is it appropriate to use AsyncTask for my app? Or do I have to do everything manually? Is ThreadPoolExecutor a 3rd way to do this? Is it easier than manual threading?
Any advice would be appreciated, I can't move forward in the implementation without deciding on this issue.
Thanks in Advance!
My understanding is that the comment about using AsyncTasks only for short operations is aimed more at not expecting the same views to be available when a long operation finishes. For example, if a user leaves the app and comes back or the current activity goes away for some reason. Typical ways around this would be to use a Service and start up a plain old Thread there, then send some message telling the current Activity to refresh when the operation is done.
The download and processing of your data is likely to be the longest operation. So I'd use that as a basis for whether this is short or long. If you don't care about persisting data at all and don't mind restarting downloads if a user leaves and comes back, you can just use an AsyncTask with very little thought.
If you are using a GridView, you should only ever be populating enough views to for just over the number displayed on the screen at one time.
I'd say that AsyncTask is fine in your situation assuming it's a few kilobytes of data and not megabytes or hundreds of kilobytes. Megs of data, I'd say move to a Service with a Thread. Hundreds of k, is a toss up.
Also, take a look into Loaders... if you want to see an alternative that is better for this kind of loading.
When attending DroidCon in London last year, a presentation brought to my attention why using AsyncTasks for loading data from the network is unreliable.
This presentation was about the RoboSpice library.
The site also has a very nice infographic explaining why exactly AsyncTasks are unreliable and what RoboSpice does to amend these problems.
Disclaimer:
I am in no way affiliated with RoboSpice, nor have I ever tried it. I was just impressed and convinced by their presentation that it's a tool worth trying.
Friend, I am working in a project exactly as you need, and to support API 8 and above you should use Asynctask to download anything or you will get a crash for API 15 and above, because it won't even let you run your app without AsyncTask even for short operations.
So as I almost did everything that you need and it is working very well for API 9 above, you should use Asynctask, I´ve implemented SherlockActionbar, EndlessAdapter and ViewPager all with AsyncTask, so go on, if you need more help just ask again later.
Are there any advantages of Loaders over Async task? Also, how to make loaders compatible for phones with Android froyo.
Edit:
The primary problem here is that I'm not using the native DB(SqlLite). Using the DB on development server. Obviously, I can't use CursorLoader any more. AsyncTaskLoader has no examples at all. If any, please do link.
Is it a better idea to load the data required onto the local DB and then query it using CursorLoader?
Yes, Loaders are more advantageous than AsyncTask as they take care of a lot of things that AsyncTask falls short of, miserably.
Screen Orientation changes are difficult in AsyncTask. I used to have such a problem, till I used an Activity Control class, which I used to retain while configuration changed. I can give you some code if you want to know how. The app used to crash, though, when you changed the orientation multiples times even before the entire data loaded. The secret here is not load a lot of data with your first thread and and finish your threading tasks as soon as possible. Even if it happens in the background, Android has a shabby way of dealing with threads. You never know when one of your tasks would be killed.
Even if you use a AsyncTaskLoader, makes sure that you use an Activity manager. This will help you in getting more control over the activites and AsyncTask.
Yes, it is compatible in all the old version of Android. You need to include the support library(Most of the times, this is included by default but its always nice to double check.)
For one, loaders are easier to code (they're almost built-in in Fragments).
Loaders (specifically CursorLoader) also handles your cursor for you (like the deprecated manageQuery).
Check out this link to read on how to use Loaders pre-Honeycomb.
There simpler to implement and take care of a lot of the life cycle management which previously had to be done "by hand" with AsyncTasks. See the answer to this question for further detail.
With regards to using them with Froyo, they're available via the compatibility library.
It seems no one is talking about the disadvantages of loaders! I'm currently working on a system that runs other services in the background.
What I have noticed is that as soon as a screen with a loader is resumed. The cursor used by the loader locks up the DB.
It may not be open to most people but getDatabaseWriter from sqlite is actually a synchronized method and hence the cursor used by the loader is never closed until the loader is reset or terminated thus locking up access to the DB.
I cannot recommend using a loader under these circumstances nor can I advice using a loader when your result set consists of less than 100 items which are static and never seem to change.
Another advantage with loaders is that they handle screen turn event gracefully whereas asynctask can give you trouble.
Biggest diff:
CursorLoader will update your UI's content as soon as its related ContentProvider changes its content(say through a Service), while AsyncTask will only update your UI when you tell it.
Facebook has the most smooth UI in my Android Phone, and I am wondering how can they do that.
While I am writing my demo, ListView with images always seems to be laggy, while facebook's new feed activity behaviors so amazing.
Anyone can tell me whether the Facebook App uses native ListView but with some improvement, or just rewrite the whole view for better performance?
EDIT: I have already used the caching strategy such as using async threads, caching ViewHolder as tag and storing images in memory for acceleration, while I still feel laggy. I do really want to know how did facebook engineers do that, they are really brilliant
Try hooking the device up to adb, open DDMS and press the method profiling button, then start scrolling a bunch for a few seconds. Traceview will open and you see what is using up all the CPU time.
I've never used a ListView before, but if I had to guess maybe they are retrieving the results and then caching them, whereas you're querying for the results everytime and not caching them.