Home » Android » java – Performance and Usability comparison of Android JSON libraries

java – Performance and Usability comparison of Android JSON libraries

Posted by: admin April 23, 2020 Leave a comment

Questions:

What is the best library out there for parsing JSON on android. I know the Android framework has a JSON library built in, and I’ve heard of GSON. But I’m wondering if anyone has compared the various JSON options on android and come up with a justification for choosing one over the other. I’m thinking of performance and usability as the main criteria.

How to&Answers:

While there is a handful of Java-to/from-JSON APIs that provide for easy (basic) binding between JSON and an arbitrary Java data structure, Jackson and Gson are by far the most sophisticated (capable) and feature-rich options.

Back in July (2011), I posted a multi-part series on my blog comparing using Gson versus Jackson, stepping through features as they were organized in the Gson User Guide, including examples of comparable implementations in Jackson (and of implementations in Gson, where the Gson User Guide was incomplete or broken).

The sixth part of the series provides easy navigation links for the comparison, as well as a summary comparison listing. http://programmerbruce.blogspot.com/2011/07/gson-v-jackson-part-6.html

This is the most comprehensive comparison of using Gson versus Jackson for common JSON-to/from-Java tasks known.

As mentioned, performance comparisons of various Java-to/from-JSON APIs are available at https://github.com/eishay/jvm-serializers/wiki. The current release of Gson (2.0) shows to be about 16 times slower than the current release of Jackson (1.9.2) at serializing and deserializing a 500 byte JSON structure, using very comparable implementation efforts (just one or two lines of code).

Martin Adamek posted some performance results of various APIs running on Android at http://martinadamek.com/2011/01/31/comparison-of-json-parsers-performance-on-android/ and http://martinadamek.com/2011/02/04/json-parsers-performance-on-android-with-warmup-and-multiple-iterations/

Answer:

GSON is really simple to use and if performance isn’t an issue, it’s quite nice. Jackson is much, much faster though and is not really that much more effort to use. As I’ve said in the past in another related SO question, I’ve gotten huge performance gains (when working with large sets of JSON) by simply switching to Jackson from GSON.

Answer:

Well sometimes performance and usability can be at odds, but I’ve found GSON to be easier to use than alternatives like Jackson, org.json and others. I’m currently serializing JSON data that has objects and lists 3 or 4 levels deep. That being said, I have tailored my JSON to be more suitable for serialization, but overall GSON has been great.

Answer:

This answer is seen from a memory perspective, as that can also be considered performance :-P.

I just implemented parsing of a 70KB JSON file in Android, parsing an array of objects which should either load from scratch or update previously present data binding objects, all over HTTP.

The biggest drawback with the built-in org.json package for android runtime 3 was

  1. the JSONTokener constructor only accepts a String, no Reader
  2. the lack of practical support for pull-parsing

This typically means you need to keep the whole file in memory (think 2x byte size) and in addition hold all the resulting JSON objects in memory at the same time, before you start making your data binding. So worst case is 2x file size, JSON objects and data-binding objects – usually at least 2x the memory requirement.

If you pull-parse from a reader, you can get this down to 1x. That is the most important thing you can do from memory perspective.

And, surprise surprise, if you go with some more modern classes, like Jackson or just the latest sources from org.json, you will be able to get around both these constraints without a problem, a later android runtime also seems to have some utility classes for JSON pull-parsing.

If you are stuck with an old runtime, and want to keep the footprint of the application down, as did I, you can copy the JSONTokener from org.json and modify your top level parse loop (in my case the array parse loop) and do data binding on each member of the array instead of the whole array at once. This way you reuse the JSON objects already in the android runtime as much as possible and still get the streaming effect (at the price of adding ids to each top-level object).

Answer:

the Android JSON is very functional, but has not bells a whistles. Where as GSON allows you to specify mappings between your classes and their json representation. It also has very nice automatic conversion of any primitive values to json, with no additional work on your part.

The payoff with GSON is if you have a lot of JSON communcaion, or complex objects that require value checking to prevent illegal values (such as NaN) and other cases where java-to-JSON is less than straight forward.

But if you just need to send and recieve a simple json object, the native library does the trick quite respectably. I am using it in my current project to post high scores to a server.

Answer:

I’m testing out GSON and have tried some others.

GSON does an excellent job of serializing (converting object to json) complex objects with basically no changes or thought at all on your part, but is a bit slow and memory intensive.

The GSON Roadmap website indicates they expect version 2.0 to address some performance issues and that it will be out in Oct 2011 (ending soon). So I’m hoping they deliver that because I really need it.

Other libraries (sorry can’t recall names right now) don’t seem to serialize as well. Some may only look at public variables in your classes or just call on public methods that look like getters/setters. Gson doesn’t do it that way, and will grab everything.

I haven’t done much yet on the deserializing side (converting JSON back to Java objects).

Answer:

try android-async-http

  • Make asynchronous HTTP requests, handle responses in anonymous callbacks
  • HTTP requests happen outside the UI thread
  • Requests use a threadpool to cap concurrent resource usage
  • GET/POST params builder (RequestParams)
  • Multipart file uploads with no additional third party libraries
  • Tiny size overhead to your application, only 25kb for everything
  • Automatic smart request retries optimized for spotty mobile connections
  • Automatic gzip response decoding support for super-fast requests
  • Binary file (images etc) downloading with BinaryHttpResponseHandler
  • Built-in response parsing into JSON with JsonHttpResponseHandler
  • Persistent cookie store, saves cookies into your app’s SharedPreferences

and also you can try fastjson which is a fast json processor.