例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
[0056]参考图1，示出了本申请一种基于智能设备的呼叫处理方法实施例的流程图，本实施例可以应用于云计算系统中的各台主机上，本实施例可以包括以下步骤:
[0057]步骤101:响应于用户触发的呼叫当前APP对应的客服电话的请求，监听所述APP所集成的智能设备的通话状态。
[0058]在本申请实施例中，用户在使用智能设备上安装的应用程序APP的时候，可能会遇到一些问题，例如在使用手机软件付款时，密码多次校验错误，或者在玩游戏过程中，多次调用器材失败等，则用户可以通过触发当前APP在手机上的显示界面中提供的客服电话的快捷链接，来拨打当前APP的客服电话进行咨询。如果用户触发了客服电话的快捷链接，本申请实施例需要启动对该APP集成的智能设备的通话状态(例如，接通，或者未接通)的监听。
[0059]具体的，在监听所述APP所集成的智能设备的通话状态时，可以通过启动一个用于监听所述APP所集成的智能设备的通话状态的独立的监听线程的方式实现。智能设备的操作系统一般都开放有电话监听状态类接口，那么在APP中新建一个独立的监听线程调用该电话监听状态类接口，形成一个可读的新对象，然后该监听线程读取该对象的状态即可获得智能设备的通话状态。
[0060]步骤102:判断所述通话状态是否表示当前呼叫所述客服电话失败，如果是，则进入步骤103。
[0061]在监听通话状态的过程中，监听线程可以实时判断当前监听到的通话状态是否表示当前呼叫客服电话失败。具体在实现时，可以通过在通话状态发生了从空闲到繁忙再到空闲的变化的情况下，判断记录的当前呼叫客服电话的通话时间是否为零。例如，该线程监听到的通话状态从空闲(CALL_STATE_IDLE)变化到正拨打(CALL_STATE_0FFH00K)，又变化到空闲，如果是的话，则读取上一次的通话时间记录，如果通话时间大于零说明接通了，而如果通话时间等于零则说明没有接通，即当前呼叫客服电话失败。
[0062]需要说明的是，在本步骤中，如果没有判断得到当前呼叫客服电话失败，则不执行后续流程。
[0063]步骤103:依据所述用户操作所述当前APP的行为日志确定当前呼叫对应的APP问题。
[0064]如果监听线程判断得到用户打不通客服电话，则会将该用户拨打不通客服电话通知给APP，则APP可以依据用户近一段时间内操作APP的行为日志，来确定用户当前呼叫客服电话对应的APP问题。APP可以保存一段时间内用户的行为日志，具体可以根据APP的实际应用场景需求来设置不同的时间段，例如支付宝钱包可以保存I?3天内的行为日志。
[0065]可以理解的是，APP直接将用户行为日志存在本地即可实现本步骤。当然，APP也可以将用户行为日志同步到服务器端，那么，服务器端也可以根据APP同步的行为日志进行问题的定位。但是用户行为日志由于数据量较大，并且将用户行为日志同步到服务器端会耗费较多的流量和通信资源，因此，一般情况下由APP依据本地存储的用户行为日志进行判断即可。
[0066]本步骤具体实现时，可以采用以下方式:先通过分析所述当前APP的行为日志确定当前用户行为异常，再确定当前用户行为异常对应的APP问题。例如，对于支付宝钱包APP来讲，用户可能2天内在收银台页面上多次输入正确的支付密码都无法校验成功，那么就可以确定用户行为异常，并且该用户行为异常所对应的APP问题是支付密码校验失败的问题。
[0067]在实际应用中，可以预先将用户可能出现的异常行为与该异常行为确定出的APP问题，对应保存至一个特定的数据库中，等待后续执行步骤103的时候再去数据库中匹配即可。
[0068]步骤104:将所述APP问题发送至所述APP的服务器端。
[0069]将定位出的APP问题由APP应用系统与APP的客户服务系统建立的连接通道(通常有https协议连接、tcp协议连接，本方案不限各种协议连接方式，以建立通信连接为准)发送至APP的服务器端，例如，可以发送给APP的客服系统(第三方企业为客服人员服务用户提供的客户服务工作台)，在服务器端保存有各种APP问题所对应的答案，那么在其中就可以检索到当前APP的问题对应的答案。后续客服人员可以在看到答案之后，再将该答案通过短信、电话或者邮件等其他方式主动告知用户。
[0070]具体的，APP在将APP问题发送至APP的客服系统的时候，可以通过以下方式实现:
[0071]步骤Al:从预置的数据库中获取与所述当前APP问题对应的当前编码，所述数据库中保存有APP问题与编码的对应关系；
[0072]因为用汉字描述APP问题的时候，可能会使得数据量因为汉字过多而较大，所以APP可以预先为各种APP问题设置编码，例如，PO表示安全类的支付密码错误的问题，Pl表示查询类的信息查询失败的问题，等等。那么首先，APP可以从保存有APP问题与编码的对应关系的数据库中获取到与当前APP问题对应的当前编码。
[0073]步骤A2:将所述对应的当前编码发送至APP的服务器端。
[0074]再将当前编码发送至APP的客服系统，因为该过程传输的是编码了，因此就比传输汉字更为节省流量。
[0075]可以理解的是，在不同的实施例中，在步骤104之前还可以包括:
[0076]步骤100:在有多个APP问题的情况下,依据所述多个APP问题对应的问题等级对所述多个APP问题进行排序。
[0077]如果最终确定出的当前APP问题有多个，例如用户支付密码的输入有误，并且查询界面显示不正常，那么可以按照预先为APP问题划分的问题等级来对这多个APP问题进行排序。例如，安全类问题定义为最高级，包括支付密码的相关问题等，而查询类问题则可以定义为最低级，例如，查询界面显示不正常等。那么，如果当前多个APP问题有安全类问题也有查询类问题，则相应的将安全类问题排在查询类问题之前进行发送。
[0078]相应的步骤104就需要按照步骤100的排序顺序依次将所述多个APP问题发送至APP的客服系统。
[0079]按照顺序发送APP问题可以保证重要的问题可以优先发送给客服系统，这样就可以在节省传输资源及流量的前提下，为用户优先提供更重要的问题答案，从而使用户获得更好地使用体验。
[0080]参考图2所示，为本申请方法实施例在实际应用中的一个具体实例的信令图。其中的各个步骤在图1中均有对应的描述，在此不再赘述。
[0081]可见，在本申请实施例中，通过监听智能设备的通话状态可以使APP的客服系统在用户拨打不同客服电话的情况下，仍然能够获取到用户使用APP的相关操作信息，进一步的，也可以避免由于过多用户的重复拨打或者拨打不通而导致通信资源过多的浪费问题，再进一步的，还能提升用户使用智能设备中安装的APP的使用体验。
[0082]对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。
[0083]与上述本申请一种基于智能设备的呼叫处理方法实施例所提供的方法相对应，参见图3，本申请还提供了一种基于智能设备的呼叫处理装置实施例，在本实施例中，该装置可以包括:
[0084]监听模块301，用于响应于用户触发的呼叫当前应用程序APP对应的客服电话的请求，监听所述APP所集成的智能设备的通话状态。
[0085]其中，在不同的实施例中，所述监听模块301，具体可以包括:
[0086]启动子模块，用于启动一个独立