从源码分析JSONObject的optLong()的坑

image

1、说明问题

通常我们Android客户端跟后台在做网络请求、数据交互的时候，会使用到json。对于id等long类型字段，我们通常会使用jsonObject.optLong("id")来直接获取到id，正常来说也没什么问题，但如果遇到id比较大，比如达到15、16位以上，并且后台以String类型返回的时候，会遇到获取到的值跟实际的值会有那么一点点差距。这是什么原因呢？这次从源码的角度来分析下这个问题。

先来看看现象：

public void test() {
    try {
        // 设置id（注意：这里使用的是String）
        String id = "103929979578499878";
        JSONObject jsonObject = new JSONObject();
        jsonObject.put("id", id);

        // 获取新id（注意：这里使用的是optLong()）
        long newId = jsonObject.optLong("id");

        System.out.println("newId = " + newId);
    } catch (JSONException e) {
        e.printStackTrace();
    }
}

看看输出结果的对比：

String id = "12967957849998989"; // 12967957849998988 // 有差异
String id = "12967957849999089"; // 12967957849999088 // 有差异
String id = "129679578499990866"; // 129679578499990864 // 有差异
String id = "129679585491108365"; // 129679585491108368 // 有差异
String id = "12907957849998989"; // 12907957849998988 // 有差异
String id = "103929979578499878"; // 12907957849998988 // 有差异
String id = "129079578499898"; // 12907957849998988 // ok
String id = "129979578499878"; // 12997957849998988 // ok

看看int、long、double的最大值，上面的输入并没有超出long的最大值，但依然会导致精度丢失

Integer.MAX_VALUE = 2147483647
Long.MAX_VALUE = 9223372036854775807
Double.MAX_VALUE = 1.7976931348623157E308

这是为什么呢？

2、看源码分析

注意：这里看的是API-23版本，后来发现API-25版本有差异，至于API-25有没有这个问题有待验证。

在JSONObject类里面，无论是optInteger()、optLong()、optDouble()方法，最终都会走到toInteger()、toLong()、toDouble()

static Double toDouble(Object value) {
    if (value instanceof Double) {
        return (Double) value;
    } else if (value instanceof Number) {
        return ((Number) value).doubleValue();
    } else if (value instanceof String) {
        try {
            return Double.valueOf((String) value);
        } catch (NumberFormatException ignored) {
        }
    }
    return null;
}

static Integer toInteger(Object value) {
    if (value instanceof Integer) {
        return (Integer) value;
    } else if (value instanceof Number) {
        return ((Number) value).intValue();
    } else if (value instanceof String) {
        try {
            return (int) Double.parseDouble((String) value);
        } catch (NumberFormatException ignored) {
        }
    }
    return null;
}

static Long toLong(Object value) {
    if (value instanceof Long) {
        return (Long) value;
    } else if (value instanceof Number) {
        return ((Number) value).longValue();
    } else if (value instanceof String) {
        try {
            return (long) Double.parseDouble((String) value);
        } catch (NumberFormatException ignored) {
        }
    }
    return null;
}

可以看到，如果后台给客户端返回的数据是以String类型的话，这些方法最终都会调用

Double.parseDouble((String) value);

进去后看到，调用StringToReal类的parseDouble(String s)方法

/**
 * Returns the closest double value to the real number in the string.
 *
 * @param s
 *            the String that will be parsed to a floating point
 * @return the double closest to the real number
 *
 * @throws NumberFormatException
 *                if the String doesn't represent a double
 */
public static double parseDouble(String s) {
    s = s.trim();
    int length = s.length();

    if (length == 0) {
        throw invalidReal(s, true);
    }

    // See if this could be a named double
    char last = s.charAt(length - 1);
    if (last == 'y' || last == 'N') {
        return parseName(s, true);
    }

    // See if it could be a hexadecimal representation.
    // We don't use startsWith because there might be a leading sign.
    if (s.indexOf("0x") != -1 || s.indexOf("0X") != -1) {
        return HexStringParser.parseDouble(s);
    }

    StringExponentPair info = initialParse(s, length, true);
    if (info.infinity || info.zero) {
        return info.specialValue();
    }
    double result = parseDblImpl(info.s, (int) info.e);
    if (Double.doubleToRawLongBits(result) == 0xffffffffffffffffL) {
        throw invalidReal(s, true);
    }
    return info.negative ? -result : result;
}

这里看到一句

double result = parseDblImpl(info.s, (int) info.e);

进去后发现这是一个native方法，这就比较难跟踪下去了，但我们依然可以看看这个native方法的注释

/**
 * Takes a String and an integer exponent. The String should hold a positive
 * integer value (or zero). The exponent will be used to calculate the
 * floating point number by taking the positive integer the String
 * represents and multiplying by 10 raised to the power of the of the
 * exponent. Returns the closest double value to the real number, or Double.longBitsToDouble(-1).
 */
private static native double parseDblImpl(String s, int e);

上面已经写明了应用到浮点类型的时候，可能会返回一个跟实际值接近的值，也就是可能会发生精度丢失，这个注释藏的比较深，一般可不好发现，很容易会踩到这个坑。

参考了网上关于float、double精度的文章
float与double的范围和精度
Java浮点数

float和double的精度是由尾数的位数来决定的。浮点数在内存中是按科学计数法来存储的，其整数部分始终是一个隐含着的“1”，由于它是不变的，故不能对精度造成影响。
float：2^23 = 8388608，一共七位，这意味着最多能有7位有效数字，但绝对能保证的为6位，也即float的精度为6~7位有效数字；
double：2^52 = 4503599627370496，一共16位，同理，double的精度为15~16位。

可以看到，String类型的数据，经过double转换以后，只能保证15~16位的精度，后面的精度就不能保证了，这就是为什么我们在接收后台返回来的String类型数据，使用optLong()去获取，导致精度丢失的原因。

3、解决方法

前面也说明了一下，当后台返回来的数据是以String类型而不是Long类型，我们才会执行到

Double.parseDouble((String) value);

正常情况下

if (value instanceof Integer) {
    return (Integer) value;
} else if (value instanceof Number) {
    return ((Number) value).intValue();
} 

是不会产生这个问题的

所以解决的方法有两个：
1、跟后台沟通，以long类型返回；
2、使用String去接收，代码如下：

public static long optLong(JSONObject jsonObject, String columnName) {
    if (jsonObject == null || TextUtils.isEmpty(columnName)) {
        return 0L;
    }
    try {
        String columnValue = jsonObject.optString(columnName);
        if (TextUtils.isEmpty(columnValue)) {
            return 0L;
        }
        return Long.valueOf(columnValue);
    } catch (Exception e) {
        e.printStackTrace();
        return 0L;
    }
}

4、总结

多读源码，会发现一些有意思的的事情。