41,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Unlock the power of multi-core mobile devices to build responsive and reactive Android applications
About This Book
- Construct scalable and performant applications to take advantage of multi-thread asynchronous techniques
- Explore the high-level Android asynchronous constructs available on the Android SDK
- Choose the most appropriate asynchronous technique to implement your next outstanding feature
Who This Book Is For
This book is for Android developers who want to learn how to build multithreaded and reliable Android applications using high-level and advanced asynchronous techniques and concepts. No prior knowledge of concurrent and asynchronous programming is required. This book will also be great for Java experts who are new to Android.
Whether you are a beginner at Android development or a seasoned Android programmer, this book will guide you through the most basic and advanced asynchronous constructs used in Android programming.
What You Will Learn
- Get familiar with the android process model and low-level concurrent constructs delivered by the Android SDK
- Use AsyncTask and loader framework to load data in the background, delivering progress results in the meantime
- Create services that interact with your activity without compromising the UI rendering
- Learn the working of Android concurrency on the Native Layer
- Interact with nearby devices over Bluetooth and WiFi communications channels
- Create and compose tasks with RxJava to execute complex asynchronous work in a predictable way
- Get accustomed to the use of the Android Loader construct to deliver up-to-date results
In Detail
Asynchronous programming has acquired immense importance in Android programming, especially when we want to make use of the number of independent processing units (cores) available on the most recent Android devices. With this guide in your hands you'll be able to bring the power of Asynchronous programming to your own projects, and make your Android apps more powerful than ever before!
To start with, we will discuss the details of the Android Process model and the Java Low Level Concurrent Framework, delivered by Android SDK. We will also guide you through the high-level Android-specific constructs available on the SDK: Handler, AsyncTask, and Loader. Next, we will discuss the creation of IntentServices, Bound Services and External Services, which can run in the background even when the user is not interacting with it. You will also discover AlarmManager and JobScheduler APIs, which are used to schedule and defer work without sacrificing the battery life. In a more advanced phase, you will create background tasks that are able to execute CPU-intensive tasks in a native code-making use of the Android NDK. You will be then guided through the process of interacting with remote services asynchronously using the HTTP protocol or Google GCM Platform. Using the EventBus library, we will also show how to use the Publish-Subscribe software pattern to simplify communication between the different Android application components by decoupling the event producer from event consumer.
Finally, we will introduce RxJava, a popular asynchronous Java framework used to compose work in a concise and reactive way. Asynchronous Android will help you to build well-behaved applications with smooth responsive user interfaces that delight the users with speedy results and data that's always fresh.
Style and approach
This easy-to-follow guide is full of code examples of real-world use cases. Each asynchronous topic is explained sequentially, from the most basic and low-level to the more advanced, using concise and effective language. Some lifecycle flows and concepts feature illustrations to help you understand the complex interactions between Android entities.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 461
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Asynchronous Android Programming Second Edition
Asynchronous Android Programming Second Edition
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: July 2016
Production reference: 1260716
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78588-324-8
www.packtpub.com
Credits
Author
Helder Vasconcelos
Reviewer
Gavin Matthews
Commissioning Editor
Edward Gordon
Acquisition Editor
Indrajit Das
Content Development Editor
Siddhesh Salvi
Technical Editor
Danish Shaikh
Copy Editor
Vibha Shukla
Project Coordinator
Nidhi Joshi
Proofreader
Safis Editing
Indexer
Mariammal Chettiyar
Graphics
Disha Haria
Production Coordinator
Arvindkumar Gupta
Cover Work
Arvindkumar Gupta
About the Author
Helder Vasconcelos is a Portuguese Software Engineer based on Dublin, Ireland, with more than 10 years of experience designing and developing real-time/multithreaded Java and C++ applications for the telecommunications and aviation industries. Apart from his day-to-day job, he occupies his spare time building native Android applications for Bearstouch Software and other third-party companies.
He graduated with a degree in Electronic and Telecommunications Engineering from the University of Aveiro in January 2006. During his career, he has worked as a Software Engineer for companies such as PT Inovação (Portugal), Airtel ATN (Dublin, Ireland) and Axway (Dublin, Ireland). You can find Hélder on LinkedIn at (https://ie.linkedin.com/in/heldervasc/en) or on his website at (http://hvasconcelos.github.io).
I would like to sincerely thanks all technical reviewers, but especially Gavin. I really appreciate your invaluable feedback and commit that shaped the quality of the book. A special thanks to my awesome wife Tania for encourage me when the lack of motivation was killing my productivity. It would not have been possible without your precious support. Thanks also to my parents and family for their awesome effort in my education. Additionally, I would like to thank my friends, colleagues, clients, and teachers for helping me to shape and improve my skills and perspectives during my career.
About the Reviewer
Gavin Matthews is a veteran software engineer specializing in enterprise scale B2B, MFT and EFSS systems.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Preface
Whether you are Android beginner developer or an Android seasoned programmer, this book will explore how to achieve efficient and reliable multithreaded Android applications.
We'll look at best asynchronous constructs and techniques, commonly used by Android Developer community, to execute computation intensive or blocking tasks off the main thread, keeping the UI responsive, telling the user how things are going, making sure we finish what we started, using those powerful multicore processors, and doing it all without wasting the battery.
By using the right asynchronous construct, much of the complexity is abstracted from the developer, making the application source code more readable and maintainable and less error prone.
Using step-by-step guidelines and code examples, you will learn how manage interactions between several threads and avoid concurrency and synchronization problems that might occur when two or more threads access a shared resource to complete a background job, to update the UI or retrieve the latest application data.
At the end of this journey you will know how build well-behaved applications with smooth, responsive user-interfaces that delight users with speedy results and data that's always fresh.
What this book covers
Chapter 1, Asynchronous Programming in Android, gives an overview of the Android process and thread model, and describes some of the challenges and benefits of concurrency in general, before discussing issues specific to Android.
Chapter 2, Performing Work with Looper, Handler and HandlerThread details the fundamental and related topics of Handler, HandlerThread, and Looper, and illustrates how they can be used to schedule tasks on the main thread, and to coordinate and communicate work between cooperating background threads.
Chapter 3, Exploring the AsyncTask, covers the most common concurrent construct of programming in Android. We learn how AsyncTask works, how to use it correctly, and how to avoid the common pitfalls that catch out even experienced developers.
Chapter 4, Exploring the Loader, introduces the Loader framework and tackles the important task of loading data asynchronously to keep the user interface responsive and glitch free.
Chapter 5, Interacting with Services, we explored the very powerful Service Android component, putting it to use to execute long-running background tasks with or without a configurable level of concurrency. This component gives us the means to perform background operations beyond the scope of a single Activity lifecycle and to ensure that our work is completed even if the user leaves the application.
Chapter 6, Scheduling Work with AlarmManager, introduces to us a system API that could be used to defer work or create periodic tasks. The scheduled task could wake up the device to complete the work or alert users to new content.
Chapter 7, Exploring the JobScheduler API, covers a job scheduling system API introduced with Android Lollipop that allows us to start background work when a set of device conditions, such as energy or network, are fulfilled.
Chapter 8, Interacting with the Network, we cover in detail HttpUrlConnection Android HTTP client. With the HttpUrlConnection HTTP client, we will create an asynchronous toolkit that is able to fetch JSON documents, XML or text from a remote server.
Chapter 9, Asynchronous Work on the Native layer, introduces the JNI interface, an Java standard interface that will allow us to execute concurrent tasks on native code (C/C++), interact with the Java code from the native layer or update the UI from the native code.
Chapter 10, Network Interactions with GCM, we will learn how to use the Google GCM to efficiently push and pull efficiently realtime messages from your server and how to schedule work with Google Play Services framework.
Chapter 11, Exploring Bus-based Communications, we will introduce to the reader the publish-subscribe messaging pattern and the Event Bus Library, a publish-subscribe implementation that allow us to deliver asynchronous messages between Android application components.
Chapter 12, Asynchronous Programing with RxJava, we will introduce RxJava, a library used to easily compose asynchronous and event-based tasks on Java by using observable data streams.
What you need for this book
To follow along and experiment with the examples, you will need a development computer with a Java 7 (or 8) SE Development Kit and the Android Software Development Kit Version 9 or above (you will need at least Version 21 to try all of the examples).
You will also need Android Studio IDE. The examples have been developed using Google's new Android Studio IDE and use its integrated build system, Gradle.
While you can run the examples using the emulator provided by the Android SDK, it is a poor substitute for the real thing. A physical Android device is a much faster and more pleasurable way to develop and test Android applications!
Many of the examples will work on a device running any version of Android since 2.3, GingerBread. Some examples demonstrate newer APIs and as a result, require a more recent Android version—up to Android 5, Lollipop.
Who this book is for
This book is for Android Developers who want to learn how to build multithreaded and reliable Android applications using high level and advanced asynchronous techniques and concepts.
They want to learn this technology because they want learn how to build efficient applications that are able to interact orderly with internal/external services and frameworks using Android standard constructs and APIs.
No prior knowledge of of concurrent and asynchronous programming is required. This book is also targeted towards Java experts who are new to Android.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "We can include other contexts through the use of the include directive."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Clicking the Next button moves you to the next screen."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
The code bundle for the book is also hosted on GitHub at https://github.com/PacktPublishing/Asynchronous-Android-Programming. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Asynchronous Programming in Android
Asynchronous programming has become an important topic of discussion in the past few years, especially when using the concurrent processing capabilities available on the most recent mobile hardware.
In recent years, the number of independent processing units (cores) available on the CPU have increased, so to benefit from this new processing power, a new programming model called asynchronous programming has appeared to orchestrate the work between the several independent hardware-processing units available on the device. Asynchronous programming comes to the rescue to solve the problems that could arise from this new processing paradigm.
Android applications, since they mostly run on devices with multiple units of processing, should take advantage of asynchronous programming to scale and improve the application performance when blocking operations, and when CPU-intensive tasks are required.
Android is an open source operating system (OS) based on Linux kernel that was devised in 2003 by Andy Rubin, Nick Sears, Chris White, and Rick Miner, and then acquired by Google in July, 2005.
The Android OS, actually maintained by Google and the Open Handset Alliance, was created to provide an open mobile-device platform for devices with limited resources of computation, memory, and energy.
The platform has been incorporating advanced mobile devices standards, such as NFC and Bluetooth LE, and its scope has grown from a pure smartphone platform to a broader software platform for smart watches, TVs, tablets, and consoles.
The maintainers have been regularly updating the platform with great features and some improvements over minor and major releases since the first release.
The following diagram displays the Android versions over time:
Android software stack
Android software stack (C libraries and Java frameworks), orchestrated by the Android runtime (Dalvik VM, and most recently, ART) was created around the Linux kernel to provide highly interactive user experiences over a well-proven group of technologies.
In each new OS version, a well-defined application interface (API) is provided to the developer in order to create applications around the new features and standards introduced with the release.
The Android application compiled code (bytecode), typically a Java compiled code, runs on a virtual machine based on Dalvik or ART.
Dalvik runtime
The Dalvik VM (DVM) runtime, created by Dan Borstein, was the first runtime for the platform and is a register-based virtual machine that was created to run the Java code efficiently in a constrained runtime with a limited amount of power processing, RAM, and electric power.
Dalvik's creators claim that the DVM is, on an average, around 30% more efficient than the standard Java VM (Oracle). According to Bornstein, it requires 30% less instructions and 35 % less coding units.
Clearly, Google has gone to great lengths to squeeze every drop of performance out of each mobile device to help developers build responsive applications.
The virtual machine, which runs the Java code compiled and transformed to the dex format over the dx tool, runs on a Linux process with its own memory space and file descriptors. It also manages its own group of threads.
In more advanced architectures, an Android application might run a service in a separate process and communicate over the IPC mechanism, but most of the time, it runs on a single self-contained process.
The dex file and application resources are packed in an Android application package (APK) by the AAPT and installed over Google Play in the end user devices.
Note
The application store distribution model has become extremely popular on the mobile platforms since the launch of the Apple iPhone in 2007.
Since Android 2.2 the DVM comes with a trace-based Just-In-Time (JIT) compilation feature that actively optimizes every time the application runs some short segments of frequently used bytecode called traces.
The generated machine code provides significant performance improvements in the application execution and on the time spent on some intensive CPU tasks, and thereafter, decreases the battery power used.
ART runtime
The ART runtime is a new version of the DVM and was introduced to improve the runtime performance and memory consumption. The new runtime was introduced in Android 4.4 KitKat as an experimental runtime, and since the Android 5.0 Lollipop, it has become the main Android runtime.
This new runtime, making use of the ahead-of-time (AOT) compilation, brings new app-performance optimizations on startup time and application execution. The AOT, as opposed to DVM JIT (Just in Time), compiles the dex files during the installation time using the device dex2oat tool. The compiled code generated from the dex2oat tool generates system-dependent code for the target device and removes the delay introduced by the JIT compilation during each application execution.
The AOT compiler also reduces the number of processor cycles used by the application as it removes the time spent by the JIT compiler to convert the code into machine code, and then uses less battery power to run the application.
One of the drawbacks of the AOT compilation is the larger memory footprint in comparison with the JIT used by DVM.
With the new runtime, some improvements were also introduced in the memory allocation and on Garbage Collection (GC), resulting in a more responsive UI and better application experience.
Memory sharing and Zygote
Basically, the platform runs an instance of DVM/ART for each application, but large optimization of the platform is brought about by the way a new DVM instance is created and managed.
A special process called the Zygote (first life cell in an animal's reproduction)—the process that all the Android applications are based on—is launched when an Android device initially boots.
The Zygote starts up a virtual machine, preloads the core libraries, and initializes various shared structures. It then waits for instructions by listening on a socket.
When a new Android application is launched, the Zygote receives a command to create a virtual machine to run the application on. It does this by forking its pre-warmed VM process and creating a new child process that shares some memory portions with the parent, using a technique called copy-on-write (COW).
The COW technique, available on most Unix systems, only allocates new memory on the child process when the process tries to change the memory cloned from the parent process.
This technique has some fantastic benefits, as listed in the following:
Android process model
Android is a multiuser, multitasking system that can run multiple applications in parallel, where all the applications attempt to acquire CPU time to execute its job.
Each application runs independently on an isolated Linux process cloned from the Zygote process, and by default, all the Android components run within the same process with the same name as the application package specified in Android Application Manifest (AAM).
The Linux kernel will fairly allocate small amounts of CPU time for application execution called CPU time slices. This time-slicing approach means that even a single-processor device can appear to be actively working in more than one application at the same time, when in fact, each application is taking very short turns on the CPU.
Process ranks
The Android operating system tries to maintain the application running for as long as possible, but when the available memory is low, it will try to free resources in the system by killing the processes with lower importance first.
This is when process ranking comes into the picture; the Android processes are ranked in the next five categories from the higher priority to the lower priorities:
When the system reaches a point that it needs to release resources, the processes available to be killed will be sorted, taking into account the process rank, last used processes, and components running.
Process sandboxing
The Android application always runs under a unique Linux user ID (UID) assigned to the application during the application installation so that the process runs on a sandboxed environment, which by default, isolates your data and code execution from other apps.
In some cases, a user could explicitly be required to share the UID with another application to have access to their data:
The preceding table that results from running the adb shell ps command in the computer with Android SDK Table is a list of Android running processes.
The first column shows the user identifier (UID) assigned at the time of installation, the second column is the process ID (PID), the third column shows the parent process ID (PPID) that for Android applications is the Zygote process, and the last column shows the application package.
From this list, we can assure that the WhatsApp application is running under the user ID u0_a221 with the process ID 5993 and the parent process is the Zygote process with the PID 319.
Android thread model
Within an Android process, there may be many threads of execution. Each thread is a separate sequential flow of control within the overall program—it executes its instructions in order, one after the other, and they also share allocated slices of CPU time managed by the operating system task scheduler.
While the application process is started by the system and prevented from directly interfering with data in the memory address space of other processes, the threads may be started by an application code and can communicate and share data with other threads within the same process. Apart from the shared data that all the threads share in the same process, a thread can use its own memory cache to store its data in its own memory space.
The main thread
When the application process starts, apart from DVM housekeeping threads, the system creates a thread of execution called main. This thread, as the name explains, plays a crucial role in the application lifetime as it is the thread that interacts with the Android UI components, updating the state and their look on the device screen.
Moreover, by default, all the Android application components (Activity, Service, ContentProvider, and BroadcastsReceiver) are also executed over the main thread line of execution. The following image shows the lists of threads running inside an application process with the main thread at the top of the list with a unique thread ID (TID) assigned by the system:
The main thread, also known as UI Thread, is also the thread where your UI event handling occurs, so to keep your application as responsible as possible, you should:
The following diagram displays the main interactions and components involved in the Looper line of execution thread:
The UI/Main thread, which has a Looper facility attached to it, holds a queue of messages (MessageQueue) with some unit of work to be executed sequentially.
When a message is ready to be processed on the queue, the Looper Thread pops the message from the queue and forwards it synchronously to the target handler specified on the message.
When the target Handler finishes its work with the current message, the Looper thread will be ready to process the next message available on the queue. Hence, if the Handler spent a noticeable amount of time processing the message, it will prevent Looper from processing other pending messages.
For example, when we write the code in an onCreate() method in the Activity class, it will be executed on the main thread. Likewise, when we attach listeners to user-interface components to handle taps and other user-input gestures, the listener callback executes on the main thread.
For apps that do little I/O or processing, such as applications that don't do complex math calculations, don't use the network to implement features, or don't use filesystem resources, this single thread model is fine. However, if we need to perform CPU-intensive calculations, read or write files from permanent storage, or talk to a web service, any further events that arrive while we're doing this work will be blocked until we're finished.
Note
Since the Android 5.0 (Lollipop), a new important thread named RenderThread was introduced to keep the UI animations smooth even when the main thread is occupied doing stuff.
The Application Not Responding (ANR) dialog
As you can imagine, if the main thread is busy with a heavy calculation or reading data from a network socket, it cannot immediately respond to user input such as a tap or swipe.
An application that doesn't respond quickly to user interaction will feel unresponsive—anything more than a couple of hundred milliseconds delay is noticeable. This is such a pernicious problem that the Android platform protects users from applications that do too much on the main thread.
Note
If an app does not respond to user input within five seconds, the user will see the Application Not Responding (ANR) dialog and will be offered the option to quit the application.
The following screenshot shows a typical Android ANR dialog:
Android works hard to synchronize the user interface redraws with the hardware-refresh rate. This means that it aims to redraw at the rate of 60 frames per second—that's just 16.67 ms per frame. If we do work on the main thread that takes anywhere near 16 ms, we risk affecting the frame rate, resulting in jank—stuttering animations, jerky scrolling, and so on.
Ideally, of course, we don't want to drop a single frame. Jank, unresponsiveness, and especially the ANR, offer a very poor user experience, which translates into bad reviews and unpopular applications. A rule to live by when building Android applications is: do not block the main thread!
Note
Android provides a helpful strict mode setting in Developer Options on each device, which will flash on the screen when applications perform long-running operations on the main thread.
Further protection was added to the platform in Honeycomb (API level 11) with the introduction of a new Exception class, NetworkOnMainThreadException, a subclass of RuntimeException that is thrown if the system detects network activity initiated on the main thread.
Maintaining responsiveness
Ideally then, we may want to offload any long-running operations from the main thread so that they can be handled in the background by another thread, and the main thread can continue to process user-interface updates smoothly and respond in a timely fashion to user interactions.
The typical time-consuming tasks that should be handled on a background thread include the following:
For this to be useful, we must be able to coordinate the work and safely pass data between cooperating threads—especially between background threads and the main thread, and it is exactly to solve this problem that asynchronous programming is used.
Let's get started with the synchronous versus asynchronous diagram:
The preceding example graphically shows the main differences between the two models of processing. On the left-hand side, the data download task occurs on the main thread, keeping the thread busy until the download data is finished. So if the user interacts with the UI and generates an event such as a touch event, the application will suffer a lag or will become unresponsive if the download task takes a substantial amount of time to finish.
On the right-hand side, the asynchronous model will hand over the download data task to another background thread, keeping the main thread available to process any event coming from the UI interaction. When the downloaded data is available, the background task could post the result to the main thread if the data handling needs to update any UI state.
When we use an asynchronous model to program our application, the Android OS will also take advantage of additional CPU cores available in the most recent devices to execute multiple background threads at the same time and increase the application's power efficiency.
Note
This simultaneous execution of separate code paths that potentially interact with each other is known as concurrency.
The simultaneous execution of subunits of work in parallel to complete one unit of work is known as parallelism.
Android primary building blocks
A typical Android application is composed of the following four main building blocks:
The Activity, Service, and BroadcastReceiver are activated explicitly or implicitly over an asynchronous message called Intent.
Each of these building blocks have their own life cycle, so they could be exposed to different concurrency issues if an asynchronous architecture is used to offload work from the main thread.
Activity concurrent issues
The Activity building block has a tight connection with a presentation layer because it's the entity that manages the UI view over a defined tree of fragments and views that display information and respond to user interactions.
Android applications are typically composed of one or more subclasses of android.app.Activity. An Activity instance has a very well-defined lifecycle that the system manages through the execution of lifecycle method callbacks, all of which are executed on the main thread.
To keep the application responsive and reactive, and the activity transition smooth, the developer should understand the nature of each Activity lifecycle callback.
The most important callbacks on the Activity lifecycle are as follows:
An Activity instance that is completed should be eligible for garbage collection, but background threads that refer to Activity or part of its view hierarchy can prevent garbage collection and create a memory leak.
Similarly, it is easy to waste CPU cycles (and battery life) by continuing to do background work when the result can never be displayed as Activity is completed.
Finally, the Android platform is free at any time to kill processes that are not the user's current focus. This means that if we have long-running operations to complete, we need some way of letting the system know not to kill our process yet.
All of this complicates the do-not-block–the-main-thread rule as we need to worry about canceling background work in a timely fashion or decoupling it from the Activity lifecycle where appropriate.
Manipulating the user interface
The other Android-specific problem lies not in what you can do with the UI thread, but in what you cannot do.
Note
You cannot manipulate the user interface from any thread other than the main thread.
This is because the user interface toolkit is not thread-safe, that is, accessing it from multiple threads may cause correctness problems. In fact, the user interface toolkit protects itself from potential problems by actively denying access to user interface components from threads other than the one that originally created these components.
If the system detects this, it will instantly notify the application by throwing CalledFromWrongThreadException.
The final challenge then lies in safely synchronizing background threads with the main thread so that the main thread can update the user interface with the results of the background work.
If the developer has access to an Activity instance, the runOnUiThread instance method can be used to update the UI from a background thread.
The method accepts a Runnable object like the one used to create an execution task for a thread:
