32

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.

Peter O.
  • 32,158
  • 14
  • 82
  • 96
Kurtis Nusbaum
  • 30,445
  • 13
  • 78
  • 102
  • Great responses so far. But I'd really like to hear more about performance. – Kurtis Nusbaum Oct 29 '11 at 04:01
  • If you are thinking performance, you should probably also think memory usage. The version I am using of Android JSON does not support tokenizing from reader/inputstream and mapping to the data model will therefore require 2x the memory. – ThomasRS Nov 29 '11 at 15:49
  • In my "much, much faster" link is a pretty extensive performance comparison with serialization time, deserialization time, and size. Is there anything beyond that you're looking for? – kabuko Nov 30 '11 at 19:48

7 Answers7

40

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/

Jon Adams
  • 24,464
  • 18
  • 82
  • 120
Programmer Bruce
  • 64,977
  • 7
  • 99
  • 97
  • 2
    Don't forget to factor in library size. Gson will be about 200kb, while Jackson's 3 dependencies will run about 1mb. Provided you don't need blazing performance, I recommend Gson for simplicity and library size. – CorayThan Apr 29 '14 at 08:46
9

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.

Community
  • 1
  • 1
kabuko
  • 36,028
  • 10
  • 80
  • 93
3

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.

Mike Marshall
  • 7,788
  • 4
  • 39
  • 63
3

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).

ThomasRS
  • 8,215
  • 5
  • 33
  • 48
  • I like this response because it explains why something like a tokenizing approach is faster. – Kurtis Nusbaum Dec 06 '11 at 00:37
  • Yeah if the important delay is measured as the time a networked requests is initiated to the response processing is complete, streaming processing is ideal both for XML and JSON and surely other formats too. – ThomasRS Dec 06 '11 at 08:21
1

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.

Miracle
  • 11
  • 2
  • Hi, please read http://stackoverflow.com/questions/how-to-answer especially "**Provide context for links**" part. – Eel Lee Nov 14 '13 at 12:05
1

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.

Plastic Sturgeon
  • 12,527
  • 4
  • 33
  • 47
1

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).

Fraggle
  • 8,607
  • 7
  • 54
  • 86
  • I'm comparison-shopping for gson libraries, and would love to hear if gson 2.0+ has improved performance much. – JimN Aug 31 '12 at 02:51
  • @JimN: Yes gson 2.0 seems to work better. Actually there is even a newer version than 2.0 out I think that I haven't tried. I'm using it pretty effectively. One thing to watch out for: After exporting my app and testing I ran into problems due to Proguard and GSON. – Fraggle Aug 31 '12 at 14:59