视图处理方法、装置、电子设备及计算机存储介质与流程

本申请涉及计算机软件技术领域，具体而言，本申请涉及一种视图处理方法、装置、电子设备及计算机存储介质。

背景技术：

在现有技术中，随着终端设备的普及，如智能手机、平板电脑，移动终端等设备的广泛应用，使得移动终端上运行的客户端越来越多，大量客户端的出现在让用户感受不同客户端带来的便利的同时，也给用户带来一定的困扰，比如用户需要不断地更新客户端的版本。

而且，随着技术的不断发展和更新，客户端的功能也越来越强大，研发人员也会在现有客户端的基础上进行一些功能的扩充，例如现有版本的客户端(比如客户端1.0版本)支持5个功能，而当研发人员新开发出了3个功能，并准备将新开发的3个功能集成到原来的客户端中时，只能通过升级客户端的版本才能实现(比如将客户端1.0版本升级到客户端1.1版本)，即需要重新进行客户端版本的发布，例如，先分别开发针对安卓系统的1.1版本安卓客户端与针对ios系统的1.1版本ios客户端，随后将1.1版本ios客户端提交到苹果应用程序商店审核，等审核通过后用户可以在苹果应用程序商店里下载1.1版本的ios客户端，同样也将1.1版本安卓客户端发布到相应的各个应用商店，以使得用户可以下载1.1版本的安卓客户端。

然而，这种实现方式不仅导致开发和维护成本极高，而且新版本的上线时间不确定，导致更新周期较长，同时用户需要重新下载新版本客户端才能体验客户端中的新增功能，给用户带来极大不便，导致用户体验较差，而且客户端的不断更新也造成用户流量的极大消耗。

技术实现要素：

本申请的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：

第一方面，提供了一种视图处理方法，包括：

接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及从服务器获取到的目标客户端的网页视图webview，原生视图为目标客户端中固有的视图；

加载获取到的视图，并进行显示。

具体地，在获取目标客户端的视图之前，还包括：

将原生视图的视图层与从服务器获取到的webview的视图层进行叠加处理，其中，webview的视图层覆盖于原生视图的视图层之上。

进一步地，将原生视图的视图层与从服务器获取到的webview的视图层进行叠加处理，包括：

检测原生视图与webview中的视图是否发生显示冲突；

若发生显示冲突，通过webview在预设调整范围内对原生视图的显示位置进行调整，以解决显示冲突；

显示冲突包括以下任一种情形：显示位置重叠；显示位置间的距离小于预设距离。

进一步地，在显示加载后的视图之后，还包括：

接收用户对任一视图的触发操作，并检测触发操作是否为热区内的触发操作；

如果是热区内的触发操作，则确定触发操作是针对webview的操作；

如果不是热区内的触发操作，则确定触发操作是针对原生视图的操作；

热区是通过目标客户端与webview间的预设应用程序编程接口api在webview中设置的可点击区域。

进一步地，在获取目标客户端的视图之前，还包括：

在目标客户端与webview间建立api，以使得目标客户端与webview之间进行资源和功能共享。

进一步地，在确定触发操作是针对webview的操作之后，还包括：

确定触发操作对应的在webview中的目标功能对象；

基于webview与目标功能对象间的预设功能接口，执行相应操作，以提供目标功能对象的相应功能；

webview中包括至少一个功能对象。

进一步地，在基于webview与目标功能对象间的预设功能接口，向用户提供相应功能之前，还包括：

建立webview与各个功能对象分别对应的预设功能接口。

进一步地，基于webview与目标功能对象间的预设功能接口，执行相应操作，包括：

加载与预设功能接口对应的子webview，并通过子webview执行相应操作。

进一步地，基于webview与目标功能对象间的预设功能接口，执行相应操作之后，还包括：

关闭预设功能接口，并释放目标功能对象占用的资源。

第二方面，提供了一种视图处理装置，包括：

获取模块，用于接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及从服务器获取到的目标客户端的网页视图webview，原生视图为目标客户端中固有的视图；

显示模块，用于加载获取到的视图，并进行显示。

具体地，还包括第一处理模块；

第一处理模块，用于将原生视图的视图层与从服务器获取到的webview的视图层进行叠加处理，其中，webview的视图层覆盖于原生视图的视图层之上。

进一步地，第一处理模块包括检测子模块与调整子模块；

检测子模块，用于检测原生视图与webview中的视图是否发生显示冲突；

调整子模块，用于当发生显示冲突时，通过webview在预设调整范围内对原生视图的显示位置进行调整，以解决显示冲突；

显示冲突包括以下任一种情形：显示位置重叠；显示位置间的距离小于预设距离。

进一步地，还包括第二处理模块与第一确定模块；

第二处理模块，用于接收用户对任一视图的触发操作，并检测触发操作是否为热区内的触发操作；

第一确定模块，用于当是热区内的触发操作时，确定触发操作是针对webview的操作；以及用于当不是热区内的触发操作时，确定触发操作是针对原生视图的操作；

热区是通过目标客户端与webview间的预设应用程序编程接口api在webview中设置的可点击区域。

进一步地，还包括第一建立模块；

第一建立模块，用于在目标客户端与webview间建立api，以使得目标客户端与webview之间进行资源和功能共享。

进一步地，还包括第二确定模块与执行模块；

第二确定模块，用于确定触发操作对应的在webview中的目标功能对象；

执行模块，用于基于webview与目标功能对象间的预设功能接口，执行相应操作，以提供目标功能对象的相应功能；

webview中包括至少一个功能对象。

进一步地，还包括第二建立模块；

第二建立模块，用于建立webview与各个功能对象分别对应的预设功能接口。

进一步地，执行模块具体用于加载与预设功能接口对应的子webview，并通过子webview执行相应操作。

进一步地，还包括资源释放模块；

资源释放模块，用于关闭预设功能接口，并释放目标功能对象占用的资源。

第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的视图处理方法。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的视图处理方法。

本申请实施提供的视图处理方法，接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及与目标客户端对应的网页视图webview，原生视图为目标客户端中固有的视图，接着加载获取到的视图，并进行显示，从而既可以通过获目标客户端中固有的视图，来实现目标客户端的基础功能，又可以通过从服务器获取与目标客户端对应的webview，来实现目标客户端的新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验，同时也有效避免了用户因不断更新客户端而消耗无谓的流量。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例一的视图处理方法的流程示意图；

图2为本申请实施例一的对客户端视图进行处理的过程示意图；

图3为本申请实施例二的视图处理装置的基本结构示意图；

图4为本申请实施例二的视图处理装置的详细结构示意图；

图5为本申请实施例的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

本申请提供的视图处理方法、装置、电子设备和计算机可读存储介质，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

实施例一

本申请实施例提供了一种视图处理方法，如图1所示，包括：

步骤s110，接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及从服务器获取的目标客户端的网页视图webview，原生视图为目标客户端中固有的视图。

具体地，终端设备(例如智能手机、平板电脑等)中可以安装很多个分别实现不用功能的客户端，用户可以根据需要在终端设备中直接启动相应的目标客户端，或者通过其它关联方式间接启动相应的目标客户端，即终端设备接收针对目标客户端的启动请求。

进一步地，终端设备接收到针对目标客户端的启动请求时，可以获取本地存储的目标客户端的视图，也可以通过向服务器发送获取请求来获取目标客户端的视图，其中，目标客户端的视图包括原生视图以及从服务器获取的目标客户端的网页视图webview，原生视图为目标客户端中固有的视图。

步骤s120，加载获取到的视图，并进行显示。

具体地，终端设备获取到目标客户端的视图后，加载获取到的目标客户端的视图，并进行显示，即显示加载后的目标客户端。

本申请实施例提供的视图处理方法，接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及与目标客户端对应的网页视图webview，原生视图为目标客户端中固有的视图，接着加载获取到的视图，并进行显示，从而既可以通过获目标客户端中固有的视图，来实现目标客户端的基础功能，又可以通过从服务器获取与目标客户端对应的webview，来实现目标客户端的新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验，同时也有效避免了用户因不断更新客户端而消耗无谓的流量。

本申请实施例提供了另一种可能的实现方式，其中，在步骤s110之前还包括步骤s100(图中未标注)：将原生视图的视图层与webview的视图层进行叠加处理，其中，webview的视图层覆盖于原生视图的视图层之上。

另外，步骤s100具体包括步骤s1001(图中未标注)与步骤s1002(图中未标注)，其中，

步骤s1001：确定原生视图与webview中的视图是否发生显示冲突；

步骤s1002：若发生显示冲突，通过webview在预设调整范围内对原生视图的显示位置进行调整，以解决显示冲突；

显示冲突包括以下任一种情形：显示位置重叠；显示位置间的距离小于预设距离。

具体地，在一些必须用到客户端开发的视图场景中，开发者可以只在客户端中做必要的视图和功能(即上述的原生视图)，以实现客户端的基础功能，而通过网页视图webview来实现除原生视图外的其余的功能或视图，或者通过webview来实现新增的功能或视图，其中，该webview是透明的，即该webview的框架结构是透明的，但是该webview里面的视图不透明，且可以设置样式。其中，在完成客户端的原生视图及webview的开发后，可以将只有原生视图的客户端进行发布，以供用户下载使用，并将实现新增功能或视图的webview存储于服务器，当终端设备接收到针对目标客户端的启动请求时，可以向服务器发送获取目标客户端的网络视图webview的获取请求，并接收服务器针对该获取请求返回的目标客户端的webview。

进一步地，接收到服务器返回的目标客户端的webview之后，目标客户端通过将原生视图的视图层与从服务器获取到的webview的视图层进行叠加处理，来生成目标客户端的视图，其中，在对客户端原生视图与webview进行叠加处理的过程中，可以将webview的视图层覆盖于原生视图的视图层之上，即将客户端的原生视图和相应webview的视图叠加在一起，以供用户使用，从而通过视图层的叠加处理确保了客户端原生视图与webview的融合，使得用户既能够看到客户端的原生视图，又可以看到通过webview实现的新增视图。

进一步地，终端设备在接收到针对目标客户端的启动请求时，获取到的目标客户端的视图是包括原生视图以及与目标客户端对应的webview的，即获取到的是整个目标客户端的完整视图，这使得用户既可以通过获目标客户端中固有的视图，来实现目标客户端的基础功能，又可以通过获取与目标客户端对应的webview，来实现目标客户端的新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验。

进一步地，客户端在对原生视图的视图层与webview的视图层进行叠加处理的过程中，确定原生视图与webview中的视图是否发生显示冲突，例如发生显示位置重叠、显示位置间的距离小于预设距离等显示冲突，如果确定发生显示冲突，则可以通过webview在预设调整范围内对原生视图的显示位置进行调整，以解决显示冲突，即webview可以在一定范围内调整相应客户端的原生视图。

本申请实施例提供了另一种可能的实现方式，其中，在步骤s120之后还包括步骤s130(图中未标注)、步骤s140(图中未标注)与步骤s150(图中未标注)，其中，

步骤s130：接收用户对任一视图的触发操作，并检测触发操作是否为热区内的触发操作。

步骤s140：当触发操作是热区内的触发操作时，确定触发操作是针对webview的操作。

步骤s150：当触发操作不是热区内的触发操作时，确定触发操作是针对原生视图的操作。

其中，热区是通过目标客户端与webview间的预设应用程序编程接口api在webview中设置的可点击区域。

另外，在步骤s110之前还包括步骤s101(图中未标注)：在目标客户端与webview间建立api，以使得目标客户端与webview之间进行资源和功能共享。

另外，在步骤s140之后还包括步骤s160(图中未标注)与步骤s170(图中未标注)，其中，

步骤s160：确定触发操作对应的在webview中的目标功能对象。

步骤s170：基于webview与目标功能对象间的预设功能接口，执行相应操作，以提供目标功能对象的相应功能。

其中，webview中包括至少一个功能对象。

另外，步骤s170之前还包括步骤s161(图中未标注)：建立webview与各个功能对象分别对应的预设功能接口。

另外，基于webview与目标功能对象间的预设功能接口，执行相应操作，包括：加载与预设功能接口对应的嵌入式框架，并通过预设嵌入式框架执行相应操作。

另外，在步骤s170之后还包括步骤s150(图中未标注)：关闭预设功能接口，并释放目标功能对象占用的资源。

具体地，客户端的完整视图可以由客户端和webview共同来完成，但是如果客户端和webview各自行事，互不通气，将会造成资源的浪费和产品功能的限制，因此需要客户端提供给webview底层api，即在客户端与webview间建立api，使得webview可以使用客户端提供的api，在客户端与webview之间进行资源共享，例如共用长链通道，另外，可以实现一些webview不具备的功能，即在客户端与webview之间进行功能共享，例如设置热区、控制显示或隐藏webview、获取终端设备(例如手机)信息、终端设备(例如手机)屏幕翻转时通知webview、webview通过客户端调用终端设备(例如手机)震动功能等。通过在客户端与webview间建立api，使业务逻辑由webview来实现，避免了业务逻辑频繁变更带来的发版和跨平台的各种缺陷，使得客户端和webview能够取长补短。

进一步地，在基于客户端的原生视图和相应的webview生成客户端的整体视图之后，为了使得用户既可以对原生视图进行相应操作，又可以对客户端的webview进行相应操作，预先通过客户端与webview间的api，给webview设置热区，其中，让webview受理热区区域中的用户操作事件，而把热区区域之外的用户操作事件交给客户端的原生视图受理。从而通过热区的设置，巧妙地解决了不同视图层事件受理用户操作的问题，让用户在一个视图窗口，可以同时操作客户端原生视图和webview的功能。

进一步地，在终端设备显示加载后的目标客户端的视图之后，用户可以根据需要触控相应的视图，即用户可以触控目标客户端的任一视图，也即终端设备接收用户对任一视图的触发操作，其中，终端设备在接收用户对任一视图的触发操作后，检测该触发操作是否为热区内的触发操作，当检测到是热区内的触发操作时，终端设备确定该触发操作是针对webview的操作，此时由webview对用户的触发操作进行响应，当检测到不是热区内的触发操作时，终端设备确定该触发操作是针对原生视图的操作，此时由目标客户的原生视图对用户的触发操作进行响应。

进一步地，随着技术的不断发展和更新，一个webview中的视图窗口产品功能越来越多，例如一个视图中多个独立复杂的活动(即实现不同功能的多个功能对象)都需要用到webview来承担，即一个webview中包括至少一个功能对象，于是，在终端设备确定用户的触发操作是针对webview的操作之后，可以进一步确定该触发操作对应的webview中的目标功能对象，即确定用户的触发操作是针对webview中的哪个功能对象的触发操作。

进一步地，在确定用户触发的目标功能对象之后，终端设备可以通过webview与目标功能对象间的预设功能接口，执行相应操作，例如加载该功能对象，以提供该目标功能对象的相应功能，即通过webview与目标功能对象间的预设功能接口，实现该目标功能对象的相应功能，从而能够根据用户的触发需求进行按需加载，有效避免了同步加载webview中的全部功能对象，所造成的页面加载慢、性能低下、客户端维护困难等问题。其中，在通过webview与目标功能对象间的预设功能接口，向用户提供相应功能之前，预先建立webview与各个功能对象分别对应的预设功能接口。

进一步地，在基于webview与目标功能对象间的预设功能接口，执行相应操作的过程中，终端设备可以通过加载与预设功能接口对应的iframe，来执行相应操作，其中，frame相当于一个子webview，是webview自带的功能，此处利用iframe这种技术，可规避同时加载多个功能时资源太大的问题，即webview根据用户触发的目标功能对象，加载相应的预设功能接口，通过该预设功能接口调用相应的iframe，并通过该iframe将相关功能展示给用户。

进一步地，在基于webview与目标功能对象间的预设功能接口，执行相应操作之后，还可以关闭预设功能接口，并释放目标功能对象占用的资源，即在用户操作完(或使用完)目标功能对象之后，终端设备可以关闭相应的嵌入式框架，即关闭webview与目标功能对象间的预设功能接口，同时释放目标功能对象占用的新源，实现了无用资源的及时销毁、回收等，有效避免了webview因功能太多而占用过多内存的问题，进而避免了内存溢出的问题。

换言之，随着一个视图窗口产品功能越来越多，例如在一个视图中的多个独立复杂的活动(即功能对象)都需要用到webview来承担，如果在一个webview里同时加载这些功能对象，不仅导致页面加载慢，影响客户端的性能，而且不利于客户端的维护。现在通过开启一个子webview(即iframe)，来解决上述问题，首先通过webview加载各个独立的功能对象的预设功能接口，当用户点击相应的预设功能接口时，就会启动与之对应的iframe，相关功能对象的代码也会通过iframe展示给用户，同时当用户操作完某个功能对象后，便会关闭与之对应的iframe，并将占用的资源随之释放。通过预设功能接口与嵌入式框架，不仅实现了根据用户触发操作的按需加载，又实现了无用资源的及时销毁、回收等，有效避免了webview因功能太多而占用过多内存的问题，进而避免了内存溢出的问题。

进一步地，图3给出了在客户端、前端及服务器间共同配合来进行视图处理的过程示意图，其中，在图3中，可以通过客户端提供的注册信息通道函数registermessagechannel，推送系统(即push系统)提供的服务器端服务，可以让前端和客户端共用长链通道，减少资源消耗；另外，通过客户端提供的热区设定函数sethotregions，可以设置webview的热区，解决客户端原生视图和webview中的视图同在一个视图窗口的问题；另外，服务器端解决了配置webview中多功能对象的预设功能接口的问题，通过服务器端的配置，页面可以加载加载不同的css、js、img等静态资源，可以在一个页面中展示多个功能对象的预设功能接口，通过不同的预设功能接口可以启动不同页面的嵌入式框架(即iframe)，解决了多个功能对象存在于一个webview中时，维护成本高、存在性能瓶颈等问题。

通过上述方案，只需对客户端进行一次开发，提供相应的基础服务，就可以由webview、服务器端实现产品功能，相对于之前单纯依赖客户端开发，更高效，成本更低，而且通过webview开发业务逻辑，不再需要客户端的发版，可以做到功能测试完成即可上线，用户便可看到相关功能的更新，不需要再下载新的安装包，产品开发效率和用户体验都得到了很大提升，并且webview开发出的功能可以适用于不同的终端设备。

实施例二

图3为本申请实施例提供的一种视图处理装置的结构示意图，如图3所示，该装置30可以包括获取模块31与显示模块32，其中，

获取模块31用于接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及从服务器获取到的目标客户端的网页视图webview，原生视图为目标客户端中固有的视图；

显示模块32用于加载获取到的视图，并进行显示。

具体地，还包括第一处理模块33，如图4所示，其中，第一处理模块33用于将原生视图的视图层与从服务器获取到的webview的视图层进行叠加处理，其中，webview的视图层覆盖于原生视图的视图层之上。

进一步地，第一处理模块33包括检测子模块331与调整子模块332，如图4所示，其中，

检测子模块331用于检测原生视图与webview中的视图是否发生显示冲突；

调整子模块332用于当发生显示冲突时，通过webview在预设调整范围内对原生视图的显示位置进行调整，以解决显示冲突；

显示冲突包括以下任一种情形：显示位置重叠；显示位置间的距离小于预设距离。

进一步地，还包括第二处理模块34与第一确定模块35，如图4所示，其中，

第二处理模块34用于接收用户对任一视图的触发操作，并检测触发操作是否为热区内的触发操作；

第一确定模块35用于当是热区内的触发操作时，确定触发操作是针对webview的操作；以及用于当不是热区内的触发操作时，确定触发操作是针对原生视图的操作；

热区是通过目标客户端与webview间的预设应用程序编程接口api在webview中设置的可点击区域。

进一步地，还包括第一建立模块36，如图4所示，其中，第一建立模块36用于在目标客户端与webview间建立api，以使得目标客户端与webview之间进行资源和功能共享。

进一步地，还包括第二确定模块37与执行模块38，如图4所示，其中，

第二确定模块37用于确定触发操作对应的在webview中的目标功能对象；

执行模块38用于基于webview与目标功能对象间的预设功能接口，执行相应操作，以提供目标功能对象的相应功能；

webview中包括至少一个功能对象。

进一步地，还包括第二建立模块39，如图4所示，其中，第二建立模块39用于建立webview与各个功能对象分别对应的预设功能接口。

进一步地，执行模块38具体用于加载与预设功能接口对应的子webview，并通过子webview执行相应操作。

进一步地，还包括资源释放模块310，如图4所示，其中，资源释放模块310用于关闭预设功能接口，并释放目标功能对象占用的资源。

本申请实施例提供的装置，与现有技术相比，接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及与目标客户端对应的网页视图webview，原生视图为目标客户端中固有的视图，接着加载获取到的视图，并进行显示，从而既可以通过获取目标客户端中固有的视图，来实现目标客户端的基础服务或基础功能，又可以通过从服务器获取与目标客户端对应的webview，来实现目标客户端的新增服务或新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验，同时也有效避免了用户因不断更新客户端而消耗无谓的流量。

实施例三

本申请实施例提供了一种电子设备，如图5所示，图5所示的电子设备500包括：处理器501和存储器503。其中，处理器501和存储器503相连，如通过总线502相连。进一步地，电子设备500还可以包括收发器504。需要说明的是，实际应用中收发器504不限于一个，该电子设备500的结构并不构成对本申请实施例的限定。

其中，处理器501应用于本申请实施例中，用于实现图3或图4所示的获取模块与显示模块的功能以及图4所示的第一处理模块、第一建立模块、第二处理模块、第一确定模块、第二确定模块、第二建立模块、执行模块与资源释放模块的功能。

处理器501可以是cpu，通用处理器，dsp，asic，fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器501也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。

总线502可包括一通路，在上述组件之间传送信息。总线502可以是pci总线或eisa总线等。总线502可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器503可以是rom或可存储静态信息和指令的其他类型的静态存储设备，ram或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom、cd-rom或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器503用于存储执行本申请方案的应用程序代码，并由处理器501来控制执行。处理器501用于执行存储器503中存储的应用程序代码，以实现图3或图4所示实施例提供的视图处理装置的动作。

本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，与现有技术相比，可实现：接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及与目标客户端对应的网页视图webview，原生视图为目标客户端中固有的视图，接着加载获取到的视图，并进行显示，从而既可以通过获目标客户端中固有的视图，来实现目标客户端的基础服务或基础功能，又可以通过从服务器获取与目标客户端对应的webview，来实现目标客户端的新增服务或新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验，同时也有效避免了用户因不断更新客户端而消耗无谓的流量。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现实施例一中的视图处理方法，与现有技术相比，接收到针对目标客户端的启动请求时，获取目标客户端的视图，视图包括原生视图以及与目标客户端对应的网页视图webview，原生视图为目标客户端中固有的视图，接着加载获取到的视图，并进行显示，从而既可以通过获目标客户端中固有的视图，来实现目标客户端的基础服务或基础功能，又可以通过从服务器获取与目标客户端对应的webview，来实现目标客户端的新增服务或新增功能，使得用户无需重新下载新版本客户端即可体验客户端中的新增功能，极大提升了用户体验，同时也有效避免了用户因不断更新客户端而消耗无谓的流量。

本申请实施例提供的计算机可读存储介质适用于上述方法的任一实施例。在此不再赘述。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。