应用程序换肤方法、装置、可读存储介质和车辆

技术领域

本公开涉及计算机技术领域，具体地，涉及一种应用程序换肤方法、装置、可读存储介质和车辆。

背景技术

随着安卓系统的广泛应用，用户对安卓系统UI设计(User Interface，用户界面)的使用体验有着越来越高的要求，仅依靠原生安卓自带的主题换肤功能已无法满足用户对换肤功能使用体验的需求。应用于不同领域的安卓系统一般都具有自己的主题皮肤，用户可根据自己的喜好更换系统的主题皮肤。

目前，现有的换肤功能主要通过以下两种方式实现。一种是在重启时加载提前安装在安卓系统上的皮肤包，从而达到换肤的效果。但该方式无法做到应用程序在当前页面静态的换肤和同时多个应用程序支持多套皮肤的切换。另一种是动态换肤，是第三方开源的通用方案，目前用该方案实现安卓应用程序换肤的开发者更多，但需要修改应用程序的代码，修改布局文件，页面越多，工作量越大，而且无法支持任意的安卓UI资源替换。

发明内容

本公开的目的是提供一种应用程序换肤方法、装置、可读存储介质和车辆，以在不重启应用程序且不修改应用程序的代码情况下，支持任意形式的安卓UI资源切换，提高开发人员的开发效率并提升用户换肤功能使用的体验感。

为了实现上述目的，本公开第一方面提供一种应用程序换肤方法，应用于装有安卓系统的终端，该方法包括：

皮肤管理服务响应于接收到第一换肤指令，向目标应用程序对应的皮肤包加载类发送换肤通知，以使所述皮肤包加载类加载待更换的目标皮肤包资源；

所述皮肤包加载类在资源代理类中创建皮肤包资源管理对象，并通过所述皮肤管理服务向系统窗口管理类发送界面更新通知；

所述系统窗口管理类响应于所述界面更新通知，查找所述目标应用程序的应用程序根视图，并由所述应用程序根视图向所述目标应用程序的视图分发皮肤切换事件；

所述目标应用程序的视图响应于所述皮肤切换事件，通过访问所述皮肤包资源管理对象来加载所述目标皮肤包资源，以完成换肤。

可选地，所述终端上安装有皮肤商城，该方法还包括：

所述皮肤商城响应于接收到第二换肤指令，从云端服务器下载所述目标皮肤包资源，并将所述目标皮肤包资源解压缩到目标路径下；

所述皮肤商城确定需要进行换肤的所述目标应用程序，并向所述皮肤管理服务发送所述第一换肤指令。

可选地，所述皮肤包加载类从所述目标路径加载所述皮肤包资源。

可选地，该方法还包括：

通过应用程序上下文类创建所述资源代理类，以替换原生资源管理类；

响应于所述皮肤商城的启动指令，所述资源代理类为所述目标应用程序创建所述皮肤包加载类。

可选地，所述目标应用程序为多个。

可选地，所述终端为车机。

本公开第二方面提供一种应用程序换肤装置，应用于装有安卓系统的终端，包括：

存储器，其上存储有计算机程序；

处理器，所述计算机程序被处理器执行时，实现本公开第一方面所述方法的步骤。

本公开第三方面提供一种非暂时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开第一方面所述方法的步骤。

本公开第四方面提供一种车辆，包括车机，所述车机包括本公开第二方面所述的应用程序换肤装置。

本公开提供的换肤方案，完全是通过安卓框架(Framework)的机制实现动态的生成资源管理对象，视图(View)动态的加载资源，所以目标应用程序(目标App)不需要修改任何代码，不需要提前安装皮肤包，不需要重启目标App，就能支持Activity、Dialog、Fragment、Window等任何形式的Android UI的切换，以及支持多套皮肤的切换。这样，不仅可以提高开发人员的开发效率，而且还方便用户的使用，提升用户体验。

本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本公开的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本公开，但并不构成对本公开的限制。在附图中：

图1是本公开一示例性实施例提供的应用程序换肤方法的流程图；

图2显示了本公开提供的应用程序换肤方法所涉及的各进程之间的交互流程图；

图3是本公开一示例性实施例提供的应用程序换肤装置的框图。

具体实施方式

以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是，此处所描述的具体实施方式仅用于说明和解释本公开，并不用于限制本公开。

在详细描述本公开提供的应用程序换肤方法之前，先介绍一下目前现有的两种换肤方案：

方案一：Runtime Resources Overlay，即运行时加载皮肤，通过制作RRO的皮肤包，在皮肤包里面指定要重载的目标APP，再将该皮肤包安装到Android设备上。重新启动目标APP，启动时会判断是否存在有覆盖(Overlay)的资源，如果有就加载Overlay的资源，目标App在渲染、加载图片时就会用Overlay里面的定义，从而达到换肤的效果。该方案的优点是：不需要修改目标App代码，从而可以实现更换图片、颜色、大小等资源。该方案的缺点是：需要重启目标App，无法做到目标App在当前页面静态的换肤。并且由于需要提前安装皮肤包，所以也无法做到同时多个目标App支持多套皮肤的切换。

方案二：Skin Loader，即皮肤加载器，该方案是一个第三方开源的通用方案，可以达到动态换肤。其实现思路是：对需要换肤的View进行打桩，然后Activity继承SkinLoader的BaseActivity，在BaseActivity收到onCreate事件时替换了原生的LayoutInflater.Factory2，在View被创建时会回调自定义的Factory2的onCreateView接口，Skin Loader在该方法根据在布局文件里面的打桩，替换成自定义的View。当收到皮肤包已准备好后就通过AssetManager去创建对应的Resource对象，再通过反射替换View的mResource对象，这样再次获取资源就是从修改后的Resource对象里面获取。另外还需要制作一个皮肤包，皮肤包里面只需要包含需要被替换的图片、颜色、大小等资源。皮肤包的存放路径要和Skin Loader加载的路径保持一致。该方案的优点是：App不需要重启就可以完成换肤，而且不需要安装皮肤包，可以快速切换多套皮肤。但该方案的缺点是：需要修改App的代码，重载Activity和Application，修改布局文件，如果页面很多，那么工作量就很大，而且只能支持Activity相关的UI页面换肤，无法支持Service里面启动的全局窗口。

有鉴于此，本公开提供一种应用程序换肤方法、装置、可读存储介质和车辆，以解决上述问题。

图1是本公开一示例性实施例提供的应用程序换肤方法的流程图，该方法可以应用于装有安卓系统的终端，该终端可以为手机、车机或者其他搭载安卓系统、具有显示功能的任何智能设备。如图1所示，该方法可以包括：

S101，皮肤管理服务响应于接收到第一换肤指令，向目标应用程序(即，目标App)对应的皮肤包加载类发送换肤通知，以使皮肤包加载类加载待更换的目标皮肤包资源。

示例地，终端上安装有皮肤商城，皮肤商城用于对皮肤包进行管理。皮肤管理服务是与皮肤商城对应的Service，皮肤商城和对应的皮肤管理服务均运行于APP端。皮肤商城可以向皮肤管理服务发送第一换肤指令，以通知该皮肤管理服务开始切换皮肤。皮肤管理服务在接收到第一换肤指令后，通知要进行换肤的目标App对应的皮肤包加载类，该皮肤包加载类随之去加载待更换的目标皮肤包资源。

S102，皮肤包加载类在资源代理类(即，Resource代理)中创建皮肤包资源管理对象，并通过皮肤管理服务向系统窗口管理类(即，WindowManagerService)发送界面更新通知。

示例地，皮肤包加载类在资源代理类中创建皮肤包资源管理对象，以便后续可通过访问该皮肤包资源管理对象来加载目标皮肤包资源。之后，皮肤包加载类可以向皮肤管理服务发送界面更新通知，该皮肤管理服务随即向系统窗口管理类发送界面更新通知，以准备开始换肤。

S103，系统窗口管理类响应于界面更新通知，查找目标应用程序的应用程序根视图(App Root View)，并由该应用程序根视图向目标应用程序的视图(View)分发皮肤切换事件。

示例地，由WindowManagerService的WindowState找到目标App的App Root View，之后，由App Root View遍历该目标App的全部View，并向目标App的每一View分发皮肤切换事件，以由View重新设置对应的资源。

S104，目标应用程序的视图响应于皮肤切换事件，通过访问皮肤包资源管理对象来加载目标皮肤包资源，以完成换肤。

本公开提供的换肤方案，通过安卓Framework的Resource代理设计，实现动态的生成资源管理对象，View动态的加载资源，所以目标App不需要修改任何代码，不需要提前安装皮肤包，不需要重启目标App，就能支持Activity、Dialog、Fragment、Window等任何形式的Android UI的切换，以及支持多套皮肤的切换。这样，不仅可以提高开发人员的开发效率，而且还方便用户的使用，提升用户体验。

可选地，上述方法还可以包括：

皮肤商城响应于接收到第二换肤指令，从云端服务器下载该目标皮肤包资源，并将该目标皮肤包资源解压缩到目标路径下；

皮肤商城确定需要进行换肤的目标应用程序，并向皮肤管理服务发送第一换肤指令。

在本公开提供的换肤方案中，皮肤包资源存储在云端服务器中。

在一种示例场景中，用户可以在皮肤商城中选择期望的主题，不同的主题对应不同的皮肤包资源。当用户选择了期望的主题，皮肤商城便接收到了第二换肤指令。之后，皮肤商城从云端服务器下载与用户期望的主题相对应的皮肤包资源。皮肤商城将该皮肤包资源存储到目标路径下，并在该路径下对皮肤包资源进行解压缩。

在另一种示例场景中，本方法所应用的终端为车机。车机可以与云端服务器交互，用户的手机端也可以与云端服务器交互。在该场景下，用户可以在手机端选择期望的主题。当用户选择了期望的主题，手机端会向云端服务器通知用户所选择的主题。云端服务器与车机通信，向车机上的皮肤商城推送换肤消息。皮肤商城接收到该换肤消息，相当于接收到第二换肤指令，之后从云端服务器下载与用户期望的主题相对应的皮肤包资源。皮肤商城将该皮肤包资源存储到目标路径下，并在该路径下对皮肤包资源进行解压缩。

皮肤商城在下载了皮肤包资源之后，可以根据皮肤包资源中的配置文件，确定需要进行换肤的目标App。示例性地，在皮肤包资源的配置文件中可以预先设定该皮肤包资源所针对的目标App的标识信息。皮肤商城通过该标识信息，确定需要换肤的目标App，其中，该目标App的数量可以为一个，也可以为多个。相应地，皮肤包资源中包括与每一目标App分别对应的目标皮肤包资源，也就是说，在目标App为多个时，下载的皮肤包资源中包括了分别应用于每一目标App的目标皮肤包资源。之后，皮肤商城向皮肤管理服务发送第一换肤指令，以由皮肤管理服务向每一目标App对应的皮肤包加载类发送换肤通知，从而使得每一目标App对应的皮肤包加载类分别加载与该目标App对应的目标皮肤包资源。示例性地，皮肤包加载类从上述目标路径加载目标皮肤包资源。

可选地，上述方法还可以包括：

通过应用程序上下文类创建资源代理类，以替换原生资源管理类；

响应于所述皮肤商城的启动指令，所述资源代理类为所述目标应用程序创建所述皮肤包加载类。

示例性地，安卓系统的所有进程都会创建对应的应用程序上下文类，应用程序上下文类会根据配置，比如屏幕的大小、语言、地区等属性创建资源管理类。本方案中，在系统创建原生的资源管理类时，通过应用程序上下文类创建资源代理类，并且该资源代理类引用原生的资源管理类。当皮肤商城未下载过皮肤包资源时，资源代理类直接用原生的资源管理类来加载资源。当用户点击皮肤商城、生成皮肤商城的启动指令时，资源代理类会为每一目标App创建对应的皮肤包加载类，之后，通过该皮肤包加载类来加载资源。

通过安卓Framework的Resource代理设计，可以实现动态的生成资源管理对象，View动态的加载资源，所以目标App不需要修改任何代码，不需要提前安装皮肤包，不需要重启目标App，就能支持Activity、Dialog、Fragment、Window等任何形式的Android UI的切换。

图2显示了本公开提供的应用程序换肤方法所涉及的各进程之间的交互流程图。通过该图2，可以更为清晰地了解本公开提供的应用程序换肤方法的实现过程。如图2所示，该方法可以包括：

S201，应用程序上下文类创建应用程序资源对象，即原生资源管理类。

S202，应用程序上下文类创建资源代理类，以替换原生资源管理类。

S203，资源代理类为每个换肤相关的应用程序创建与该应用程序对应的皮肤包加载类。

S204，皮肤包加载类向皮肤管理服务进行注册换肤通知回调。其中，注册换肤通知回调用于应用程序和安卓系统通信。

S205，皮肤商城响应于接收到第二换肤指令，向云端发出皮肤包下载请求，以获取皮肤包资源。

S206，皮肤商城从云端服务器下载皮肤包资源。

S207，皮肤商城将皮肤包资源解压缩到目标路径下。

S208，皮肤商城确定需要进行换肤的目标应用程序，并向皮肤管理服务发送第一换肤指令。其中，需要进行换肤的目标应用程序的数量可以为一个，也可以为多个，相应地，下载的皮肤包资源中包括每个目标应用程序对应的目标皮肤包资源。

S209，皮肤管理服务响应于接收到第一换肤指令，向目标应用程序对应的皮肤包加载类发送换肤通知。

S210，皮肤包加载类加载与该目标应用程序对应的待更换的目标皮肤包资源。示例地，从上述目标路径中加载该目标皮肤包资源。

S211，皮肤包加载类在资源代理类中创建皮肤包资源管理对象。

S212，皮肤包加载类向皮肤管理服务发送界面更新通知。

S213，皮肤管理服务响应于界面更新通知，向系统窗口管理类发送界面更新通知。

S214，系统窗口管理类响应于界面更新通知，查找到目标应用程序的应用程序根视图。

S215，目标应用程序的应用程序根视图遍历目标应用程序所有的视图。

S216，目标应用程序的应用程序根视图向目标应用程序的每一视图分发皮肤切换事件。

S217，目标应用程序的视图响应于皮肤切换事件，通过访问皮肤包资源管理对象来加载目标皮肤包资源，以完成换肤。

本公开提供的换肤方案，完全是通过安卓Framework的机制实现动态的生成资源管理对象，View动态的加载资源，所以目标App不需要修改任何代码，不需要提前安装皮肤包，不需要重启目标App，就能支持Activity、Dialog、Fragment、Window等任何形式的Android UI的切换，以及支持多套皮肤的切换。这样，不仅可以提高开发人员的开发效率，而且还方便用户的使用，提升用户体验。

图3是根据一示例性实施例示出的一种应用程序换肤装置300的框图。如图3所示，该应用程序换肤装置300可以包括：处理器301，存储器302。该应用程序换肤装置300还可以包括多媒体组件303，输入/输出(I/O)接口304，以及通信组件305中的一者或多者。

其中，处理器301用于控制该应用程序换肤装置300的整体操作，以完成上述的应用程序换肤方法中的全部或部分步骤。存储器302用于存储各种类型的数据以支持在该应用程序换肤装置300的操作，这些数据例如可以包括用于在该应用程序换肤装置300上操作的任何应用程序或方法的指令，以及应用程序相关的数据，例如联系人数据、收发的消息、图片、音频、视频等等。该存储器302可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。多媒体组件303可以包括屏幕和音频组件。其中屏幕例如可以是触摸屏，音频组件用于输出和/或输入音频信号。例如，音频组件可以包括一个麦克风，麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器302或通过通信组件305发送。音频组件还包括至少一个扬声器，用于输出音频信号。I/O接口304为处理器301和其他接口模块之间提供接口，上述其他接口模块可以是键盘，鼠标，按钮等。这些按钮可以是虚拟按钮或者实体按钮。通信组件305用于该应用程序换肤装置300与其他设备之间进行有线或无线通信。无线通信，例如Wi-Fi，蓝牙，近场通信(Near Field Communication，简称NFC)，2G、3G、4G、NB-IOT、eMTC、或其他5G等等，或它们中的一种或几种的组合，在此不做限定。因此相应的该通信组件305可以包括：Wi-Fi模块，蓝牙模块，NFC模块等等。

在一示例性实施例中，应用程序换肤装置300可以被一个或多个应用专用集成电路(应用程序lication Specific Integrated Circuit，简称ASIC)、数字信号处理器(Digital Signal Processor，简称DSP)、数字信号处理设备(Digital Signal ProcessingDevice，简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述的应用程序换肤方法。

在另一示例性实施例中，还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现上述的应用程序换肤方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器302，上述程序指令可由应用程序换肤装置300的处理器301执行以完成上述的应用程序换肤方法。

在另一示例性实施例中，还提供一种计算机程序产品，该计算机程序产品包含能够由可编程的装置执行的计算机程序，该计算机程序具有当由该可编程的装置执行时用于执行上述的应用程序换肤方法的代码部分。

以上结合附图详细描述了本公开的优选实施方式，但是，本公开并不限于上述实施方式中的具体细节，在本公开的技术构思范围内，可以对本公开的技术方案进行多种简单变型，这些简单变型均属于本公开的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本公开对各种可能的组合方式不再另行说明。

此外，本公开的各种不同的实施方式之间也可以进行任意组合，只要其不违背本公开的思想，其同样应当视为本公开所公开的内容。