手机内存变小如何恢复|手机内存清理方法( 四 ) 图源：unsplash我在巴西一家P2

在这之后，我们意识到已经耗尽了所有容易的hanging fruit optimizations 。所有进一步的资产优化要么需要更多的努力，要么只会带来很小的改进。

文章图片

优化React Native JavaScript bundle
已经看完了native资产，现在是时候分析JavaScript包了。这是一件特别值得优化的事情，原因有三：

· 首先，它减小了成品APK的bundle大小；
· 其次，由于JS虚拟机解析更少的代码，所以能进行更快的应用程序启动；
· 最后，也是最重要的一点是，它加快了每周通过CodePush多次发布的空中（OTA）更新的速度。

Bundle analyzer

要决定将如何减少bundle的大小，首先，需要能够看到什么占用了最多的空间。为此，我们将依靠另一个优秀的开源工具：react-native-bundle-visualizer 。在项目运行时，得到了应用程序的每个文件夹和依赖项以及它们各自大小的可视化。

文章图片

Mutual前端代码库的库和文件夹的展示及其大小
应用程序包总共有5.49MB ，其中57.8%来自node_modules依赖项， 27.5%来自应用程序代码，其余部分是工具无法映射的。捆绑过程已经移除了未使用的代码路径，在这里看到的是应用程序实际使用的代码。即便如此，总还有改进的空间。

最大的依赖项是math.js ，顾名思义，它实现了许多数学运算。我们应该不需要这种依赖项，因为在服务器中执行所有敏感的计算，然后只需将结果发送给应用程序。

仔细查看前端代码，可以发现库用于一些简单的操作。很有可能是一个同样从事过后端代码开发者出于习惯而使用它。我们迅速地从库中提取了这些方法，并将其纳入代码库，完全消除了此依赖项。这将捆绑包的大小降至4.64MB 。移除一个lib之后，大小缩减了15.5%！

文章图片

图源：unsplash
如前所述，我们使用Storybook独立地开发和测试组件。但是，它应该只在本地和临时环境中可用。任何最终用户都不能看到它。

正因为如此，我们使用一个环境变量来控制是否启用App的这一部分。虽然这对于限制访问有效，但捆绑程序无法知道该变量的值。由于这个限制，所有的Storybook代码最终都要放入到production bundle中去。

为了解决这个问题，将此部分的导入隔离到单个文件中。然后创建了该文件的两个版本：一个包含Storybook ，另一个用于生产，只有一个虚拟组件。为了在面向生产时在这些文件之间切换，编写了一个脚本，该脚本在交换两个文件的绑定步骤之前运行。