直播应用程序的管理方法及装置与流程

本申请涉及互联网技术领域，尤其涉及直播应用程序的管理方法及装置。

背景技术：

网络直播技术是一种服务端将主播用户的直播视频数据广播至多个观众用户进行观看的互联网技术。越来越多的用户选择在移动终端在安装直播服务商提供的直播应用程序，通过直播应用程序参与直播活动。

在直播应用程序件中，通常会涉及多种不同的业务功能，例如直播间里有秀场、现场、玩唱会或电竞等业务功能，或者当直播间有重要活动(如年度盛典、情人节活动、新年活动、圣诞活动等)时，也需要开发新的业务功能。相关技术中，当有业务功能更新时，通常是由直播服务端发布新版本的应用程序，由用户在终端中下载安装新的应用程序。此种方式，一方面操作比较繁琐；另一方面，无法保证所有用户都会进行应用程序更新，使得新的业务功能无法推广。

技术实现要素：

为克服相关技术中存在的问题，本申请提供了直播应用程序的管理方法及装置。

根据本申请实施例的第一方面，提供一种直播应用程序的管理方法，所述方法包括：

接收直播服务端所发送的直播业务更新指令；

在直播业务更新指令的指示下，从直播服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他直播业务插件对应的数据包；

动态加载所获取的数据包，将对应的所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。

可选的，所述数据包中包括资源，在动态加载所获取的数据包时，通过如下方式加载所述资源：

通过反射机制调用操作系统的资源管理器的成员函数，将所述资源的路径提供给所述成员函数，并利用所述成员函数为所述资源创建资源对象，完成所述资源的动态加载。

可选的，所述数据包中包括类文件，在动态加载所获取的数据包时，通过如下方式加载所述类文件：

通过操作系统的类加载器加载所述类文件，并执行所述类文件，完成所述类文件的动态加载。

可选的，所述方法还包括：

在所述直播业务插件运行时，通过如下方式进行插件项目的生命周期的回调：

通过应用程序的主项目代理执行所述直播业务插件的插件项目，以进行插件项目的生命周期的回调；和/或

通过反射机制，将ActivityThread中的成员变量mInstrumentation的实例替换为插件项目的实例，通过重写Instrumentation的newActivty方法来实现插件项目的实例化，以利用所述mInstrumentation进行插件项目的生命周期的回调。

可选的，所述方法还包括：

在动态加载所获取的数据包前，对所述数据包进行安全验证。

根据本申请实施例的第二方面，提供一种直播应用程序的管理装置，所述装置包括：

指令接收模块，用于：接收直播服务端所发送的直播业务更新指令；

数据包获取模块，用于：在直播业务更新指令的指示下，从直播服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他直播业务插件对应的数据包；

加载模块，用于：动态加载所获取的数据包，将所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。

可选的，所述数据包中包括资源，所述加载模块，包括资源加载子模块，用于在动态加载所获取的数据包时，通过如下方式加载所述资源：

通过反射机制调用操作系统的资源管理器的成员函数，将所述资源的路径提供给所述成员函数，并利用所述成员函数为所述资源创建资源对象，完成所述资源的动态加载。

可选的，所述数据包中包括类文件，所述加载模块，包括类文件加载模块，用于在动态加载所获取的数据包时，通过如下方式加载所述类文件：

通过操作系统的类加载器加载所述类文件，并执行所述类文件，完成所述类文件的动态加载。

可选的，所述装置还包括回调模块，用于：

在所述直播业务插件运行时，通过如下方式进行插件项目的生命周期的回调：

通过应用程序的主项目代理执行所述直播业务插件的插件项目，以进行插件项目的生命周期的回调；和/或

通过反射机制，将ActivityThread中的成员变量mInstrumentation的实例替换为插件项目的实例，通过重写Instrumentation的newActivty方法来实现插件项目的实例化，以利用所述mInstrumentation进行插件项目的生命周期的回调。

可选的，所述装置还包括安全验证模块，用于：在动态加载所获取的数据包前，对所述数据包进行安全验证。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请中，可以接收直播服务端所发送的直播业务更新指令；在直播业务更新指令的指示下，从服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他功能的直播业务插件；动态加载所述数据包，将所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。本实施例中，通过将业务功能开发为独立的数据包，在应用程序需要更新时，应用程序可以自动下载数据包并进行动态加载，因此不需要安装新版本的应用程序，能减少用户操作，给用户提供了便利，防止用户流失。

通过应用本实施例的直播应用程序的管理方案，直播服务商可以根据不同的业务需求，快速更新业务插件。当直播应用程序出现问题时，能在线更新插件，修复问题。并且，可以减少频繁发版的过程，解决新版本用户覆盖率低的过程。还可以减少用户应版本升级，繁琐的安装操作过程。同时，还可以解决安装包体积不断变大的问题，提升手机客户端的用户体验，增加直播应用程序的高可用性。通过上述方案，开发人员可以将业务模块尽可能抽象出来，并能在一个独立工程中开发，减低耦合，也减少在同一个工程项目中开发所带来的代码冲突。

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

附图说明

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

图1A是本申请根据一示例性实施例示出的一种直播应用程序的管理方法的应用场景示意图。

图1B是本申请根据一示例性实施例示出的一种直播应用程序的界面示意图。

图2是本申请根据一示例性实施例示出的一种直播应用程序的管理方法的流程图。

图3是本申请根据一示例性实施例示出的一种直播应用程序的管理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1A所示，是本申请根据一示例性实施例示出的一种直播应用程序的管理方法的应用场景示意图，图1A中包括作为服务端设备的服务器、以及作为客户端设备的智能手机和平板电脑。其中，客户端设备还可以是PDA(Personal Digital Assistant，个人数字助理)、多媒体播放器、可穿戴设备等智能设备。

直播应用程序中，根据不同的业务需求，会涉及秀场、现场、玩唱会或电竞等不同的直播业务功能；或者，当直播间有重要活动(如年度盛典、情人节活动、新年活动、圣诞活动等)时，直播应用程序中也会提供较多的业务功能。如图1B所示，是本申请根据一示例性实施例示出的一种直播应用程序的界面示意图，图1B中示出了直播应用程序中的四种不同的业务功能。

相关技术中，若直播业务有更新，通常需要在原应用程序的基础上迭代开发，发布新版本的应用程序，由用户在终端中下载并安装。此种方式下，需要用户手动升级安装新版本，新版本应用程序的更新过程较为繁琐；由于用户并不一定都会主动升级安装新版本，因此新版本的用户覆盖率往往也无法保证，甚至还会导致用户流失。

实际应用中还经常出现如下情况：在应用开发过程中，对于一种业务需求可能会有多种设计方案，当无法确定哪种方案是最优的时候，可能会通过多次的版本迭代发布试错，然后观察用户使用的统计数据，进而选择最多用户使用的方案，这个过程为A/B TEST过程。由于每次都需要发布新版本的应用程序，该过程较为漫长，且覆盖率较低。

而本申请实施例中所提供的方案，可以接收直播服务端所发送的直播业务更新指令；在直播业务更新指令的指示下，从服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他功能的直播业务插件；动态加载所述数据包，将所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。本实施例中，通过将业务功能开发为独立的数据包，在应用程序需要更新时，应用程序可以后台下载数据包并进行动态加载，因此不需要安装新版本的应用程序，能减少用户操作，给用户提供了便利，防止用户流失。接下来对本申请实施例进行详细说明。

如图2所示，图2是本申请根据一示例性实施例示出的一种直播应用程序的管理方法的流程图，可应用于智能设备，包括以下步骤201至203：

在步骤201中，接收直播服务端所发送的直播业务更新指令。

在步骤202中，在直播业务更新指令的指示下，从直播服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他功能的直播业务插件。

在步骤203中，动态加载所获取的数据包，将对应的所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。

本申请实施例中，智能设备可以为智能手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、电子书阅读器、智能手表、多媒体播放器等等。当然，本申请实施例也不排除在计算机上的应用。通常，智能设备中安装有操作系统，操作系统是管理和控制计算机硬件与软件资源的计算机程序，是直接运行在设备上的最基本的系统软件，任何其他应用软件须在操作系统的支持下才能运行。常见的智能设备的操作系统包括有Android(安卓)操作系统、iOS(苹果公司开发的手持设备操作系统)、Linux操作系统或Windows操作系统等。

本实施例的直播应用程序，由直播服务商提供，并由用户安装于智能设备中。直播业务插件，是指没有被安装且希望借助已经安装到智能设备上的直播应用程序，通过该直播应用程序运行的插件。直播服务端的开发人员可以根据直播业务需求，开发新的直播业务插件的工程文件，将直播业务插件编译封装成数据包。

利用本申请实施例的方法，服务端的开发人员可以将应用程序的各个功能独立的模块尽可能的抽离拆分出来，开发互相独立的应用模块，也即是业务插件项目，从而使得各个业务插件之间具有较低的耦合度。当有新的直播业务功能时，可以开发独立的直播业务插件，将开发的工程文件打包为数据包，该数据包通常为.zip、.apk或.so等格式的文件。该数据包可提供给智能终端的应用程序，由应用程序动态加载该数据包，将直播业务插件添加至应用程序中。

在实际应用中，由于不同智能设备的机型、操作系统、设备屏幕等差异，为了适配不同的智能设备，直播服务商所提供的应用程序会有多种不同的版本，针对不同版本的应用程序，所对应开发的直播业务插件也可能有不同的版本。服务端可以存储直播业务插件与应用程序的对应关系，具体的，可以为直播业务插件和应用程序都配置相应标识，直播业务插件的标识可以指示如下一种或多种信息：插件的版本、插件的生效时间(即插件是在什么时间范围内是可用的)、覆盖类型(如iOS系统，Android系统等)、覆盖用户类型(如收费用户、免费用户等)，以便于对应的插件数据包能下发到对应类型的智能设备。

开发人员可以根据业务需要，选择需要更新的数据包，并下发给客户端。具体的下发过程，可以是服务端向应用程序推送直播业务更新指令，直播业务更新指令中可以携带有数据包的具体下载地址以及标识，应用程序在接收到直播业务更新指令后，根据下载地址下载匹配的数据包。具体下载时，还可以将当前应用程序中所添加的插件版本与待下载的版本号进行对比，若当前应用程序中所添加的插件版本不是最新版本，则可以下载更新，若不是最新版本，则可以不更新插件。

应用程序在下载数据包后，可以对所获取的数据包进行动态加载的处理。为了防止插件的数据包在下载过程中出错或被篡改等问题，在一个可选的实现方式中，所述方法还包括：

在动态加载所获取的数据包前，对所述数据包进行安全验证。

其中，安全验证可以采用相关技术中的消息摘要算法、对称密钥、非对称密钥等多种安全验证方式。所下载的数据包通过安全验证后，才可进行后续的动态加载处理；若没有通过安全验证，则表示数据包有可能被篡改，或者是文件发生错误等，应用程序则可以进行重新下载或停止更新等处理，从而提高应用程序管理的安全性。

本申请实施例中，对于Android操作系统，将业务插件包动态加载至应用程序时，需要考虑资源加载、类文件加载以及生命周期回调等问题。接下来针对上述问题进行详细说明。

资源加载：

本实施例中，所述业务插件中包括资源，在动态加载所获取的数据包时，通过如下方式加载所述资源：

通过反射机制调用操作系统的资源管理器的成员函数，将所述资源的路径提供给所述成员函数，并利用所述成员函数为所述资源创建资源对象，完成所述资源的动态加载。

其中，资源是指插件数据包中所包括的图像文件、xml(可扩展标记语言，Extensible Markup Language)文件、动画文件或音视频文件等文件。具体的，Android系统中，资源加载需要调用操作系统的AssetManager(资源管理器)中的addAssetPath方法(资源管理器的成员函数)。由于addAssetPath方法属于隐藏接口，无法直接调用。因此本实施例采用反射机制调用该方法。

反射机制，是指在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为Java(一种计算机编程语言)语言的反射机制。因此，通过反射机制调用addAssetPath方法，将资源的路径提供给所调用的addAssetPath方法。其中，资源文件整合在数据包中，此处资源的路径可以指数据包的路径。通过addAssetPath方法，可以将数据包中的资源加载至AssetManager中，之后通过AssetManager来创建一个新的Resources(资源)对象，完成资源的加载。通过创建的Resources对象，应用程序就可以使用数据包中的资源，从而共享插件和应用程序的资源文件。

类文件加载：

本实施例中，所述业务插件中包括类(class)文件，在动态加载所获取的数据包时，通过如下方式加载所述类文件：

通过操作系统的类加载器加载所述类文件，并执行所述类文件，完成所述类文件的动态加载。

在Java中，类加载器(ClassLoader)，可以用来动态装载class文件，标准的Java SDK(软件开发工具包，Software Development Kit)包含ClassLoader类，通过该类可以装载需要的class文件，前提是ClassLoader类初始化需得到class文件的路径。ClassLoader可以自由灵活的加载类文件，并且对于Android而言，其本质上使用的是Java开发，使用标准的Java编译器能编译出class文件，Android的工程文件编译后，数据包中所包含的类文件为dex类型的文件，dex文件是将class文件重新打包所生成的，打包的规则不是简单地压缩，而是完全对class文件内部的各种函数表，变量表进行优化，产生一个新的文件。因此加载这种特殊的class文件时，可以采用DexClassLoader加载器完成类文件的动态加载。

生命周期的回调：

本实施例中，直播业务插件动态加载后，插件可以在应用程序中运行，然而，由于插件数据包中的Activity(活动)等插件项目没有在主项目的Manifest里面注册，所以无法经历操作系统Framework层级的一系列初始化过程，最终导致获得的Activity实例并没有生命周期，以及无法使用res资源。因此，本实施例通过如下两种方式实现生命周期的回调。

第一种、

通过应用程序的主项目代理执行所述直播业务插件的插件项目，以进行插件项目的生命周期的回调。

本实施例通过代理的形式实现插件项目生命周期的回调，及插件项目视图的创建及绑定。因为应用程序主项目(也称为宿主项目)的activity(Android的四大基础组件之一)，services(Android的四大基础组件之一)是受操作系统管理及初始化，宿主项目可以接收到操作系统的生命周期的回调。本实施例通过宿主项目去代理的执行插件项目的activity或service，进而让插件项目也能收到操作系统的生命周期的回调，并且插件项目也能通过宿主项目的引用，通过宿主项目设置视图的创建及更新。

第二种、

通过反射机制，将ActivityThread中的成员变量mInstrumentation的实例替换为插件项目的实例，通过重写Instrumentation的newActivty方法来实现插件项目的实例化，以利用所述mInstrumentation进行插件项目的生命周期的回调。

本实施例中，在Android操作系统中，Instrumentation是ActivityThread的一个管家，宿主项目的生命周期的回调，操作系统底层也是通过Instrumentation进行调用。因此，本实施例通过Java的反射机制，通过调用Instrumentation方法，将Instrumentation方法中的mInstrumentation成员变量的实例替换为插件项目的实例，通过重写Instrumentation的newActivty的方法能实现插件项目的实例化，从而可以利用mInstrumentation解决生命周期回调的问题。

由上述实施例可知，通过应用本实施例的直播应用程序的管理方法，直播服务商可以根据不同的业务需求，快速更新业务插件。当直播应用程序出现问题时，能在线更新插件，修复问题。并且，可以减少频繁发版的过程，解决新版本用户覆盖率低的过程。还可以减少用户应版本升级，繁琐的安装操作过程。同时，还可以解决安装包体积不断变大的问题，提升手机客户端的用户体验，增加直播应用程序的高可用性。通过上述方法，开发人员可以将业务模块尽可能抽象出来，并能在一个独立工程中开发，减低耦合，也减少在同一个工程项目中开发所带来的代码冲突。

与前述直播应用程序的管理方法的实施例相对应，本申请还提供了直播应用程序的管理装置的实施例。

如图3所示，图3是本申请根据一示例性实施例示出的一种直播应用程序的管理装置的框图，所述装置包括：

指令接收模块31，用于：接收直播服务端所发送的直播业务更新指令。

数据包获取模块32，用于：在直播业务更新指令的指示下，从直播服务端获取直播业务插件对应的数据包，所述数据包预先开发，并独立于其他直播业务插件对应的数据包。

加载模块33，用于：动态加载所获取的数据包，将对应的所述直播业务插件添加至应用程序中，通过所述直播业务插件更新应用程序的直播业务功能。

在一个可选的实现方式中，所述数据包中包括资源，所述加载模块31，包括资源加载子模块(图3中未示出)，用于在动态加载所获取的数据包时，通过如下方式加载所述资源：

通过反射机制调用操作系统的资源管理器的成员函数，将所述资源的路径提供给所述成员函数，并利用所述成员函数为所述资源创建资源对象，完成所述资源的动态加载。

在一个可选的实现方式中，所述数据包中包括类文件，所述加载模块31，包括类文件加载模块(图3中未示出)，用于在动态加载所获取的数据包时，通过如下方式加载所述类文件：

通过操作系统的类加载器加载所述类文件，并执行所述类文件，完成所述类文件的动态加载。

在一个可选的实现方式中，所述装置还包括回调模块(图3中未示出)，用于：

在所述直播业务插件运行时，通过如下方式进行插件项目的生命周期的回调：

通过应用程序的主项目代理执行所述直播业务插件的插件项目，以进行插件项目的生命周期的回调；

和/或

通过反射机制，将ActivityThread中的成员变量mInstrumentation的实例替换为插件项目的实例，通过重写Instrumentation的newActivty方法来实现插件项目的实例化，以利用所述mInstrumentation进行插件项目的生命周期的回调。

在一个可选的实现方式中，所述装置还包括安全验证模块(图3中未示出)，用于：在动态加载所获取的数据包前，对所述数据包进行安全验证。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

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

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。