DEV Community: Nikhil Dupally

What Happens When You Click on an App in Android: A Deep Dive

Nikhil Dupally — Thu, 06 Mar 2025 20:22:29 +0000

What Happens When You Click on an App in Android: A Deep Dive

Have you ever wondered what’s really going on behind the scenes when you tap an app icon on your Android phone? That one simple action sets off a whole chain reaction of processes working together to bring the app to your screen. Let’s take a look at what happens step by step.

1. The Launcher Gets to Work

When you tap an app icon, the Launcher (your home screen app) picks up the touch event. Here’s what happens next:

Touch Processing: The system detects your touch through Android’s input framework and determines which icon was pressed.
Intent Creation: The launcher creates an Intent that tells the system which app you want to open.
Communicating with the System: It sends a request to the Activity Manager Service (AMS) via Binder IPC to start the app.

2. Checking If the App is Already Running

The Activity Manager Service (AMS), which is part of the Android system, now takes over and decides what to do next:

Is the app already open? If the app is already running, AMS just brings it to the foreground.
If not, find the process: AMS checks if the app’s process is active.
Starting fresh: If the process isn’t running, AMS requests Zygote to start a new instance of the app.

3. Zygote: The Process Factory

Zygote is a special system process responsible for launching apps efficiently. Here’s what it does:

Receiving the request: Zygote gets a command from AMS via a socket message.
Forking a new process: Instead of creating a whole new process from scratch, Zygote forks itself to make a lightweight copy. This saves time and resources.
Starting the Android Runtime (ART): The new process is now ready to load the app.

4. Initializing the App

Now that the app’s process is up and running, the Android Runtime (ART) takes over:

Loading classes and resources: The app’s code and assets are loaded into memory.
Calling main() method: The entry point of the app (ActivityThread.main()) is executed, setting up the main thread and event loop.
Creating the Application object: The app’s Application class (defined in AndroidManifest.xml) is instantiated, and onCreate() is called.

5. Creating and Rendering the First Screen

After the app is initialized, the first activity is launched:

AMS tells the app process to start an activity.
ActivityThread handles the launch: The activity is created, and lifecycle methods (onCreate(), onStart(), onResume()) are executed.
Rendering the UI: The app’s interface is drawn using ViewRootImpl and SurfaceFlinger, which handle OpenGL rendering and sending the image to your screen.

6. Your App Appears!

The final step is making sure you see the app on your display:

The UI updates sync with the screen’s refresh rate using Choreographer.
SurfaceFlinger combines all the visual elements and sends the final frame to your phone’s display.
Your app is now ready to use! 🎉

Conclusion

Opening an app on Android may seem instant, but under the hood, it’s a well-orchestrated process involving multiple system components. Understanding this flow can help Android developers optimize app launch times and improve performance.

Got questions or thoughts? Let’s discuss LinkedIn 🚀

JSON vs Protocol Buffers vs FlatBuffers: A Deep Dive

Nikhil Dupally — Thu, 06 Mar 2025 20:21:17 +0000

JSON vs Protocol Buffers vs FlatBuffers: A Deep Dive

Why I Explored These Three?

In today’s fast-paced technological landscape, efficient data serialization is more critical than ever. As developers, we constantly seek ways to optimize our applications for speed and performance. Recently, while working on a project that required handling large volumes of data, I encountered a bottleneck in our data processing pipeline. That’s when I started exploring different data serialization formats and stumbled upon JSON, Protocol Buffers, and FlatBuffers. These three formats offer unique approaches to data serialization, each with its own set of strengths and weaknesses. In this blog post, we’ll delve into the world of JSON, Protocol Buffers, and FlatBuffers, comparing their performance characteristics and exploring their suitability for various use cases. So, if you’re curious to learn about the trade-offs between these popular data serialization formats, join me on this journey as we uncover their secrets and discover which one reigns supreme in the realm of efficient data handling.

Understanding the Three Serialization Formats

1. JSON (JavaScript Object Notation)

JSON is the most widely used data interchange format due to its simplicity, readability, and human-friendly syntax. It is text-based and widely supported across programming languages.

Pros:

Easy to read and debug.
Supported in almost every programming language.
No schema enforcement, making it flexible.

Cons:

Larger size due to human-readable formatting.
Slow parsing speed compared to binary formats.
No built-in support for strong typing.

2. Protocol Buffers (ProtoBuf)

Protocol Buffers, developed by Google, is a compact and efficient binary serialization format designed for high-performance data exchange.

Pros:

Compact binary format, reducing size significantly compared to JSON.
Faster serialization and deserialization.
Strongly typed with schema enforcement.
Backward and forward compatibility with versioning.

Cons:

Requires defining a schema (.proto file) before use.
Not human-readable, making debugging harder.
Needs a compiler to generate language-specific code.

3. FlatBuffers

FlatBuffers, also developed by Google, is a highly optimized serialization library designed for scenarios where zero-copy deserialization is required.

Pros:

Extremely fast as it allows direct access to serialized data without parsing.
Efficient memory usage, avoiding extra allocations.
Backward and forward compatible.
Supports optional schema evolution like ProtoBuf.

Cons:

More complex API compared to JSON and ProtoBuf.
Not as widely supported as JSON.
Generates larger binary files than ProtoBuf due to additional metadata.

Benchmarking in Java Using JMH

To get a precise comparison, I used JMH** (Java Microbenchmark Harness)** to benchmark the serialization and deserialization times of JSON, Protocol Buffers, and FlatBuffers in Java. JMH is designed for benchmarking Java code with precise control over JVM optimizations.

Benchmark Setup:

Test Data: A simple object with multiple fields (integers, strings, nested objects).

Libraries Used:

JSON: Jackson
ProtoBuf: Google’s Protocol Buffers Java library
FlatBuffers: Google’s FlatBuffers Java library

Benchmarking Process:

Serialize the object to a byte array.
Deserialize the byte array back into an object.
Measure the time taken for both operations.
Run the benchmarks multiple times to minimize JVM warm-up effects.
Use different payload sizes to test performance under various conditions.

Results

Observations:

JSON had the slowest performance due to its text-based format and parsing overhead.
Protocol Buffers significantly outperformed JSON in both serialization and deserialization.
FlatBuffers had the best deserialization performance due to its zero-copy access mechanism.
ProtoBuf had the smallest serialized size, making it ideal for network efficiency.

Real-World Use Cases

When to Use JSON?

When human readability and debugging are important (e.g., REST APIs, configuration files).
When interoperability with multiple systems is required.
When schema enforcement is not critical.

Example: JSON is widely used in web APIs like OpenWeather API, where readability and ease of use matter more than performance.

When to Use Protocol Buffers?

When data exchange needs to be compact and fast (e.g., gRPC services, IoT data transfer).
When schema enforcement and strong typing are needed.
When backward and forward compatibility is essential.

Example: gRPC-based microservices in large-scale distributed systems, such as in banking or messaging applications, often use ProtoBuf for efficient data transfer.

When to Use FlatBuffers?

When ultra-low latency is required (e.g., game development, real-time applications, high-frequency trading systems).
When zero-copy deserialization is needed for performance.
When dealing with structured data requiring frequent reads but infrequent writes.

Example: Game engines like Unity use FlatBuffers for real-time physics and AI updates because they require fast access to large structured data without parsing overhead.

Final Thoughts

JSON, Protocol Buffers, and FlatBuffers each serve distinct purposes. JSON is ideal for human-readable data exchange, Protocol Buffers excel in efficient network communication, and FlatBuffers shine in real-time scenarios requiring zero-copy deserialization.

For my hobby project, I found that while JSON was easy for quick prototyping, switching to ProtoBuf significantly improved performance. If extreme speed was necessary, FlatBuffers would be the best choice. Choosing the right serialization format depends on the specific use case and performance constraints.

The code can be found in this Github repository.

Which one do you prefer in your projects? Let’s discuss LinkedIn

Leveraging Filter Correlations for Deep Model Compression

Nikhil Dupally — Thu, 06 Mar 2025 20:16:19 +0000

Leveraging Filter Correlations for Deep Model Compression

This Blog is to explain Leveraging Filter Correlations for Deep Model Compression Paper accepted in WACV 2020.

Approach

Iteratively identify pairs of filters with the largest pairwise correlations.
The model is re-optimized to make the filters in these pairs maximally correlated.
After discarding the filters in each round, we further fine tune the model (for smaller number of epochs) to recover from the potential small loss incurred due to the compression.

Episode Selection

N- pairs of filters are selected from each layer with maximum correlation.
Correlation between filters:

This selected set of filter pairs from all the layers is called one episode.

Optimization

We optimize this cost function with the new regularizer applied to the selected episode.
Our new regularizer (CSt) is as follows:

This new regularizer is added to the original cost function so our new objective function is as follows:

Pruning and Fine-Tuning

After increasing the correlation between filters in each pair we can prune one filter from each pair.
Our model has a reduced set of the parameter Θ’.

Where pi is the set of filters finally selected to be removed from the model.
Further, we fine-tune the model w.r.t. the parameter Θ’.

References

[1] .Singh, Pravendra, et al. “Leveraging filter correlations for deep model compression.” The IEEE Winter Conference on Applications of Computer Vision. 2020.