iOS恶心的Double精度

最近发现在iOS中将String类型转化为Double类型的时候会有莫名奇妙的精度丢失问题,甚至在Double与Double之间的乘除运算结果也会出现很奇葩的精度问题。试过Objective-C和Swift,都有同样的问题,看来是iOS系统底层对这些情况有特殊处理吧。

下面以一个很常见的场景来说明问题:

假如在你的项目中需要提供给用户“提现”的功能,并收取一定比例的手续费(相信玩过各大比特币交易所的同学深有感触)。要求金额保留两位小数,并以手续费四舍五入为准,计算实际提取金额。

创建很简单的视图:

提现

我们输入提现金额,并实时计算手续费,那么我们可能会这样写:

屏幕快照 2018-06-04 下午8.32.54.png

得到的结果是:

结果1

发现问题了吗?

按道理,我们输入1234.1的时候,手续费四舍五入保留两位小数应该是61.71,但这里结果是61.70,而且实际提取的金额和手续费的金额加起来也不等于1234.1。

看图中的断点,是不是很惊讶!为什么inputValue的值是1234.0999999?这就是题目中说的恶心的精度。48行直接将String类型转Double类型就会出现这样奇怪的问题,然后计算的feeValue就相应的变小了一点点,再四舍五入就少了0.01了,同样地,第55行的结果是1172.39499,四舍五入之后变成了1172.39。所以,总的来说,手续费不对,实际提取的也不对了。

怎么办呢? 有两种方法: 一是手动修正手续费的值;二是使用NSDecimalNumber,也是最推荐的方式。

首先第一种方法,既然我们知道系统会丢失一点精度,那我们在转化之后手动修复一点点,比如给inputValue加上一个很小的小数,然后再对feeValue手动四舍五入,这样就保证了feeValue的值是正确的,也能保证realValue四舍五入的结果是对的:

手动修正精度

第二种方法是推荐使用的,在处理金钱相关的精度问题首先应该考虑使用它

使用NSDecimalNumber

其中我们所有的操作都是基于String和NSDecimalNumber的,中间不涉及Double的转换。其中NSDecimalNumberHandler 是可以定义一些行为参数的:

scale : 需要保留的精度。
raiseOnExactness : 为YES时在处理精确时如果有错误,就会抛出异常。
raiseOnOverflow  : YES时在计算精度向上溢出时会抛出异常,否则返回。
raiseOnUnderflow : YES时在计算精度向下溢出时会抛出异常,否则返回.
raiseOnDivideByZero : YES时。当除以0时会抛出异常,否则返回。

这样得到的结果是精确的NSDecimalNumber类型的,我么可以像第56行那样取出他的string格式结果。

使用这两种方式的结果如下:

正确结果

推荐阅读更多精彩内容