CN114185604B - 金融服务舱系统及其运用方法、装置、电子设备和介质 - Google Patents

Abstract

本公开关于一种金融服务舱系统及其运用方法、装置、电子设备和介质，属于移动互联网技术领域。其中，金融服务舱系统包括：第一操作系统平台的金融服务应用模块中每个功能应用的接口为应用标准接口，第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口；通信层的网络通信适配模块的接口为通信标准接口；第二操作系统平台的设备驱动模块通过第二操作系统平台通用接口、网络通信适配模块与第一操作系统平台通用接口通信，第一操作系统平台通用接口通过驱动标准接口驱动与驱动标准接口对应的功能应用，以实现第一操作系统平台与第二操作系统平台的交互。由此，该系统能够大大提高金融服务舱功能的迭代和交付，降低质量风险。

Description

金融服务舱系统及其运用方法、装置、电子设备和介质

技术领域

本公开涉及移动互联网技术领域，尤其涉及金融服务舱系统及其运用方法、装置、电子设备和介质。

背景技术

移动金融服务舱功能丰富，是一款由软件和硬件结合的产品，外观样式如图1所示，包括基础金融服务和基础控制服务。其中，基础金融服务可包括个人开户、信用卡、存折补登、账户明细等；基础控制服务可包括刷脸认证门禁、千人千面广告、AI对话式语音交互服务等。涉及的多种硬件设备可包括监控摄像头、密码键盘和身份证读取口。

随着金融服务舱在金融行业越来越广泛的应用，新的业务场景不断推出，接入的硬件厂商将越来越多。对于相同的业务场景，接入的硬件厂商不同，对应的硬件接口和逻辑也不同。由于硬件厂商的更换，将导致软件和硬件都要同时修改，这样会大大降低金融服务舱功能的迭代和交付，同时也会带来不必要的质量风险。

发明内容

本公开提供一种金融服务舱系统及其运用方法、装置、电子设备和介质，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种金融服务舱系统，包括：

第一操作系统平台，包括金融服务应用模块和第一操作系统平台适配模块；其中，所述金融服务应用模块包括多个功能应用，每个所述功能应用的接口为应用标准接口；所述第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口，所述多个所述驱动标准接口均与所述第一操作系统平台通用接口的一端相连；

通信层，包括网络通信适配模块，所述网络通信适配模块的接口为通信标准接口，所述通信标准接口的一端与所述第一操作系统平台通用接口的另一端相连；

第二操作系统平台，包括多个设备驱动模块和第二操作系统平台通用接口，所述第二操作系统平台通用接口的一端与所述通信标准接口的另一端相连，所述第二操作系统平台通用接口的另一端与每个所述设备驱动模块相连，所述设备驱动模块通过所述第二操作系统平台通用接口、所述网络通信适配模块与所述第一操作系统平台通用接口通信，所述第一操作系统平台通用接口通过所述驱动标准接口驱动与所述驱动标准接口对应的所述功能应用，以实现所述第一操作系统平台与所述第二操作系统平台的交互。

在本公开实施例的一种可能的实现方式中，所述第一操作系统平台与所述第二操作系统平台的交互过程包括：

所述第二操作系统平台的交互界面发送调用参数，并接收返回的根据所述调用参数生成的模块参数；

所述第二操作系统平台的交互界面通过调用所述第二操作系统平台通用接口向所述第一操作系统平台通用接口发送所述模块参数；

所述第一操作系统平台根据所述模块参数，调用硬件设备，并接收所述硬件设备反馈的处理结果；

所述第二操作系统平台的交互界面显示所述处理结果。

在本公开实施例的一种可能的实现方式中，所述第一操作系统平台根据所述模块参数，调用硬件设备，包括：

所述第一操作系统平台根据所述模块参数向硬件模块的管理服务模块发送调用硬件设备的请求；

通过所述硬件模块的管理服务模块查找所述调用模块设备的类名，并向所述第一操作系统平台反馈所述调用模块设备的类名；

所述第一操作系统平台调用所述调用模块设备的类名对应的所述驱动标准接口，以驱动对应的所述硬件设备的适配器；

所述第一操作系统平台接收所述硬件设备的适配器反馈的处理结果。

在本公开实施例的一种可能的实现方式中，每个所述金融服务应用模块均为封装的程序包，其中，不同的所述金融服务应用模块对应不同的所述程序包。

在本公开实施例的一种可能的实现方式中，多个所述功能应用包括语音识别、页面管理、设备信息生成、日志管理、文件生成和常用工具；

多个所述驱动标准接口包括身份证读卡接口、电子签名接口、存折打印接口和银行卡读卡接口。

根据本公开实施例的第二方面，提供一种金融服务舱系统的运行方法，所述方法包括：

发送调用参数，并接收返回的根据所述调用参数生成的模块参数；

向第一操作系统平台通用接口发送所述模块参数，以使第一操作系统平台根据所述模块参数调用硬件设备；

显示所述硬件设备反馈的处理结果。

根据本公开实施例的第三方面，提供一种金融服务舱系统的运行方法，所述方法包括：

根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求；

通过所述硬件模块的管理服务模块查找所述调用模块设备的类名，并反馈所述调用模块设备的类名；

调用所述调用模块设备的类名对应的所述驱动标准接口，以驱动对应的所述硬件设备的适配器；

接收所述硬件设备的适配器反馈的处理结果。

根据本公开实施例的第四方面，提供一种金融服务舱系统的运行装置，所述装置包括：

第一发送模块，被配置为发送调用参数，并接收返回的根据所述调用参数生成的模块参数；

第一调用模块，被配置为向第一操作系统平台通用接口发送所述模块参数，以使第一操作系统平台根据所述模块参数调用硬件设备；

显示模块，被配置为显示所述硬件设备反馈的处理结果。

根据本公开实施例的第五方面，提供一种金融服务舱系统的运行装置，所述装置包括：

第二发送模块，被配置为根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求；

查找模块，被配置为通过所述硬件模块的管理服务模块查找所述调用模块设备的类名，并反馈所述调用模块设备的类名；

第二调用模块，被配置为调用所述调用模块设备的类名对应的所述驱动标准接口，以驱动对应的所述硬件设备的适配器；

接收模块，被配置为接收所述硬件设备的适配器反馈的处理结果。

根据本公开实施例的第六方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现上述的金融服务舱系统的运行方法。

根据本公开实施例的第七方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述的金融服务舱系统的运行方法。

根据本公开实施例的第八方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述的金融服务舱系统的运行方法。

在本公开的实施例中，本公开实施例的金融服务舱系统，包括第一操作系统平台、通信层和第二操作系统平台，其中，第一操作系统平台包括金融服务应用模块和第一操作系统平台适配模块，金融服务应用模块包括多个功能应用，每个功能应用的接口为应用标准接口，第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口，多个驱动标准接口均与第一操作系统平台通用接口的一端相连；通信层包括网络通信适配模块，网络通信适配模块的接口为通信标准接口，通信标准接口的一端与第一操作系统平台通用接口的另一端相连；第二操作系统平台，包括多个设备驱动模块和第二操作系统平台通用接口，第二操作系统平台通用接口的一端与通信标准接口的另一端相连，第二操作系统平台通用接口的另一端与每个设备驱动模块相连，设备驱动模块通过第二操作系统平台通用接口、网络通信适配模块与第一操作系统平台通用接口通信，第一操作系统平台通用接口通过驱动标准接口驱动与驱动标准接口对应的功能应用，以实现第一操作系统平台与第二操作系统平台的交互。由此，该系统通过搭建一套适用于金融服务舱的一体化框架，在框架中，需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是现有技术中的金融服务舱的示意图；

图2是本公开第一实施例所示出的金融服务舱系统的方框示意图；

图3是本公开第一实施例所示出的金融服务舱系统的结构示意图；

图4是本公开第二实施例所示出的金融服务舱系统运行的时序图；

图5是本公开第三实施例所示出的金融服务舱系统运行的时序图；

图6是本公开第四实施例所示出的应用于第二操作系统平台的金融服务舱系统的运行方法的流程图；

图7是本公开第五实施例所示出的应用于第一操作系统平台的金融服务舱系统的运行方法的流程图；

图8是本公开第四实施例所示出的应用于第二操作系统平台的金融服务舱系统的运行装置的方框示意图；

图9是本公开第五实施例所示出的应用于第一操作系统平台的金融服务舱系统的运行装置的方框示意图；

图10是本公开第六实施例所示出的电子设备的结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

移动金融服务舱功能丰富，是一款由软件和硬件结合的产品，外观样式如图1所示，包括基础金融服务和基础控制服务。其中，基础金融服务可包括个人开户、信用卡、存折补登、账户明细等；基础控制服务可包括刷脸认证门禁、千人千面广告、AI对话式语音交互服务等。涉及的多种硬件设备可包括监控摄像头、密码键盘和身份证读取口。

随着金融服务舱在金融行业越来越广泛的应用，新的业务场景不断推出，接入的硬件厂商将越来越多。对于相同的业务场景，接入的硬件厂商不同，对应的硬件接口和逻辑也不同。由于硬件厂商的更换，将导致软件和硬件都要同时修改，这样会大大降低金融服务舱功能的迭代和交付，同时也会带来不必要的质量风险。

目前，对于金融服务舱这种硬件设备里的软硬件的交互，更多的是适配硬件厂商提供的硬件，比较局限，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，软件部分也要做相应的适配和修改，容易带来额外的工作量，也不利于软件的版本管理和升级。

为此，本公开提出了一种新的金融服务舱系统，本系统通过对金融服务舱中的软硬件接口进行标准化，这样在更换硬件厂商或者更换金融服务舱中的硬件的同时，不需要再次修改上层应用软件，这样能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险。

图2是本公开第一实施例所示出的金融服务舱系统的方框示意图。图3是本公开第一实施例所示出的金融服务舱系统的结构示意图。

如图2所示，本公开实施例的金融服务舱系统，包括：第一操作系统平台100、通信层200、第二操作系统平台300。

其中，第一操作系统平台100，包括金融服务应用模块和第一操作系统平台适配模块；其中，金融服务应用模块包括多个功能应用，每个功能应用的接口为应用标准接口；第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口，多个驱动标准接口均与第一操作系统平台通用接口的一端相连。通信层200，包括网络通信适配模块，网络通信适配模块的接口为通信标准接口，通信标准接口的一端与第一操作系统平台通用接口的另一端相连。第二操作系统平台300，包括多个设备驱动模块和第二操作系统平台通用接口，第二操作系统平台通用接口的一端与通信标准接口的另一端相连，第二操作系统平台通用接口的另一端与每个设备驱动模块相连，设备驱动模块通过第二操作系统平台通用接口、网络通信适配模块与第一操作系统平台通用接口通信，第一操作系统平台通用接口通过驱动标准接口驱动与驱动标准接口对应的功能应用，以实现第一操作系统平台100与第二操作系统平台300的交互。

在该实施例中，第一操作系统平台100可以为安卓平台或苹果平台，本公开的第一操作系统平台100是以安卓平台为例进行说明的，如图3所示，本公开的第二操作系统平台300以wins平台为例进行说明。

本公开实施例提出的金融服务舱的标准开发框架(即，金融服务舱系统)，支持Android原生开发，也支持HTML5、微应用开发的接入，该框架还支持MVP(Model ViewPresenter)的模式架构，其中，Model为模型层，负责管理数据的接口，模型的职责包括使用API、缓存数据、管理数据库等；View为视图层；Presenter为发布层，负责查询模型和更新视图，响应用户交互更新模型。

在框架中，需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效。

对开发页面进行抽象封装了相应的基类Activity和Fragment，例如，封装成了基类Base Activity和Base Fragment，并在基类Base Activity和Base Fragment中各自实现一些功能如状态栏颜色的设置、标题栏的设置和隐藏、页面的切换动画效果、页面的跳转、基本对话框的显示和隐藏、抽象方法指向页面布局id等等，开发者可以不需要单独实现各自的功能方法，只需要提供API直接调用即可。

另外，本公开的系统还标准化了以下接口，包括：语音识别、页面管理、设备信息生成、日志管理、文件生成和常用工具等等，应用标准接口封装具体如下：

语音识别：

语音识别大致包括语音的初始化、相关授权认证、语音转文字、语义处理等，因此将语音识别模块进行标准化，开发者无需知道语音识别的逻辑，只需要调起语音识别的应用标准接口即可。实现的大致过程如下：首先初始化某平台的SDK配置和相关授权验证，授权和初始化完成后，调用语音识别或者语音播报等API，识别出文字后，再把文字送到服务端进行语义处理，包括功能的跳转、界面展示的话术等等，根据服务端处理后的结果返回给调用者，调用者再根据结果进行页面上的处理和业务功能的逻辑处理。其中，在语音识别中一些异常情况也通过语音识别的应用标准接口进行回调返回，接口的回调在调用语音识别功能时，通过传入相关接口对象的实现类作为参数传入，常见的异常错误有识别错误、语音识别超时等，回调结束后，再调用相关停止、销毁语音的方法，完成语音识别的操作。

页面管理：

随着功能、场景的增多，页面复杂度相应增加，页面间的交互也变的复杂。跨越多个界面的处理、场景数据的传递等需要统一的管理，所以需要把相关的页面统一放到一个容器中，需要处理某一个具体界面时，通过页面索引到容器中找到对应的页面，此容器设计基于列表，对页面的存储、查找、获取、移除、销毁等进行封装。同时，封装内存管理的方法，内存管理即对页面的管理，对于频繁调用的页面，可能造成内存泄漏，通过此封装方法可解决。

设备信息生成：

提供金融服务舱的唯一标识编号。每台金融服务舱都需要一个唯一硬件标识，即物理的设备编号，因此，可以采用一定的生成规则生成设备编号，用于保障金融服务舱的唯一性，取每台金融服务舱的设备编号值(如果存在的话)，进行哈希计算后取哈希值，再转16进制，进行计算，最后整成相关位数的值；如果金融服务舱没有设备编号值，可以考虑取安卓设备上尽可能有值的部分，比如IMEI、androidId、SERIAL、设备uuid等并通过一系列算法后再经过哈希运算后，取其哈希值，转16进制，再整成相关位数的值；如果上面这些都没有值，则取金融服务舱系统的UUID随机生成一位系统随机数。经过以上处理，保证了这个金融服务舱的硬件标识有值且相对唯一。

日志管理：

基于实现Thread Uncaught Exception Handler接口的捕获异常，当异常发生时，来不及或者不方便看日志信息，也难以从众多日志信息中找出崩溃信息，有了日志管理工具后，当有异常导致应用莫名退出后，可以捕获并把相关信息写入sd卡文件中，方便日后查找出错信息，配合bugly(bugly是一个可提供问题页面截图、日志、机型、网络等信息的问题反馈工具)效果会更好。

文件生成：

封装提供PDF格式的文件生成接口，基于安卓Print Attributes和PrintDocument Adapter相关类来生成打印文件类型、尺寸和参数文件，生成的文件符合打印机打印标准，如44纸张的打印标准，此工具仅生成符合打印机打印的pdf文件，项目中以A4打印为标准，生成的pdf文件是标准的A4纸张尺寸打印文件，接入打印机时，直接打印此文件即可。

常用的工具：

此工具接口标准化的是处理大量的字符串，字符串需要正则、截取、去空等接口，在金融服务舱中经常用到的字符串处理有电话号码正则判断、金额处理、机构代码截取分离、币种类型的筛选和过滤、产品类型分析判断，把常用的字符串处理归类、抽取整合到一处，标准化后，减少了重复代码且使用灵活。

对于金融服务舱系统与硬件设备交互的通用接口：

针对软件部分与硬件设备的交互，封装了统一的标准化通用接口。外设驱动通过aidl(Android Interface Definition Language，Android接口定义语言)和金融服务舱内仓的功能应用通过服务绑定建立关联，再通过不同字段的信息来区分不同的服务请求，外设驱动作为提供服务方，内舱的金融服务应用作为调用方。用来区分不同的服务的请求对象需要实现Parcelable接口，请求对象封装了各种请求如获取身份证号码、银行卡号、调用打印机打印等，再把连接外设驱动和请求交互的类打包成程序包如jar包，供金融服务应用使用。即言，每个金融服务应用模块均为封装的程序包，其中，不同的金融服务应用模块对应不同的程序包。

在本公开的实施例中，第一操作系统平台100与第二操作系统平台300的交互过程包括：第二操作系统平台300的交互界面发送调用参数，并接收返回的根据调用参数生成的模块参数；第二操作系统平台300的交互界面通过调用第二操作系统平台通用接口向第一操作系统平台通用接口发送模块参数；第一操作系统平台100根据模块参数，调用硬件设备，并接收硬件设备反馈的处理结果；第二操作系统平台300的交互界面显示处理结果。

也就是说，在软件与硬件设备的交互流程中，由上层应用的软件界面触发，获取调用的硬件模块需要上送的模块参数，模块参数准备就绪后调用标准通用服务接口，通过aidl的服务这个纽带调起硬件设备工作，硬件设备完成指定任务后发起回调通知，将结果返回给上层应用。调用的时序如图4所示，包括：

1.第二操作系统平台的交互界面发送调用参数。

2.生成模块参数。

3.第二操作系统平台的交互界面接收返回的根据调用参数生成的模块参数。

4.第二操作系统平台的交互界面向安卓平台通用接口发送需要的调用通用接口。

5.安卓平台通用接口根据需要调用的硬件向硬件设备与相应的硬件设备通信。

6.硬件设备进行工作处理。

7.硬件设备返回硬件处理结果至安卓平台通用接口。

8.第二操作系统平台的交互界面接收返回结果。

金融舱硬件接口标准化，简单来说就是对金融舱接入的第三方硬件驱动程序进行封装，向上层软件部分提供标准通用接口，屏蔽底层实现细节，即把对第三方硬件的调用分成了两部分：一部分通过软件主应用(Client)；一部分通过服务进程(Service)提供服务调用支持。硬件标准化屏蔽了不同厂商硬件设备的差异，为上层软件主应用提供了统一的访问硬件设备的接口，不同的硬件厂商按照金融舱硬件标准化实现硬件的控制逻辑，上层软件主应用无须关心硬件设备的差异，只要按照金融舱硬件标准化提供的标准接口访问硬件设备即可。这样对于同一个上层软件主应用就可以运行在不同厂商的硬件设备上了。

实现原理如下：

金融舱硬件标准化把对第三方硬件的支持分成了两层，RPC Client层和RPCService层。RPC Service层为独立的apk主要用于封装第三方硬件驱动，针对不同的硬件有对应的apk实现。RPC Client层为aar库，主要提供调用硬件的通用方法。由于RPC Client层和RPC Service层属于不同应用，运行在不同的进程，所以它们之间的调用需跨进程调用。这里使用Android提供的跨进程调用方式：通过AIDL定义跨进程接口调用跨进程逻辑。

实现过程如下：

为了适配不同硬件，需要针对不同的硬件实现共同的硬件模块管理服务，此管理服务为一常住服务，并封装好获取硬件设备所需参数的方法。

在本公开的实施例中，第一操作系统平台100根据模块参数，调用硬件设备，包括：第一操作系统平台根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求；通过硬件模块的管理服务模块查找调用模块设备的类名，并向第一操作系统平台反馈调用模块设备的类名；第一操作系统平台调用调用模块设备的类名对应的驱动标准接口，以驱动对应的硬件设备的适配器；第一操作系统平台接收硬件设备的适配器反馈的处理结果。

也就是说，上层应用首先向硬件模块管理服务请求获取硬件模块，硬件模块管理服务会以硬件设备的类名为依据查找到硬件模块并返回给上层应用。上层应用调用windows通用硬件接口，经层层调用，最终会调用到硬件适配器的工作方法，驱动硬件进行工作，待硬件完成工作后返回结果给上层应用。实现的时序如图5所示，包括：

1.上层应用向硬件模块管理服务模块发送硬件调用请求。

2.硬件模块管理服务模块查找硬件模块，组成参数得到硬件模块类名。

3.硬件模块管理服务模块将硬件模块类名发送给上层应用。

4.上层应用通过调用硬件接口与硬件模块通信。

5.硬件模块调用硬件接口与硬件设备适配器相连。

6.硬件设备适配器进行硬件工作处理。

7.上层应用接收硬件设备适配器返回的结果。

由此，本公开针对不同的硬件设备和不同的软件开发工具包sdk、软硬件的数据交互主要是通过安卓平台适配模块、网络通信适配模块、windows平台设备驱动模块三个模块完成。

对于不同的硬件设备，传入不同的参数到windows平台设备驱动模块，将数据通过网络通信适配层将数据传输到安卓平台适配模块，同时安卓平台适配模块适配后，将数据按统一的标准数据送到应用软件模块。

本公开实施例，首先搭建了一套适用于金融服务舱的一体化框架，该框架有利于规范金融服务舱的软硬件开发。其次，对软硬件模块的交互和调用进行标准化，可以很好的简化交互流程，以及大大减少软硬件开发的成本和迭代复杂度。

综上所述，在本公开的实施例中，本公开实施例的金融服务舱系统，包括第一操作系统平台、通信层和第二操作系统平台，其中，第一操作系统平台包括金融服务应用模块和第一操作系统平台适配模块，金融服务应用模块包括多个功能应用，每个功能应用的接口为应用标准接口，第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口，多个驱动标准接口均与第一操作系统平台通用接口的一端相连；通信层包括网络通信适配模块，网络通信适配模块的接口为通信标准接口，通信标准接口的一端与第一操作系统平台通用接口的另一端相连；第二操作系统平台，包括多个设备驱动模块和第二操作系统平台通用接口，第二操作系统平台通用接口的一端与通信标准接口的另一端相连，第二操作系统平台通用接口的另一端与每个设备驱动模块相连，设备驱动模块通过第二操作系统平台通用接口、网络通信适配模块与第一操作系统平台通用接口通信，第一操作系统平台通用接口通过驱动标准接口驱动与驱动标准接口对应的功能应用，以实现第一操作系统平台与第二操作系统平台的交互。由此，该系统通过搭建一套适用于金融服务舱的一体化框架，在框架中，需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

图6是本公开第四实施例所示出的应用于第二操作系统平台的金融服务舱系统的运行方法的流程图。

需要说明的是，本公开实施例的金融服务舱系统的运行方法的执行主体为第二操作系统平台。

如图6所示，本公开实施例的金融服务舱系统的运行方法，包括以下步骤：

S601，发送调用参数，并接收返回的根据调用参数生成的模块参数。

S602，向第一操作系统平台通用接口发送模块参数，以使第一操作系统平台根据模块参数调用硬件设备。

S603，显示硬件设备反馈的处理结果。

也就是说，在软件与硬件设备的交互流程中，由上层应用的软件界面触发，获取调用的硬件模块需要上送的模块参数，模块参数准备就绪后调用标准通用服务接口，通过aidl的Service Connection这个纽带调起硬件设备工作，硬件设备完成指定任务后发起回调通知，将结果返回给上层应用，调用的时序如图4所示。

需要说明的是，本公开实施例的金融服务舱系统的运行方法中未披露的细节，请参考本公开实施例的金融服务舱系统。

综上，根据本公开实施例的金融服务舱系统的运行方法，第二操作系统平台发送调用参数，并接收返回的根据调用参数生成的模块参数，第二操作系统平台调用第二操作系统平台通用接口向第一操作系统平台通用接口发送模块参数，以使第一操作系统平台根据模块参数调用硬件设备，第二操作系统平台显示硬件设备反馈的处理结果。由此，本公开的金融服务舱的一体化框架，只需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

图7是本公开第五实施例所示出的应用于第一操作系统平台的金融服务舱系统的运行方法的流程图。

需要说明的是，本公开实施例的金融服务舱系统的运行方法的执行主体为第一操作系统平台。

如图7所示，本公开实施例的金融服务舱系统的运行方法，包括以下步骤：

S701，根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求。

S702，通过硬件模块的管理服务模块查找调用模块设备的类名，并反馈调用模块设备的类名。

S703，调用调用模块设备的类名对应的驱动标准接口，以驱动对应的硬件设备的适配器。

S704，接收硬件设备的适配器反馈的处理结果。

也就是说，上层应用首先向硬件模块管理服务请求获取硬件模块，硬件模块管理服务会以硬件设备的类名为依据查找到硬件模块并返回给上层应用。上层应用调用windows通用硬件接口，经层层调用，最终会调用到硬件适配器的工作方法，驱动硬件进行工作，待硬件完成工作后返回结果给上层应用。实现的时序如图5所示。

需要说明的是，本公开实施例的金融服务舱系统的运行方法中未披露的细节，请参考本公开实施例的金融服务舱系统。

综上，根据本公开实施例的金融服务舱系统的运行方法，第一操作系统平台根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求，第一操作系统平台通过硬件模块的管理服务模块查找调用模块设备的类名，并反馈调用模块设备的类名，第一操作系统平台调用调用模块设备的类名对应的驱动标准接口，以驱动对应的硬件设备的适配器，第一操作系统平台接收硬件设备的适配器反馈的处理结果。由此，本公开的金融服务舱的一体化框架，只需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

图8是本公开第四实施例所示出的应用于第二操作系统平台的金融服务舱系统的运行装置的方框示意图。

需要说明的是，本公开实施例的金融服务舱系统的运行装置应用于第二操作系统平台。

如图8所示，本公开实施例的金融服务舱系统的运行装置80，包括：第一发送模块81、第一调用模块82和显示模块83。

其中，第一发送模块81被配置为发送调用参数，并接收返回的根据调用参数生成的模块参数。第一调用模块82被配置为向第一操作系统平台通用接口发送模块参数，以使第一操作系统平台根据模块参数调用硬件设备。显示模块83被配置为显示硬件设备反馈的处理结果。

需要说明的是，本公开实施例的金融服务舱系统的运行装置中未披露的细节，请参考本公开实施例的金融服务舱系统的运行方法中所披露的细节，具体这里不再详述。

根据本公开实施例的金融服务舱系统的运行装置，通过第一发送模块发送调用参数，并接收返回的根据调用参数生成的模块参数，通过第一调用模块调用第二操作系统平台通用接口向第一操作系统平台通用接口发送模块参数，以使第一操作系统平台根据模块参数调用硬件设备，通过显示模块显示硬件设备反馈的处理结果。由此，本公开的金融服务舱的一体化框架，只需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

图9是本公开第五实施例所示出的应用于第一操作系统平台的金融服务舱系统的运行装置的方框示意图。

需要说明的是，本公开实施例的金融服务舱系统的运行装置应用于第一操作系统平台。

如图9所示，本公开实施例的金融服务舱系统的运行装置90，包括：第二发送模块91、查找模块92、第二调用模块93和接收模块94。

其中，第二发送模块91被配置为根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求。查找模块92被配置为通过硬件模块的管理服务模块查找调用模块设备的类名，并反馈调用模块设备的类名。第二调用模块93被配置为调用调用模块设备的类名对应的驱动标准接口，以驱动对应的硬件设备的适配器。接收模块94被配置为接收硬件设备的适配器反馈的处理结果。

需要说明的是，本公开实施例的金融服务舱系统的运行装置中未披露的细节，请参照本公开实施例的金融服务舱系统的运行方法中所披露的细节，具体这里不再详述。

根据本公开实施例的金融服务舱系统的运行装置，通过第二发送模块根据模块参数向硬件模块的管理服务模块发送调用硬件设备的请求，通过查找模块通过硬件模块的管理服务模块查找调用模块设备的类名，并反馈调用模块设备的类名，通过第二调用模块调用调用模块设备的类名对应的驱动标准接口，以驱动对应的硬件设备的适配器，通过接收模块接收硬件设备的适配器反馈的处理结果。由此，本公开的金融服务舱的一体化框架，只需要对开发需要用到的常见模块进行标准化，封装常用的工具类、适用于金融服务舱系统的通信模块、以及相关功能接口，这样就不需要重写相关代码，只需要继承这些父类，就可以完成绝大部分的功能开发，同时也支持对相应属性、方法的重新设置和修改，从而达到功能开发过程的便捷、高效，有利于规范金融服务舱的软硬件开发；通过对软硬件模块的交互和调用进行标准化，如果要更换硬件厂商或者更换(如新增)金融服务舱中的硬件，不需要再次修改上层应用软件，这样可以很好的简化交互流程，大大减少软硬件开发的成本和迭代复杂度，能够大大提高金融服务舱功能的迭代和交付，同时降低了质量风险，并且利于软件的版本管理和升级。

为了实现上述实施例，本公开还提出了一种电子设备。

其中，该电子设备，包括处理器和用于存储处理器可执行指令的存储器；其中，处理器被配置为为执行指令，以实现上述的应用于第二操作系统平台的金融服务舱系统的运行或者应用于第一操作系统平台的金融服务舱系统的运行。

为了实现上述实施例，本公开还提出了一种存储介质。

其中，当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述的应用于第二操作系统平台的金融服务舱系统的运行或者应用于第一操作系统平台的金融服务舱系统的运行。

为了实现上述实施例，本公开还提供一种计算机程序产品。

其中，该计算机程序由电子设备的处理器执行时，使得电子设备能够执行上述的应用于第二操作系统平台的金融服务舱系统的运行或者应用于第一操作系统平台的金融服务舱系统的运行。

图10是根据一示例性实施例示出的一种电子设备框图。图10示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图10所示，电子设备100包括处理器101，其可以根据存储在只读存储器(ROM，Read Only Memory)102中的程序或者从存储器106加载到随机访问存储器(RAM，RandomAccess Memory)103中的程序而执行各种适当的动作和处理。在RAM 103中，还存储有电子设备100操作所需的各种程序和数据。处理器101、ROM 102以及RAM 103通过总线104彼此相连。输入/输出(I/O，Input/Output)接口105也连接至总线104。

以下部件连接至I/O接口105：包括硬盘等的存储器106；以及包括诸如LAN(局域网，Local Area Network)卡、调制解调器等的网络接口卡的通信部分107，通信部分107经由诸如因特网的网络执行通信处理；驱动器108也根据需要连接至I/O接口105。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分107从网络上被下载和安装。在该计算机程序被处理器101执行时，执行本公开的方法中限定的上述功能。

在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由电子设备100的处理器101执行以完成上述方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (5)

1.一种金融服务舱系统，其特征在于，包括：

第一操作系统平台，包括金融服务应用模块和第一操作系统平台适配模块；其中，所述金融服务应用模块包括多个功能应用，每个所述功能应用的接口为应用标准接口；所述第一操作系统平台适配模块包括多个驱动标准接口和第一操作系统平台通用接口，所述多个所述驱动标准接口均与所述第一操作系统平台通用接口的一端相连；

通信层，包括网络通信适配模块，所述网络通信适配模块的接口为通信标准接口，所述通信标准接口的一端与所述第一操作系统平台通用接口的另一端相连；

第二操作系统平台，包括多个设备驱动模块和第二操作系统平台通用接口，所述第二操作系统平台通用接口的一端与所述通信标准接口的另一端相连，所述第二操作系统平台通用接口的另一端与每个所述设备驱动模块相连，所述设备驱动模块通过所述第二操作系统平台通用接口、所述网络通信适配模块与所述第一操作系统平台通用接口通信，所述第一操作系统平台通用接口通过所述驱动标准接口驱动与所述驱动标准接口对应的所述功能应用，以实现所述第一操作系统平台与所述第二操作系统平台的交互。

2.如权利要求1所述的金融服务舱系统，其特征在于，所述第一操作系统平台与所述第二操作系统平台的交互过程包括：

所述第二操作系统平台的交互界面发送调用参数，并接收返回的根据所述调用参数生成的模块参数；

所述第二操作系统平台的交互界面通过调用所述第二操作系统平台通用接口向所述第一操作系统平台通用接口发送所述模块参数；

所述第一操作系统平台根据所述模块参数，调用硬件设备，并接收所述硬件设备反馈的处理结果；

所述第二操作系统平台的交互界面显示所述处理结果。

3.如权利要求2所述的金融服务舱系统，其特征在于，所述第一操作系统平台根据所述模块参数，调用硬件设备，包括：

所述第一操作系统平台根据所述模块参数向硬件模块的管理服务模块发送调用硬件设备的请求；

通过所述硬件模块的管理服务模块查找调用模块设备的类名，并向所述第一操作系统平台反馈所述调用模块设备的类名；

所述第一操作系统平台调用所述调用模块设备的类名对应的所述驱动标准接口，以驱动对应的所述硬件设备的适配器；

所述第一操作系统平台接收所述硬件设备的适配器反馈的处理结果。

4.如权利要求1所述的金融服务舱系统，其特征在于，每个所述金融服务应用模块均为封装的程序包，其中，不同的所述金融服务应用模块对应不同的所述程序包。

5.如权利要求1所述的金融服务舱系统，其特征在于，其中，

多个所述功能应用包括语音识别、页面管理、设备信息生成、日志管理、文件生成和常用工具；

多个所述驱动标准接口包括身份证读卡接口、电子签名接口、存折打印接口和银行卡读卡接口。

Images