我在Mutual 工作，这是一家位于巴西的P2P 在线借贷金融科技公司。我的具体工作是帮助寻求公平利率的借款人与寻求高于市场回报的贷款人建立联系。我们的ReactNative iOS 和Android 应用程序在巴西广泛使用，可以在各种设备上下载。
然而，我们可以通过Facebook 的Device-Year-Class 库了解这一点：给定一个设备型号，该库显示该设备在哪一年被认为是高端设备。我们的大多数用户都使用低端设备。
例如，最受用户欢迎的手机是三星Galaxy A10，尽管它于2019 年3 月推出，但在2013 年仍被认为是高端手机。纵观所有用户设备，85% 是2015 年或前。
因此，我们打算重点优化应用程序，让我们的用户即使在不太高端配置的设备上也能获得良好的体验。
每年旗舰设备的百分比
我们最近仔细研究了应用程序大小，Android 上的应用程序大小为26.8MB。虽然这不是一个巨大的数字，但它绝对高于同行的中位数，Google Play 控制台报告为16.3MB。
对于由于数据计划有限且可用磁盘空间很少或没有可用磁盘空间而必须选择保留或卸载哪些应用程序的用户来说，程序大小可能是一个决定性因素。
这对于Mutual 来说尤其重要，因为借款人必须通过该应用程序支付每月分期付款。当借款人卸载该应用程序时，他们按时还款的机会急剧下降，直接影响企业市场的投资者回报。
Mutual 的应用程序(26.8 MB) 比类似的应用程序大得多
应用程序的大小不仅影响卸载率，而且对安装激活转化率也有巨大影响。 APK 大小每增加6 MB，安装到激活的转化率就会降低1%。
Google Play 的一篇文章深入讨论了这个问题(https://medium.com/googleplaydev/shrinking-apks-forming-installs-5d3fcba23ce2)。在低端设备比例较大的发展中国家，这种影响更大。在新兴市场，如果应用程序的APK删除10MB，安装激活转化率可提高约2.5%。
每个国家/地区APK 大小每减少10MB，安装到激活的转化率就会提高
因此，需要在不降低用户体验的情况下尽可能减小应用程序的大小。我们需要采取的第一步是查看Android 开发人员可用的官方资源。
安卓应用程序包
本节展示了减少应用程序大小的最简单方法是尝试新的Android App Bundle (AAB) 分发方法。到目前为止，我们一直在编译在大多数Android 设备中运行的旧Android 包(APK) 文件，并将其上传到Google Play 控制台以分发应用程序。
但是，AAB 包仅包含已编译的代码和资源。因此，在上传时，Google Play 会通过了解每种设备类型的规格和CPU 架构，自行生成优化的APK。
图片来源：unsplash
因此，通过对构建管道进行简单的更改，您就可以免费获得减少程序大小的好处！
阅读本文后，我们修改了其React Native Gradle 构建脚本以运行bundleRelease 而不是当前的assembleRelease。就是这样，我们就有了AAB 文件。
对FastlaneConfig 源进行一些进一步修改后，它可以自动直接上传到Play Store，新版本将出现在Google Play Console 上。通过此更改，我们将交付的APK 大小减少了9.1MB~12.4MB！
旧的APK 为26.8 MB，而新的AAB 为14.4 至17.7 MB
但要小心：如果您将React Native 与Hermes 一起使用，您可能需要根据此问题更新您的soloader 依赖项，否则您将面临给用户提供严重错误的应用程序的风险。
幸运的是，我们能够通过alpha 版本轨道中的测试发现这个问题。但它可能很容易通过，因为它不会在本地或构建APK 时显示。
使用Android Size Analyzer 优化资源
下一个建议是Android Size Analyzer。这是一个命令行工具，可以分析Android 应用程序并指示可以减少多少大小。
使用命令size-analyzercheck-bundle[BUNDLE] 运行后，您将收到大量可以优化的资产和图像，包括配置ProGuard。
尺寸分析器命令的输出
混淆者
Proguard 是一个用于压缩、混淆和优化Java 字节码的工具。我们还没有探索这个途径，因为我们知道可能与其他Android 库不兼容。我们正在寻找快速、简单的方法来减少这种情况并在未来进行优化。
大资产
使用-d 标志再次运行该命令将为您提供按大小排序的每个资产的列表。由于大小分析器工具不知道应用程序的用户流程，因此它可以让我们决定可以动态删除或捆绑哪些内容。
按大小排序的大型资产列表
第一个也是最大的项目是React Native JavaScript 包。分割和动态加载目前还不可能，但我们稍后会看到如何缩小范围。在建议列表的下方，我们看到许多大字体（TTF）和图像（JPG 和PNG）资源。
不需要的图片
内部Storybook 工具中使用的四张巨大的JPG 图像引起了我们的注意。他们在生产APK 中添加了额外的2MB 垃圾！
字体
在快速处理掉这些大图片后，我们继续查看列表的其余部分。很明显，捆绑了大量的字体。在与设计团队交谈后，他们告诉我们许多旧的组件没有严格遵循排版指南。
图片来源：unsplash
因此，我们确定了哪些组件可以删除，哪些组件可以使用类似的更新字体。通过这种方式，我们将字体数量从六种减少到四种。
另一个问题是字体资源大小巨大！每个字体大小近670KB。这意味着这四种字体占用了未压缩包的2.7MB 之多。
有一个名为FontForge 的工具可以让您更深入地查看和修改这些字体文件。打开后可以看到，大部分资源大小都可以使用扩展的西里尔字母和其他不需要的字形来解释。这些都可以删除，因为该应用程序完全是葡萄牙语的。
通过此更改，每个字体大小从670KB 缩小到70KB，减少了90%！
字体中包含的一些字形示例
删除不必要的字体并优化剩余字体总共减少了3.8 MB，这意味着最终APK 大小减少了2 MB。
删除两种字体，优化前后对比剩余字体
优化图像
剩下的一些图像相当大。我们用图像优化工具（tinyjpg）对其中的几个进行了优化，尺寸减小了很多。随后，我们决定优化应用程序中使用的所有41 个JPG 和PNG 资源。
优化前后的图像
这将图像资源从2.5MB 减少到756 KB，减少了70%。但图片本身并没有优化，在生成最终APK的过程中已经被压缩了。因此，最终用户实际上只减少了500 KB。
在此之后，我们意识到我们已经用尽了所有容易挂果的优化。所有进一步的资产优化要么需要更多的努力，要么只能带来微小的改进。
优化React Native JavaScript 包
现在我们已经了解了原生资源，现在是时候分析JavaScript 包了。这是特别值得优化的，原因有以下三个：
· 首先，它减少了成品APK 的包大小；
· 其次，由于JS虚拟机解析的代码较少，因此应用程序启动速度更快；
· 最后，也是最重要的一点，它加快了每周通过CodePush 发布多次的无线(OTA) 更新速度。
束分析仪
要决定如何减小捆绑包的大小，首先，您需要能够查看哪些内容占用了最多的空间。为此，我们将依赖另一个出色的开源工具：react-native-bundle-visualizer。当项目运行时，我可以看到应用程序的每个文件夹和依赖项及其各自的大小。
互助前端代码库的库和文件夹的显示以及大小
应用程序包总共5.49MB，其中57.8% 来自node_modules 依赖项，27.5% 来自应用程序代码，其余部分未由工具映射。捆绑过程已删除未使用的代码路径，您在此处看到的是应用程序使用的实际代码。即便如此，总有改进的空间。
最大的依赖是math.js，顾名思义，它实现了许多数学运算。我们不需要这种依赖性，因为所有敏感计算都在服务器中执行，然后结果简单地发送到应用程序。
仔细观察前端代码，可以看到该库用于一些简单的操作。也从事后端代码工作的开发人员很可能出于习惯而使用它。我们很快从库中提取了这些方法并将它们合并到代码库中，完全消除了这种依赖性。这会将捆绑包大小减少到4.64MB。删除1 个lib 后，大小减少了15.5%！
图片来源：unsplash
如前所述，我们使用Storybook 来独立开发和测试组件。但是，它应该仅在本地和临时环境中可用。任何最终用户都看不到它。
正因为如此，我们使用一个环境变量来控制App的这部分是否启用。虽然这适用于限制访问，但捆绑器无法知道该变量的值。由于此限制，所有Storybook 代码最终都必须放入生产包中。
要解决此问题，请将这部分导入隔离到单个文件中。然后创建了该文件的两个版本：一个包含故事书，另一个用于仅包含虚拟组件的生产。为了在目标生产时在这些文件之间切换，编写了一个脚本，该脚本在交换两个文件的绑定步骤之前运行。
通过这种方法，我们能够从生产中完全删除Storybook 代码路径，消除了node_modules 依赖项以及内部配置的所有代码。
使用两个版本索引文件更新了故事书文件
通过这两项更改，捆绑包大小可以从5.49MB 减少到4.2MB。这意味着用户将有更快的应用程序启动和更新下载。
最终捆绑包大小为4.2MB
经过所有这些改进后，我们再次将应用程序上传到Play 商店。最终的APK 大小将在10.5 到13.7MB 之间，比原来的26.8MB 减少了60%！根据Google Play 团队的文章，这可以将安装激活转化率提高3.75%。
原始APK 与包含所有改进的最终AAB 版本之间的比较
作为面向业务的软件工程师，我们知道公司最好的决策是积累技术债务以更快地迭代产品。对于像Mutual 这样试图寻找产品与市场契合点的初创公司来说尤其如此。
但如果您不监控这笔债务，您可能会犯一些大错误，例如捆绑2MB 测试图像并使用不必要的庞大库。这在隧道视野中也很常见，这是一种快速而简单的机会来优化您已有的东西。
图片来源：unsplash
因此，定期退后一步。确保您不会错过应用程序大小、速度或任何其他方面的快速改进。我们只用了两天的时间就分析、规划和执行了上述所有改进，使应用程序的大小减少了60%。
用户评论
求分享一下具体的修复方法啊！我最近发现手机越来越卡了，不知道是哪个app占内存太大了，希望可以按照这篇文章的方法减少一些占用空间。
有8位网友表示赞同！
60%的容量压缩？听起来有点夸张吧，总觉得这个效果很难达到，不过还是想试试看，看看能不能帮到我！
有12位网友表示赞同！
我也有同样的烦恼，一直换不同软件都解决不了内存问题。这篇文章说的是真的吗？感觉文章内容很详细，我打算试试看方法一！
有5位网友表示赞同！
我的手机经常提示内存不足，真的很烦人！希望能通过这篇文章的方法来提升手机运行速度，这样才能更顺畅地使用。
有12位网友表示赞同！
其实大部分 APP 现在都非常占用内存，这是个系统级别的问题。建议厂商们应该注重资源优化，而不是仅仅依赖用户自行修复。
有5位网友表示赞同！
我感觉很多时候不是APP本身占用了太多内存，而是某些后台程序不断运行导致的。这篇文章有没有讲到如何管理后台进程？
有13位网友表示赞同！
手机卡这个情况真烦透了，特别是玩游戏的时候要一直关掉那些不必要的 APP 后才勉强流畅。希望能通过文章的方法改善一下手机体验！
有5位网友表示赞同！
说真的，很多软件我根本用不到的功能，却占用大量的内存空间。希望官方能根据用户实际使用情况优化软件大小、提供更精简的版本选择。
有10位网友表示赞同！
感觉这篇文章给出了不少实用的建议，尤其是那些关于卸载和清理垃圾文件的问题。我的手机确实积累了一些无用数据，估计用这两招就能解决问题了。
有10位网友表示赞同！
我试过很多方法都治不了手机内存卡顿问题，直到看到了这篇文章，我才明白原来是软件占用了太多空间！现在按照文章中的方法来操作，期望可以改善手机运行速度。
有17位网友表示赞同！
感觉像是在推销什么软件的感觉啊，总觉得文章内容太单向了，并没有给出客观的评价和建议。
有18位网友表示赞同！
60%的容量压缩可能有些誇大其词，但一些软件优化确实可以减少内存占用。我还是希望官方能够重视用户的体验问题，推出更加轻量级的软件版本选择。
有9位网友表示赞同！
我更倾向于使用自带的功能来管理手机应用，比如“清理进程”或“强制关闭”功能。觉得这比单独安装其他APP 更安全便捷。
有12位网友表示赞同！
这个方法确实挺好用的，特别是对于那些老旧的手机来说，可以有效缓解内存不足的情况。但要注意的是这些操作可能会导致一些软件数据丢失，要做好备份。
有13位网友表示赞同！
感觉这篇文章写得很好，很详细地讲解了APP占用了那么多内存的原因以及如何解决这个问题。如果能提供更多具体的软件推荐和使用技巧，那就更好了！
有13位网友表示赞同！
手机越来越贵了，配置也越来越高了，居然还是会被这些占用内存的APP搞到卡顿!真希望厂商们重视系统优化，而不是仅仅靠硬件参数来吸引用户!
有9位网友表示赞同！
总觉得文章过于简单化了问题，好像只要按照步骤去做就能解决所有内存问题。其实情况很复杂，需要根据不同的手机型号和使用环境来采取不同的措施。
有15位网友表示赞同！