业界最全的iOS包瘦身技术实践总结

　　作者：洪尉（洪茶）阿里互动技术团队一、前言
　　包大小是衡量APP性能的一项重要指标，它直接影响用户的下载点击率（包太大不想下）、下载安装成功率（下载慢不用了）、APP卸载率（太占空间先删掉）。包大小的计算逻辑很简单，它是各种类型的文件占用磁盘大小相加，但APP瘦身的技术却很复杂，代码文件的复杂度和编译器策略决定了可执行文件的大小，业务功能和工程架构决定了代码文件的复杂度。
　　iOSAPP瘦身，需要掌握的技能有XCode构建技术、LLVM编译器技术、CocoaPods构建技术、图片压缩技术、持续集成技术。本文总结提炼了Alibaba。comApp的瘦身的技术和策略，系统化地介绍APP瘦身的业务价值、分析技术、瘦身技术、防劣化机制，让读者可以系统化地了解APP瘦身的技术体系。本文还基于实践经验，介绍各种瘦身技术的ROI，让读者可以避免踩雷，将资源浪费在效果不佳的技术上。希望对你有所帮助。二、业务价值2。1包体大小每上升6MB，应用下载转化率就会下降1
　　在2019谷歌开发者大会上，谷歌给出了一个很详细的数据，包体大小每上升6MB，应用下载转化率就会下降1。不同地区转化率略有差异，APK包体大小每减少10MB，全球平均下载转化率会提升1。75，新兴国家代表印度和巴西下载转化率提升2。0以上，高端市场代表美国和德国下载转化率提升1。5。
　　上图标题：APK减少10MB，在不同国家转化率增长
　　数据来源：googleplay内部数据
　　详细材料：
　　白鲸出海：2019谷歌开发者大会首日看点：GooglePlay的新变化
　　http：www。baijingapp。comarticle24808
　　googleplaydev：ShrinkingAPKs，growinginstalls
　　https：medium。comgoogleplaydevshrinkingapksgrowinginstalls5d3fcba23ce2
　　上述数据调研分析报告是2019年以前，已经有所滞后，仅供参考
　　包大小影响下载转化率可能有3个原因：蜂窝网络环境下，用户不愿意支付流量费用。包大小超过200MB时，AppStore会弹框提醒用户下载可能会产生流量费用。下载时间太长，用户不愿意等就取消了下载过程中出现网络连接问题
　　虽然GooglePlay没有给出不同APP类目的数据，但是从以上三个原因推断，不同类目包大小对下载转化率的影响估计差不多。AppStore的用户人群比较高端，可以参考美国和德国的数据。2。220的人因为存储空间有限而卸载应用程序
　　clevertap在2021年做了一项调查，他们调查了2000多个移动应用程序用户，询问了他们卸载移动应用程序的主要原因，其中有20的人因为存储空间有限而卸载应用程序。
　　最主要的3个原因是：他们不再使用该应用程序有限的存储空间太多的广告
　　详细材料：
　　clevertap：WhyUsersUninstallApps
　　https：clevertap。combloguninstallapps2。3AppStore发布和下载限制
　　兼容iOS8的App，主二进制文件的Text段不能超过60MB，否则将无法提交AppStore。AppStore下载包超过200MB，无法使用蜂窝流量下载和更新。
　　三、分析技术
　　APP瘦身最终目标是减少AppStore的安装包大小和下载包大小，但研发阶段对比XCode构建包大小会更方便，需要理清楚他们之间的口径差异。3。1结果指标：AppStore安装包大小和下载包大小
　　查看路径是AppStoreConnectTestFlight交付版本构建版本元数据AppStore文件大小
　　3。2过程指标：XCode构建包大小
　　XCode构建产物ipa包的大小和AppStore的安装大小口径差异很大，通过模拟Apple处理的流程可以得到它们的关系。开发者上传的ipa包里有多个架构的产物，多套尺寸的图片资源，苹果会进行裁剪和二次分发，转化为AppStore下载的ipa包。
　　构建产物ipad包大小：静态库二进制文件（arm64、armv7）、动态库（arm64、armv7）、asset。car（2x、3x）、其他资源文件
　　AppStore的安装大小：静态库二进制文件（单架构）、动态库（单架构）、asset。car（单尺寸）、其他资源文件
　　使用lipo工具拆分单架构lipooriginalExecutablethinarm64outputarm64Executable
　　使用assetutil工具拆分assetxcrunsdkiphoneosassetutilscale3outputtargetFolderAssets3。carsourceFolderAssets。car3。3构建包组成
　　学习如何治病前，得先了解人体的构成。同样的道理，我们首现要了解iOS工程结构和IPA包结构。
　　iOS工程结构：iOS工程由壳工程和Pod模块组成，模块有静态库和动态库两种类型。壳工程的构成有主Target、Apple插件T模块内部的构成有源代码文件（OC、C、C的。h和。m）、nib、bunlde、xcassets、多语言文件、各种配置文件（plist、json）。IPA包结构：iOS上传到AppStore是IPA包，IPA包解压后是一个文件夹，内部由各种类型的文件构成，主要包括MachO可执行文件、。framework（动态库）、Assets。car、。appex（Apple插件）、。strings（多语言）、。bundle、nib、json、png。。。。从iOS工程到IPA包：iOS工程构建为IPA包，核心的变化是编译和文件拷贝，静态库里的源代码会被编译为MachO可执行文件，xcassets文件夹会被转化为Assets。car，其他都可以简单理解为文件拷贝。
　　通过分析构建包的组成，可以判断有哪些优化空间。如果动态库占比太高，就可能有大量可裁剪代码。建议根据资源大小敏感程度划分，比如：MachOexecuteable（包含所有静态库）、动态库、AppleExtension、assets。car、bundle、nib、音频、视频。3。4Pod模块大小
　　APP瘦身会涉及大量业务模块，离不开业务团队的参与。因此，我们需要分析出每个Pod模块的大小，从而可以横向比较各个业务团队的包大小占比。静态库和动态库计算的原理不同，对于静态库，先解析linkmap数据，计算出Pod模块代码大小，在解析PodstargetNameresource。sh的资源拷贝代码，计算出拷贝到Pod模块的资源大小；对于动态库，先使用lipo拆分动态库的二进制文件，计算出单架构的代码大小，然后再计算动态库framework内的资源文件，得到动态库的资源文件大小。3。5运行时Objc类覆盖率
　　如果能知道App运行时有哪些类被使用过，就可以下线掉无用的模块或代码文件，Objc类覆盖率指标可以帮到我们。APP运行时，某1个Pod模块被加载的类数量除以所有类数量，可以称为这个模块的Objc类覆盖率。核心技术是判断一个类是否被加载过，下面介绍一个经过线上验证的轻量级方案，ObjC的类第一次被使用时会调用initialize方法，类被加载过后clsisInitialized会返回True。isInitialized方法读取了metaClass的data变量里的flags，如果flags里的第29位为1，则返回True。objcclass。mmClassclassinitialize（Classcls，idinst）｛if（！clsisInitialized（））｛initializeNonMetaClass（classgetNonMetaClass（cls，inst））；｝｝objcruntime。hdefineRWINITIALIZED（129）boolisInitialized（）｛returngetMeta（）data（）flagsRWINITIALIZED；｝3。6未被使用的图片资源
　　技术原理是先解析出所有拷贝到构建产物的资源文件，再解析出代码中实际引用到的资源文件，两者的差集就是无用资源。
　　第一步获取全量资源文件：在Cocoapos工程中，PodstargetNameresource。sh脚本负责拷贝Pod里的文件资源到构建产物，包括所有文件类型bundle、xcassets、json、png，解析该脚本可以得到每个Pod模块都拷贝了哪些图片资源。PodstargetNameresource。shinstallresource｛PODSROOT｝APodNameAPodName。frameworkAPodName。bundleinstallresource｛PODSROOT｝BPodNameBPodName。frameworkBPodName。xcassetsinstallresource｛PODSROOT｝BPodNameBPodName。frameworkxxx。png
　　第二步，获取代码中实际引用到的资源文件：OC代码中引用资源文件都是以字符串字面量的形式声明，构建后存放在MachO文件cstringsection，利用strings解析framework的二进制文件就可以得到代码中所有的字符串声明，然后基于代码的各种引用方式匹配xxx，xxx2x。png，xxx。png，xxx。bundlexxx。pngstringsexecutablegrepxxxcstrings。txt3。7编译时未被引用的类
　　iOS编译的产物是Macho格式的，文件里DATAobjcclassrefs段记录了所有引用过的类的地址，DATAobjcclasslist段记录了所有类的地址，两者Differ可以得到未被引用类的地址。然后将地址符号化，就可以得到未被引用类信息。因为Objc是动态语言，如果使用runtime动态调用某个class，这种情况扫描不出来。（例如TargetAction和JSCore）otoolvsDATAobjcclassrefsxxxMainClient读取DATASegment中section为objcclassrefs的符号otoolvsDATAobjcclasslistxxxMainClient读取DATASegment中section为objcclasslist的符号nmnmxxxMainClient
　　扫描未使用类的开源工具：
　　https：github。comxuezhulianclassunref四、瘦身技术
　　包大小瘦身可以从纯技术视角瘦身，也可以从逻辑视角瘦身。
　　从纯技术视角有两种思路，第一种思路是优化编译逻辑，第二种思路是删减各种其他类型（非编译产物）的文件。编译优化对业务逻辑无侵入式，风险和成本比较低，但收益通常也不高；删减文件则比较复杂，删减资源文件收益高但成本不小，逐个删减源码文件风险高且收益小。
　　相比而言，从逻辑的视角瘦身效果会更明显。站在逻辑的视角，工程是由许多功能模块组成的，主要可以分为业务功能模块（首页、搜索、收银台、订单）、基础功能模块（网络库、图片库、中间件、各种三方库。。。）。大型工程通常几百甚至上千个模块组成，小模块的有几十KB，大的模块有1MB10MB。功能模块内聚性强，当某个功能模块可以废弃或被替代时，整体下线的风险和成本比较低，ROI很高。4。1瘦身技术大图
　　根据项目经验，我梳理出各种优化方法的ROI，下面依次介绍。
　　4。2组件瘦身
　　组件瘦身的ROI：类加载率0的组件无用功能组件重复功能组件
　　类加载率0的组件是一个完整的Pod模块，模块的代码和资源可以被整体删除，ROI最高。无用功能组件通常是模块内某个文件目录，需要处理一些耦合，梳理资源的归属，ROI其次。重复功能组件需要适当重构，迁移成本和风险最高，ROI相对较低。4。2。1类加载率0的组件
　　类加载率0的组件是指运行时没有任何一个类被加载过的组件，它在运行过程中完全没有用到，可以整体下线。统计类加载率时一般会进行采样，有些低频业务组件可能会误报，下线前需要和业务Owner二次确认。
　　4。2。2无用功能组件
　　无用功能组件是逻辑上已经没用的组件，它可能代码还有耦合，但逻辑已经没用，通过重构就可以下线。比如AB实验没效果的业务代码、往年大促的业务代码、业务改版后遗留的老业务、已经过时的三方库。4。2。3重复功能组件
　　对于大规模团队，不同业务线可能会引入重复功能组件，比如图片选择器、缓存库、UI组件。重复的功能组件会带来不必要的包大小压力，同时也会带来维护成本。4。3资源瘦身
　　资源瘦身ROI：大资源有损压缩重复资源iconfont多语言文案瘦身无用资源4。3。1大资源
　　对大资源进行单点优化收益很大，优先分析100KB以上的资源。比如音频文件，本工程中音频铃声900KB，优化后去掉了700KB。4。3。2有损压缩
　　XCode构建时会做compileassetcatalog，会重新对图片进行无损压缩。因此使用imageoptim等工具进行无损压缩效果不明显，其中压缩png图片没有效果，压缩jpg图片有一定效果。根据实践经验，icon做有损压缩并不影响视觉体验，压缩率可以达到7080。比如使用tinypng算法压缩一张425。9KB的png图片，压缩后79。8KB，压缩率达到81。业界有不少png压缩工具，我们使用到的有tinypng、pngquant、pngcrush、optipng（无损）、advpng。实测发现不同的图片，压缩效果最好的工具不一样，所以压缩图片时可以用每个工具尝试，然后取效果最好的。需要注意的是，压缩APNG图片可能会变成非动图，尽量避免对APNG图片进行压缩，压缩前先识别是否为APNG图片。判断是否APNG格式，APNG格式不压缩functionisApng（）｛retgrepacTL1lastWord｛ret｝if〔〔lastWordmatches〕〕；thenechoYESelseechoNOfi｝使用各种工具压缩png图片pngquantpngquant256s5quality70output｛tmpFileName｝｛tmpOrigName｝pngcrushpngcrushbruteremallanofilecheckbailblackenreducecctmpOrigNametmpFileNameoptipngoptipngo6i0outtmpFileNametmpOrigNameadvpngcptmpOrigNametmpFileNameadvpng4ztmpFileName逐个比较压缩效果，保留效果最好的压缩图片sizeBeforestatfz｛tmpOrigName｝sizeBeforeexprsizeBeforesizeNowstatfz｛tmpFileName｝sizeNowexprsizeNowif〔sizeNowltsizeBefore〕；then大小变小了echo〔advpng〕tmpOrigNameretImgtmpFileNamefi记录hash值imgsumusrbinshasuma256retImgcutdf1cachefilecacheFolderimgsum。png4。3。3无用资源
　　业务长期迭代会积累许多无用的资源。通过代码静态扫描，可以分析出没有被引用的图片资源。例如本工程中无用资源有12MB，其中有20个模块无用资源超过100KB。
　　4。3。4重复图标
　　不同业务需求会引入重复资源，长期积累也会造成很大浪费。解决方案是在构建时计算资源的哈希值，去重相同哈希资源，并保留源文件名和哈希值的映射表。运行时Hook资源加载的imageNamed方法，根据映射表替换资源名称。4。3。5ODR
　　iOS不能像Android一样，运行时更新Framework。iOS的ODR技术（OnDemandResource）提供了运行时动态下载的能力。如果启动用不到的资源文件，可以通过ODR处理。4。3。6iconfont
　　iconfont支持缩放、修改颜色、size小，适合用于箭头、占位图等图标场景，使用iconfont可以减少包大小也能提高开发视觉体验的统一性。首先，基于设计规范出一套完整的iconfont，封装iconfont组件，提供易用的API；然后禁止新业务场景增加图片资源，团队形成开发习惯后再逐步替换存量的图片。4。3。7多语言文案
　　对于国际化App，多语言文案也是大头。本App支持20个语种，每个语种4000多条文案，文案总大小6MB，瘦身后减少了2MB。4。4编译优化
　　编译优化ROI：OptimizationLevel动态库复用主二进制静态库链接器产物压缩
　　XCode编译优化选项中，OptimizationLevel效果最明显，建议所有模块构建都开启Oz选项。如果APP有动态库，并且依赖了openssl等基础静态库，建议和APP工程共享，并通过EXPORTEDSYMBOLSFILE的选型，确保动态库中需要用到的符号都在编译过程保留。如果团队技术储备强，可以自研链接器产物压缩技术，效果也很大，具体效果如下：
　　主工程OC模块
　　62880行代码
　　C模块
　　LTO
　　10KB开启前
　　modulesize：2020KB，
　　MainProjectSize：6463KB
　　开启后
　　modulesize：1582KB
　　MainProjectSize：6888KB
　　收益：13KB
　　剥离符号表：StripLinkedProduct
　　10KB
　　精简编译产物Oz：OptimizationLevel
　　100200KBOs：2261KB
　　Oz：2020KB
　　收益：241KB
　　SymbolsHiddenbyDefault
　　10KB优化前：2020KB
　　优化后：2020KB
　　收益：0KB
　　剔除未引用的CCSwift代码：DeadCodeStripping
　　10KB
　　AssetCatalogCompiler
　　10KB
　　动态库共享APP基础静态库
　　动态库A依赖了公共的静态库库B，通过设置只导出必要符号
　　收益：1367KB
　　C全局静态数组改成动态分配内存
　　收益：200KB
　　C去掉RTTI支持
　　收益：1MB4。4。1精简编译产物Oz：OptimizationLevel
　　OptimizationLevel多个级别，Oz比O3的编译产物体积小10左右。设置Oz以后，XCode会优化连续的汇编指令，从而减少二进制大小，但副作用是执行速度会变慢，C工程建议都开启。主工程ReleaseOptimizationLevel：OzFramework工程OptimizationLevel：Oz4。4。2LTO（OCC）
　　LTO是在LLVM链接时，优化跨模块调用代码。根据大家分享的经验，它不同APP包大小优化效果差异较大，需要具体测试。另外它也有一些副作用，建议只在Release包开启。
　　LTO介绍：代码优化利器LTO介绍知乎
　　优点：将一些函数內联化去除了一些无用代码对程序有全局的优化作用
　　缺点：降低编译链接速度，只建议在打正式包时开启降低linkmap可读性（出现XXlto。thin的类）
　　主工程设置主工程ReleaseLinkTimeOptimization设置为Incrementalframework工程ReleaseLinkTimeOptimization设置为Incremental4。4。3动态库复用主二进制静态库
　　C动态库经常用到一些基础库比如openssl、libyuv、libcurl，他们一般是静态库。如果动态库引用了静态库，它编译时默认会内嵌静态库的所有符号，虽然我们可以在动态库中设置只导出需要用到的静态库符号，但是有可能多个动态库都用到了同一个基础库，这样还是会造成基础库的冗余。比如openssl大小1MB，如果A、B两个动态库依赖了openssl，APP也引用了openssl，最终ipa包实际有3个openssl，有2MB大小是冗余的。
　　这种场景下，最佳解决方案是共享符号表，让动态库可以调用主二进制的基础库符号，从而可以去掉内置的静态库，只要修改XCode的Link配置，无需额外的代码开发。
　　动态库工程：设置当遇到未定义的函数时，动态查找APP主二进制符号表；关闭OtherLinkerFlagsundefineddynamiclookupEnableBitcodeNo导出动态库需要调用的外部符号，写到一个文件exportedsymbols内。nmuxxx。frameworkxxxexportedsymbols。txt
　　APP工程：配置需要导出exportedsymbols文件内的所有符号，避免编译时动态库需要用到的符号被strip掉；关闭bitcode。exportedsymbols。txt是需要被导出的符号文件路径EXPORTEDSYMBOLSFILEexportedsymbols。txtEnableBitcodeNo
　　如果C动态库里依赖了外部静态库，该静态库的符号默认会被全部导出。实际上动态库只用了其中的部分符号，可以设置导出符号的白名单，从而减少导出没有用到的静态库符号。
　　注意事项：APP和framwork工程都要关闭bitcode，否则编译不过；如果多个动态库都使用同一个基础库，导出的符号表需要取并集；动态库升级要及时更新符号表，基础库升级要测试兼容性。4。4。4链接器产物压缩（黑科技）
　　iOS工程构建产物是MachO文件，MachO文件中的TEXT段存放了各种只读的数据段，cstring段存放了普通的CString，objcmethtype和objcmethname存放了Objc的方法签名和方法名。例如Objc代码中声明的Helloworld，底层会产生一个CFString，构建后存放在cstring中。这些数据很占空间，一般工程至少会有10MB以上，压缩的收益很可观，我们上线后，AppStore安装包大小从191MB优化到174MB，减少了16MB。
　　技术原理：
　　链接时将TEXT段数据移到DATA段并压缩，运行时先执行解压代码，解压TEXT段数据存到自定义段中，将代码中对字符串的引用的地址修正为解压后的自定义段。4。4。5剥离符号表：StripLinkedProduct
　　StripLinkedProduct设置会剥离特定的符号，Debug环境不要设置YES，否则调试时看不到符号。主工程ReleaseDeploymentPostprocessing：YESStripLinkedProduct：YESStripStyle：AllSymbols（剥离所有符号表和重定向信息）Framework工程DeploymentPostprocessing：YESStripLinkedProduct：YESStripStyle：NonGlobalSymbols（剥离包括调试信息等非全局的符号，保留外部符号）
　　说明：静态库不能将StripStyle设置为AllSymbols，因为剥离了所有符号的静态库是无法被正常链接的；去除符号不影响dSYM文件中的符号信息，查看崩溃日志时，可以从dSYM文件中找对应符号。4。4。6SymbolsHiddenbyDefault
　　SymbolsHiddenbyDefault用于设置符号默认可见性，如果设置为YES，XCode会把所有符号都定义为privateextern，包大小会略有减少；动态库设置为NO，否则会有链接错误。主工程ReleaseSymbolsHiddenbyDefault：YesFramework工程静态库动态库SymbolsHiddenbyDefault：NO4。4。7剔除未引用的CCSwift代码：DeadCodeStripping
　　DeadCodeStripping开启后会在链接时移除未使用的代码，它对静态语言CCSwift有效，对动态语言OC无效。主工程DeadCodeStripping：Yes4。4。8AssetCatalogCompiler
　　Optimization有三个选项，空、time和Space，选择Space可以优化包大小。主工程AssetCatalogCompilerOptimization设置为space4。4。9C只导出必要符号：SymbolVisibility
　　C的静态库和动态库都只导出必须的符号，默认设置为隐藏所有符号，然后用VisibilityAttributes单独控制需要导出的符号。
　　默认隐藏所有C符号OtherCFlags添加fvisibilityhidden
　　设置需要导出的符号attribute（（visibility（default）））voidMyFunction1（）｛｝attribute（（visibility（default）））voidMyFunction2（）｛｝。。。。4。5代码下线
　　根据Objc类覆盖率统计的结果，可以逐步下线掉未被使用的类。代码文件的量级比较小，下线代码需要仔细确认，避免引起功能问题或crash，ROI比较低。
　　4。6Flutter专项
　　Flutter是单独构建的，引入的内容包括Flutter引擎产物、Flutter业务代码产物。APP如果引入Flutter，需要对Flutter进行专项瘦身。4。6。1精简编译产物Oz：OptimizationLevel
　　Oz选项相比Os，收益预估11，但首屏性能19的损耗。4。6。2Dart符号剔除和混淆
　　根据官方文档，可以通过dwarfstacktrace选项去除Dart标准的调试符号；通过obfuscate选项，可以将较长的符号替换为短符号，副作用是符号会被混淆。实践效果：Release环境下，dwarfstacktrace和obfuscate选项开启后减少14的大小。4。6。3Fluttericon摇树优化
　　treeshakeicons
　　实践效果：Alibaba。comApp开启后减少了300KB左右大小。4。6。4去除NOTICES文件
　　实践效果：压缩前700KB，压缩后80KB。五、防劣化机制5。1增量标准和集成卡口
　　包大小瘦身的技术就像各种减肥运动，跑步、跳舞、燃脂瑜伽，但想达到减肥的目标，只靠运动是不够的，还得控制卡路里的摄入，管住嘴的人最后才能减肥成功。因此，我们还需要新增卡路里的规范（包大小增量规范）和监工（集成卡口）。持续集成当中加入一个卡口插件，分析构建包的linkemap文件得到模块的大小，然后对比基线数据，如果违反了包大小增量标准，则禁止集成。
　　包大小增量规范（参考）：基线数据：基于特定版本，通过上文提到的计算模块大小的方法，计算出每个模块的基线数据存量模块：模块增量超过基准数据100KB时禁止集成。设置补偿机制，如果能对存量模块瘦身，可以抵消新增的模块大小。对于特殊情况可以走特殊审批，加入审批流程是启发大家反思。增加那么多是否有价值？有没有带入不必要的资源？新模块：新业务功能需要走审批流程，评估新业务价值和包大小增量是否合理。
　　5。2横向对比业务健康度
　　当包大小从技术层面已经优化到极致时，想要进一步瘦身，只能从业务价值的角度去挖掘。如果一个模块磁盘尺寸大，用户使用量却少，那可以认为它对业务的价值较小。因此我们可以定义一个技术指标来衡量模块单位大小的业务贡献度。基于容积率指标，我们就可以横向对比各个业务，要求容积率低的业务做包大小瘦身，或下线不太重要的业务功能。
　　容积率BusinessPVBusinesssize六、总结
　　总结一下包大瘦身的实施路径。
　　第一步：制定目标，跟踪APP下载转化率（AppStoreConnectAnalytics）、APP安装包大小、XCode构建包大小等结果指标；
　　第二步：建设分析体系，包括Pod模块大小分析、Objc类覆盖率分析、无用图片资源分析等；
　　第三步：根据ROI使用各项瘦身技术，组件瘦身资源瘦身编译优化代码下线；
　　第四步：建设防劣化机制，包括增量标准、集成卡口能力、健康度分析。参考
　　〔01〕白鲸出海：2019谷歌开发者大会首日看点：GooglePlay的新变化
　　http：www。baijingapp。comarticle24808
　　〔02〕googleplaydev：ShrinkingAPKs，growinginstalls
　　https：medium。comgoogleplaydevshrinkingapksgrowinginstalls5d3fcba23ce2
　　〔03〕clevertap：WhyUsersUninstallApps
　　https：clevertap。combloguninstallapps
　　〔04〕Pngcrush
　　https：pmt。sourceforge。iopngcrush
　　〔05〕pngquant
　　https：pngquant。org
　　〔06〕OptiPNG
　　http：optipng。sourceforge。net
　　〔07〕advpng
　　http：www。advancemame。itdocadvpng。html