共计 1790 个字符,预计需要花费 5 分钟才能阅读完成。
简述:在应用 uni-app 开发微信小程序时,iOS 手机在领取的时候,申请接口始终 pending,安卓手机没问题,模拟器也没问题,只有 iOS 真机调试的时候有问题。
接口在其它页面能够失常申请,唯独在领取页面始终 pending,不能失常走上面的流程。
因为安卓没事儿,所以应该不是服务器的问题,所以我就始终在找前端的问题。看到 pending 的上一个 页面渲染的接口
能失常申请,所以我先把上一个接口正文掉了,正文掉就好了。
过后感觉很奇怪,就追根溯源看看这个接口外面做了什么吧。外面有一个 setInterval
领取倒计时的定时器,猜想是不是定时器外面做的货色太多了,把过程跑满了,所以就卡在接口那了呢?
把 页面渲染的接口
放开,把外面定时器的 start
正文试了一下,验证了我的想法,果然是定时器外面的代码的问题。
先前写的代码的确堪忧:
self.timer = setInterval(() => {var today = new Date()// 以后工夫
var D,H,M,S;
var shenyu = this.stopTime.getTime()-today.getTime(),// 倒计时毫秒数
shengyuD = parseInt(shenyu/(60*60*24*1000)),// 转换为天
D = parseInt(shenyu)-parseInt(shengyuD*60*60*24*1000),// 除去天的毫秒数
shengyuH = parseInt(D/(60*60*1000)),// 除去天的毫秒数转换成小时
H = D-shengyuH*60*60*1000,// 除去天、小时的毫秒数
shengyuM = parseInt(H/(60*1000)),// 除去天的毫秒数转换成分钟
M = H-shengyuM*60*1000;// 除去天、小时、分的毫秒数
S = parseInt((shenyu-shengyuD*60*60*24*1000-shengyuH*60*60*1000-shengyuM*60*1000)/1000)// 除去天、小时、分的毫秒数转化为秒
if(shenyu>0){
// 赋值
var timeText;
if(shengyuM < 0 && S < 0){timeText = '00:00';}else{shengyuH = shengyuH<10 ? ('0'+shengyuH):shengyuH;
shengyuM = shengyuM<10 ? ('0'+shengyuM):shengyuM;
S = S<10 ? ('0'+S):S;
timeText = shengyuH+':'+shengyuM+':'+S;
}
self.timeText = timeText;
}else{clearInterval(self.timer);
}
}, 1000);
1 秒一获取以后工夫 1 秒一计算以后工夫。。咳咳 …
简化后:
var today = new Date();// 以后工夫
var shenyu = this.stopTime.getTime()-today.getTime();// 倒计时毫秒数
self.timer = setInterval(() => {
// 定义变量 d,h,m,s 保留倒计时的工夫
var d,h,m,s;
if(shenyu>=0){d = Math.floor(shenyu/1000/60/60/24);
h = Math.floor(shenyu/1000/60/60%24);
m = Math.floor(shenyu/1000/60%60);
s = Math.floor(shenyu/1000%60);
console.log(d+':'+h+':'+m+':'+s);
// 赋值
var timeText;
if(shenyu == 0){timeText = '00:00';}else{h = h<10 ? ('0'+h):h;
m = m<10 ? ('0'+m):m;
s = s<10 ? ('0'+s):s;
timeText = h+':'+m+':'+s;
}
self.timeText = timeText;
}else{
timeText = '00:00';
clearInterval(self.timer);
}
shenyu = shenyu-1000;
},1000);
(所以如果始终 pending 的话,能够试这看看,代码的是否能够优化来解决,具体问题具体分析)
以上是我调 bug 的经验,记录下来,心愿有幸能够帮到你,比心。
正文完