I'm using DDMS to monitor threads in my app, and I see that my app has a bunch of native threads as shown in follow picture. And time to time, the number of native threads increased as user interact with my app, which cause my app sometime does not serve as I expect. Is there anyway to kill these native threads?
There is no such thing as a "native thread" on Android, although some people might use that to refer to threads that are not attached to the VM (which would also make them invisible to DDMS). The threads happen to be executing (or waiting) in native code at the time you did a thread dump, but may spend most of their time executing bytecode. (A list of Dalvik thread states is available here.)
The names of the threads suggests that they were created without being given an explicit name. The one thread with a name, NsdManager probably exists because you're using NsdManager, which "responses to requests from an application are on listener callbacks on a seperate thread" [sic].
It's possible that you can glean some useful information from a stack trace. In DDMS, double-click the thread to get a backtrace. On a rooted device, you can kill -3 <pid> to get a full dump, including native stack frames.
Killing arbitrary threads is not allowed, as they might be holding locks or other resources. If you can determine what is starting them, and that they are unnecessary, you can prevent them from being started in the first place.
Related
My application uses background thread to initialize some of the stuff required by main thread to load the hero activity. It has bunch of locks for synchronization. I am looking for a quick way to plot possible stack traces where main thread was waiting for lock held by background thread during app startup. I checked Thread Status Monitor. How do I debug this? What's causing it? but this is talking about point to time thread state where as I am looking for all such events that occurred during startup without knowing where those occured.
I do see that this information can be found by manually inspecting startup android profile trace and looking at various thread stacks to find these occurrences, but there is lot of data to go through. It would be great if the tool can just show me # of times main thread waited for lock held by other threads, total amount of time spent and places where it held those locks.
Q1) Do we know whether Android profiler can show this? I checked https://developer.android.com/studio/profile/cpu-profiler but couldn't find it.
Q2) If not, is there any other tool that can parse profiler exported trace and print this info?
Q3) If not, do you have any pointers on how to read exported trace file. It seems to be binary. I am going through https://github.com/JetBrains/android to figure it out. It seems to be using perfetto now, but I haven't been able to write any utility to read that data yet.
Update: I discovered that CPU profiling/Systrace option shows that my main thread does remain idle or waits for some resources, however it doesn't have information around what does it wait for or what methods run after it was idle for some time. Any pointers to how to marry java method traces and sys trace view?
Perfetto is able to show this information. Look for "Lock Contention" messages on the timeline for a given thread. It also prints the data which thread has obtained that lock.
What is the difference between all the above?
I found various posts which were helpful but also quite confusing. According to my understanding in short this is what I came upto:
Threads are tasks that share same resources
Processes are tasks which have independent rersources. A process can
have multiple threads.
Tasks are the instructions being executed
Now this is where I get confused. How is an activity related to all
these three in android. Activity can have multiple tasks so it must be something like a process. But then what is the difference between activity and process. Moreover I read somewhere that tasks are stack of activities. It got me all confused. Ive also read that all activities run on UI thread which just make the distinction a little more confusing.
You should differentiate between Processes & Threads vs. Activities vs. Task. They aren't even really in the same category.
Let's start with the simplest one, Task's. Assuming you are not talking abouy any actual class, i.e. TimerTask, the basic concept of a Task is the following.
When a user starts your app for the first time, a new Tasks is created. You can see this by pressing the "OverviewButton", represented by a Square for the software buttons. (on Android 5.0 an higher)
A Task will not get disposed of, unless the User actually removes(swipes left/right) it from the Overview screen.
So a Task is really just a high-level abstraction for the user.
Like you alluded to, a Tasks has an Activity backstack, which is just a normal stack that is used to keep track of the "history" for the user. For example, your App is launched, your MainActivity will be at the bottom of the stack, the User enters some values and then goes on to a new Activity. Now this new Activity is above the previous one, and the user can press the "back button" at -hopefully- any time to get back to the previous activity.
Now for Processes &Thread's, a Processes under Android is very similar to a linux process, your app will usually only be working within one single process. A process gets assigned a certain part of the memory by the OS, if you're familiar with languages like C, attempting to acess memory that does not belong to your process wil cause a
"segmentation fault".
Like you said, a process may have any number of Threads, assuming the OS can manage the required Overhead.
A process will at least have one Thread, under android this is called Main-Thread or UI-Thread. Threads, very basically, allow you to do some work in parallel. You will most likely need to make use of them, for example when performing network operations.
Now for Activities, they have no direct relationship to multithreading. The currently "active Activity" is the one that is run on the UI-Thread. So all of its callbacks will be run on the UI-Thread, unless specifically documented not to.
An Activity is an abstraction used by the android framework, it exists at a fundamentally different level than a Processes & Thread's. You can call a method defined in a Activity, from any Thread you want.
A really nice question, from my little experience with android development, I'd like to contribute. Let's start from..
Processes
Ever opened task manager on windows to see open apps? Those are processes. On android, when an app is launched, a new process is opened and allocation of memory etc is given.
The activity classes,imports and threads all make a process in the Android system. sometimes you see an error message when an app crashes "unfortunately com.android.bakerapp has stopped."
This means an error causes the whole process of threads, imports, activities to close. So basically processes are parts of an app or an app in general that's running.
Activity
An activity is the heart and soul of all android apps, all Threads, preferences, views and layouts are opened by android activity class. It is the container object that holds views, passes information around and runs threads too. Activities communicate with each other through intents, objects in the class extends and methods.
Activity is the piece of code that creates and communicates UI and everything a user sees and uses. It is used to create threads. Which is discussed below.
Threads
This one is easy, a thread is basically a process to get something done, it lives and dies after its work. Imagine you have an activity with a view of picture on the screen and you want to automatically set your apps theme color to the most common color on the picture using a library.
The best method to do this without the user knowing and also confusing the main thread responsible for loading the picture into a view from a website is to open a thread using an Asynchronous task (something that runs in background) is an example of a thread.
So a thread is basically a life cycle of a task to be done, it can be continuous (Main activity views and list views) or short (Find a dominant color in a picture) or fun and multitasking (downloading a picture from a group chat while at thesame time chatting with your girlfriend on WhatsApp).
Threads are the most essential part of all activities and processes and can send,receive and process data.
Activities cannot work without threads because the setContentview and UI itself is just another thread, you can have multiple threads in one activity.
Happy coding!
https://developer.android.com/guide/components/processes-and-threads.html
I know this is old, but you can also say that a thread is the smallest unit of execution of code. Threads are scheduled to run on the CPU. A process can have one or more threads.
Are you able to use the Android Trace class (http://developer.android.com/reference/android/os/Trace.html) from multiple threads and have it log time doing operations on each of those threads appropriately?
In particular, I have 2 threads that are each doing things and I'd like to visualize what each thread is doing at a given point in time using systrace. The docs for Trace only say that you should call #endSection from the same thread that called #beginSection, but it doesn't say whether multiple threads can be making their own calls to beginSection and endSection at the same time. Does anyone know if this is safe?
It's safe. It writes a marker to the systrace device, which is shared across multiple processes and threads.
I was reading a article in Android developer blog Process and Threads which talks about creating new process for specific component of Application. But I failed to understand when will creating a new process in my application becomes a absolute need. Could you please help me understand following doubts I have in this regard.
When as a developer I should feel I need to have a separate process for a Android component/s?
Does introducing a new process has any side effect on application's overall performance?
Any other info is greatly appreciated.
Thanks,
SKU
Having a separate process can be useful if there are components of your application that do not necessarily need to both be running to be useful to the user, and the background task is critical to application "correctness" (either now or in the future). The classic example of this is an app that has a service where the service saves or uploads some data that is critical to your application (critical meaning the only way to get the data back is to have the user re-enter it!). The service might be responsible for doing something like uploading or saving data, while the activity is just the interface for the user. So developers should decouple these two components to prevent problems that may arise from my next point..
Android was designed to run in a resource (especially memory) constrained environment, so processes deemed unimportant are killed periodically to open up memory for important ones by the "low memory killer" (LMK) (if you Google this you'll get tons of information on the topic). Things like foreground processes are understandably given a higher priority since they're currently in use, but they're sometimes killed off as well for reasons like consuming too much memory. Now, imagine you need to save off some data to a database after the user does something in the app and you use a service to do so to ensure that it is done even if the user navigates away from the app. Unless you create the service in its own process the process containing both the activity and the service is likely to be killed since the process belongs to a non-foreground activity.
However it is not always necessary to place the service in its own process, oftentimes simply giving the service its own thread will suffice; it's very application specific. I would only place a service in its own process if it took longer than maybe a few seconds (long enough for the user to navigate away from my application and for the LMK to step in) to perform some task in the background and that task related to the "correctness" of my application (I.E. saving data for later). For something like caching, stick to threads, since if the process gets prematurely killed you can just recreate that data later.
Another reason to have a separate process is if you're running a global service (a service that can be used by applications other than your own) that maybe you provide an interface with via an Activity for configuration.
As for the performance question, there will definitely be a performance hit for something like this. Interprocess communication is not cheap, so you should really only use a separate process if you fit into a specific use case, like the ones mentioned above. Also, there's a certain amount of memory overhead for maintaining a process, so that's another performance hit.
1.)You need to do something on seperate process or thread when you don't want your app to behave slowly. As by introducing threads you force your app not to run on UI thread. Thus making your app responsive to other events. For Example : you can use threads when you have to fetch some data from web service so that it happens in background and doesn't effect your app.
2.)Threads should not be used..We should use AsyncTask or loaders rather in android.
1.) In android 4.0 (and possibly 3.0, not sure though) The device does not let you use the HTTP Agent in the main thread, for this slows the UI..
This is when threads come in handy.
Also with the use of functions that need alot of cpu, if these are run in the UI thread, the UI will lag and not respond until the function finishes.
2.) as stated at 1, it will actually improve the visual performance of your app ;)
What are all the possible thread states during execution for native (C/C++) threads on an Android device? Are they the same as the Java Thread States? Are they Linux threads? POSIX threads?
Not required, but bonus points for providing examples of what can cause a thread to enter each state.
Edit: As requested, here's the motivation:
I'm designing the interface for a sampling profiler that works with native C/C++ code on Android. The profiler reports will show thread states over time. I need to know what all the states are in order to a) know how many distinct states I will need to possibly visually differentiate, and b) design a color scheme that visually differentiates and groups the desirable states versus the undesirable states.
I've been told that native threads on Android are just lightweight processes. This agrees with what I've found for Linux in general. Quoting this wiki page:
A process (which includes a thread) on a Linux machine can be in any of the following states:
TASK_RUNNING - The process is either executing on a CPU or waiting to be executed.
TASK_INTERRUPTIBLE - The process is suspended (sleeping) until some condition becomes true. Raising a hardware interrupt, releasing a system resource the process is waiting for, or delivering a signal are examples of conditions that might wake up the process (put its state back to TASK_RUNNING). Typically blocking IO calls (disk/network) will result in the task being marked as TASK_INTERRUPTIBLE. As soon as the data it is waiting on is ready to be read an interrupt is raised by the device and the interrupt handler changes the state of the task to TASK_INTERRUPTIBLE. Also processes in idle mode (ie not performing any task) should be in this state.
TASK_UNINTERRUPTIBLE - Like TASK_INTERRUPTIBLE, except that delivering a signal to the sleeping process leaves its state unchanged. This process state is seldom used. It is valuable, however, under certain specific conditions in which a process must wait until a given event occurs without being interrupted. Ideally not too many tasks will be in this state.
For instance, this state may be used when a process opens a device file and the corresponding device driver starts probing for a corresponding hardware device. The device driver must not be interrupted until the probing is complete, or the hardware device could be left in an unpredictable state.
Atomic write operations may require a task to be marked as UNINTERRUPTIBLE
NFS access sometimes results in access processes being marked as UNINTERRUPTIBLE
reads/writes from/to disk can be marked thus for a fraction of a second
I/O following a page fault marks a process UNINTERRUPTIBLE
I/O to the same disk that is being accessed for page faults can result in a process marked as UNINTERRUPTIBLE
Programmers may mark a task as UNINTERRUPTIBLE instead of using INTERRUPTIBLE
TASK_STOPPED - Process execution has been stopped; the process enters this state after receiving a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal.
TASK_TRACED - Process execution has been stopped by a debugger.
EXIT_ZOMBIE - Process execution is terminated, but the parent process has not yet issued a wait4() or waitpid() system call. The OS will not clear zombie processes until the parent issues a wait()-like call.
EXIT_DEAD - The final state: the process is being removed by the system because the parent process has just issued a wait4() or waitpid() system call for it. Changing its state from EXIT_ZOMBIE to EXIT_DEAD avoids race conditions due to other threads of execution that execute wait()-like calls on the same process.
Edit: And yet the Dalvik VM Debug Monitor provides different states. From its documentation:
"thread state" must be one of:
1 - running (now executing or ready to do so)
2 - sleeping (in Thread.sleep())
3 - monitor (blocked on a monitor lock)
4 - waiting (in Object.wait())
5 - initializing
6 - starting
7 - native (executing native code)
8 - vmwait (waiting on a VM resource)
"suspended" [a separate flag in the data structure] will be 0 if the thread is running, 1 if not.
If you design a system app that has to work with threads in even more advanced way than usual app, I'd first start by examining what API is available on Android to access threads.
The answer is pthread = POSIX threads, with pthread.h header file, implemented in Bionic C library. So you have starting point for knowing what you can achieve.
Another thing is that Android doesn't implement full pthread interface, only subset needed for Android to run.
More on threads + Bionic here, and how they interact with Java and VM is described here. Also I feel that thread is actually a process, as my code uses setpriority(PRIO_PROCESS, gettid(), pr); to set new thread's priority - I don't recall where I got this info, but this works.
I assume that thread may be in running, finished or blocked (e.g. waiting for mutex) state, but that's my a bit limited knowledge since I never needed other thread state.
Now question is if your app can actually retrieve these states using available API in NDK, and if there're more states, if your users would be really interested to know.
Anyway, you may start by displaying possibly incomplete states of threads, and if your users really care, you'd learn about another states from users' feedback and requests.
Google:
Thread.State BLOCKED The thread is blocked and waiting for a lock.
Thread.State NEW The thread has been created, but has never been started.
Thread.State RUNNABLE The thread may be run.
Thread.State TERMINATED The thread has been terminated.
Thread.State TIMED_WAITING The thread is waiting for a specified amount of time.
Thread.State WAITING The thread is waiting.
These states are not very well explained - I don't see the difference between BLOCKED and WAITING, for example.
Interestingly, there is no 'RUNNING' state - do these devices ever do anything?