android - Infinite in other thread cause high cpu loading. why? - android

high cpu loading screenshot link
Please see the screenshot hyperlink. Does anyone knows what's going on?
I want to do keep detecting and send message through socket in while loop. But it cause my app high cpu loading and getting slower and slower, then stop finally. So, I simply the code like screenshot. The problem is still there. If I can't write the code like screenshot and of course I can reach what I want. Does anyone have any idea?
I monitor by android studio and get 97% runs in "android.os.MessageQueue.nativePollOnce".
Thank you for your help~

"The thread has a while loop to deal with tasks about socket"
ANRs indicates you are doing an excessive amount of work on the primary thread. Without showing your code we cannot be sure what causes it, but since you mentioned a while loop I guess you are either not running on a new thread or blocking the UI thread in some other place.

Related

Calling createCaptureSession in a background thread

When calling createCaptureSession this one takes around 200ms to comeback in my test device.
I thought this call was asynchronous, so it is very strange that it takes so long.
To mitigate the issue I am now calling it from a background thread in order to not block the UI while these 200ms. And for the call I am re-using the same thread (executor) that I am passing in the SessionConfiguration.
So far I've found no side effects. But I would like to know if it is fine to perform such call on a background thread, or I may encounter problems in specific use-cases, device models, android versions.
The problem that can be experienced there may be a problem due to the fact that the android device is single-core or a process that requires performance at that time. However, this is a problem caused by the device and user, not by the developer.
We know that there are no single core Android phones.
Threads do not cause any problems since they are software elements that come into play during this performance load. Only in case of load the processing is done a little later

Why can't UI thread and Render thread run at the same time?

I am a mediocore android developer for years. I like android but there's a big problem; frame drops. Even the most powerful ones can stutter so frequently while IOS devices can run at constant 60fps. I just can't understand why. I want to know it. So first thing i did was watching an I/O presentation about performance. And i didn't really understand one thing. Why can't ui and render thread run at the same time ? Yeah i know the basics like render thread can't know what to render while ui thread is doing it's thing but why can't render thread render the frame before? You can see the video here:
https://youtu.be/9HtTL_RO2wI?t=491
And here's a diagram what am i asking for:
You get the idea. I don't know about low level things about android, can anyone explain this like i'm five.
Your process' main thread is responsible for the rendering of the frames that will be presented to the user, so you should keep the code running there as fast and light as possible. If you have to do some heavy processing or access any IO (network, sdcard, etc) that may impact on the fluidity of the application since the thread may be waiting for a response.
As a good practice you should start that IO access/heavy processing on another thread to run in background and let the system decide the priority to run it, if necessary is recommended to present some feedback to the user like a ProgressBar or something to indicate that something is being processed.
Also, the Render Thread need to know what to render before it does it, so the UI Thread have to process which information the app would like to present to the user.
As #JonGoodwin points out, they both run in parallel, but usually in two cores of the same processor, as nowadays phones have at least two cores. Both threads are run in CPU, where RenderThread sends rendering commands to the GPU. Notice that this is true since API 21 (RenderThread is what enables things like ripple effect).
The problem, though, is what #LucianoFerruzzi points out: usually poor code that does too many things in the UI thread (RenderThread is not accessible, at least not with standard mechanisms).
Also, see the following episode of Android Developers Backstage: Episode 74: Graphics

LibGDX game freezes (because of a mulithreading issue?)

After playing my libgdx-game for some time, it just freezes. the game loop is not being executed anymore and it does not react to any input; the game can just be killed.
Logcat says this:
The memory graph shows:
(The freeze starts at about 8m30s. Before this time the game is running normally.)
The question: What is happing here? What do I have to do to avoid this game crash?
Could you post more logcat? It's hard do gather any information as to what is causing the problem just by looking at it saying it's suspending all threads.
This usually happens when you run out of memory. Do you have peices of code which load stuff into memory? You may want to take a look at that. Just a possibility, but maybe you are running out of memory. I know what the memory graph shows, but I had a similar problem and I fixed it by optimizing some asset loading.
(you may want to use asset manager to handle memory optimization)
https://github.com/libgdx/libgdx/wiki/Managing-your-assets
If that is not the case, please post some code. (or more logcat)

Debugging Threads in Android - How can I see in real time number of threads in queue etc

I'm loading a bunch of images using AsyncTasks, creating bitmaps. Lots of recycling views going on etc. Without going into the gory details, I would like to know if there is any way I can get some realtime stats on threads that might be helpful. In particular what I am noticing is that the doInBackground runs really fast once it gets kicked off, but it seems they it takes a while for these tasks to run. So I was wondering how I can know how many threads are running at a given time. I have seen the dreaded 128 limit on thread exception with 10 in queue, but thats once there is an overload, I would like to be able to watch this as the program is running. Hopefully this visibility will tell me something. BTW, I did try bumping of the thread priority within the doInBackground() but again its really not that it is not fast once it runs, its that it does not get scheduled to run fast. I'm on Android Studio, what kind of tools are available?
When debugging and stopped on a breakpoint you can scroll through all the launched threads and their current execution points (the spinner on the left of the debug tab).
Knowing where your threads are started you can launch method profiling on this method and see how your threads are performing (a "timer" button on the left of the android tab).

UI thread is getting stuck on 2.3 devices

I have a pretty big app that I am working on. Sometimes when I start it on 2.3 devices, the UI thread gets somehow stuck. I don't think it is one of my own tasks, but I just cannot figure out what it is. Is there any way that I can figure out what exact task is currently running in the UI Thread?
More info:
I'm running a Runnable on a Handler that uses the main Looper at some point, but run() never gets executed in those cases. I also get an ANR when I touch the screen then. I assume it must be related to the memory in some way because when I remove one of the background images, it feels like it gets stuck less. I do not get an OOM exception though.
Edit
I enabled logging for the main Looper. The last task that gets dispatched has what=1004. This is definitely not from me.
Looper: >>>>> Dispatching to Handler{406cbec0} null: 1004
Sorry for posting as answer (Not enough points for comment) but I believe naming your AsyncTasks and Threads and then using DDMS or any other Android profiling tool could possibly help solve your problem.
By figuring out the most performance/time consuming methods and threads, or possibly something that is overloading the memory (Examine the heap using DDMS).
Take a look at the following links:
http://developer.android.com/tools/debugging/ddms.html
http://developer.android.com/tools/debugging/debugging-tracing.html
Sorry if this wasn't any help.

Categories

Resources