Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Android High Performance Programming
Android High Performance Programming

Android High Performance Programming: Build fast and efficient Android apps that run as reliably as clockwork in a multi-device world

Arrow left icon
Profile Icon López Mañas Profile Icon Grancini
Arrow right icon
£16.99 per month
Paperback Aug 2016 412 pages 1st Edition
eBook
£7.99 £32.99
Paperback
£41.99
Subscription
Free Trial
Renews at £16.99p/m
Arrow left icon
Profile Icon López Mañas Profile Icon Grancini
Arrow right icon
£16.99 per month
Paperback Aug 2016 412 pages 1st Edition
eBook
£7.99 £32.99
Paperback
£41.99
Subscription
Free Trial
Renews at £16.99p/m
eBook
£7.99 £32.99
Paperback
£41.99
Subscription
Free Trial
Renews at £16.99p/m

What do you get with a Packt Subscription?

Free for first 7 days. £16.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing
Table of content icon View table of contents Preview book icon Preview Book

Android High Performance Programming

Chapter 1. Introduction: Why High Performance?

According to the Cambridge dictionary, one of the acceptations of performance is "How well a person, machine, etc. does a piece of work or an activity." If we put it together with "high" we can define it as the output or efficiency with which a task is being done.

High performance in software refers to the strategies that developers adopt to create pieces of software that can perform a process efficiently. When we are developing mobile software, this affects, but is not limited to, layout development, energy and battery management, security concerns, efficient multithreading, programming patterns, and debugging techniques.

There is a big difference between doing things, and doing things right. In a real world with deadlines, budgets, and managers, software engineers fall very often into acquiring technical debt. A technical debt is "bought " (if we can use that verb) when a system is developed without a complete or proper design, moving problems forward instead of correctly addressing them. This has a snowball effect: at an advanced stage, the technical debt is so high that further development is very costly, and this leads to a dead point or astronomical damage to budgets in organizations.

While deadlines cannot always be avoided, adopting an efficient development process in any software development is vital to delivering good quality at a reasonable cost. It also means that the development skills become more mature in a developer, and instead of achieving tasks that fulfill the requirements, engineers can develop software that is efficient, robust, and that can be further extended in the future (what we called "maintainability").

This book introduces techniques for constructing high-performance software for Android devices.

Why does the performance of an application mean so much to so many?

Regardless of the industry, a decrease in the performance or quality of a software system can mean big losses. Software systems today control our finances and control the machines that take care of our health or our public transportation. There is almost no area in our lives that is not at least partially computerized. Not only losses: in a globalized and competitive world, a company producing low-performance software will soon be devoured by the more efficient and cheaper competition.

For a while, the only metric used in software development was "Is the software correct? Is it doing what it is supposed to be doing?". This made sense at the dawn of the computer systems era, when not every single process was computerized and we had not developed a culture of software engineering or good methods for quality control, team organization, and so on. Now, everybody demands more.

Graphs are an excellent way to display information. Let's analyze the smartphone penetration numbers:

Why does the performance of an application mean so much to so many?

The numbers are clear. In the last quarter of 2008, in almost every region of the world smartphone penetration was under 20%. Nowadays, in 2015, most developed countries present a penetration close to 80%, whereas developing countries are close to 40%. In 2020, it is estimated that developed countries will have a penetration close to 100%, and countries in development over 50%. There are a few countries with more mobile phones than inhabitants!

Mobile users nowadays do not only check their e-mail on a mobile phone. There are many operations that are performed on a mobile phone: the entertainment industry, banking and payment, tourism and traveling, gaming… This leads us to a conclusion: software must be not only correct but also efficient. Failure in software will lead to annoyed customers who might opt to use a different competitor with a better-performing product. In extreme cases, non-performing software can lead our business to lose its revenue—imagine the case of an application to make hotel reservations where you cannot proceed to payment.

Manual testing and automatic testing

One of the first thoughts that naturally arise is that testing plays a central role in increasing and improving application performance. This is partially true, or as we prefer to say: testing is a good complement to a smartly designed application, but not a substitute.

If we concentrate just on testing, there are two main types: manual testing and automatic testing. As in the previous case, both types of testing are mutually inclusive, and one should not be used in detriment to the other. Manual testing involves a real user playing around with an application and some defined use-case scenarios, but also with more free will and the ability to leave the road of predefined tests and explore new paths.

Automatic tests are tests written by developers to ensure consistency of the application throughout the evolution in the life of a system. There are a few different types: unit tests, integration tests, or UI tests, which will be familiar to the reader. Good test coverage provides robustness to the system when new changes are being applied, improving resistance against failures and performance problems. As in the previous case, we do not want to exclude manual tests in favor of automatic tests, or vice versa (at least until machines are able to pass the Turing test!).

ANR and delays in software

ANR stands for Application Not Responding, and is one of the several nightmares of an Android developer. The Android operating system analyzes the status of apps and threads, and when certain conditions are met it triggers an ANR dialog, blocking the user from any interactive experience. The dialog announces that the application stopped responding, and is not responsive anymore. The user can select whether he/she wants to close the application, or keep waiting until the application becomes responsive again (if this ever happens):

ANR and delays in software

What triggers ANRs and how can I avoid them?

Android systems trigger ANRs in two different situations:

  • When there has been no response for an event in five seconds
  • If a BroadcastReceiver is still executing 10 seconds after its execution

This happens mostly when an operation is being executed in the UI Thread. In general, any operation expected to be time- or operation-consuming should be performed in a separate thread, keeping the UI Thread available for the user interaction, and only notifying the UI Thread when the operation has been finished. In Chapter 5, Multithreading, we will show some advanced techniques for multithreading and thread communication. There are also different classes that can be used to perform operations in different threads, each of them with its own advantages and disadvantages. In general, when developing an application, remember: ANR dialog appearance frequency is inversely proportional to user satisfaction.

Android architecture

As with any other development framework, Android defines its own architecture and module. Android is a Linux-based operating system, although the numerous abstract layers provided by the SDK hide the Linux kernel almost completely, and it is really rare that we will be programming directly at the kernel level:

Android architecture

Dalvik Virtual Machine

Each Android application runs in its own process inside a virtual machine called Dalvik. As we have seen, programs are typically written in Java and then compiled to bytecode. From the bytecode (.class files) they are afterwards transformed into DEX format, commonly using a special tool provided by the Android SDK called dx. This DEX format is more optimized and designed to have a smaller memory footprint in comparison with normal Java .class files, since mobile devices lack the computational capabilities of desktops. This is achieved through compression and merging/optimization of the multiple .class files.

Note

It is not completely accurate that the coding has to be strictly done in Java. Android allows using native code in our applications, too. Therefore, existing code that we were using before can be reused here. Also, in the computer vision area, there is a lot of code that has been reused from the OpenCV framework. This is achieved through the Native Development Kit (NDK), which is explored in Chapter 9, Native Coding in Android and Chapter 10, Performance Tips.

The Dalvik Virtual Machine also includes some Java Virtual Machine (JVM) features, such as garbage collection (GC). There has been a lot of criticism through the GC because of its non-generational nature; it's famous for driving developers crazy. However, since Android 2.3, an improved concurrent garbage collector makes some of the development easier.

Each application running on Dalvik has at least a total of 16 MB of available heap memory. This can be a real limitation for some applications, since we will likely need to deal with large amounts of image and audio resources. However, newer devices such as tablets or high-end devices have a higher heap limit to allow the usage of high-resolution graphics. We expect this situation to improve in the near future due to the fast evolution of mobile hardware.

Memory management

Memory is always, by definition, a scarce resource on any software platform. But when it comes to mobile devices, this is an even more constrained resource. Mobile devices often have less physical memory and processor capacity that their bigger peers, and having an efficient memory management is crucial to improving user experience and software stability.

Dalvik Virtual Machine routinely triggers garbage collection in a similar way to Java, but this does not mean that we can ignore memory management completely. One very common error in junior programmers is to create memory leaks. A memory leak happens when an object is stored in memory, but it cannot be accessed anymore by the running code. The size can vary a lot (from an integer to a big bitmap or structure of several megabytes), but in general they affect software smoothness and integrity. We can use automated tools and frameworks to detect memory leaks and also apply some programming techniques to avoid allocating objects unnecessarily (and equally important, to deallocate them when they are no longer needed).

An Android application has a maximal amount of RAM memory that it can manage. It is different for each device (yes, another problem of the system fragmentation), and can be particularly checked by calling the function getMemoryClass() on the ActivityManager. Early devices had a per-app cap of 16 MB. Later devices increased that to 24 MB or 32 MB, and it will not be surprising to see devices up to 48 or 64 MB. There are several factors contributing to this fact, such as screen size. Larger screens generally mean larger resolutions for bitmaps; thus, as they increase, memory requirements will also grow. Some techniques can also bypass this limitation, such as using the NDK or requesting from the system a larger heap. This last is, however, considered to be poor form for an Android app.

When a process starts, it is forked from an existing or root process called Zygote. Zygote starts every time the system boots and loads the resources common to all the apps. By doing this, Android tries to share all the common resources among the applications, avoiding duplicating memory usage for the same frameworks.

Energy consumption

Mobile devices have a limited battery size, and they are not connected to a permanent power supply as with a standard computer. Therefore, an efficient usage of the battery and energy is a vital factor of survival. If you are continuously performing operations that drain the battery or require continuous access to the device hardware it will affect the user experience, and it might lead to rejection of the application.

Good energy management requires an excellent understanding of how the energy is used, and which operations can drain the battery very quickly. There are tools and benchmark frameworks to find out the energy bottlenecks and sections in the software where the energy consumption is higher than expected.

Mobile consumer-electronics devices, especially phones, are powered from batteries that are limited in size, and therefore, capacity. This implies that managing energy well is paramount in such devices. Good energy management requires a good understanding of where and how the energy is used. To this end we present a detailed analysis of the power consumption of a recent mobile phone, the Openmoko Neo Freerunner. We measure not only overall system power, but the exact breakdown of power consumption by the device's main hardware components. We present this power breakdown for micro-benchmarks as well as for a number of realistic usage scenarios. These results are validated by the overall power measurements of two other devices: the HTC Dream and Google Nexus One.

Java language

Android is mostly written in Java. Although a few alternatives have appeared lately (we can come up with Kotlin and Android, which is a fantastic combination, for example), Java will likely remain the language of choice for Android. Its very mature environment, massive support from Google and other companies, and the vibrant developer scene, ensure it goes on leading Android's development.

One factor that did attract developers to the Android ecosystem was precisely this shared usage of an existing language. Java has some particular characteristics and techniques that we need to learn in order to use it effectively.

Native Development Kit or how to develop with native code when needed

Using Native Development Kit (NDK) can mean sometimes the difference between a performing application or an application that just does its job. We will generally use NDK in the following contexts:

  • Use of existing C/C++ libraries: This is an obvious advantage, since you have access to powerful existing software such as OpenCV1, audio encoders, and so on.
  • Performance: For some critical inner loops, the marginal performance advantage of C/C++ over Java, especially before Just-In-Time compilation (JIT) is available in the Android compiler, may be a deciding factor.
  • To do something that the NDK allows that the Java API can't manage: Low-level operations close to the hardware, particularly to impact manufacturer-specific hardware, might only be possible through C/C++.
  • Obfuscation: Compiled code is somehow more difficult to reverse-engineer than Java bytecode. Security by obscurity is, however, not the ideal solution, but it can complement your already existing system.

Three limits in application responsiveness

There are three different thresholds accepted as limits to the user experience in any software system:

  • 0.1 seconds is perceived by the user as instantaneous responsiveness. In such operations, there is no need to display any visual feedback or notification to the user, and this includes most operations in normal scenarios (for example, the lapse between clicking on a button and displaying a dialog, or showing a different activity).
  • 1.0 seconds is the lapse when the user flow gets interrupted. Between 0.1 and 1.0 there is still no need to provide any feedback, but after a second, the user has lost the perception of performing an immediate operation.
  • 10 seconds is the final limit, when the user loses concentration and interest in the application. More than 10 seconds in an operation generally means that the user will lose her/his interest in the system and procrastinate while the operation is being performed. Visual feedback is crucial here; without it, the user will get frustrated and reject our system.

Google suggests keeping all interactions under 100 to 200 ms. That is the threshold beyond which users will perceive slowness in an application. Although this is not always possible (think about downloading a large amount of data, such as media and so on), we will learn techniques to provide the user with the best experience.

Business value of software quality

Developers often need to justify to non-technical peers why some decisions are taken that do not bring immediate value (think about refactoring an old module or developing some test coverage). There is a clear gap between the business and engineer departments that needs to be reconciled.

When we have to discuss with other departments the business value of decisions that have been made for the sake of software quality, I always like to mention the word "money". Making some decisions, in the long run, is equivalent to saving money and providing direct value to the software. They might not generate an immediate output, or a corporeal item (as much as software can be corporeal), but they certainly will come back in the future with some benefits. I can remember a few situations when refactoring a piece of software at the right moment made the difference between having a sustainable artifact that could be extended and having a monolith, as the result of many bad design decisions, that nobody was able to maintain and in the end meant money and financial costs. The following figure reveals the losses and consequences for companies over time due to bad software quality:

Business value of software quality

This graph has been taken from a document by David Chappell, and it explains some examples of when bad software quality incurs financial loss. Losing value from lost business might remind us of when Sony closed the PlayStation network due to a network attack. If the software had been properly designed and protected, the network might have been able to keep operating, but poor design led to the company losing a considerable amount of money. A financial loss due to customer reparations happens every time a company needs to compensate clients for a problem happening as a consequence of a poor software system. The obvious financial loss from lost customers will happen when customers do not want to acquire any more services provided by an infamous company! Financial loss from lawsuits is inevitable in many cases, especially when privacy issues or stolen data are involved (and they can be very expensive!).

Summary

After this chapter, the reader should have a more accurate idea of the different areas we will explore together in this book. We also hope our arguments are convincing enough, and we will work towards developing them further throughout the entire book.

The reader should be able to argue why performance will matter in the context of his/her organization, and should know some of the keywords of efficient Android development. Do not get stressed, this is only the beginning.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Wide coverage of various topics that help in developing optimal applications
  • Explore the concepts of Advanced Native Coding in depth
  • A must-have for professional-standard Android developers for whom performance failures and the sloppy use of resources are simply unacceptable

Description

Performant applications are one of the key drivers of success in the mobile world. Users may abandon an app if it runs slowly. Learning how to build applications that balance speed and performance with functionality and UX can be a challenge; however, it's now more important than ever to get that balance right. Android High Performance will start you thinking about how to wring the most from any hardware your app is installed on, so you can increase your reach and engagement. The book begins by providing an introduction to state–of-the-art Android techniques and the importance of performance in an Android application. Then, we will explain the Android SDK tools regularly used to debug and profile Android applications. We will also learn about some advanced topics such as building layouts, multithreading, networking, and security. Battery life is one of the biggest bottlenecks in applications; and this book will show typical examples of code that exhausts battery life, how to prevent this, and how to measure battery consumption from an application in every kind of situation to ensure your apps don’t drain more than they should. This book explains techniques for building optimized and efficient systems that do not drain the battery, cause memory leaks, or slow down with time.

Who is this book for?

This book is aimed at developers with an advanced knowledge of Android and who want to test their skills and learn new techniques to increase the performance of their applications. We assume they are comfortable working with the entire Android SDK, and have been doing it for a few years. They need to be familiar with frameworks such as NDK to use native code, which is crucial for app performance

What you will learn

  • Create Android applications that squeeze the most from the limited resource capacity of devices
  • Swap code that isn't performing
  • Efficient memory management by identifying problems such as leaks
  • Reap the benefits of multithreaded and asynchronous programming
  • Maximize the security and encryption mechanisms natively provided by Android
  • Perform efficient network operations and techniques to retrieve data from servers
  • Master the NDK to write native code that can perform faster operations

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Aug 29, 2016
Length: 412 pages
Edition : 1st
Language : English
ISBN-13 : 9781785288951
Vendor :
Google
Category :
Languages :
Tools :

What do you get with a Packt Subscription?

Free for first 7 days. £16.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing

Product Details

Publication date : Aug 29, 2016
Length: 412 pages
Edition : 1st
Language : English
ISBN-13 : 9781785288951
Vendor :
Google
Category :
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
£16.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
£169.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just £5 each
Feature tick icon Exclusive print discounts
£234.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just £5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total £ 120.97
Asynchronous Android Programming
£41.99
Android High Performance Programming
£41.99
Android Application Development Cookbook
£36.99
Total £ 120.97 Stars icon
Banner background image

Table of Contents

11 Chapters
1. Introduction: Why High Performance? Chevron down icon Chevron up icon
2. Efficient Debugging Chevron down icon Chevron up icon
3. Building Layouts Chevron down icon Chevron up icon
4. Memory Chevron down icon Chevron up icon
5. Multithreading Chevron down icon Chevron up icon
6. Networking Chevron down icon Chevron up icon
7. Security Chevron down icon Chevron up icon
8. Optimizing Battery Consumption Chevron down icon Chevron up icon
9. Native Coding in Android Chevron down icon Chevron up icon
10. Performance Tips Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is included in a Packt subscription? Chevron down icon Chevron up icon

A subscription provides you with full access to view all Packt and licnesed content online, this includes exclusive access to Early Access titles. Depending on the tier chosen you can also earn credits and discounts to use for owning content

How can I cancel my subscription? Chevron down icon Chevron up icon

To cancel your subscription with us simply go to the account page - found in the top right of the page or at https://subscription.packtpub.com/my-account/subscription - From here you will see the ‘cancel subscription’ button in the grey box with your subscription information in.

What are credits? Chevron down icon Chevron up icon

Credits can be earned from reading 40 section of any title within the payment cycle - a month starting from the day of subscription payment. You also earn a Credit every month if you subscribe to our annual or 18 month plans. Credits can be used to buy books DRM free, the same way that you would pay for a book. Your credits can be found in the subscription homepage - subscription.packtpub.com - clicking on ‘the my’ library dropdown and selecting ‘credits’.

What happens if an Early Access Course is cancelled? Chevron down icon Chevron up icon

Projects are rarely cancelled, but sometimes it's unavoidable. If an Early Access course is cancelled or excessively delayed, you can exchange your purchase for another course. For further details, please contact us here.

Where can I send feedback about an Early Access title? Chevron down icon Chevron up icon

If you have any feedback about the product you're reading, or Early Access in general, then please fill out a contact form here and we'll make sure the feedback gets to the right team. 

Can I download the code files for Early Access titles? Chevron down icon Chevron up icon

We try to ensure that all books in Early Access have code available to use, download, and fork on GitHub. This helps us be more agile in the development of the book, and helps keep the often changing code base of new versions and new technologies as up to date as possible. Unfortunately, however, there will be rare cases when it is not possible for us to have downloadable code samples available until publication.

When we publish the book, the code files will also be available to download from the Packt website.

How accurate is the publication date? Chevron down icon Chevron up icon

The publication date is as accurate as we can be at any point in the project. Unfortunately, delays can happen. Often those delays are out of our control, such as changes to the technology code base or delays in the tech release. We do our best to give you an accurate estimate of the publication date at any given time, and as more chapters are delivered, the more accurate the delivery date will become.

How will I know when new chapters are ready? Chevron down icon Chevron up icon

We'll let you know every time there has been an update to a course that you've bought in Early Access. You'll get an email to let you know there has been a new chapter, or a change to a previous chapter. The new chapters are automatically added to your account, so you can also check back there any time you're ready and download or read them online.

I am a Packt subscriber, do I get Early Access? Chevron down icon Chevron up icon

Yes, all Early Access content is fully available through your subscription. You will need to have a paid for or active trial subscription in order to access all titles.

How is Early Access delivered? Chevron down icon Chevron up icon

Early Access is currently only available as a PDF or through our online reader. As we make changes or add new chapters, the files in your Packt account will be updated so you can download them again or view them online immediately.

How do I buy Early Access content? Chevron down icon Chevron up icon

Early Access is a way of us getting our content to you quicker, but the method of buying the Early Access course is still the same. Just find the course you want to buy, go through the check-out steps, and you’ll get a confirmation email from us with information and a link to the relevant Early Access courses.

What is Early Access? Chevron down icon Chevron up icon

Keeping up to date with the latest technology is difficult; new versions, new frameworks, new techniques. This feature gives you a head-start to our content, as it's being created. With Early Access you'll receive each chapter as it's written, and get regular updates throughout the product's development, as well as the final course as soon as it's ready.We created Early Access as a means of giving you the information you need, as soon as it's available. As we go through the process of developing a course, 99% of it can be ready but we can't publish until that last 1% falls in to place. Early Access helps to unlock the potential of our content early, to help you start your learning when you need it most. You not only get access to every chapter as it's delivered, edited, and updated, but you'll also get the finalized, DRM-free product to download in any format you want when it's published. As a member of Packt, you'll also be eligible for our exclusive offers, including a free course every day, and discounts on new and popular titles.