CN113542323A - 业务处理方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供一种业务处理方法、装置、设备及计算机可读存储介质，其中，方法包括：接收业务处理请求，所述业务处理请求包括应用程序中待处理业务的标识；根据所述标识确定所述待处理业务的业务类型；当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加RN标识；在组件运行环境下的组件库中，匹配与所述RN标识对应的业务组件；采用所述业务组件对所述RN业务进行处理。通过本申请，能够极大的减小RN业务对应的组件运行环境所占用的内存，从而提高应用程序的性能。

Description

业务处理方法、装置、设备及计算机可读存储介质

技术领域

本申请实施例涉及计算机技术领域，涉及但不限于一种业务处理方法、装置、设备及计算机可读存储介质。

背景技术

在基于跨平台移动应用开发框架(RN，React Native)开发应用程序时，每一应用程序中可以具有多个RN业务，也就是说可以将多个RN业务集成在原生应用中。

相关技术中，在将RN业务集成到原生应用中时，是使用编程语言(例如Object C)构建原生视图，并在原生视图中挂载RN业务。在实现的过程中，各个RN业务分别生成一个RN实例(例如视图实例)，各自在不同的视图、不同的运行环境中运行，并且由RN核心层提供运行环境与原生应用的视图界面之间的桥梁。

但是，相关技术中的方法，在启动多个RN业务时，其中每个RN业务包含了一个运行环境、一个原生视图、一个运行环境与原生视图之间的通信模块，当应用程序中嵌入了多个RN业务时，由于每个RN业务所包含的运行环境和通信模块会占用大量的内存，应用程序的性能会下降甚至崩溃。

发明内容

本申请实施例提供一种业务处理方法、装置、设备及计算机可读存储介质，通过在组件运行环境下的组件库中匹配出业务组件，并采用业务组件对RN业务进行处理，能够减小RN业务对应的组件运行环境所占用的内存，从而提高应用程序的性能。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种业务处理方法，包括：

接收业务处理请求，所述业务处理请求包括应用程序中待处理业务的标识；

根据所述标识确定所述待处理业务的业务类型；

当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加R N标识；

在组件运行环境下的组件库中，匹配出与所述RN标识对应的业务组件；

采用所述业务组件对所述RN业务进行处理。

本申请实施例提供一种业务处理装置，包括：

接收模块，用于接收业务处理请求，所述业务处理请求中包括待处理业务的标识；

确定模块，用于根据所述标识确定所述待处理业务的业务类型；

添加模块，用于当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加RN标识；

匹配模块，用于在组件运行环境下的组件库中，匹配出与所述RN标识对应的业务组件；

处理模块，用于采用所述业务组件对所述RN业务进行处理。

在一些实施例中，所述组件运行环境包括JS运行环境，其中，所述应用程序中的预设数量的所述RN业务，与同一个所述JS运行环境下的所述预设数量的业务组件一一对应，且每一所述RN业务与一个业务组件之间建立通信连接。

在一些实施例中，所述RN标识包括上报标识；所述处理模块还用于：

当所述RN业务为脚本异常上报业务、产品数据上报业务和事件交互业务中的任意一种时，采用所述业务组件确定所述RN业务的上报接口和回调业务；

通过所述上报接口，采用所述回调业务对携带有所述上报标识的所述RN业务进行上报。

在一些实施例中，所述装置还包括：

创建模块，用于在所述组件运行环境下创建业务框架层，所述业务框架层中包括至少一个业务组件；

存储模块，用于将所述至少一个业务组件存储于所述组件运行环境下的组件库中。

在一些实施例中，所述处理模块还用于：

通过通信模块建立所述业务组件与所述RN业务之间的通信；

在所述业务组件与所述RN业务之间正常通信后，采用所述业务组件对所述RN业务进行处理。

在一些实施例中，所述处理模块还用于：

将所述RN业务挂载于所述应用程序的任一视图中；

通过通信模块建立所述业务组件与所述视图之间的通信，以使得所述业务组件对所述视图中的RN业务进行处理。

在一些实施例中，所述装置还包括：

新建模块，用于当在所述组件运行环境下的组件库中，不能匹配出与所述RN标识对应的业务组件时，新建与所述RN标识对应的目标业务组件；

更新模块，用于将所述目标业务组件更新至所述组件库中。

本申请实施例提供一种业务处理设备，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现上述的方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现上述的方法。

本申请实施例具有以下有益效果：

当确定出待处理业务为RN业务时，为RN业务添加RN标识；在组件运行环境下的组件库中，匹配出与RN标识对应的业务组件，并采用业务组件对RN业务进行处理。由于采用RN标识匹配出的业务组件对RN业务进行处理，且业务组件存储于组件运行环境下的组件库中，也就是说，在同一组件运行环境下存在一组件库，组件库中包括多个组件，每一组件能够对应处理一个RN业务，即同一应用程序的多个RN业务可以在一个组件运行环境中匹配出对应的业务组件，如此，无需对应多个RN业务部署多套运行环境，从而能够极大的减小RN业务对应的组件运行环境所占用的内存，提高应用程序的性能。

附图说明

图1是相关技术中集成RN业务的原理图；

图2A是本申请实施例提供的业务处理系统20的一个可选的架构示意图；

图2B是本申请实施例提供的业务处理系统20应用于区块链系统的一个可选的结构示意图；

图2C是本申请实施例提供的区块结构的一个可选的示意图；

图3是本申请实施例提供的服务器300的结构示意图；

图4是本申请实施例提供的业务处理方法的一个可选的流程示意图；

图5是本申请实施例提供的容器云的应用场景示意图；

图6A是本申请实施例提供的一种开发环境的结构示意图；

图6B是本申请实施例提供的另一种开发环境的结构示意图；

图7是本申请实施例提供的业务处理方法的一个可选的流程示意图；

图8是本申请实施例提供的业务处理方法的一个可选的流程示意图；

图9是本申请实施例提供的业务处理方法的应用场景示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)React Native(缩写为RN)：是一种开源的跨平台移动应用开发框架，是开源的编程语言(JS，JavaScript)框架React在原生移动应用平台的衍生产物，支持iOS和安卓两大平台。RN使用JavaScript语言，类似于超级文本标记语言(HTML，Hyper Text MarkupLanguage)的JSX(一种JavaScript的语法扩展)，以及层叠样式表(CSS，Cascading StyleSheets)来开发移动应用。

2)JSCore(即JavaScriptCore)：本申请中是指组件运行环境，是开源的浏览器引擎(WebKit)默认内嵌的JS引擎，用来对JavaScript代码进行词法分析、语法分析以及解释执行。JSCore建立起了扩充C的面向对象编程语言(ObjC，Objective-C)和JavaScript两门语言之间沟通的桥梁。

3)Objective C：通常写作ObjC和较少用的Obj-C，是扩充C的面向对象编程语言，用于编写IOS操作系统的应用程序。

4)实例：在面向对象程序设计中，“类”在实例化之后叫做一个“实例”。“类”是静态的，不占进程内存，而“实例”拥有动态内存。

为了更好地理解本申请实施例中提供的业务处理方法，首先对相关技术中的业务处理方法进行说明：

在基于RN开发框架开发应用程序时，RN官方提供了把RN业务集成到原生应用的方案：使用Object C构建原生视图，并在原生视图中挂载RN业务。在实现的过程中，各个RN业务分别生成一个视图实例，各自在不同的视图、不同的JS运行环境中运行，并且由RN核心层提供运行环境与原生应用的视图界面之间的桥梁。业务之间没有各自环境污染的问题，不同团队开发各自的RN业务不需要考虑冲突问题。

图1是相关技术中集成RN业务的原理图，如图1所示，在一个应用程序(APP)10中集成有多个RN实例(即视图实例)101，每个RN实例101中实现一个RN业务102。在启动多个RN业务102时，其中每个RN业务102包含了一个运行环境103、一个原生视图104、一个运行环境103与原生视图104之间的通信模块(RTCBridge)105，即每个RN业务102会生成一个RN实例101，在这个RN实例101中包括一个运行环境103、一个原生视图104、一个运行环境与原生视图之间的通信模块105，并且，在这个原生视图104中挂载该RN业务102。

由于每一个RN业务会占用对应的RN实例的整个生命周期，虽然相关技术中，每个业务与其他业务之间保持独立，但是在RN的技术实现中，由于每个RN业务均包含有一个通信模块和运行环境，因此，通信模块和运行环境占用了大量的内存。那么，如果一个应用程序中嵌入了多个RN业务，内存占用就会具有成倍的扩张趋势，应用程序的性能反而会下降甚至崩溃。

基于相关技术所存在的上述至少一个问题，本申请实施例提供一种业务处理方法，首先，根据待处理业务的标识确定待处理业务的业务类型；然后，当业务类型表明待处理业务为RN业务时，为RN业务添加RN标识；在组件运行环境下的组件库中，匹配出与RN标识对应的业务组件；最后，采用匹配出的业务组件对RN业务进行处理。如此，由于采用RN标识匹配出的业务组件对RN业务进行处理，且业务组件存储于组件运行环境下的组件库中，那么同一应用程序的多个RN业务可以在一个组件运行环境中匹配出对应的业务组件，因此能够极大的减小RN业务对应的组件运行环境所占用的内存，从而提高应用程序的性能。

下面说明本申请实施例提供的业务处理设备的示例性应用，本申请实施例提供的业务处理设备可以实施为笔记本电脑，平板电脑，台式计算机，移动设备(例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备)、智能机器人等任意的终端，也可以实施为服务器。下面，将说明业务处理设备实施为服务器时的示例性应用。

参见图2A，图2A是本申请实施例提供的业务处理系统20的一个可选的架构示意图。为支撑任意一种应用程序中的待处理业务，以实现对待处理业务进行处理，业务处理系统20中包括终端100、网络200和服务器300。其中，终端100上运行有应用程序，在实现本申请实施例的业务处理方法时，终端100接收用户输入的业务处理请求；并将业务处理请求通过网络200发送给服务器300，其中，业务处理请求包括应用程序中待处理业务的标识；服务器300根据标识确定待处理业务的业务类型；当业务类型表明待处理业务为RN业务时，为RN业务添加RN标识；并在组件运行环境下的组件库中，匹配出与RN标识对应的业务组件；采用业务组件对RN业务进行处理，并将业务处理结果通过网络200反馈给终端100；其中，业务处理结果在应用程序上可以以视图的形式展示，那么，终端100则可以在当前界面100-1上显示该视图，以向用户呈现待处理业务的业务处理结果。

本申请实施例涉及的业务处理系统20也可以是区块链系统的分布式系统201，参见图2B，图2B是本申请实施例提供的业务处理系统20应用于区块链系统的一个可选的结构示意图，其中，所述分布式系统201可以是由多个节点202(接入网络中的任意形式的计算设备，如服务器、用户终端)和客户端203形成的分布式节点，节点之间形成组成的点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，TransmissionControl Protocol)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点，节点包括硬件层、中间层、操作系统层和应用层。

参见图2B示出的区块链系统中各节点的功能，涉及的功能包括：

1)路由，节点具有的基本功能，用于支持节点之间的通信。

节点除具有路由功能外，还可以具有以下功能：

2)应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。

例如，应用实现的业务包括：

2.1)钱包，用于提供进行电子货币的交易的功能，包括发起交易(即，将当前交易的交易记录发送给区块链系统中的其他节点，其他节点验证成功后，作为承认交易有效的响应，将交易的记录数据存入区块链的临时区块中；当然，钱包还支持查询电子货币地址中剩余的电子货币。

2.2)共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的节点发送确认。

2.3)智能合约，计算机化的协议，可以执行某个合约的条款，通过部署在共享账本上的用于在满足一定条件时而执行的代码实现，根据实际的业务需求代码用于完成自动化的交易，例如查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于交易的合约，还可以执行对接收的信息进行处理的合约。

3)区块链，包括一系列按照产生的先后时间顺序相互接续的区块(Block)，新区块一旦加入到区块链中就不会再被移除，区块中记录了区块链系统中节点提交的记录数据。

4)共识(Consensus)，是区块链网络中的一个过程，用于在涉及的多个节点之间对区块中的交易达成一致，达成一致的区块将被追加到区块链的尾部，实现共识的机制包括工作量证明(PoW，Proof of Work)、权益证明(PoS，Pr oof of Stake)、股份授权证明(DPoS，Delegated Proof-of-Stake)、消逝时间量证明(PoET，Proof of Elapsed Time)等。

参见图2C，图2C是本申请实施例提供的区块结构(Block Structure)的一个可选的示意图，每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值，各区块通过哈希值连接形成区块链。另外，区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了相关的信息，用于验证其信息的有效性(防伪)和生成下一个区块。

参见图3，图3是本申请实施例提供的服务器300的结构示意图，图3所示的服务器300包括：至少一个处理器310、存储器350、至少一个网络接口320和用户接口330。服务器300中的各个组件通过总线系统340耦合在一起。可理解，总线系统340用于实现这些组件之间的连接通信。总线系统340除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图3中将各种总线都标为总线系统340。

处理器310可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口330包括使得能够呈现媒体内容的一个或多个输出装置331，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口330还包括一个或多个输入装置332，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器350可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器350可选地包括在物理位置上远离处理器310的一个或多个存储设备。存储器350包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器350旨在包括任意适合类型的存储器。在一些实施例中，存储器350能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统351，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块352，用于经由一个或多个(有线或无线)网络接口320到达其他计算设备，示例性的网络接口320包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

输入处理模块353，用于对一个或多个来自一个或多个输入装置332之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图3示出了存储在存储器350中的一种业务处理装置354，该业务处理装置354可以是服务器300中的业务处理装置，其可以是程序和插件等形式的软件，包括以下软件模块：接收模块3541、确定模块3542、添加模块3543、匹配模块3544和处理模块3545，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的业务处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specif ic Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic De vice)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

下面将结合本申请实施例提供的服务器300的示例性应用和实施，说明本申请实施例提供的图像处理方法。参见图4，图4是本申请实施例提供的业务处理方法的一个可选的流程示意图，将结合图4示出的步骤进行说明。

步骤S401，接收业务处理请求，业务处理请求包括应用程序中待处理业务的标识。

这里，业务处理请求可以是用户通过终端上的应用程序的客户端发送的，或者也可以是程序开发人员在开发新业务或者对业务进行更新的过程中发送的。业务处理请求用于请求对应用程序的至少一个业务进行处理，服务器接收到业务处理请求之后，对业务处理请求进行响应。

待处理业务的标识可以是待处理业务的名称、类型、ID等信息，通过待处理业务的标识可以区分待处理业务的类型。

步骤S402，根据标识确定待处理业务的业务类型。

这里，业务类型包括RN业务类型和非RN业务类型。由于RN业务的标识是待处理业务的名称、类型、ID等信息，因此，通过待处理业务的标识即可对待处理业务的业务类型进行初步判断。

步骤S403，当业务类型表明待处理业务为RN业务时，为RN业务添加R N标识。

这里，RN标识可以记为RNID，RNID用于使得服务器能够确定出当前激活或显示的是哪个业务。

RN业务是指基于RN开发框架进行开发的业务，RN业务可以是原生APP(NativeAPP)或者网络APP(Web APP)中的业务。这里以终端上的即时通信应用为例，RN业务可以是即时通信应用中的语音通话业务、文字聊天业务或者公众号文章推送业务。由于语音通话业务、文字聊天业务等这些业务，用户对业务的时效性要求较高，且对业务的效率很敏感，为了保证业务响应的速度和稳定性，因此，这些对时效性要求较高的业务可以是NativeAPP中的RN业务；而对于公众号文章推送业务，由于这些功能暂时不是用户的最基本需求，且公众号文章推送业务是在公众号维护等业务上进行调整和增加内容的业务，因此，业务的要求很灵活，所以可以采用内嵌Web网页的方式来实现，将用户引导进入自己和其它第三方的网站里，即RN业务可以是Web APP中的业务。

步骤S404，在组件运行环境下的组件库中，匹配与RN标识对应的业务组件。

组件运行环境是运行业务组件的环境，业务组件就是一些符合一定规范的类组合在一起所构成的，是相对于本申请实施例中的待处理业务来说的，业务组件可以一些特定的功能，比如本申请实施例中对RN业务进行处理的功能，以及，根据RN业务的类型确定业务流向和业务上报接口等功能。本申请实施例的业务组件属于常规组件的一种，可以与任意一种组件具有相同的数据结构，只是业务组件是对应于RN业务的RN标识，且负责对RN业务进行对应处理的组件。

组件(Component)是对数据和方法的简单封装。例如，在C++语音构建器(C++Builder)中，一个组件就是一个从TComponent派生出来的特定对象。组件可以有自己的属性和方法，属性是组件数据的简单访问者，方法则是组件的一些简单而可见的功能。使用组件可以实现拖放式编程、快速的属性处理以及真正的面向对象的设计。

本申请实施例中，业务组件存储于组件运行环境下的组件库中，当业务类型表明待处理业务为RN业务时，根据RN业务的RN标识在组件库中匹配出与该RN业务对应的业务组件。

步骤S405，采用业务组件对RN业务进行处理。

这里，在确定出业务组件之后，采用该业务组件对RN业务进行处理。需要说明的是，每一RN业务对应一个业务组件，在组件运行环境下，可以同时采用多个业务组件对多个RN业务同时进行处理。

本申请实施例提供的业务处理方法，当确定出待处理业务为RN业务时，为所述RN业务添加RN标识，在组件运行环境下的组件库中，匹配出与RN标识对应的业务组件，并采用业务组件对RN业务进行处理。由于采用业务组件对RN业务进行处理，且业务组件存储于组件运行环境下的组件库中，那么同一应用程序的多个RN业务可以在一个组件运行环境中匹配出对应的业务组件，如此，能够极大的减小RN业务对应的组件运行环境所占用的内存，从而提高应用程序的性能。

在一些实施例中，在对上述应用程序的RN业务进行开发时，可以在RN开发框架下进行程序的开发。在开发移动应用时，可以选择使用原生、纯基于Web或使用混合方法(即使用原生和基于Web的技术的组合)等，还可以使用Apache Cordova(或Adobe PhoneGap)等开源平台编写HTML、CSS和JS的跨平台混合应用。这些应用在原生Web视图(浏览器)中运行，所以看着就像Web应用，不过可以使用JS和一些Apache Cordova插件调用原生功能和API。

本申请实施例的业务处理方法还可以应用于容器技术中，在一个应用容器中，每个界面会包含一个或多个视图(和样式)、界面跳转导航、状态管理和数据模型，还有本地存储和网络请求等功能。其中，应用容器可以部署在容器云中，图5是本申请实施例提供的容器云的应用场景示意图，容器云50提供应用程序的镜像文件51的开发环境52、测试环境53和线上环境54，其中，开发环境52用于实现对应用程序的镜像文件51等进行开发和持续更新，测试环境53用于实现对所开发或所更新的镜像文件进行性能测试，线上环境54即发布环境，用于提供真实用户访问的环境，以实现用户通过终端55访问线上环境54，实现所开发应用程序的至少一个业务。

举例来说，所述应用程序可以是即时通信APP，那么，所述开发环境52可以为该即时通信APP的开发环境，所述测试环境53可以为该即时通信APP的测试环境，所述线上环境54可以为该即时通信APP的线上环境，所述容器云50则可以用来承载该即时通信APP后台的服务，例如，该即时通信APP的消息推送服务、朋友圈管理服务和聊天消息查询服务等。

容器云50可以从镜像仓库中获取镜像文件，以在开发环境52对镜像文件进行开发和持续更新，在测试环境53对镜像文件进行测试，或者在线上环境54对镜像文件对应的容器服务进行上线发布。

需要说明的是，应用程序的镜像文件51可以是对应用程序和其依赖的运行环境的封装。例如，镜像文件可以是文件系统格式，除了包括提供容器运行时所需的应用程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。

图6A是本申请实施例提供的一种开发环境的结构示意图，如图6A所示，应用程序的上述开发环境52可以包括组件运行环境61，组件运行环境61下包括业务框架层62，业务框架层62中包括至少一个业务组件621，通过业务组件621对应用程序中的RN业务63进行处理。

图6B是本申请实施例提供的另一种开发环境的结构示意图，如图6B所示，应用程序的上述开发环境52可以包括JS运行环境64，JS运行环境64下包括业务框架层65，业务框架层65中包括至少一个业务组件651，通过业务组件651对应用程序中的RN业务63进行处理，并且，应用程序中的预设数量的RN业务63，与同一个JS运行环境64下的预设数量的业务组件651一一对应，且每一RN业务63与一个业务组件651之间建立通信连接，也就是说，在业务框架层65中确定出的业务组件651的数量与RN业务63的数量相同。

图7是本申请实施例提供的业务处理方法的一个可选的流程示意图，如图7所示，在步骤S404之前，方法还包括以下步骤：

步骤S701，在组件运行环境下创建业务框架层，业务框架层中包括至少一个业务组件。

这里，在对待处理业务进行处理之前，预先创建业务框架层，业务框架层中包括至少一个业务组件，即预先在组件运行环境下创建至少一个业务组件，以实现通过预先创建的业务框架层中的业务组件对待处理业务进行处理。

本申请实施例中，由于组件运行环境下的业务框架层中包括至少一个用于对待处理业务进行处理的业务组件，因此，只需一套组件运行环境即可运行多个业务组件，即只需一套组件运行环境即可对多个待处理业务进行处理，而无需对应于每个待处理业务均部署一套运行环境，从而极大的降低了RN业务对应的组件运行环境所占用的内存，提高应用程序的性能。

步骤S702，将至少一个业务组件存储于组件运行环境下的组件库中。

请继续参照图7，在步骤S404之后，方法还包括以下步骤：

步骤S703，判断在组件运行环境下的组件库中，是否匹配到与RN标识对应的业务组件。当判断结果为是，则执行上述步骤S405；当判断结果为否，则执行步骤S704。

步骤S704，新建与RN标识对应的目标业务组件。

这里，当在组件运行环境下的组件库中不能匹配到与RN标识对应的业务组件时，需要新建业务组件，可以新建与RN标识对应的目标业务组件，即新建与RN业务对应的目标业务组件，以通过该目标业务组件对RN业务进行处理。

步骤S705，将目标业务组件更新至组件库中。

这里，将目标业务组件更新至组件库中，可以保证后续再次对RN业务进行业务处理时，可以在组件库中匹配到该目标业务组件。

请继续参照图7，在一些实施例中，步骤S405可以通过以下步骤实现：

步骤S706，通过通信模块建立业务组件与RN业务之间的通信。

这里，步骤S706可以通过以下步骤实现：

步骤S7061，将RN业务挂载于应用程序的任一视图中。

这里，每一视图中挂载一RN业务，这里的视图可以是应用程序中构建的原生视图(View)，也可以是HTML5页面视图。在一些实施例中，一个视图中可以挂载至少一个RN业务，每一RN业务与一个业务组件对应。

步骤S7062，通过通信模块建立业务组件与视图之间的通信，以使得业务组件对视图中的RN业务进行处理。

这里，可以由应用程序中RN实例的RN核心层提供业务组件与视图之间的连接桥梁，即建立通信模块实现业务组件与视图之间的通信，从而实现组件对视图中的RN业务进行处理，其中，这里的通信模块可以是实时通信桥梁(R TCBridge，Real-timeCommunications Bridge)。

步骤S707，在业务组件与RN业务之间正常通信后，采用业务组件对RN业务进行处理。

本申请实施例提供的业务处理方法，预先创建业务框架层，业务框架层中包括至少一个业务组件，这样在后期对RN业务进行处理时，可以在业务框架层中的组件库中匹配对应的业务组件，通过匹配到的业务组件进行RN业务处理，如此，只需一套组件运行环境即可运行多个业务组件，即只需一套组件运行环境即可对多个待处理业务进行处理，而无需对应于每个待处理业务均部署一套运行环境，从而极大的降低了RN业务对应的组件运行环境所占用的内存，提高应用程序的性能。

在一些实施例中，RN标识包括上报标识，该上报标识用于标识业务上报处理时的上报接口和上报路径。

图8是本申请实施例提供的业务处理方法的一个可选的流程示意图，如图8所示，步骤S405可以通过以下步骤实现：

步骤S801，为RN业务添加上报标识。

步骤S802，当RN业务为脚本异常上报业务、产品数据上报业务和事件交互业务中的任意一种时，采用业务组件确定RN业务的上报接口和回调业务。

这里，当RN业务对应的业务场景是脚本异常上报场景、产品数据上报场景和事件交互场景中的任意一种场景时，则可以采用本申请实施例的方法提供的业务组件来对RN业务进行处理，即RN业务会走到业务框架层，通过业务框架层中的业务组件来对RN业务进行处理，确定RN业务处理时的处理方式、业务上报接口、业务上报流程和回调业务等一系列处理流程相关的信息。

步骤S803，通过上报接口，采用回调业务，对携带有上报标识的RN业务进行上报。

这里，回调业务用于确定RN业务应该回调给哪个业务，并进一步地将R N业务回调给这个业务。本申请实施例中，在确定出上报接口之后，通过上报接口对RN业务进行上报，并且，由于确定出了回调业务，因此，可以采用回调业务来将RN业务回调给回调业务所确定出的应该回调到的业务。

上报标识用于标识业务上报处理时的上报接口和上报路径，在进行RN业务上报时，业务组件通过上报标识即可确定出上报接口和上报路径，进而采用该上报接口和上报路径对RN业务进行上报。

本申请实施例提供的业务处理方法，对应于三种不同的业务场景，均可以采用本申请实施例创建的业务框架层中的业务组件进行RN业务处理。另外，由于RN业务处理至少包括RN业务上报处理，并且RN业务中包括上报标识，那么，业务组件通过上报标识即可确定RN业务的上报接口和上报路径，从而能够基于所确定出的上报接口和上报路径进行RN业务上报，实现对RN业务的上报处理。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

本申请实施例提供一种业务处理方法，在避免相关技术中应用程序性能低下的问题的基础上，通过合并运行环境、拆分代码、逻辑隔离、约束开发规范等方式，提升运行性能，减少运行内存消耗，并且避免多团队开发、发布过程中的业务冲突，最大化地减少对业务的入侵。

本申请实施例的业务处理方法，重点在于解决与内存消耗相关的应用程序的性能问题，同时由于方案中会导致一些业务冲突的新问题，存在引发一些新的开发效率层面的新问题的可能，所以又采取了业务隔离方案来规避开发效率问题。

本申请实施例中，引入RN技术的直接动机是为了提升产品的性能，并且依赖React的“一处学习，处处编码”的思想优势，在现有的Web开发人员熟悉JS语言这一基础上，扩展开发技术栈，在无需开发使用和学习新语言的前提下，对产品透明地引入新的技术方案，提升产品体验。

本申请实施例的方案，主要涉及命令行界面(CLI，Command-line Interfac e)工具、组件仓库和自动化模块三部分，而私有npm(是随同NodeJS一起安装的包管理工具)、私有git(是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理)仓库和乐高平台均可以为本申请实施例的内部平台系统。

图9是本申请实施例提供的业务处理方法的应用场景示意图，如图9所示，在APP90中的一个RN实例91中包括组件运行环境92，组件运行环境92可以是JS运行环境，JS运行环境中包括一业务框架层921，业务框架层921中包括多个业务组件922。

请继续参照图9，一个RN实例91中还包括原生视图93和业务组件922与原生视图93之间的通信模块94，其中，每一原生视图93中挂载一个待处理的RN业务931，每一RN业务931在业务框架层921中对应一个业务组件922。由于原生视图93之间互相独立，因此实现了对原生视图93中挂载的RN业务931的业务隔离。

本申请实施例中，在JS运行环境中抽象一个业务框架层921，统一以下场景的上报出口(即上报接口)：脚本异常上报、产品数据上报、JS与Native事件交互。也就是说，所有业务在处理这三种业务场景的时候，统一会走到业务框架层921，业务框架层921决定当前属于哪个RN业务的上报，或者决定当前native事件该回调给哪个RN业务。

在一些实施例中，在实现业务渲染时，由native端为各个RN业务提供唯一的标识符号RNID(即RN业务的标识)；在实现业务切换时，业务框架层921通过RNID可以知道当前激活(或显示)的是哪个RN业务。

在一些实施例中，对于脚本异常场景，报错源(即jsbundle地址)与RNI D一一对应；对于数据上报场景，数据上报ID逻辑存在多个实例，每个业务的上报附带上报ID，由业务框架层921统一作上报处理；对于事件交互场景，事件的监听和回调处理统一由业务框架层921聚合，并由业务框架层921决定将时间分发给哪一个业务进行处理。

本申请实施例提供的业务处理方法，提高了RN业务中各式各样组件的开发效率，通过规范化管理加强了应用程序的可维护性。而随着组件的不断沉淀，继而减少开发人员在业务中重复的工作量，提高开发效率。在通过实际业务的沉淀，可以促使运营产品去借鉴其它历史业务的模式，尽可能的去复用从而达到更高的迭代效率，从而使得整个开发过程形成了一个良性循环。

下面继续说明本申请实施例提供的业务处理装置354实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器350的业务处理装置354中的软件模块可以是服务器300中的业务处理装置，包括：

接收模块3541，用于接收业务处理请求，所述业务处理请求中包括待处理业务的标识；

确定模块3542，用于根据所述标识确定所述待处理业务的业务类型；

添加模块3543，用于当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加RN标识；

匹配模块3544，用于在组件运行环境下的组件库中，匹配出与所述RN标识对应的业务组件；

处理模块3545，用于采用所述业务组件对所述RN业务进行处理。

在一些实施例中，所述组件运行环境包括JS运行环境，其中，所述应用程序中的预设数量的所述RN业务，与同一个所述JS运行环境下的所述预设数量的业务组件一一对应，且每一所述RN业务与一个业务组件之间建立通信连接。

在一些实施例中，所述RN标识包括上报标识；所述处理模块还用于：当所述RN业务为脚本异常上报业务、产品数据上报业务和事件交互业务中的任意一种时，采用所述业务组件确定所述RN业务的上报接口和回调业务；通过所述上报接口，采用所述回调业务，对携带有所述上报标识的所述RN业务进行上报。

在一些实施例中，所述装置还包括：创建模块，用于在所述组件运行环境下创建业务框架层，所述业务框架层中包括至少一个业务组件；存储模块，用于将所述至少一个业务组件存储于所述组件运行环境下的组件库中。

在一些实施例中，所述处理模块还用于：通过通信模块建立所述业务组件与所述RN业务之间的通信；在所述业务组件与所述RN业务之间正常通信后，采用所述业务组件对所述RN业务进行处理。

在一些实施例中，所述处理模块还用于：

将所述RN业务挂载于所述应用程序的任一视图中；

通过通信模块建立所述业务组件与所述视图之间的通信，以使得所述业务组件对所述视图中的RN业务进行处理。

在一些实施例中，所述装置还包括：

新建模块，用于当在所述组件运行环境下的组件库中，不能匹配出与所述RN标识对应的业务组件时，新建与所述RN标识对应的目标业务组件；

更新模块，用于将所述目标业务组件更新至所述组件库中。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图4示出的方法。

在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(FRAM，Ferromagnetic Random Access Memory)、只读存储器(ROM，R ead Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM，Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM，Compact Disk-Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(H TML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种业务处理方法，其特征在于，包括：

接收业务处理请求，所述业务处理请求包括应用程序中待处理业务的标识；

根据所述标识确定所述待处理业务的业务类型；

当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加RN标识；

在组件运行环境下的组件库中，匹配与所述RN标识对应的业务组件；

采用所述业务组件对所述RN业务进行处理。

2.根据权利要求1所述的方法，其特征在于，所述组件运行环境包括JS运行环境，其中，所述应用程序中的预设数量的所述RN业务，与同一个所述JS运行环境下的所述预设数量的业务组件一一对应，且每一所述RN业务与一个业务组件之间建立通信连接。

3.根据权利要求1所述的方法，其特征在于，所述RN标识包括上报标识；

所述采用所述业务组件对所述RN业务进行处理，包括：

当所述RN业务为脚本异常上报业务、产品数据上报业务和事件交互业务中的任意一种时，采用所述业务组件确定所述RN业务的上报接口和回调业务；

通过所述上报接口，采用所述回调业务对携带有所述上报标识的所述RN业务进行上报。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述组件运行环境下创建业务框架层，所述业务框架层中包括至少一个业务组件；

将所述至少一个业务组件存储于所述组件运行环境下的组件库中。

5.根据权利要求1所述的方法，其特征在于，所述采用所述业务组件对所述RN业务进行处理，包括：

通过通信模块建立所述业务组件与所述RN业务之间的通信；

在所述业务组件与所述RN业务之间正常通信后，采用所述业务组件对所述RN业务进行处理。

6.根据权利要求5所述的方法，其特征在于，所述通过通信模块建立所述业务组件与所述RN业务之间的通信，包括：

将所述RN业务挂载于所述应用程序的任一视图中；

通过通信模块建立所述业务组件与所述视图之间的通信，以使得所述业务组件对所述视图中的RN业务进行处理。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：

当在所述组件运行环境下的组件库中，不能匹配出与所述RN标识对应的业务组件时，新建与所述RN标识对应的目标业务组件；

将所述目标业务组件更新至所述组件库中。

8.一种业务处理装置，其特征在于，包括：

接收模块，用于接收业务处理请求，所述业务处理请求中包括待处理业务的标识；

确定模块，用于根据所述标识确定所述待处理业务的业务类型；

添加模块，用于当所述业务类型表明所述待处理业务为RN业务时，为所述RN业务添加RN标识；

匹配模块，用于在组件运行环境下的组件库中，匹配出与所述RN标识对应的业务组件；

处理模块，用于采用所述业务组件对所述RN业务进行处理。

9.一种业务处理设备，其特征在于，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至7任一项所述的方法。

Images