常在河边走，难免会湿鞋
继上次分享了十个错误资式后，再一次开车，献上5个错误姿式，供大家学习参考，正确的事情，随便搜搜，到处都是，但别人犯过的错误，更是最宝贵的学习经验。
十一、付费安装App数量计算错误
-
错误姿式:
- 前期App用户的获取，都会来源于广告平台推广，这很正常，广告推广就会涉及到安装一个App要给多少钱的问题，然后最后按装机量来结帐，付钱。但前期，我们统计到只有100个安装，但广告平台说，我给你装了200个！WTF？到底是怎么回事？
-
原因：
- 采用了打点平台进行计算，大家都应该清楚，打点平台不是即时上传打点，通常会在本地DB中建一个事件表，当数据库记录达到固定条数时，再执行上传。而广告平台带来的用户，又不属于忠实用户，装上，立马就卸载，太正常了。但打点平台的数据还没有上报。所以就少数据了。
- 做推广，大部分都会选择的方案是：Google Play InstallReferrerReceiver, 通过广告网址链接到Google Play, 安装App后，Google Play会向系统发送一个 install_referrer的广播，但发送时间不受控件，可能有如下几种情况：
- 安装就发送广播。 4.0以下的机器会这样做。
- 打开App的时候，才发送广播。
- App打开一段时间后，才发送广播。
- 然后在接收referrer的代码也存在问题，导致只能接收到安装就发送的广播。丢了大量安装数据。
-
解决方案：
- 打点平台的方案，因为不是即时传送，必须不可以再用。那就直接调用服务端接口来传送数据，同时还要保证服务端正确返回，否则下次继续补传直到上传成功。涉及到钱的事，一定要慎重，容不得一丝差错，打点平台这种方案绝对不能用。
- 针对install_referrer不确定发送时机的问题，只能做到去堵入口，三种场景都考虑进去，同时加上服务端补传逻辑来确保数据的正确性。
-
小问题和补充：
- 你肯定会说：你这不是忽悠人吗？你刚安装了，还没有打开App，你怎么可以接收到广播？我写过DEMO，只安装，不启动App，是没办法收到广播消息的。
- 你说的很对，普通的广播是不能收到的，但Google Play发的广播做了小动作，他在 Intent中设置了Flag：FLAG_INCLUDE_STOPPED_PACKAGES，这种FLAG，即使没有启动App也可以收到广播。详见：FLAG_INCLUDE_STOPPED_PACKAGES
- 你还会问还有没有其他方案来做安装？不走referrer的方式。当然有，国内的话，都是走渠道包的，给这个广告平台特别的打一个渠道包，然后来自这个渠道的安装量，都算他的，要简单很多，我就不多说什么了。
十二、static错误使用姿式
-
错误姿式:
- 用户反馈，某些按钮点击了，没有任何反应。客记端又是一个无法重现，只能去猜想。
-
原因：
- 虽然无从查起，但初步想法，还是觉得是初始化问题。代码如下, D类中定义静态代码块负责初始化操作，调用时就直接：调用E.doThing("openAds") 来执行操作。大家先看一下如下代码到底有没有问题呢？
// 这是一个入口类
public class D {
static {
init();
}
static void init() {
E.register("openads", new ActionClass());
}
}
public class E {
public static Map<String,String> map = new HashMap<String,String>():
public static void register(String action, ActionClass ac){
map.put("action", ac);
}
public static void doThing(String cmd){
if(map.get(cmd)!=null){
// show ads
Toast.makeText(context,"ads",Toast.LENGTH_SHORT).show();;
}
}
}
// 按钮不生效的地方调用如下：
E.doThing("openads");
- 解决方案：
- 这里的问题在于，千万不要以为安装了你的APK后，你APK里面的静态代码块就会执行。静态代码块也要在这个类被用到的时候才会执行，比如用到其中某个变量，或者某个方法。
- 这里的错误，就是初始化希望用静态代码块，但还存在入口直接调用了：E.doThing("openads");没有先初始化类。
十三、 开发权限大于天
-
错误姿式：
- 新发布的版本，竟然又出现上个版本已经修复的问题。明明已经修复了啊？怎么会又出现呢？
-
错误原因：
- 上个版本，有小版本紧急修复，然后拉了一个分支专门修复问题。但新发布的版本忘了把代码合并到主干，导致上个版本出现的问题，又再一次出现在了新发布的版本中，然后开发又直接把安装包上传到了市场上，导致问题再次出现。
-
解决方案：
- 建立分支合并流程规范，建立版本负责人，专门跟进分支合并相关事项。
- 建立checkList, 每次发版本前，一项项确认，分支合了吗？打点打开了吗？覆盖安装测试了吗？等一系列的问题检查。
- 发布交互测试跟进，权限收回，所有对外发布的包，经过测试回归后再能发布。
十四、 发布到线上的版本，等了两三个小时，竟然没有一个用户更新？
-
错误姿式：
- 发布到线上的版本，等了两三个小时，也不见有Crash上报，也不见有评论反馈，是什么原因呢？
-
错误原因：
- 发布的App，因为包含安全漏洞，被拒绝审核通过，然后又是晚上，大家没有费劲去看,一看 Play 后台：您的 APK 包含安全漏洞，这违反了恶意行为政策，因此遭到了拒绝。
-
解决方案：
- Google Play 安全升级：从 2016 年 11 月 25 日起，Google Play 将禁止发布任何包含此类漏洞的新应用或应用更新。开发环境经常有 sslError错误，所发布的包当出现 SSL Error Handler 错误的时候，给继续执行了，导致Play审核不过。详见：链接
- 所以可以看出，iOS以前推全App https, 以及 禁止patch之类的黑科技，Google 也一直这样声明，估计也快要执行了吧。详见：链接
- 所以说啊，阿里云 王坚 博士讲话：App开发，终究是在别人家的后花园搞盆载，你搞得再好，再漂亮，也只是个盆载，长不出森林。微信牛吧？赞赏说关就得关，科大讯飞的语音助手，和Siri太相似，对不起，不让你上线。App开发，还是要再抓一抓Web的技术噢！
- 意思就是下面的这个方法，不要再覆盖了。
void onReceivedSslError (WebView view,
SslErrorHandler handler,
SslError error)
十五、客户端无法打开产品详情的问题
-
错误姿式：
- 客户端打开某个产品页面就出错，但只是个别产品，换一些产品后，就没有这个问题。
-
错误原因：
- 客户端定义的productID 的json转换对象ID为： int. 而大数据时代，已经不是万千上万的数据了，而是数以亿计的数据，那int最大可支持是：21,4748,3647 21亿多一点，对于产品不断增加的系统，那在客户端定义为int 值，就会报错了。导致产品打不开。
-
解决方案：
- 全部改为 long 来转化，long值最大可到：9223372036854775807，自己数吧，我觉得有生之年，产品库是到不了这个数字了。或者定义成String，但因为是string，会有空对象判断的问题。所以还是用long吧。
- 这个时候，讲的就是系统预见性了，你的容量还够不够消耗？还可以顶多久？ID长度的问题，设计系统的时候，一定记得设计进去。
