Why Should Android Developers Consider FlatBuffers over JSON?

FlatBuffers saves serialized data in buffers in a cross-platform manner, allowing format evolution through a schema that is entirely forwards and backward compatible. These buffers may be saved in files or transferred across the network in their raw form, and they can be accessed in place without any processing cost. So, What exactly are Flat Buffers? You may ask

The FlatBuffers is a robust cross-platform serialization library that works with C++, C#, C, Go, Java, JavaScript, PHP, and Python. They were initially developed at Google for game development and other high-performance applications.

Using the Flat Buffers

Without further ado, let’s dive straight into the topic of why you as an Android Developer use Flat Buffers over JSON. Well, the answer to this is pretty simple, as it breaks down to a few points:

• Fetches data access without parsing it actually — What distinguishes FlatBuffers is that they represent hierarchical data in a flat binary buffer, allowing for direct access without parsing and unpacking while still providing data structure development (forwards/backward compatibility).
• Better in performance — The buffer is the only memory required to access your data. It necessitates no additional allocations (at least not in C++). Other languages may differ). FlatBuffers are also ideal for usage with mmap (or streaming), as just a portion of the buffer is required to reside in memory.
• Ductile— Having optional fields means that you not only get fantastic forward and backward compatibility (which is increasingly crucial for long-lived games: you don’t have to update all data with each new version), but you also get great forward and backward compatibility. It also implies that you have a lot of freedom in terms of what data you write and what data you don’t and how you construct data structures.
• FlatBuffers require only a tiny amount of produced code and a single short header as the minimum requirement, making them very straightforward to incorporate. For more information, please refer to the benchmark section.
• Robust and Rigid — Errors are caught at compile-time, rather than having to manually perform repetitious and error-prone run-time checks. You may have useful code produced for you.
• Simple to utilize — The generated C++ code provides for terse access and construction code. Then there’s the optional feature for parsing schemas and running JSON-like text representations at runtime if you require it (faster and more memory efficient than other JSON parsers).
• C++ code is cross-platform and has no dependencies; it will work with any current GCC/clang and VS2010. It includes building files for the tests and samples (Android .mk files, and cmake for all other platforms).

After going through the above advantages it’s now valid to ask that:

How Much Performance Gain would be there if I use Flat Buffers?

There is an overall performance gain while using the flat buffers, however, it depends on the use case as well, if you use code that has a lot of usage of auto-generated stub the surely you would gain in the following aspects:

• The rate of parsing. A JSON stream of 10 KB (a typical response size) took 20 ms to parse, which is faster than the UI frame refresh period of 16.6 ms. We were unable to load data on demand from our disc cache without experiencing frame drops (visual stutters) while scrolling using this technique.

Starting the parsing demon  — Any modern-day JSON parser which you might be using takes some time to initialize itself, think it as of a two-wheeler taking time to heat up before you can actually ride it after being still for a while, which can take 200 ms to 400 ms, significantly slowing down application startup time.

• Collection of garbage. During JSON parsing, many tiny objects are generated, and in our tests, over 50 KB of temporary memory was allocated when processing a 10 KB JSON stream, putting substantial strain on Java Garbage Collector.

Using the Flat Buffer by now would be proved as a better idea, so 

Who uses Flat Buffers?

The use case of Flat Buffers is huge and the potential they carry is large so a variety of developers tend to use FB in their projects which include (not limited to) :

1. Google —  of course, as they’d developed it, uses it in a variety of different products, which are mentioned here.
2. Tabnine —   yet another user of Flat Buffer, uses it in a different retro style, can be found here.
3. Facebook —  the social giant uses the Flat Burner over the JSON for increased reliability and speed, more about which can be found out here.

The FlatBuffers schema compiler and runtime are built-in platform-independent C++, with no library requirements outside of the STL, allowing them to be used on any platform that supports a C++ compiler. The schema compiler can create C++ and Java code to read and write FlatBuffers binary files. It can also parse JSON-formatted data and convert it into type-safe binaries.

Conclusion and Speed Check

With all the performance, speed, and other improvements which Flat Buffers bring to the table, undoubtedly makes it a better choice to be used in place of JSON, the JSON s now also getting its way of aging as it has come a long way and now slowly begin to show the issues. 

If you still need a reason to migrate, here’s an actual use case where we see FB performing better than JSON. FlatBuffer took 1–3 ms and JSON took around 1990ms. And no GC was called in the android app during FlatBuffer use. But GC was called so many times while using JSON. As a result, the user Interface became laggy and sometimes unresponsive making the user agitated.