精华内容
下载资源
问答
  • android 4.0版本手机接受多条短信分析

    千次阅读 2015-01-27 11:00:22
    实例:android4.0版本以及以前版本【信息】对比机发送一条短信,手机显示收到2条信息  测试机接受条短信时,有时会接受到4,5条不定数目的短信信息。时间间隔不一。 2. 短信接受基本流程    分析一下流程
    手机接受多条短信分析

    1. 空闲中整理下笔记,先上android 4.0 短信接收多条异常问题处理,再写 android 4.5 的。 
    实例:android4.0版本以及以前版本 【信息】对比机发送一条短信,手机显示收到2条信息
        测试机接受多条短信时,有时会接受到4,5条不定数目的短信信息。时间间隔不一。

    2. 短信接受基本流程
        
     分析一下流程:   
      网络端向moderm发送消息, modem收到一条消息后,上报给SMS的framework,sms的framework再发送order broadcast通知上层app,
     SMS的app处理完后framework再通知modem发送ACK给网络。这是短信接收大致流程。代码后面做分析。

     **  ACK (ACK (Acknowledgement),即确认字符,在数据通信中,接收站发给发送站的一种传输类 控制字符。表示发来的数据已确认接受无误。 )

     注意:android 4.0 framework发送order broadcast一直到app处理完后framewrok再通知modem发送ACK,这个时间段不能超过8s(根据相关协议规定) 也即SMS的app处理这条有序广播的时间不能超过8s,  如果超过8s则不会通知modem去回复ACK,网络没收到ACK认为终端没有收到该短信,所以会再发送一次,这就是收到重复短信原因。

    3.  接受部分流程及部分代码


    短信接收,对于偏上层应用程序是要处理广播事件SMS_RECEIVED_ACTION,它是由Frameworks发出告诉上层有新的SMS已收到。
    在Mms中,由PrivilegedSmsReceiver来处理,当收到广播SMS_RECEIVED_ACTION(android.provider.Telephony.Intents.SMS_RECEIVED_ACTION=” android.provider.Telephony.SMS_RECEIVED”)
    后会启动SmsReceiverService来做具体的处理。

    PrivilegedSmsReceiver .java
    public class  PrivilegedSmsReceiver extends SmsReceiver {
                onReceiveWithPrivilege();
    }

    SmsReceiver.java中
    beginStartingService(context, intent);  会去调用 SmsReceiverService.java 进行处理。
    此方法内获取一个wake lock 然后启动SmsReceiverService服务
          MmsLog.d(MmsApp.TXN_TAG, "SmsReceiver: onReceiveWithPrivilege(). Slot Id = " 
                + Integer.toString(intent.getIntExtra(EncapsulatedPhone.GEMINI_SIM_ID_KEY, -1), 10)
                +", Action = " + intent.getAction()
                +", result = " + getResultCode());
             intent.setClass(context, SmsReceiverService.class);
            intent.putExtra("result", getResultCode());
            beginStartingService(context, intent);
    对应的常见log:
    05-29 09:11:28.723844 20407 20407 D Mms/Txn : SmsReceiver: onReceiveWithPrivilege(). Slot Id = 0, Action = android.provider.Telephony.SMS_RECEIVED, result = -1

    SmsReceiverService.java中

    启动该服务后,会调用onStartCommand方法,该方法传来的Intent为Message的Obj发送一条Message

    在handleMessage方法里面通过Intent判断后执行相应的操作, 如handleSmsSent,handleSmsReceived,handleBootCompleted,handleServiceStateChanged 接受到短信时执行handleSmsReceived方法 private void handleSmsReceived(Intent intent, int error) { SmsMessage[] msgs = Intents.getMessagesFromIntent(intent); 该方法内通过Intents.getMessagesFromIntent(intent)方法从Intent里面取出Message[] 然后通过insertMessage(this, msgs)方法插入短信insertMessage里通过调用storeMessage方法 Uri messageUri = null; try { messageUri = insertMessage(this, intent, error, format); } catch (IllegalArgumentException e) { MmsLog.e(TAG, "Save message fail:" + e.getMessage(), e); return; } 再在storeMessage方法执行values.put(Inbox.BODY, sms.getDisplayMessageBody())方法就可以将 短信以ContentValues的形式插入数据库。 storeMessage方法如果插入成功将会返回插入短信的Uri,如果此Uri不为Null,说明已经插入数据库,于是 在SmsReceiverService.java 中 handleSmsReceived()中 执行MessagingNotification.updateNewMessageIndicator(this, true); 该方法则会根据短信的状态,发出提示音或震动,也可以根据设置notification 自此,一条新信息就成功接受了。


    主要log分析掌握:
    //表示接受到短信广播,来了一条短信,
    05-29 09:11:28.723844 20407 20407 D Mms/Txn : SmsReceiver: onReceiveWithPrivilege(). Slot Id = 0, Action = android.provider.Telephony.SMS_RECEIVED, result = -1

    //短信内容
    05-29 09:11:29.820343 20407 20443 D Mms/Txn : handleSmsReceived messageUri: content://sms/35, address: +8615901809630, body: QWERTY

    4 .此问题分析关键代码及log信息:
      (1)代码可见 SMSDispatcher.java
           private final BroadcastReceiver mResultReceiver = new BroadcastReceiver()   
                        if (rTime != -1) {
                        long curTime = System.currentTimeMillis();
                        Log.d(TAG, "CNMA elplased time: " + (curTime - rTime));
                         if ((curTime - rTime) / 1000 > 8) {
                            Log.d(TAG, "APP process too long");

                        } else {
                            // For a multi-part message, this only ACKs the last
                            // part.
                            // Previous parts were ACK'd as they were received.
                            acknowledgeLastIncomingSms(success, rc, null);
                        }

         收到重复短信一般都是这里发生超时
         可以在radio log搜" APP process too long",如果有这条trace,表示发生超时了

      (2)  可以在mainLog里查看这条广播被发送出来的时间点是什么,被com.android.mms.transaction.PrivilegedSmsReceiver
        接收到的时间点又是什么,   这之间的时间差就表示过了多少时间才被SMS的app接收到。
     
    如下:
    ------------------------------------
    FW发送有序广播的时间点是08:00:31
    003314 01-01 08:00:31.587   655  1047 V ActivityManager: Broadcast: Intent { act=android.provider.Telephony.SMS_RECEIVED flg=0x10 (has extras) } ordered=true userid=0
     
    app在08:00:40才接收到这个广播,已经过了9s
    018183 01-01 08:00:40.753  1193  1193 D ActivityThread: BDC-Calling onReceive: intent=Intent { act=android.provider.Telephony.SMS_RECEIVED flg=0x10 cmp=com.android.mms/.transaction.PrivilegedSmsReceiver (has extras) }, ordered=true,  receiver=com.android.mms.transaction.PrivilegedSmsReceiver@413fda90
     
    从radio log看到,超时了,不回再通知modem回复ack
    04460 01-01 08:00:40.766  1000  1000 D SMS     : CNMA elplased time: 9185
    04461 01-01 08:00:40.766  1000  1000 D SMS     : APP process too long
    --------------------------------------
    05-29 09:11:20.635894  9837  9837 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:11:20.851822  9837  9837 V CooeeShell: NwsR onReceive = android.provider.Telephony.SMS_RECEIVED
    05-29 09:11:21.379688 20263 20263 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:11:21.537198 20263 20263 V CooeeShell: NwsR onReceive = android.provider.Telephony.SMS_RECEIVED
    05-29 09:11:26.785888 20394 20394 V CallAlarm: onCreate()  intent-->Intent { act=android.provider.Telephony.SMS_RECEIVED flg=0x10 cmp=com.sprd.note/com.huaqin.note.CallAl
    05-29 09:11:28.723844 20407 20407 D Mms/Txn : SmsReceiver: onReceiveWithPrivilege(). Slot Id = 0, Action = android.provider.Telephony.SMS_RECEIVED, result = -1
    05-29 09:11:29.820343 20407 20443 D Mms/Txn : handleSmsReceived messageUri: content://sms/35, address: +8615901809630, body: QWERTY

    05-29 09:16:31.302055  9837  9837 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:16:31.375205  9837  9837 V CooeeShell: NwsR onReceive = android.provider.Telephony.SMS_RECEIVED
    05-29 09:16:31.616181 20793 20793 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:16:31.688361 20793 20793 V CooeeShell: NwsR onReceive = android.provider.Telephony.SMS_RECEIVED
    05-29 09:16:36.353451 20910 20910 V CallAlarm: onCreate()  intent-->Intent { act=android.provider.Telephony.SMS_RECEIVED flg=0x10 cmp=com.sprd.note/com.huaqin.note.Ca
    05-29 09:16:37.561728 20922 20922 D Mms/Txn : SmsReceiver: onReceiveWithPrivilege(). Slot Id = 0, Action = android.provider.Telephony.SMS_RECEIVED, result = -1
    05-29 09:22:49.574934  9837  9837 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:22:55.927822 21608 21632 D Mms/Txn : handleSmsReceived messageUri: content://sms/37, address: +8615901809630, body: Wewewewewewe

    05-29 09:22:49.853961 21470 21470 V CooeeShell: SdkReceiver action = android.provider.Telephony.SMS_RECEIVED
    05-29 09:22:49.937389 21470 21470 V CooeeShell: NwsR onReceive = android.provider.Telephony.SMS_RECEIVED
    05-29 09:22:54.860996 21595 21595 V CallAlarm: onCreate()  intent-->Intent { act=android.provider.Telephony.SMS_RECEIVED flg=0x10 cmp=com.sprd.note/com.huaqin.note.Call

    05-29 09:22:55.338483 21608 21608 D Mms/Txn : SmsReceiver: onReceiveWithPrivilege(). Slot Id = 0, Action = android.provider.Telephony.SMS_RECEIVED, result = -1
     
    5. 短信发生超时有两种可能:
       (1)刚开机就去接收短信,容易发生超时现象,导致接收到重复短信。
           这是因为开机初始化阶段,一定有很多广播要接收和处理,SMS_received是有序广播,容易发生超时现象。
          如果开机后去接收短信发生接收到重复短信,可以在 main log里查看ActivityManager打印出来的broadcast,
          一定会看到有大量的广播被接收和处理。
          有可能客户定制了一些广播放在开机阶段去处理,如果是这种情况,需要去掉这些广播再测试看看。
          ( 如果这些广播都是系统的,都是必须要处理的,目前这种情况没有优化方案)
        
       (2)有三方应用在拦截该广播。有可能客户定制了一些apk,这些apk也在接收SMS_RECEIVED的广播,且这些apk定的优先级比较高,
          先收到这个广播,再一层一层往后传递,最后才被com.android.mms.transaction.PrivilegedSmsReceiver接收到,这中间的时间达到8s以上,
          发生 超时。
          如果是这种case,可以在mainLog里搜一下act=android.provider.Telephony.SMS_RECEIVED分别被什么app给接收到,顺序是怎样的,
          客户再自行做代码上的调整。


    ******android 4.5 以后版本中framework 做了更改,出现接收多条短信分析也改变了,后面会继续写出来。。。




           

    展开全文
  • 在调试期间,去讨论别的问题了,我自己收到多条短信的同时,那些接受者账户也收到多条短信。短信接口会按着账户去查手机号码,如果接收者账户和接收者手机号码不一样,就会有两个人收到短信。 第二:默认...
    两次事故原因:
    • 第一次:本地调试时发出,发送短信的接口需要传一个接收者账户和接收者手机号码,在调试的时候我把接受者手机号码填自己的,然后接受者账户是真实的账户。在调试期间,去讨论别的问题了,我自己收到多条短信的同时,那些接受者账户也收到多条短信。 短信接口会按着账户去查手机号码,如果接收者账户和接收者手机号码不一样,就会有两个人收到短信。
    • 第二次:默认触发器是24小时触发一次,但为了调试触发是否正常以及其他逻辑是否正确,我把间隔时间设置成了5秒。部署前代码改回来了,但是未编译,所以部署的代码还是间隔5秒。 应该是早上9点半触发,为什么会每隔5秒触发? 第一次的间隔时间比较特别,与部署时间相关。假设第一次触发的间隔时间也是24小时,假设我们下午5点半部署,那么下次触发时明天5点半,这样不满足早上9点半触发的要求。 所以第一次的触发时间需要矫正,即第一次的间隔时间是:触发器初始化的时间与明天早上9点半之间的时间长度,明天早上触发后再自动把触发时间更改为24小时。

     

    ps:第一次8位内勤,第二次6位内勤。第一次间隔3秒,第二次间隔5秒。每次持续大概10分钟后收到反馈,然后停止服务。两次初略估计发送(10*60/3)*8+(10*60/5)*6=2320条重复短信。

    启发:应有自动检测故障功能,假设10分钟内发现3条内容和接受者一样的短信发送请求,短信平台应予以不接受请求。

     

    转载于:https://www.cnblogs.com/langu/p/3965843.html

    展开全文
  • 原来我是用 BroadcastReceiver 来监听短信接收,后来了解到用 ContentObserver 也能实现这种功能,而且...在使用 ContentObserver 监听短信的过程中,发现了个问题,问题描述如下:当手机接收短信的时候, onCha

    原来我是用 BroadcastReceiver 来监听短信的接收,后来了解到用 ContentObserver 也能实现这种功能,而且还更方便。于是就尝试使用这种方法。

    ContentObserver的原理是观察(捕捉)特定 Uri 引起的数据库的变化,继而可以做一些相应的处理。

    在使用 ContentObserver 监听短信的过程中,发现了一个问题,问题描述如下:当手机接收到短信的时候, onChange 方法调用了一次,当打开短信App后,onChange方法又调用了一次。这样一来就调用了两次 onChange。

    我们一般都不希望它调用两次,比如目前市场上的手环类App一般都具有短信提醒功能,只要手机接收到短信,手环App就会发送某些指令到手环上,手环收到指令进行振动提醒。实现的思路一般是在 onChange方法中发送数据到手环。假如出现了上述的问题,出现的结果是,手机接到短信后,手环振动一下,打开短信App,手环又振动一下。

    经过一番查询。找到了解决的方法。

    使用方法:

    // 获取 ContentResolver 
    mContentResolver = getContentResolver();
    // 注册ContentObserver ,第一个参数是 Uri,第二个参数如果为 true,则该Uri的派   生 Uri(比如 “content://sms/ inbox”)也可以监听,第三个参数是一个ContentObserver。
        mContentResover.registerContentObserver(Uri.parse("content://sms"), true,
    new SmsContentObserverr(new Handler()));
    
    // SmsContentObserver 继承 ContentObserver:
    class SmsContentObserver extends ContentObserver{
    
       private Uri mUri;
    
       public SmssReciever(Handler handler) {
    
          super(handler);
    
       }
    
        // 只要 “content://sms” 里面的数据发生了变化就会调用该方法
        public void onChange(boolean selfChange,Uri uri){
            super.onChange(selfChange,uri);
    
            Log.e("onChange","selfChange = "+selfChange+", Uri = "+uri.toString());
    // 接收短信后,然后再打开短信 App 后,两次的 Log 信息:
    // selfChange = false, Uri = content://sms/2750 收到短信后调用的
    // selfChange = false, Uri = content://sms/inbox 打开了短信 App 后调用的
    
            // 第一遍 先执行 content://sms/raw 
            // 第二遍则是 content://sms/inbox
            if (uri.toString().equals("content://sms/inbox")) {
            // return 后就不会执行发送数据到手环的代码了 
            return;
            } 
    
            // 发送数据到手环的代码
            ……
    
        }
    
    }
    展开全文
  • 最近在项目中发现了一个奇葩的 BUG ,当用户调用后台时,后台向消息队列中发布一条消息,这条消息会被监听器(消费者)监听到,有趣的事情就在这里,此时由于只发送了一条消息,照理说监听器应该只会触发一,但是却...

    最近在项目中发现了一个奇葩的 BUG ,当用户调用后台时,后台向消息队列中发布一条消息,这条消息会被监听器(消费者)监听到,有趣的事情就在这里,此时由于只发送了一条消息,照理说监听器应该只会触发一次,但是却总是订阅2次(有的客户服务器启动甚至会初始化好几次,不知具体原因),然后就不会再订阅了,当时向消息队列发布信息我是使用的 RedisTemplate 里面的 convertAndSend(channel,message) 方法(看了一遍发现并没有看出什么代码上的问题),于是我去看了一下源码并走了一下断点,发现程序在发布消息的时候确确实实只发布了一次,但是监听器却订阅了2次。

    当时为了测试,特意写了一个跟下面所有代码片段差不多的内容

    消息发布者

    // Controller 的某个方法内容 用于向 "channel" 发布信息
    // 此处使用的 RedisTemplate 对象
    // 消息发布者
    @RequestMapping("publishMsg")
    public void publishMsg(){
        // 向 "channel" 发布一个信息 "这是我发送的一个消息"
        redisTemplate.convertAndSend("channel","这是我发送的一个消息");
    }

    消息订阅者 ( xxxConsumer )

    // xxxListener 类,主要用于订阅向 "channel" 发布的信息
    // 消息订阅者
    public void handleMessage(Message message,byte[] pattern){
        // 输出 channel
        System.out.print("channel : " + stringRedisSerializer.deserialize(message.getChannel()));
        // 输出发布的信息
        System.out.print("message : " + stringRedisSerializer.deserialize(message.getBody()));
    }

    spring.xml Redis 的队列大概配置

    <!-- 将订阅者的类注册到 spring 中 -->
    <bean id="stringRedisSerializer" 
          class="org.springframework.data.redis.serializer.StringRedisSerializer"></bean>
    <!-- 将订阅者的类注册到 spring 中,这个 bean 是消息订阅者 -->
    <bean id="xxxConsumer" class="com.xxx.xxx.xxxConsumer"></bean>
    <redis:listener-container>
        <redis:listener ref="xxxConsumer" serializer="stringRedisSerializer" 
                        method="handleMessage" topic="channel" />
    </redis:listener-container>

    此时我联想到以下几点可能会引起的问题。
    1、代码逻辑或者配置文件内容写的还是有问题,需要再 review 一遍 ?
    2、spring-data-redis 版本问题导致的重复订阅多次 ?
    3、redis 版本过于古老 ?
    4、程序从前几个月的某次更新之后就出现了扫描了两次项目的问题,会不会跟这个有关系 ?

    经过排查与尝试之后,最终问题定位在了第 4 点上,随后我便想到每次初始化资源的时候队列都会起一个线程(xxxConsumer)来监听(订阅) 某个 channel 发布的信息,如果程序连续初始化了两次项目,会不会有两个消费者线程,同时运作并监听一个 channel 发布的信息呢 ?
    于是我尝试了一下,在程序第一次初始化成功之后立马在我的 redis 客户端中手动向 “channel” 发布了一个信息,这时候发现该信息的订阅者数量是 1,然后我定位到了问题所在,随后我突然想到了很久之前为了只用 ip 地址加端口访问到项目,特意在 server.xml 中的 Host 元素里多加了一个 Context 标签,用于忽略项目名访问项目,之后我在为了能去掉项目名的同时,也不被实例化两次的想法下,进行了一些修改,下面放出代码
    修改前

    <Host appBase="wtpwebapps" autoDeploy="true" name="localhost" unpackWARs="true">
        <Context debug="0" docBase="" path="ProjectName" reloadable="false"></Context>
        <Context debug="0" docBase="ProjectName" path="/ProjectName" reloadable="false" source="..." ></Context>
        <!-- 忽略掉其它的默认配置内容 -->
    </Host>

    修改后
    注意:如果是在 IDE 中启动 tomcat 可能路径会有变化,甚至还会造成项目启动失败的问题,报错内容主要就是路径对应的项目找不到,改成正确的路径就好了,server.xml docBase 路径配置示例 : ../wtpwebapps/ProjectName

    <Host appBase="" autoDeploy="true" name="localhost" unpackWARs="true">
        <Context debug="0" docBase="webapps/ProjectName" path="/" reloadable="false" source="..." ></Context>
        <!-- 忽略掉其它的默认配置内容 -->
    </Host>

    经过这次事件之后也算是有了一点小收获(调的时候真的是一头雾水……)
    了解了一点 Tomcat 加载的机制,也巩固了一遍 redis 队列配置方法,而且不知道算不算是找到了一个比较靠谱一点的去掉项目名的配置方案 ╰(°▽°)╯
    [手动骄傲]

    PS:这是我第一次写调试笔记,主要是为了记录工作中遇到的一些尴尬事儿(居然花了我几个小时的时间,才调完),防止下次重蹈覆辙 XD,可能比较啰嗦QAQ,还望谅解

    展开全文
  • iphone短信 安卓By default, when you get an SMS or iMessage, your iPhone will make a sound once when you receive it, and then again two minutes later in case you missed it. If you read the message ...
  • android短信接收流程

    千次阅读 2014-10-13 17:49:52
    信息的接收工作是由底层来完成的,当有个 新的信息时底层完成接收后会以Intent的方式来通知上层应用,信息的相关内容也包含在Intent当中,Android所支持的信息Intent都定义在android.provider.Telephony.Intents...
  • 例如有一条短信是“用户您好,您号码为13912345678的手机本月话费是**元,余额**元”,诈骗分子就知道在这个小区里,有一个用户的电话号码是13912345678。 接下来,诈骗者会利用获取的手机号码登录网站。 他们会在...
  • Mms的接收短信

    2014-05-06 09:36:00
    大致的流程是Frameworks会先发出一条短信,告知应用程序有一个彩信,短信中含有一些信息比如过期日期,发送者手机号码,彩信的URL等,然后应用程序自行通过HTTP取回URL所指的彩信内容。具体的流程为: Telephony ...
  • 在进行一些如发送短信、邮件的业务时,我们经常会使用个表来存储待发送的数据,由后台个线程不断的从表中读取待发送的数据进行发送,发送完成后再将数据转移到历史表中,这样保证待发送表的数据一般情况下不会太...
  • 每年春节到的时候大家会在网上花很时间寻找特色的过年短信,要不就是一个人闷头苦想半天憋出一条很一般的祝福信息,小编自己包括身边亲戚朋友也都是这样子的。 如今,越来越的人活跃在微信上,微信俨然已经成为...
  • 使用阿里云短信服务API实现短信验证码以及短信服务通知前言 .短信调用简要说明二 .官方不带签名原生态测试demo调用结果如下三 .以上为不带模板和签名的API调用结果 下面加入签名和模板带有签名和模板的demo调用...
  • -- “隐患险于明火,防范胜于救灾,责任重于泰山” 某一次“看似合理”的决定就注定了自己挖好了坑,掉进自己挖的坑里是早晚的事,暴露在互联网上的所有入口,安全性容不得任何丝的“看似合理”。
  • 、模板消息 使用场景:当用户注册成功,支付成功的时候,为了方便提醒用户,或者为了提醒卖家发货时,可以用到模板消息。 模板消息的使用方法如下: 1、打开微信公众平台,功能————模板消息 或者也...
  • 在进行一些如发送短信、邮件的业务时,我们经常会使用个表来存储待发送的数据,由后台个线程不断的从表中读取待发送的数据进行发送,发送完成后再将数据转移到历史表中,这样保证待发送表的数据一般情况下不会太...
  • xxx项目中异步处理与第三方系统对接的功能,例如:发短信、发邮件、app推送等第三方系统,业务要求往第三方系统发送的请求发生异常,系统需要有重试机制,例如:第一次短信短信平台响应异常,则需要过两分钟重...
  • 短信基础

    千次阅读 2015-09-19 09:12:21
    1.1. 短信业务的由来 短信业务(SMS,Short massage services)也称为短信业务,包括GSM移动通信网的短信业务和...1992年,世界上第一条短信息在英国沃特丰的GSM网络上通过pc、移动电话发送成功,1999年后,短信才开始
  • 我做个手机短信注册(不需要得到用户微信信息),然后这个地址在电脑端和手机浏览器测试都是正常的,但是从微信公众号进去,短信却会接收
  • 遇到的问题: 已经可以获得短信验证码,但是会onChange多次调用,有短信来的时候首次会获取2条短信,且第2条的短信验证码会打印输出多次。 再发短信测试,手机有通知后,获取到的短信及验证码就不是最新的啦,就只...
  • 短信服务开发

    千次阅读 2018-09-19 19:45:35
    短信服务开发技术分享》  ——云栖 前言 短信服务功能大家都很...在实际的应用中,很开发者希望能够通过短信验证的方式来与用户进行某些重要操作的确认,比如短信验证支付、订单等,你就可以在用户验证过手...
  • 今天,终于收到一条骗子短信,还是时下最流行的冒充银行骗取卡号的骗局,全文如下:工商银行通知:贵用户牡丹卡正于沃尔玛购物商场刷卡消费4850元。此笔金额将从您的帐上扣除。如有疑问请拨: 51518332卡务部。...
  • 目录 前言 问题来了 问题又来了 问题分析 ...这是我上周工作过程中的一次解决问题的... 从业务角度说,应该是“一次短信重复发送问题的解决过程”,如果这样命名,过于土气;从技术角度说,应该是“nginx负载下...
  • 接口的幂等性实际上就是接口可重复调用,在调用方多次调用的情况下,接口最终得到的结果是一致的。 什么情况下需要幂等性? 在微服务架构下或者调用外部接口时,我们在完成个订单流程时经常遇到下面的场景: ...
  • 在进行一些如发送短信、邮件的业务时,我们经常会使用个表来存储待发送的数据,由后台个线程不断的从表中读取待发送的数据进行发送,发送完成后再将数据转移到历史表中,这样保证待发送表的数据一般情况下...
  • 【“短信车”大揭密:方圆五公里屏蔽所有手机信号 强推垃圾短信】...而在北京地区网站联合辟谣平台上发布的数据显示,2013年仅上半年,全国垃圾短信总量就超过了2000亿,平均每名手机用户接收近200,在北京、上海、
  • 10024.多媒体短信MMS

    万次阅读 2005-01-01 21:08:00
    、MMS的基本概念1. 什么是MMS?MMS是Multimedia Messaging Service的缩写,中文意为多媒体短信业务,是按照3GPP的标准( 3GPP TS 23.140)和WAP论坛的标准(WAP-206和WAP-209)有关多媒体信息的标准开发的最新业务...
  • 在今年2月份的一次试验中他们发现,有时他们天可以发送六七千条短信,这促使他们在3月份开始了这场发短信马拉松。 安德斯在接受电话采访时说:“大多数短信的内容是短语或者个词,例如LOL和Hello等,然后就是...
  • Ajax请求重复发送 内容精选换换消息发送和消费的可靠性必须由DMS服务和生产者以及消费者协同工作才能保证。同时开发者需要尽量合理使用DMS消息队列,以提高消息发送和消息消费的效率与准确性。对使用DMS服务的生产...
  • iphone4 短信截获

    2013-03-07 11:32:14
    ios3上的短信截获通过可以通过一些私有的api即可完成,网上的教程也较,这里不在重复。 前段时间在调研的ios4上的短信截获,在网上也很难找到相应的,较完整的资料,刚好前段时间学习了hook, 故周末抽了点...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,098
精华内容 4,839
关键字:

一条短信重复收到多次