Threading Performance 2

    See,a thread,by default,does three things.It starts.It does some works,and this is that work is done,it terminates.Now,by itself,that's not too useful.Instead,what you want is a thread that sticks around for a while,so you can feed it packets of work to operate on.But to do that,you need a little more scaffolding.

    First,since threads die when they run out of work,you need to have some sort of loop running on the thread to keep it alive.Just make sure to put in an exit condition so you can terminate that loop later.Inaddition,you'll need some sort of queue that the loop can pull blocks of work from to execute on.And,of course,you'll need some other thread that creates work packets and pushes them into the queue for execution.Now if you've ever tried to write the setup yourself,you know gets a little gnarly to get all of that machine reworking incorrectly.Thankfully,though,Android has a set of classes to do all that for you.

    For example,the Looper class will keep the thread alive and pop work off a queue to execute on.And rather than always inserting work at the end of that queue,the Handler class gives you the control to push work at the head,the tail or set a time-based delay that'll keep some work for being processed until that time has passed.And don't forget the units of work in Android are explicitly defined as intents or runables or messages,depending on who's issuing them and who's consuming them.And then the combination of all these things together is called a HandlerThread.

    So let's look at how you can use this in your application.When the user launches your app,Android creates its own Linux process.Alongside with this,the system creates a thread of execution for your application called the Main thread,which,at its core,is just a Handlerthread.

This Main thread handles processing of events from all over your app,for example,callbacks associated with life cycle information or callbacks from input events,or even events that are coming from other applications.And most important is that these callbacks can trigger other work that runs on the thread too,like making a change to the UI will create work packets that allow the UI to be redrawn.Basically,this means that any block of code to your app wants to run has to be pushed into a work queue and then serviced on the Main thread.

    The takeway here is that with so much work happening on the Main thread,it makes a lot of sense to offload longer work to other threads,as not disturb the UI system form its rendering duties.And this is how the entirety of Android's threading model works,lots of packages of work bing passed around between threads and worked on as needed.

    So with all this in mind,some of Android's threading classes make a little bit more sense.See,each threaded class is intended for a specific type of threading work,so picking the right one for your needs is really important.