十一、付费安装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长度的问题,设计系统的时候,一定记得设计进去。
赛文市场营销