APP太占内存怎么办？几个简单的修复将应用程序的大小缩减60%( 三 ) _APP

最大的依赖项是math.js，顾名思义，它实现了许多数学运算。我们应该不需要这种依赖项，因为在服务器中执行所有敏感的计算，然后只需将结果发送给应用程序。
仔细查看前端代码，可以发现库用于一些简单的操作。很有可能是一个同样从事过后端代码开发者出于习惯而使用它。我们迅速地从库中提取了这些方法，并将其纳入代码库，完全消除了此依赖项。这将捆绑包的大小降至4.64MB 。移除一个lib之后，大小缩减了15.5%！

文章插图
图源：unsplash
如前所述，我们使用Storybook独立地开发和测试组件。但是，它应该只在本地和临时环境中可用。任何最终用户都不能看到它。
正因为如此，我们使用一个环境变量来控制是否启用App的这一部分。虽然这对于限制访问有效，但捆绑程序无法知道该变量的值。由于这个限制，所有的Storybook代码最终都要放入到production bundle中去。
为了解决这个问题，将此部分的导入隔离到单个文件中。然后创建了该文件的两个版本：一个包含Storybook，另一个用于生产，只有一个虚拟组件。为了在面向生产时在这些文件之间切换，编写了一个脚本，该脚本在交换两个文件的绑定步骤之前运行。
通过这种方法，我们能够从生产中完全删除Storybook代码路径，消除node_modules依赖项以及内部配置的所有代码。

文章插图
更新之后带有两个版本索引文件的storybook文件
通过这两项更改，能够将bundle大小从5.49MB缩减到4.2MB 。这意味着用户将拥有更快的应用程序启动速度和更新下载速度。

文章插图
bundle最终大小为4.2MB
在所有这些改进之后，我们再次将应用程序上传到了Play商店。最终的APK大小将在10.5到13.7MB之间，从最初的26.8MB减少了60%！按照Google Play团队的文章，这可以将安装激活转化率提高3.75% 。

文章插图
最初的APK和经过所有改进的最终AAB版本之间的比较
作为面向业务的软件工程师，我们知道对公司来说最好的决定就是积累技术债务来更快地更新迭代产品。对于像Mutual这样试图找到产品与市场契合点的初创公司来说，情况尤其如此。
但是如果不监控这个债务，可能会犯一些大错误，比如捆绑2MB的测试图片和使用一个不必要的巨大的库。这也是常见的隧道视野，快速和容易的机会优化已有的。

文章插图
图源：unsplash
所以需要定期后退一步。确保不会错过对应用程序的大小、速度或任何方面的快速改进。我们只花了两天的时间来分析、规划和执行上述所有的改进，这些改进使应用程序的大小缩减了60% 。
这么小的努力，解决困扰已久的难题，带来这么多实实在在的效果，这真的很惊人。

【APP太占内存怎么办？几个简单的修复将应用程序的大小缩减60%】