The onCreate() method is called once during the Activity lifecycle, either when the application starts, or when the Activity has been destroyed and then recreated, for example during a configuration change.

The onStart() method is called whenever the Activity becomes visible to the user, typically after onCreate() or onRestart().

ThreadPool consists of a task queue and a group of worker threads, which allows it to run multiple parallel instances of a task.

Using ThreadPool is more efficient than having multiple operations waiting to run on a single thread, but it also helps you avoid the considerable overhead of creating and destroying a thread every time you require a worker thread.

The most basic approach would be to use a combination of ViewModels and onSaveInstanceState() . So how we do we that?

Basics of ViewModel: A ViewModel is LifeCycle-Aware. In other words, a ViewModel will not be destroyed if its owner is destroyed for a configuration change (e.g. rotation). The new instance of the owner will just re-connected to the existing ViewModel. So if you rotate an Activity three times, you have just created three different Activity instances, but you only have one ViewModel.

So the common practice is to store data in the ViewModel class (since it persists data during configuration changes) and use OnSaveInstanceState to store small amounts of UI data.

For instance, let’s say we have a search screen and the user has entered a query in the Edittext. This results in a list of items being displayed in the RecyclerView. Now if the screen is rotated, the ideal way to prevent resetting of data would be to store the list of search items in the ViewModel and the query text user has entered in the OnSaveInstanceState method of the activity.

Thread should be used to separate long running operations from main thread so that performance is improved. But it can’t be cancelled elegantly and it can’t handle configuration changes of Android. You can’t update UI from Thread.

AsyncTask can be used to handle work items shorter than 5ms in duration. With AsyncTask, you can update UI unlike java Thread. But many long running tasks will choke the performance.

The foreground activity, being the most important among the other states, is only killed or terminated as a last resort, especially if it is already consuming too much memory. When a memory paging state has been reach by a foreground activity, then it is killed so that the user interface can retain its responsiveness to the user.

An AsyncTask is not tied to the life cycle of the Activity that contains it. So, for example, if you start an AsyncTask inside an Activity and the user rotates the device, the Activity will be destroyed (and a new Activity instance will be created) but the AsyncTask will not die but instead goes on living until it completes.

Then, when the AsyncTask does complete, rather than updating the UI of the new Activity, it updates the former instance of the Activity (i.e., the one in which it was created but that is not displayed anymore!). This can lead to an Exception (of the type java.lang.IllegalArgumentException: View not attached to window manager if you use, for instance, findViewById to retrieve a view inside the Activity).

There’s also the potential for this to result in a memory leak since the AsyncTask maintains a reference to the Activty, which prevents the Activity from being garbage collected as long as the AsyncTask remains alive.

For these reasons, using AsyncTasks for long-running background tasks is generally a bad idea . Rather, for long-running background tasks, a different mechanism (such as a service) should be employed.

There are a number of methods, but the ones that tend to have the most impact are:

• Checking for excessive overdraw: install your app on an Android device, and then enable the "Debug GPU Overview" option.
• Flattening your view hierarchy: inspect your view hierarchy using Android Studio’s ‘Hierarchy Viewer’ tool.
• Measuring how long it takes each View to complete the measure, layout, and draw phases. You can also use Hierarchy Viewer to identify any parts of the rendering pipeline that you need to optimize.

Construction arguments for a Fragment are passed via Bundle using the Fragment#setArgument(Bundle) method. The passed-in Bundle can then be retrieved through the Fragment#getArguments() method in the appropriate Fragment lifecycle method.

It is a common mistake to pass in data through a custom constructor. Non-default constructors on a Fragment are not advisable because the Fragment may be destroyed and recreated due to a configuration change (e.g. orientation change). Using #setArguments()/getArguments() ensures that when the Fragment needs to be recreated, the Bundle will be appropriately serialized/deserialized so that construction data is restored.

We can use bundles to pass data to sub-activities. There are HashMaps that take trivial data types. These bundles transport information from one activity to another.

This is still a much-debated topic, but the code used to create an Activity is fundamentally more involved than the code used to create a Fragment. The old Activity has to be destroyed, paused or stopped, and a new Activity has to be created. The developer should acknowledge that the best practice is to only use Activities when you need to swap the entire screen, and use fragments everywhere else. In the following use case you should almost always use a Fragment, rather than an Activity:

• When you’re working with UI components or behavior that you’re going to use across multiple Activities.
• When you’re using one of the navigational methods that are closely linked to fragments, such as swipe views.
• When your users would benefit from seeing two different layouts side-by-side.
• When you have data that needs to persist across Activity restarts (i.e you need to use retained fragments).

These are a few steps that we need to follow while troubleshooting the crashing issue:

• Free up memory space: There is only limited space available on mobile devices for mobile apps. To avoid crashing issues or memory-related issues, you need to first check the memory space.
• Clear app data usage: You can clear the app data using the Application Manager under “Settings”. This will clear the cache memory and allow some free space to install another app or it will boost up your current app.
• Memory Management: Some apps run perfectly on one type of mobile device but the same app may not work on another type of device as for such devices the processing power, memory management, and CPU speed is different. For any app to run properly on any type of mobile device, you should manage the memory on the device.
• Compatibility issue: It is always not possible to test mobile apps on all mobile devices, browsers, operating systems, etc. So you need to test your mobile app on as many mobile devices as you can in order to avoid any compatibility issue.

Activities in Android are containers/windows to the UI. The lifecycle of an activity is as follows:

• OnCreate(): Here, the views are created and data is collected from bundles.
• OnStart(): It is called if the activity is visible to the user. It may be succeeded by onResume() if the activity reaches the foreground and onStop() if it converts into hidden.
• OnResume(): It is called when the activity starts an interaction with the user.
• OnPause(): This is called when the activity is going to the background but hasn’t been killed yet.
• OnStop(): This is called when you are no longer visible to the user.
• OnDestroy(): Called when the activity is finishing
• OnRestart(): Called after the activity has been stopped, prior to it being started again

To find memory leaks in an application on Android, the Android Device Manager (ADM) is used by the Android Studio. When you open ADM in Android Studio, you can see parameters such as heap size and memory analysis along with many others while you run an application.

An explicit intent is where you tell the system which Activity or system component it should use to respond to this intent. Implicit intents allow you to declare the action you want to perform; the Android system will then check which components are registered to handle that action.