一种Flutter应用安装包体积优化的方法及存储介质与流程

本发明涉及计算机应用技术领域，更具体地说，涉及一种flutter应用安装包体积优化的方法及存储介质。

背景技术：

flutter是google用以帮助开发者在ios和android两个平台开发高质量原生应用的全新移动ui框架，并且开发者可以通过dart语言开发应用app。flutter虽然带了很多创新与机遇，但为了提高用户的体验和开发效率，flutter也带来了很多问题。

根据flutter官网截至2019年7月更新的数据，一个最简版本的flutter应用(即不包含material组件)在安卓平台发布的一个apk，arm64下是4.6mb，arm下是4.3mb。在ios平台上，同一应用的发布ipa在iphonex上的下载文件体积为10.9mb。ipa比apk大，主要是因为apple加密了ipa中的二进制文件，使得文件压缩效率降低。一般而言，迷你版apk仅仅只有几百kb，ipa文件也可以达到只有1-2mb，flutter应用的安装包体积明显超重了。

现有技术中，通常采用的原生开发出来的android的apk，比用flutter开发的apk体积小8m，ios压缩包小16m，并且随着改造业务的增多，安装包体积急剧上增，动辄上百兆的安装或者更新包让用户望而却步，安装包体积决定了用户等待下载的时间和可能会耗费的流量

但是，由于flutter是在2015年dart开发者峰会上亮相的，是个有力的新生儿，这就说明了它目前的社区生态还处于发展阶段，不仅在第三方的扩展组件方面缺少沉淀，而且在相关的安装包体积优化方面的技术介绍少之又少。

技术实现要素：

1.要解决的技术问题

针对现有技术中存在的原生开发出来的android的apk和ios安装包体积，比用flutter开发的apk和ios压缩包体积小，安装包体积决定了用户等待下载的时间和可能会耗费的流量的问题，本发明提供了一种flutter应用安装包体积优化的方法及存储介质，它可以实现控制安装包体积，提高用户的体验，减小flutter安装包体积的大小。

2.技术方案

本发明的目的通过以下技术方案实现。

一种flutter应用安装包体积优化的方法，所述优化方法包括：

步骤201：检测需要优化的源代码，记录性能检测数据以及flutter项目打包数据；

步骤202：源代码关联配置文件，对源代码进行规范化检测，检测源代码的性能、规范和质量；在准备好的flutter源代码根目录下面引入eslint.dart脚本，同时自定义配置相关的eslint-config.dart配置文件，包括用户对代码风格、代码质量等对代码的限制；脚本格式使用map结构来实现；

步骤203：规范化检测后，输出优化提示信息；执行eslint.dart脚本，得出该脚本对flutter源代码修改的建议；

步骤204：根据规范化检测后优化提示信息，定位需要优化的源代码，对源代码进行针对性优化；

步骤205：再次进行规范化检测，若仍提示需要优化则继续优化，直到规范化检测后不提示优化信息为止；根据建议来修改和优化flutter源代码，修改完毕后；继续执行规范化检测脚本，观察优化的建议是否存在，若存在继续执行eslint.dart脚本，直到脚本没有检测出flutter源代码缺陷；

步骤206：使用步骤201性能检测方法，记录优化后性能检测数据；

步骤207：将flutter项目打包，记录打包后的大小；

步骤208：比较分析flutter项目优化前后的性能检测数据和打包数据，优化后的性能检测数据高于优化前的性能检测数据，优化后打包数据小于优化前打包数据。

更进一步的，源代码性能检测步骤包括：

步骤101：获取最新版本的flutter代码库；

步骤102：android真机配置到开发状态，连接编辑器；

步骤103：在编辑器中开启分析模式运行，并运行flutter源代码；

步骤104：运行分析工具；本发明使用flutter应用中devtools工具多次监测flutter应用运行时候的性能，利用devtools可以观察以下性能信息：

1、selectwidgetmode：机器上选中的widget会呈现蓝色蒙版，直观地看到该widget的相关属性。

2、performanceoverlay：可查看运行时的帧率。

3、debugpaint：查看控件宽高以及位置，便于调试。

4、paintbaselines：绘制基线。

5、slowanimationgs：减慢动画，动画效果变慢。

6、memory：运行时内存信息。

步骤105：分析源代码性能相关属性数据；

步骤106：将flutter项目最终打包，观察打包后的大小。

本发明在flutter官网中检测flutter应用性能的方法上做出了改进，改进部分包括：基本设备配置，安装flutter并配置环境变量，使用androidstudio作为编辑器，同时在此编辑器中安装对应的flutter和dart插件。

更进一步的，规范化检测时使用基于ast抽象语法树结构的递归算法，逐步和配置文件中的规范要求进行对比；得出需优化代码内容及需优化代码位置。

更进一步的，步骤202中所述配置文件包括自定义的强制性语法限制和内置的优化建议的语法限制。

更进一步的，引入图片压缩插件包，在对源代码进行优化时调用插件包对图片进行优化。本发明通过构建第三方包flutter图片压缩插件包，在图片优化时引入第三方包，对图片进行优化压缩。

更进一步的，图片压缩插件包使用哈夫曼算法压缩。

更进一步的，性能检测时对源代码进行多次性能检测，取多次检测数据的平均值为最终的性能检测数据。为了防止偶然原因导致数据不正确，多次检测性能数据后取平均值，一般来说，检测次数至少为三次。

更进一步的，打包时对flutter项目进行多次打包，取多次打包数据的平均值为最终的打包数据。为了防止偶然原因导致数据不正确，多次打包数据后取平均值，一般来说，打包次数至少为三次。

更进一步的，源代码规模大于设定值。以项目中产生的flutter源代码为评测依据，代码规模至少4k。代码规模太小优化效果不易体现，基本上没有优化的必要。由于目前市面上的应用app都有默认或者内置图片，图片压缩是整体缩小体积的一部分。一般情况下图片容易占用空间，所以对图片进行压缩，容易体现优化app体积的效果。

本发明代码优化主要是通过运行eslint.dart脚本，对flutter源代码进行分析自动提出优化建议，此脚本的形成步骤如下：

首先，eslint.dart吸取了前端eslint形成机理的思想，利用ast语法树结构，通过对在前端环境下的代码的循环遍历，得到的信息和配置信息(用户自定义的文件)进行对比，达到给出提示信息的效果)。主要通过读取flutter源代码，将代码结构的信息(该信息都存在ast语法树中)读取到内存中；

其次读取eslint-config.dart配置文件中的规范要求，写入到内存之中；

然后通过类似java中main方法作为代码检测的主程序入口，从内存中读取eslint-config.dart配置文件，将相关的信息使用map结构(一种键值对的数据结构)记录下来；

接下来从内存中读取flutter源代码的相关结构，使用基于ast抽象语法树结构的递归算法，逐步和eslint-config.dart配置文件中的规范要求(存到了map结构中)进行对比，

同时也和eslint.dart中内置语法规范进行对比，注意这里得出了相关的优化信息后，还要记录下来ast抽象语法树中此处需优化代码的位置；此处主要是对代码结构以及代码重复的优化，不包括图片优化；

最后，将优化信息和需优化代码的位置，存在内存之中，等对ast抽象语法树遍历完毕后，依次将信息打印出来；等信息打印完毕后，eslint.dart脚本检测完毕，此时将内存中的数据清理完毕。

一种存储介质，所述存储介质存储有程序，所述程序包括程序指令，所述程序指令当被处理器执行时使所述处理器执行所述一种flutter应用安装包体积优化的方法

对比压缩之后的图片，查看本发明优化效果，基本上所有的图片都可以达到想要的效果。使用flutter指令构建androidapk，通过至少3次以上将压缩前和压缩后的apk大小进行对比，发现压缩后整个app图片这块的整体体积至少可以降低20％-30％。但是图片压缩有最大极限，如果要指定压缩到多少kb，需要结合其他应用压缩方式使用经验，过度压缩会损害到图片质量。

3.有益效果

相比于现有技术，本发明的优点在于：

本发明通过对需要优化的源代码配置优化配置文件，根据性能优化标准和代码规范执行脚本对源代码进行规范化检测，检测内容包括源代码的性能、规范和质量；根据检测后提示信息对代码进行规范化优化，只要包括对代码的结构和重复的代码进行定位，根据定位处代码进行针对性优化；对源代码中的图片部分引用第三方包图片压缩插件包，第三方包中使用压缩算法对图片体积进行压缩，本发明优化方法极大的降低了安装包的体积大小，安装包体积减少20％以上，提高了flutter应用的实用性和用户体验。

附图说明

图1为本发明实施例提供的flutter应用代码检测方法的流程示意图；

图2为本发明实施例提供的flutter应用代码优化的流程示意图。

具体实施方式

下面将结合附图对本发明技术方案的实施例进行详细的描述。以下实施例仅用于更加清楚地说明本发明的技术方案，因此只作为示例，而不能以此来限制本发明的保护范围。需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本发明所属领域技术人员所理解的通常意义。

在本申请中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在本发明的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。

具体实现中，本发明实施例中描述的终端包括但不限于诸如具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的移动电话、膝上型计算机或平板计算机之类的其它便携式设备。还应当理解的是，在某些实施例中，所述设备并非便携式通信设备，而是具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的台式计算机。

在接下来的讨论中，描述了包括显示器和触摸敏感表面的终端。然而，应当理解的是，终端可以包括诸如物理键盘、鼠标和/或控制杆的一个或多个其它物理用户接口设备。

终端支持各种应用程序，例如以下中的一个或多个：绘图应用程序、演示应用程序、文字处理应用程序、网站创建应用程序、盘刻录应用程序、电子表格应用程序、游戏应用程序、电话应用程序、视频会议应用程序、电子邮件应用程序、即时消息收发应用程序、锻炼支持应用程序、照片管理应用程序、数码相机应用程序、数字摄影机应用程序、web浏览应用程序、数字音乐播放器应用程序和/或数字视频播放器应用程序。

可以在终端上执行的各种应用程序可以使用诸如触摸敏感表面的至少一个公共物理用户接口设备。可以在应用程序之间和/或相应应用程序内调整和/或改变触摸敏感表面的一个或多个功能以及计算机可读存储介质上显示的相应信息。这样，终端的公共物理架构(例如，触摸敏感表面)可以支持具有对用户而言直观且透明的用户界面的各种应用程序。

首先对本发明所涉及的名词进行解释：

flutter：flutter是google的便携式ui工具包，帮助你在移动、web、桌面端创造高质量的绝妙原生体验的应用。flutter可以和世界上的开发人员和开发组织广泛使用的那些现存代码一起使用，并且是开源的、免费的。

flutter指令构建androidapk：是一种将flutter源码编译成androidapk的过程，步骤如下：使用命令行:

1、cd<appdir>(<appdir>为您的工程目录).

2、运行flutterbuildapk(flutterbuild默认会包含--release选项).

3、打包好的发布apk位于<appdir>/build/app/outputs/apk/app-release.apk。

dart：dart是一种开源的通用编程语言。它最初由google开发，后来被ecma批准为标准。dart是一种新的编程语言，适用于服务器和浏览器。同时又是一种面向对象的语言，具有c语言风格的语法，可以选择将它编译成javascript。它支持各种编程辅助工具，如：接口，类，集合，泛型和可选类型。

apk：apk是androidpackage的缩写，即android安装包(apk)。apk是类似symbiansis或sisx的文件格式。通过将apk文件直接传到android模拟器或android手机中执行即可安装。

ipa：ipa是apple程序应用文件iphoneapplication的缩写。简单来说，mac下的软件就像是windows下的绿色软件一样，解压后即可使用，不需要安装，卸载的话也只用删除程序文件即可(这里不涉及pkg格式安装包)。

b：一种数据单位，目前情况下几乎总是由八位数据组成。一个字节可以代表一个单独的字符，例如字母、数字或标点符号。因为一个字节代表的信息量很小，所以计算机内存和存储器通常以千字节(kb)、兆字节(mb)，或吉字节(gb)为单位给出。

eslint.dart：本发明中自主发明的检测flutter语言是否规范化的脚本。主要内置功能包括检测flutter源代码的性能、规范和质量；检测依据主要参照官方的性能优化标准和代码规范。

eslint-config.dart：本发明中eslint.dart的配置文件。主要分为：1、自定义的强制性的语法限制；2、内置的优化建议的语法限制。

ast：是abstractsyntaxtree(抽象语法树)的缩写，ast是源代码语法结构的一种抽象表示。在互联网领域被大量使用，主要是用来做代码分析的功能。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。之所以说语法是“抽象”的，是因为这里的语法并不会表示出真实语法中出现的每个细节。

递归算法：在计算机科学中是指一种通过重复将问题分解为同类的子问题而解决问题的方法。递归式方法可以被用于解决很多的计算机科学问题，因此它是计算机科学中十分重要的一个概念。绝大多数编程语言支持函数的自调用，在这些语言中函数可以通过调用自身来进行递归。计算理论可以证明递归的作用可以完全取代循环，因此在很多函数编程语言(如scheme)中习惯用递归来实现循环。

devtools：是flutter提供诸如性能分析、堆测试以及显示代码覆盖率等功能的工具。其中devtool的[timeline]界面可以让开发者逐帧分析应用的ui性能，从而可以定性的衡量代码运行时候的性能。

哈夫曼树算法：哈夫曼树又称最优二叉树，是一种带权路径长度最短的二叉树。所谓树的带权路径长度，就是树中所有的叶结点的权值乘上其到根结点的路径长度，若根结点为0层，叶结点到根结点的路径长度为叶结点的层数。树的路径长度是从树根到每一结点的路径长度之和，记为wpl＝(w1*l1+w2*l2+w3*l3+...+wn*ln)，n个权值wi(i＝1,2,...n)构成一棵有n个叶结点的二叉树，相应的叶结点的路径长度为li(i＝1,2,...n)。可以证明哈夫曼树的wpl是最小的。

本发明实施例提供的flutter性能优化方法，适用于安卓平台的flutter应用的性能优化。首先实施例1提供了如何对flutter源代码进行性能检测的通用方法；并利用写好的eslint.dart脚本，对写好的flutter源代码进行规范、性能方面的检测；同时可以自定义配置eslint-config.dart，通过自定义一些固定的语法规则，让自己写的flutter源代码更加符合自己规定的代码风格。

下面这几个具体的实施例可以相互结合，其中的实施例1主要是为其他实施例提供实际的测试效果，通过分析使用了eslint.dart脚本进行改进的flutter源代码，和没有使用此脚本的flutter源代码，得出本发明的有益效果。对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

实施例1

本实例提供了一种基于flutter的性能优化的方法，图1是本发明实施例如何将flutter项目，安装到android真机上，并进行性能分析的流程图，检测需要优化的源代码，记录性能检测数据以及项目打包数据包括以下步骤：

步骤101：从代码库里面获取最新版本的flutter代码库。

具体的，要求flutter项目的源代码是可运行的、无病毒的，并且代码有一定的规模，至少4k行，并且配有图片，从而保证脚本能够检测出一定的代码质量。

步骤102：android真机配置到开发状态，并连接到编辑器。

具体的，配置一部android手机，本实施例中以小米8为例，下载编辑器，本实施例中以androidstudio编辑器为标准，并安装flutter和dart插件，配置环境变量，操作系统为window7。基本的配件准备好后，就可以进行真机调试了：将真机通过数据线连接上电脑，并打开手机的开发者选项，同时设置android手机(小米8)为usb调试模式。

步骤103：在编辑器中开启分析模式运行，并运行flutter源代码

然后在androidstudio使用run>flutterrunmain.dartinprofilemode选项，就可以打开分析模式；之后，在androidstudio右侧导航栏中显示了真机的型号后，即可以点击启动按钮，运行flutter源代码。

步骤104：在androidstudio运行devtools，根据性能图层定性的记录下相关的性能数据；

步骤105：分析性能相关属性数据，从而对apk性能进行评测。

步骤106：将flutter项目最终打包，观察打包后的大小。

图2是本发明将发明的脚本对运行中的项目进行优化的示意图，项目通过规范化检测，提示并手动修改；利用新型的压缩算法，对打包后的代码进行相关压缩。

包括以下步骤：

步骤201，检测需要优化的源代码，记录性能检测数据以及项目打包数据；对没有进行脚本规范化检测的代码，使用前述性能检测实施例，记录下定性的性能检测数据；同时记录下打包的大小。

具体的，至少性能测试3次取平均值，确保测试数据的准确性、正确性，防止因为个别的数据影响测试的结果；打包的大小同理需要至少打包3次取平均值。

步骤202，对源代码配置优化配置文件，根据性能优化标准和代码规范执行脚本对源代码进行规范化检测，检测源代码的性能、规范和质量；对需要规范化的flutter源代码，配置好eslint-config.dart的配置文件，执行我们写好的脚本eslint.dart；

具体的，flutter源代码保证和步骤201中的源代码保持一致，并保证可运行，代码的有一定的规模性。

步骤203：根据检测后显示规范化提示信息，定位需要优化和修复的源代码，对源代码进行针对性优化；上一步骤经过了检测，并打印输出了相关的优化提示信息，具体的信息内容为：

显示了eslint.dart中内置的规范化flutter源代码的提示信息；

显示了eslint-config.dart中自定义的规范化flutter源代码的提示信息；

步骤204：根据提示信息，对flutter源代码进行优化和修复；

具体的，对提示信息的结构和相关的提示语，要提前有一定的了解，并能够理解提示语的相关提示作用；可以根据提示语来对代码进行优化和修复。

步骤205：再次进行规范化检测，若仍提示需要优化则继续根据提示进行优化，直到检测不提示优化信息为止；再次运行eslint.dart脚本，查看检测的提示信息，测试下上一步骤是否修复完毕。若脚本依然提示需要优化，则继续根据提示进行优化修复，修复完后继续执行eslint.dart检测脚本，直到检测不提示优化信息为止。

具体的，需要多次重复执行步骤203和步骤204，不断的改进和修复flutter源代码，同时再次对代码进行脚本检测，得出检测的结果。此处需要用户保持细心、耐心，同时要对flutter源代码的业务、项目结构十分熟悉，能够根据代码的结构和脚本的提示信息，来快速定位需要相关优化和修复的flutter源代码，进行针对性优化。

步骤206：检测优化后的源代码，记录性能检测数据以及项目打包数据；

步骤207：将优化后的flutter源代码，使用步骤201中性能检测方法记录下定性的性能检测数据；

具体的，至少性能测试3次取平均值，确保测试数据的准确性、正确性，防止因为个别的数据影响测试的结果。

同时对彻底优化后的代码，进行至少3次的打包，从而取平均值。具体的，注意打包的严谨性，打包的大小同理需要至少打包3次取平均值。

步骤208：比较分析flutter项目优化前后的性能检测数据和打包数据，优化后的性能检测数据高于优化前的性能检测数据，优化后打包数据小于优化前打包数据。发现使用eslint.dart脚本检测的性能指标，明显好于没有使用eslint.dart脚本检测的性能指标，代码的质量和规范都有明显的改善，有很多容易犯的错误都能精准的检测并定位出来。优化后打包数据变下，安装包体积变小。

实施例2

本实例提供了一种基于flutter的对应用内项目进行优化和压缩的方法。图片到现在为止仍然是最重要的信息承载媒介，不得不说使用app的过程，其实就是一个看图片的过程，正是因为图片量大，导致flutter里图片相关的问题一直挥之不去。为了解决这些问题，需要对图片进行压缩，在利用哈夫曼树算法的基础进行封装，包装成适合flutter的插件包。

首先引入包含哈夫曼树算法的第三方包，构建flutter图片压缩插件包。哈夫曼算法是一种无损压缩算法，哈夫曼需要得到每种字符出现概率的先验知识。通过计算字符序列中每种字符出现的频率，为每种字符进行唯一的编码设计，使得频率高的字符占的位数短，而频率低的字符长，来达到压缩的目的，通常可以节省20％～90％的空间，很大程度上依赖数据的特性。

其次，在实际的flutter项目中引入构建flutter图片压缩插件包。调用对应指令对项目中的本地图片进行压缩，压缩之后的图片将覆盖原有图片，有的情况下可以将3-4mb左右的图片无损压缩到100kb。

最后，对比压缩之后的图片，查看实际的效果，基本上所有的图片都可以达到想要的效果。整个app图片这块的整体体积至少可以降低20％-30％。但是图片压缩有最大极限，如果要指定压缩到多少kb，结合其他压缩方式使用经验，过度压缩会损害到图片质量。

本实施例将优化和没有优化后的flutter源代码进行编译，得到具体的apk大小，从而推出能够优化的程度。

分别对无优化、及优化后的同一款基于flutter应用的源代码，使用print-snapshot-sizes参数打印出产物具体大小。

执行flutterbuildaot--release--extra-gen-snapshot-options＝--print-snapshot-sizes指令。

分析没有优化后的产物具体大小，得出的结果如下：

vmisolate(codesize):4660

isolate(codesize):2585632

readonlydata(codesize):2693576

instructions(codesize):8064816

total(codesize):13348684

instructions：代表aot编译后生成的二进制代码大小

readonlydata：代表生成二进制代码的元数据(例如pcdescriptor，stackmap，codesourcemap等)和字符串大小

vmisolate/isolate：代表剩下的对象的大小总和(例如代码中定义的常量和虚拟机特定元数据)

total：总体包的大小

按照上述用例进行优化后，执行相同指令分析产物具体大小，得出的结果如下：

vmisolate(codesize):3726

isolate(codesize):2068504

readonlydata(codesize):2154850

instructions(codesize):6451850

total(codesize):10678930

从两者的产物具体大小来看，优化后的大小是优化前的80％左右(10678930/13348684)，其他的模块也是大致如此(vmisolate，isolate，readonlydata，instructions)。从而可以得出，体积优化大致优化了20～30％之间。

实施例3

基于相同的发明构思，本申请实施例还提供了另一种存储介质，存储有程序，所述程序包括程序指令，所述程序指令当被处理器执行时实现本申请实施例中任意一个实施例或任意一种可选实施方式提供的任意一种数据预测方法的步骤。

本申请实施例提供的存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

以上示意性地对本发明创造及其实施方式进行了描述，该描述没有限制性，在不背离本发明的精神或者基本特征的情况下，能够以其他的具体形式实现本发明。附图中所示的也只是本发明创造的实施方式之一，实际的结构并不局限于此，权利要求中的任何附图标记不应限制所涉及的权利要求。所以，如果本领域的普通技术人员受其启示，在不脱离本创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本专利的保护范围。此外，“包括”一词不排除其他元件或步骤，在元件前的“一个”一词不排除包括“多个”该元件。产品权利要求中陈述的多个元件也可以由一个元件通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。