前情简介

事情是这样的，公司有个比较老的SDK库，在我进公司三个月之后就交由我来维护了，于是呼我就勤勤奋奋的扛起了这份神圣手动黑人脸的职责。这个SDK主要是跟向APP提供后台的服务，类似这样的：

SDK的工作角色

APP需要向server上传自己的Capability（App能支持的功能项，每个APP可能不一样）。而这个APP是一个long型，每一个Bit表示一个功能项。

63	62	61	···	5	4	3	2	1	0

祖传代码里是这样写的：

public final static long CAP_0 = 0x01;
public final static long CAP_1 = 0x01 << 1;
public final static long CAP_2 = 0x01 << 2;
···
···
···
public final static long CAP_31 = 0x01 << 30;

我接到的需求就是这样，提供后台新增的Capability,于是我就没动脑子写出了下面的代码：

public final static long CAP_0 = 0x01;
public final static long CAP_1 = 0x01 << 1;
public final static long CAP_2 = 0x01 << 2;
···
···
···
public final static long CAP_31 = 0x01 << 30;
public final static long CAP_31 = 0x01 << 31;
public final static long CAP_32 = 0x01 << 32;
public final static long CAP_33 = 0x01 << 33;

事情就是这么个事情，情况就是这么个情况!

问题分析

SDK的使用者，某APP开发（其实这个需求就分给我了）死活和后台调不通，现象就是如果APP正确上报某个Capability,点击APP上的按钮，会向server发出命令请求，实际是server一直报错。

按理说，这个事情只要后台告诉我具体是什么错误，也是很容易查出来的。然鹅...，日志上显示 error msg: deviceId not found ,我们的公司后台在台湾，沟通起来特费劲，so我就一个人默默的排查...,朝着deviceId not found这个方向去查了。。。。

我：deviceId我有传呀，怎么还是这个错误？
大佬：是不是，deviceId中途被改动了？
我：我去追踪一下看看。
……
我：deviceId是正确。
大佬：那你找台湾的后台看看吧。。
我：哦，我再看看吧。。

就这样过了许久...，咦，等等，这个capability怎么是负的...，😯😯，心里一万只喜洋洋飘过。改代码：

public final static long CAP_0 = 0x01L;
public final static long CAP_1 = 0x01L << 1;
public final static long CAP_2 = 0x01L << 2;
···
···
···
public final static long CAP_31 = 0x01L << 30;
public final static long CAP_31 = 0x01L << 31;
public final static long CAP_32 = 0x01L << 32;
public final static long CAP_33 = 0x01L << 33;

问题总结

嗯，细节打败爱（cheng）情（xu）啊（yuan）！

一个L引发的BUG

前情简介

问题分析

问题总结