CN107291506A - 一种更新app界面的方法和装置 - Google Patents

Abstract

本发明公开了一种更新APP界面的方法和装置，该方法包括：将预定APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同；在个数不相同的情况下，清除组件清单中的所有基础组件，并使用新数据在预定视图组件对应的资源下构建新的基础组件，以更新预定APP界面。该方法解决了现有技术技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

Description

一种更新APP界面的方法和装置

技术领域

本发明涉及移动互联网领域，特别是涉及一种更新APP(Application，应用软件或手机软件)界面的方法和装置。

背景技术

现有常见的页面多元素有ListView方案和ScrollView两种方案。

ListView常用于数据数目比较多，并且每一条数据的展现形式类似时使用。ListView本身有复用池，需要重写ItemViewType来扩充显示项的形式种类。当划出屏幕时，下边要显示的项目会根据缓冲池中的类型，选择是否复用。

ScrollView也可以实现显示很多项，超出显示范围时滚动显示。不过ScrollView默认没有缓存机制，数据刷新时经常是整屏重新创建来实现刷新。亦或者用不到刷新。

然而，ListView的实现方式对于处理数目不是特别多(超不出两屏)的数据时显得有些多余；并且当项与项之间不存在基本的形式一致时，复用池也基本上不起作用，而且后续如果想在里边扩展子ListView就会比较困难。

ScrollView的实现方式目前没有很好的缓存策略。

基于上述说明，现有技术处理视图(View)的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

发明内容

本发明提供一种更新APP界面的方法和装置，用以解决现有技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

为解决上述技术问题，一方面，本发明提供一种更新APP界面的方法，包括：将预定APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同；在个数不相同的情况下，清除所述组件清单中的所有基础组件，并使用所述新数据在所述预定视图组件对应的资源下构建新的基础组件，以更新所述预定APP界面。

可选的，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同之后，还包括：在个数相同的情况下，检测各个基础组件的主题元素是否发生变化；在主题元素未发生变化的情况下，将所述新数据直接替换至对应的基础组件中；在主题元素发生变化的情况下，将主题元素发生变化的基础组件对应的资源下使用所述新数据构建新的基础组件。

可选的，将预定应用软件APP界面中每个部分的视图对应的代码封装成一个视图组件，包括：将所述预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。

可选的，在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同，包括：在接收到所述刷新数据的请求消息时，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同；在位置相同的情况下，检测所述新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同。

可选的，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同之后，还包括：在位置不相同的情况下，删除所述预设json数组的数据模型中的原有的所述视图组件和所述新数据对应位置的原有的视图组件，并使用已删除的所述新数据对应位置的原有的视图组件对应的资源构建新的基础组件。

另一方面，本发明还提供一种更新APP界面的装置，包括：封装模块，用于将预定APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；检测模块，用于在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同；执行模块，用于在个数不相同的情况下，清除所述组件清单中的所有基础组件，并使用所述新数据在所述预定视图组件对应的资源下构建新的基础组件，以更新所述预定APP界面。

可选的，所述检测模块，还用于在个数相同的情况下，检测各个基础组件的主题元素是否发生变化；所述执行模块，还用于在主题元素未发生变化的情况下，将所述新数据直接替换至对应的基础组件中；在主题元素发生变化的情况下，将主题元素发生变化的基础组件对应的资源下使用所述新数据构建新的基础组件。

可选的，所述生成模块，具体用于：将所述预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。

可选的，所述检测模块包括：第一检测单元，用于在接收到所述刷新数据的请求消息时，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同；第二检测单元，用于在位置相同的情况下，检测所述新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同。

可选的，所述执行模块，具体用于：在位置不相同的情况下，删除所述预设json数组的数据模型中的原有的所述视图组件和所述新数据对应位置的原有的视图组件；使用已删除的所述新数据对应位置的原有的视图组件对应的资源构建新的基础组件。

本发明将预定APP中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件，这样，在有要刷新的数据时，就可以直接判断基础组件的数量和原有的足见清单中的基础组件个数是否相同，在不相同的情况下，直接通过原有视图组件下的资源来构建新的基础组件，以得到新的界面。该方法可以通过复用资源方式快速更新APP，解决了现有技术技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

附图说明

图1是本发明第一实施例中更新APP界面的方法的流程图；

图2是本发明第二实施例中更新APP界面的装置的结构示意图；

图3是本发明第三实施例中更新APP界面的方法的流程图。

具体实施方式

为了解决现有技术技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差；本发明提供了一种更新APP界面的方法和装置，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

本发明第一实施例提供了一种更新APP界面的方法，该方法的流程图如图1所示，包括步骤S102至S106：

S102，将预定APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；

S104，在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同；

S106，在个数不相同的情况下，清除组件清单中的所有基础组件，并使用新数据在预定视图组件对应的资源下构建新的基础组件，以更新预定APP界面。

本发明实施例将预定APP中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件，这样，在有要刷新的数据时，就可以直接判断基础组件的数量和原有的足见清单中的基础组件个数是否相同，在不相同的情况下，直接通过原有视图组件下的资源来构建新的基础组件，以得到新的界面。该方法可以通过复用资源方式快速更新APP，解决了现有技术技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

在检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同之后，如果个数相同，则检测各个基础组件的主题元素是否发生变化。

如果主题元素未发生变化，就将新数据直接替换至对应的基础组件中；如果主题元素发生变化，则将主题元素发生变化的基础组件对应的资源下使用新数据构建新的基础组件。通过该方式可以在预定APP界面改动较小的情况下快速完成界面更新。

实现的过程中，在将预定应用软件APP界面中每个部分的视图对应的代码封装成一个视图组件时，实际是将预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。由于预设json数组的数据模型中是设置了一定先后顺序的，因此，在存储视图组件时，也是按照一定顺序的，该顺序就是预定APP界面中呈现各个视图组件对应视图的顺序。

基于上述过程，在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同时，可以在接收到刷新数据的请求消息时，就检测新数据所在视图组件的位置是否与存储在预设json数组的数据模型中的位置相同，即通过位置关系来确定预定APP的界面是否有较大变化。

在位置相同的情况下，说明视图的位置没有变化，则再检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同。

在位置不相同的情况下，说明视图的位置存在变化，此时，由于该视图组件的位置都变化了，所以需要删除预设json数组的数据模型中的原有的视图组件，由于需要为新数据腾出资源，因此，也要删除要建立新数据对应位置的原有的视图组件，并使用已删除的新数据对应位置的原有的视图组件对应的资源构建新的基础组件。

本发明第二实施例提供了一种更新APP界面的装置，该装置的结构示意如图2所示，包括：

封装模块10，用于将预定APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；检测模块20，与封装模块10耦合，用于在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同；执行模块30，与检测模块20耦合，用于在个数不相同的情况下，清除组件清单中的所有基础组件，并使用新数据在预定视图组件对应的资源下构建新的基础组件，以更新预定APP界面。

上述检测模块，还用于在个数相同的情况下，检测各个基础组件的主题元素是否发生变化；执行模块，还用于在主题元素未发生变化的情况下，将新数据直接替换至对应的基础组件中；在主题元素发生变化的情况下，将主题元素发生变化的基础组件对应的资源下使用新数据构建新的基础组件。通过该方式可以在预定APP界面改动较小的情况下快速完成界面更新，提升系统性能。

具体实现时，上述生成模块，具体用于将预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。

由于预设json数组的数据模型中是设置了一定先后顺序的，因此，在存储视图组件时，也是按照一定顺序的，该顺序就是预定APP界面中呈现各个视图组件对应视图的顺序。

基于上述生成模块，检测模块具体还可以包括：第一检测单元，用于在接收到刷新数据的请求消息时，检测新数据所在视图组件的位置是否与存储在预设json数组的数据模型中的位置相同，即通过位置关系来确定预定APP的界面是否有较大变化；第二检测单元，用于在位置相同的情况下，检测新数据中基础组件的个数与组件清单中预定视图组件的基础组件个数是否相同。

上述执行模块，具体用于：在新数据所在视图组件的位置与存储在预设json数组的数据模型中的位置不相同的情况下，删除预设json数组的数据模型中的原有的视图组件和新数据对应位置的原有的视图组件；使用已删除的新数据对应位置的原有的视图组件对应的资源构建新的基础组件。

本发明实施例将预定APP中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件，这样，在有要刷新的数据时，就可以直接判断基础组件的数量和原有的足见清单中的基础组件个数是否相同，在不相同的情况下，直接通过原有视图组件下的资源来构建新的基础组件，以得到新的界面。该方法可以通过复用资源方式快速更新APP，解决了现有技术技术的如下问题：现有技术处理视图的两种方案需要耗费较大的系统资源，无法在数据变化比较频繁、但总个数变化较小的情况下快速调整视图，系统性能较差。

本发明第三实施例提供了一种更新APP界面的方法。在App页面中，会有很多子模块(即组件，也称为视图组件)，把每一个子模块封装成自己的ViewModule(视图组件)，每一个子ViewModule都继承自BaseModule(基础组件)父类。在页面中，用List<BaseModule>modulelist(组件清单)来存放页面中模块列表。

每次刷新数据时，先比较新数据与modulelist中的元素(即基础组件)个数是否相同，当元素个数发生变化时，说明此次刷新变动较大，则会清除整个modulelist中的元素，重新构建页面。而元素个数没有发生变化时，这种正是常用的情况，此时就可以用到复用池了。

本实施例设计思路如下:

(1)数据灵活配置，可以通过服务器灵活下发显示个数及显示位置。

用一个存放BaseModule的list来做缓存，以58钱柜首页为例，默认发过来的数据顺序如下表1所示：

表1

Banner模块

通知模块

菜单模块

新手模块

产品模块

收益模块

这个数据的顺序和个数都可以变动，用json数组的数据模型来控制数据的显示个数以及显示顺序。这样就可以实现客户端根据服务器的需要来动态改变显示顺序以及显示模块的个数，而可以突破原本单一固定的顺序控制和个数控制。使得应用更加灵活。

(2)采用缓存策略来节约创建View的性能损耗和内存损耗，更大限度的提升了程序运行的性能。

当创建View时，并不是每次真正创建新的View，而是先确认是否已经创建了View。如果已经创建了，那么会直接返回之前创建的View，通过重新绑定数据来实现View的复用。

另外，用list来存放每个View模块作为缓存，当json数据数量发生变化时，说明本次数据改变很大，则清除缓存，不用缓存中的View。当数据个数未变时，如果当前位置即是所要的View，那么直接绑定数据，否则就替换当前View为目标View。

通过本实施例，数据展现的个数以及位置完全由服务器端控制，页面更加灵活多变，适应力更强；创建缓存机制，最大限度的减少创建View的工作，使得页面刷新感很弱，视觉效果好，并且性能最优。

下面结合图3对上述流程进行详细说明，包括：

S1，获取APP首页json数组字符串。

S2，判断当前缓存list中的元素个数和json数组的数据模型中模块的个数是否相同。如果相同，执行S3，否则，执行S9。

S3，判断当前缓存中对应的位置上是否为对应View类型的View。如果是，则执行S4，否则执行S5。

S4，遍历json模块中的BaseModule，检测BaseModule的个数是否与原View中BaseModule个数相同。如果是，则执行S8，否则执行S5。

实现时，将json数组的每一个json元素转化成对应的View，在得到对应View的时候，如果当前已经没有此类型的对象，则直接返回该View对象，如果当前没有对应的View对象，则创建View，本实施例以当前游标i为例。

S5，当前用于计数的游标i是否已经超出缓存列表范围。如果是，则执行S6，否则执行S7。

S6，在缓存列表中追加对应的元素，并且在父页面容器中追加对应的View。

S7，替换缓存中第i个元素为对应的View所有的BaseModule，替换父页面容器中对应的View。

S8，绑定数据。

S9，清除缓存的数据和页面中所有的View，重新构建父页面。

本实施例有益效果如下：

数据可以灵活变动，模块位置也可以动态控制；创建View时使用缓存可以减少内存消耗，速度更快；利用list保存之前的View项，在整体模块变动可能性比较小的情况下，只需要重新绑定数据即可，不需要重新创建View；可以最大限度的减少页面刷新感，视觉体验更好。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。

Claims (10)

1.一种更新APP界面的方法，其特征在于，包括：

将预定应用软件APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；

在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同；

在个数不相同的情况下，清除所述组件清单中的所有基础组件，并使用所述新数据在所述预定视图组件对应的资源下构建新的基础组件，以更新所述预定APP界面。

2.如权利要求1所述的方法，其特征在于，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同之后，还包括：

在个数相同的情况下，检测各个基础组件的主题元素是否发生变化；

在主题元素未发生变化的情况下，将所述新数据直接替换至对应的基础组件中；

在主题元素发生变化的情况下，将主题元素发生变化的基础组件对应的资源下使用所述新数据构建新的基础组件。

3.如权利要求1或2所述的方法，其特征在于，将预定应用软件APP界面中每个部分的视图对应的代码封装成一个视图组件，包括：

将所述预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。

4.如权利要求3所述的方法，其特征在于，在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同，包括：

在接收到所述刷新数据的请求消息时，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同；

在位置相同的情况下，检测所述新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同。

5.如权利要求4所述的方法，其特征在于，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同之后，还包括：

在位置不相同的情况下，删除所述预设json数组的数据模型中的原有的所述视图组件和所述新数据对应位置的原有的视图组件，并使用已删除的所述新数据对应位置的原有的视图组件对应的资源构建新的基础组件。

6.一种更新APP界面的装置，其特征在于，包括：

封装模块，用于将预定应用软件APP界面中每个部分的视图对应的代码封装成一个视图组件，并按照生成树方式将每个视图组件中的代码封装成对应的基础组件；

检测模块，用于在预定视图组件接收到刷新数据的请求消息时，检测新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同；

执行模块，用于在个数不相同的情况下，清除所述组件清单中的所有基础组件，并使用所述新数据在所述预定视图组件对应的资源下构建新的基础组件，以更新所述预定APP界面。

7.如权利要求6所述的装置，其特征在于，

所述检测模块，还用于在个数相同的情况下，检测各个基础组件的主题元素是否发生变化；

所述执行模块，还用于在主题元素未发生变化的情况下，将所述新数据直接替换至对应的基础组件中；在主题元素发生变化的情况下，将主题元素发生变化的基础组件对应的资源下使用所述新数据构建新的基础组件。

8.如权利要求6或7所述的装置，其特征在于，所述生成模块，具体用于：将所述预定APP界面的每个视图组件对应的代码分别进行封装，并按照预设顺序将封装后的每个视图组件存储在预设json数组的数据模型中。

9.如权利要求8所述的装置，其特征在于，所述检测模块包括：

第一检测单元，用于在接收到所述刷新数据的请求消息时，检测新数据所在视图组件的位置是否与存储在所述预设json数组的数据模型中的位置相同；

第二检测单元，用于在位置相同的情况下，检测所述新数据中基础组件的个数与组件清单中所述预定视图组件的基础组件个数是否相同。

10.如权利要求9所述的装置，其特征在于，所述执行模块，具体用于：

在位置不相同的情况下，删除所述预设json数组的数据模型中的原有的所述视图组件和所述新数据对应位置的原有的视图组件；使用已删除的所述新数据对应位置的原有的视图组件对应的资源构建新的基础组件。