共计 3223 个字符，预计需要花费 9 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“Flutter 瘦身怎么实现”，内容详细，步骤清晰，细节处理妥当，希望这篇“Flutter 瘦身怎么实现”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
下面我们以 ios 端为例分析项目中 flutter 产物的大小（ipa 包瘦身需求更为急切）。
ios 工程对 Flutter 有如下依赖：
Flutter.framework : Flutter 库和引擎
App.framework: dart 业务源码相关文件
Flutter Plugin：编译出来的各种 plugin 的 framework
flutter_assets：Flutter 依赖的静态资源，如字体，图片等
第一次引入 flutter 版本改造详情页后，ipa 包大小增加近 20M，其中包括 flutter 引擎代码 + 被改造业务代码，继续发布页 flutter 改造后，ipa 增加 4M+。进一步分析解压 ipa 文件后发现 Flutter.framework 稳定保持在 20M+ 的大小, 增加新的 flutter 业务——发布页之后，App.framework 增幅近 10M!
Flutter.framework 是 Flutter 库和引擎的代码，我们能做的优化空间有限，先把目标放在 dart 业务相关的文件 App.framework 上。
Flutter 产物大小分析
执行如下命令编译出一个 release 模式下的 App.framework，并使用 print-snapshot-sizes 参数打印出产物具体大小
flutter build aot --release --extra-gen-snapshot-options=--print-snapshot-sizes结果如下：
Building AOT snapshot in release mode (android-arm-release)...
VMIsolate(CodeSize): 4660
Isolate(CodeSize): 2585632
ReadOnlyData(CodeSize): 2693576
Instructions(CodeSize): 8064816
Total(CodeSize): 13348684
Built to build/aot/.Instructions：代表 AOT 编译后生成的二进制代码大小
ReadOnlyData：代表生成二进制代码的元数据（例如 PcDescriptor，StackMap，CodeSourceMap 等）和字符串大小
VMIsolate/Isolate：代表剩下的对象的大小总和（例如代码中定义的常量和虚拟机特定元数据）
具体到业务层，想要分析各个业务模块所占用的大小该怎么办呢？
执行如下命令编译出一个 arm64 架构的 App.framework, 并将它的包组成结构放到指定目录 build/aot.json 文件中
flutter --suppress-analytics build aot --output-dir=build/aot --target-platform=ios --target=lib/main.dart --release --ios-arch=arm64 --extra-gen-snapshot-options= --dwarf_stack_traces,--print-snapshot-sizes,--print_instructions_sizes_to=build/aot.json使用 dart 命令将上一步生成的 aot.json 文件转化成结构可视化的网页
dart ./bin/run_binary_size_analysis.dart build/aot.json path_to_webpage_dirrun_binary_size_analysis.dart 是 dart 提供的一个分析工具，在 flutter 引擎源码中路径如下:
打开生成文件夹中的 index.html 即可分析具体业务所占用的大小，右上角的 Large Symbols 和 Large Files 按钮可以直接定位体积占比从大到小的方法 / 文件。
举个例子，上面的分析显示 PItemInfoInternal.fromJson 方法占用了大量体积，跟踪发现这个方法主要的操作是将 Map 数据转化成对象
PItemInfoInternal.fromJson(Map dynamic, dynamic map) { id = map[ id] as String;
attributes = map[attributes] as String;
title = map[title] as String;
......
}由此我们可以推断这种类型转换的操作会导致编译生成一些体积很大的代码。
优化措施
减少显示类型转换操作
按照上述分析发现显示的类型转换 as String/Bool/Int 这类操作会导致 App.framework 体积显著增加，主要是它会增加类型检查以及抛出异常的处理逻辑:
if (x.classId A x.classId B) throw x is not subtype of String通过提取静态公用方法的方式可以成功减少 400k+ 体积。
通过编译参数 –dwarf_stack_trace 和 –obfuscate 减小生成代码的体积
dwarf_stack_trace 表示在生成的动态库文件中，不使用堆栈跟踪符号
obfuscate 表示混淆，通过减少变量名 / 方法名的方式减小代码体积
// 编译 release 包并打印 size
flutter build aot --release --extra-gen-snapshot-options=--print-snapshot-sizes
//--dwarf_stack_traces， -- 减少 6.2% 大小
flutter build aot --release --extra-gen-snapshot-options= --dwarf_stack_traces,--print-snapshot-sizes
//--obsfuscation， -- 减少 2.5% 大小
flutter build aot --release --extra-gen-snapshot-options= --dwarf_stack_traces,--print-snapshot-sizes,--obfuscate
// 总大小减少 8.7%
通过修改 ios 打包脚本 xcode_backend.sh，删除 dSYM 符号表信息文件，App.framework 成功减小 20% 的大小。dSYM 是保存 16 进制函数地址映射信息的中转文件，包含我们调试的 symbols，用来分析 crash report 文件，解析出正确的错误函数信息。
使用 xcrun 命令将 dSYM 从 framework 中剥离出来，可以大大减小 App.framework 的体积。
RunCommand xcrun dsymutil -o ${build_dir}/aot/App.dSYM减少 flutter 和 native 资源重复造成的体积增大
利用桥接的方式，flutter 直接使用 Platform 端资源文件，避免因为资源文件重复导致的包大小增加问题。
主要方式是通过 BasicMessageChannel 在 Flutter 和 Platform 端传递信息。Flutter 端将资源名 AssetName 传递给 Platform 端，Platform 端接收到 AssetName 后，根据 name 定位到资源文件，并将该文件以二进制数据格式，通过 BasicMessageChannel 传递回 Flutter 端。
读到这里，这篇“Flutter 瘦身怎么实现”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
