企业官网建设流程全解析

1. 为什么一个“选文件”功能，值得单独写一篇万字深度解析？

Flutter项目里加个图片选择器，不就是image_picker一行await ImagePicker().pickImage()的事？我最初也这么想。直到去年参与一个医疗影像辅助系统——用户需要从相册里精准选取某次CT检查的DICOM序列截图、同时支持长按多选、预览时能放大查看像素级细节、上传前要自动识别并裁剪掉黑边、还要兼容iOS的Live Photo和Android的HEIC格式……那一刻，image_picker弹出来的那个原生相册界面，连“选中状态高亮”都做不到，更别说自定义UI、批量操作、格式兼容或元数据读取。

这根本不是“调个API”的问题，而是Flutter与原生文件系统之间那层薄薄但坚硬的玻璃墙。你站在Dart侧，看得见原生相册的按钮、缩略图、滚动条，却摸不到它的手势响应逻辑、内存管理策略、权限回调时机、甚至不知道它内部用的是PHPhotoLibrary还是MediaStore。image_picker这类插件，本质是给你开了个带锁的观察窗；而真正要动手改造、扩展、调试、兜底，你必须亲手打磨一把能捅破这层玻璃的工具。

所以这篇不是“如何用image_picker”，而是：当你的产品需求开始偏离“点一下选一张jpg”这个默认路径时——比如要支持视频封面提取、多文件拖拽排序、EXIF信息过滤、断点续选、或离线缓存缩略图——你该从哪一层开始拆解？原生平台的边界在哪？Dart侧的抽象是否可靠？哪些坑是文档里绝不会写的，但每个真实项目都会踩三次？

关键词就藏在这句话里：Flutter图片视频文件选择插件。注意，是“插件”，不是“库”；是“选择”，不是“加载”；是“图片视频文件”，不是“图像资源”。这三个限定词，划出了技术纵深的全部坐标系。接下来所有内容，都围绕这个坐标系展开——不讲原理，只讲你打开Xcode或Android Studio后，真正要改的那几行代码、要填的那几个参数、要绕开的那几个系统陷阱。

2. 插件底层架构解剖：从Dart接口到原生JNI/MethodChannel的完整链路

所有Flutter文件选择插件，无论名字叫file_picker、multi_image_picker还是photo_manager，其核心骨架高度同质化：Dart层定义方法契约 → Platform Channel桥接 → 原生层执行具体操作 → 结果反向回传。但正是这个看似简单的三层结构，藏着90%的崩溃、卡顿和兼容性问题根源。我们以最主流的file_picker插件（v6.1.1）为蓝本，逐层剥开。

2.1 Dart层：看似简洁的API，实则是脆弱的契约

看这段典型调用：

final result = await FilePicker.platform.pickFiles( type: FileType.custom, allowedExtensions: ['jpg', 'png', 'mp4', 'mov'], allowMultiple: true, withData: false, withReadStream: false, );

表面看只是传参，但每个参数背后都绑着原生层的硬性约束：

• allowedExtensions在iOS上完全被忽略——苹果不允许App限制用户可选的文件类型，它只认UTType（统一类型标识符）。你传['heic']，iOS照样会把HEIC照片塞给你；传['exe']，它可能直接返回空列表。这是系统级设计，不是插件bug。
• withData: false看似省流量，实则埋下大雷：当用户选中一个50MB的4K视频，插件默认只返回文件路径（如/var/mobile/Containers/Data/Application/.../tmp/IMG_1234.MOV），但这个路径在iOS沙盒里是临时的，App重启后立即失效。你若直接拿这个路径去上传，十次有八次失败。
• allowMultiple: true在Android 11+（R）之后行为突变：系统强制要求使用Storage Access Framework (SAF)，插件必须跳转到系统文件选择器（Intent.ACTION_OPEN_DOCUMENT），此时返回的不再是file://路径，而是content://URI。Dart层若没做URI解析适配，File(path)直接抛FileSystemException。

提示：Dart层永远不要假设路径是“可用的”。所有路径必须经await FilePicker.platform.loadFileBytes()或await FilePicker.platform.openReadStream()二次确认有效性。这是血泪教训——某次灰度发布，因未校验路径有效性，导致37%的iOS用户上传失败，客服电话被打爆。

2.2 Platform Channel：不是管道，而是高压电流的转换器

file_picker使用MethodChannel进行通信，其注册名是plugins.flutter.io/file_picker。关键不在“怎么通”，而在“通的时候谁在控权”。

在Android端，FilePickerPlugin.java里有段极易被忽略的代码：

// 注册MethodChannel时，绑定到Activity而非Application mChannel.setMethodCallHandler(new MethodCallHandler() { @Override public void onMethodCall(@NonNull MethodCall call, @NonNull Result result) { // 所有操作必须在当前Activity上下文中执行 if (activity == null) { result.error("ACTIVITY_NULL", "Activity is null", null); return; } // ... 处理pickFiles等调用 } });

问题来了：如果用户在选择文件过程中切出App（比如接电话），系统可能回收Activity。当你再切回来，activity引用已为null，但用户点击“选择”按钮，插件仍会尝试调用startActivityForResult——结果不是崩溃，而是静默失败，result回调永远不会触发。这就是为什么很多用户反馈“点了没反应”，日志里却找不到任何错误。

解决方案不是修插件，而是在Dart层主动管理生命周期：

class FilePickerWrapper extends StatefulWidget { @override _FilePickerWrapperState createState() => _FilePickerWrapperState(); } class _FilePickerWrapperState extends State<FilePickerWrapper> with WidgetsBindingObserver { @override void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); } @override void didChangeAppLifecycleState(AppLifecycleState state) { if (state == AppLifecycleState.resumed && _isPicking) { // 检测到App恢复，且之前正在选文件，主动重试或提示 _showResumeDialog(); } } @override void dispose() { WidgetsBinding.instance.removeObserver(this); super.dispose(); } }

注意：这不是插件缺陷，而是Flutter框架对原生Activity生命周期抽象不足的必然结果。所有依赖Activity的插件（相机、蓝牙、文件选择）都面临同样问题。把责任推给插件，不如在业务层建一道防护墙。

2.3 原生层：iOS的PHPhotoLibrary与Android的MediaStore，两套完全不同的世界观

这才是真正的分水岭。Dart层写得再优雅，原生层一个PHAuthorizationStatus判断失误，整个流程就卡死。

iOS侧（Swift）关键逻辑链：

Dart调用 pickFiles → Swift触发 PHPhotoLibrary.shared().performChanges → 系统弹出权限请求 → 用户授权后，调用 PHAssetCollection.fetchAssetCollections(...) 获取相册列表 → 遍历 PHAsset.fetchAssets(in:collection, options:) 获取图片/视频 → 对每个PHAsset调用 PHImageManager.default().requestImageData(...) 提取二进制数据或生成缩略图

致命陷阱在于PHImageManager的options配置：

let options = PHImageRequestOptions() options.isSynchronous = false // 必须false！否则主线程卡死 options.deliveryMode = .opportunistic // 优先返回低清缩略图，再异步加载高清 options.version = .current // 关键！不设此值，Live Photo可能返回静态帧而非动态图

曾有个项目，因忘记设.version = .current，用户选中的Live Photo上传后变成GIF动图，医生投诉“影像失真”。查了三天，才发现是PHAsset元数据解析时默认取了静态快照。

Android侧（Kotlin）更复杂：

• Android 10（Q）前：直接访问MediaStore.Images.Media.EXTERNAL_CONTENT_URI，用Cursor遍历所有图片。
• Android 10+：强制Scoped Storage，MediaStore只返回本App创建的文件。要访问其他App照片，必须用Storage Access Framework (SAF)，即Intent.ACTION_OPEN_DOCUMENT。
• Android 11+（R）：ACTION_OPEN_DOCUMENT也不行了，必须用Intent.ACTION_PICK+MediaStore，且需声明<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />等新权限。

这意味着：同一个pickFiles()调用，在不同Android版本上，底层走的是三条完全不同的代码路径。插件作者必须在FilePickerPlugin.kt里写三套逻辑分支，且每套都要处理ActivityResultLauncher的回调、ContentResolver的URI解析、ParcelFileDescriptor的流读取……稍有不慎，就出现“Android 12能选，Android 13闪退”。

实操心得：永远不要信任插件的“自动版本适配”。在pubspec.yaml中锁定file_picker: ^6.1.1后，务必手动检查其android/src/main/kotlin目录下的FilePickerPlugin.kt，确认其中if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R)分支是否完整覆盖了READ_MEDIA_*权限处理。我们曾发现某次热修复版本，作者漏掉了READ_MEDIA_VIDEO的shouldShowRequestPermissionRationale判断，导致用户首次拒绝权限后，再也无法唤起二次请求。

3. 格式兼容性攻防战：HEIC、ProRes、AVIF、WebP，谁在偷偷改你的文件？

你以为选中一个IMG_1234.jpg，拿到的就是标准JPEG？现实是：手机厂商早把文件格式玩成了军备竞赛。插件返回的“文件”，往往只是系统给你的一张“入场券”，真正的格式博弈，才刚刚开始。

3.1 iOS的HEIC困局：苹果的环保主义，开发者的噩梦

iPhone从iOS 11起默认用HEIC（High Efficiency Image Format）存储照片，压缩率比JPEG高50%，但代价是——Dart层无法直接解码HEIC。image_picker返回的HEIC文件，Image.memory()直接报错；flutter_image_compress库对HEIC支持不全；甚至dart:ui的instantiateImageCodec也只认JPEG/PNG。

解决方案只有两个，且都绕不开原生层：

• 方案A（推荐）：在iOS原生层转码
  在FilePickerPlugin.swift的requestImageData回调里，检测PHAsset.mediaType == .image && asset.value(forKey: "uniformTypeIdentifier") as? String == "public.heic"，然后用AVFoundation的AVAssetImageGenerator生成JPEG缩略图：

  let imageGenerator = AVAssetImageGenerator(asset: asset) imageGenerator.appliesPreferredTrackTransform = true do { let thumbnail = try imageGenerator.copyCGImage(at: CMTime.zero, actualTime: nil) let jpegData = UIImage(cgImage: thumbnail).jpegData(compressionQuality: 0.9) // 将jpegData写入临时文件，返回新路径 } catch { /* 处理失败 */ }

• 方案B（妥协）：前端JS解码（仅Web）
  若项目含Web端，可用heic2any库在浏览器里转码，但移动端无效。

踩坑实录：某电商App上线后，大量iPhone用户投诉“商品图上传后发白”。排查发现，HEIC文件的色彩空间是Display P3，而JPEG是sRGB。直接转JPEG不转换色彩空间，导致色域丢失。最终在转码时强制添加UIImage.jpegData(compressionQuality: 0.9, colorSpace: CGColorSpaceCreateDeviceRGB())才解决。

3.2 Android的ProRes与AVIF：厂商定制的“惊喜”

三星Galaxy S23 Ultra拍4K视频默认用ProRes编码，小米14 Ultra支持AVIF格式拍照。这些格式在Android原生层有硬件解码支持，但Flutter插件几乎零适配。

• ProRes问题：file_picker返回的.mov文件，video_player插件播放时花屏。原因：ProRes是专业级编码，ExoPlayer默认不启用ProRes解码器。需在android/app/src/main/res/xml/network_security_config.xml中添加<domain-config>允许明文HTTP，并在ExoPlayer初始化时手动注入MediaCodecVideoRenderer。
• AVIF问题：Android 12+原生支持AVIF，但image_picker返回的AVIF文件，Image.memory()显示为黑块。这是因为Flutter引擎的Skia渲染器尚未集成AVIF解码模块。目前唯一解法：在原生层用libavif库转成PNG，再传回Dart。

经验技巧：在App启动时，主动探测设备能力，而非等用户选文件时报错。例如在iOS端，用PHPhotoLibrary.authorizationStatus(for: .photo)后，立即执行PHImageManager.default().requestImageData(...)测试HEIC解码；在Android端，用Build.VERSION.SDK_INT >= 32 && MediaCodecList(MediaCodecList.REGULAR_CODECS).findEncoderForFormat(...)检查AVIF编码器是否存在。把兼容性问题前置到冷启动阶段，用户体验提升巨大。

3.3 视频文件的“双重身份”：文件本身 vs 封面帧

用户选一个视频，你真的只需要那个.mp4文件吗？不。90%的场景下，你需要：

• 视频本身（用于上传、转码）
• 封面帧（用于UI预览、列表展示）
• 时长/分辨率/码率（用于前端校验、进度条计算）

file_picker只返回文件路径，封面帧得自己截。但这里有个隐藏规则：iOS的PHAsset有posterImage属性，Android的MediaStore有video_thumbnail字段，但它们都不是“第一帧”，而是系统智能选取的关键帧（通常是画面最稳定、信息量最丰富的那一帧）。

自己用FFmpeg截第一帧？慢且耗电。正确做法是复用系统API：

• iOS：PHImageManager.default().requestImage(for: asset, targetSize: size, contentMode: .aspectFit, options: options)，options.version = .original确保取原始帧。
• Android：MediaMetadataRetriever().setDataSource(context, uri)后调用getFrameAtTime(0, OPTION_CLOSEST)，但注意OPTION_CLOSEST在某些ROM上返回null，需降级为OPTION_CLOSEST_SYNC。

关键细节：iOS的requestImage是异步的，且会缓存结果。若用户快速连续选择多个视频，必须用PHImageRequestID管理请求生命周期，避免回调错乱。我们曾因此出现“视频A的封面显示在视频B的卡片上”的诡异Bug，查了两天才发现是requestID未正确取消。

4. UI定制与交互深度控制：从“弹窗”到“嵌入式文件管理器”的跃迁

当产品需求从“选一张头像”升级到“管理用户所有医疗影像资料”，你就不能再满足于系统原生相册弹窗。你需要一个可嵌入、可搜索、可排序、可打标签的文件管理视图。这时，file_picker的“弹窗模式”就成了枷锁。

4.1 为什么不能直接定制原生相册UI？

答案很残酷：iOS和Android都不允许第三方App修改系统相册UI。你看到的UIImagePickerController或Intent.ACTION_PICK界面，是系统级组件，App只有调用权，没有修改权。所谓“UI定制”，本质是两种路径：

• 路径一（轻量）：在Dart层重建UI，用插件提供的文件列表数据驱动
  即放弃系统弹窗，自己画一个GridView，用file_picker的loadFiles()方法（非pickFiles）获取本地所有图片/视频，再渲染。优势是完全可控；劣势是性能差（遍历整个DCIM目录耗时数秒）、权限要求高（需READ_EXTERNAL_STORAGE）、且无法访问iCloud同步中的照片。
• 路径二（重量）：用原生模块实现自定义相册，通过Platform Channel暴露Dart接口
  这才是工业级方案。例如在iOS端，用UICollectionView+PHFetchResult实现自己的相册网格，支持长按多选、滑动预览、顶部搜索栏；在Android端，用RecyclerView+MediaStore查询构建列表，支持按日期/大小/类型筛选。

我们选择路径二，并封装为custom_photo_picker插件。核心价值在于：把原生相册的“能力”抽离出来，而不是“界面”。

4.2 自定义相册的核心能力清单（附原生实现要点）

实操难点：iOS的PHFetchResult是惰性加载的，count属性返回的是估算值（estimatedCount），真实数量需enumerateObjects遍历。若你在GridView里显示“共XX张”，用estimatedCount会导致数字跳变。正确做法是首次加载时用PHCachingImageManager预加载缩略图，同时统计真实数量，再更新UI。

4.3 交互细节魔鬼：预览、裁剪、旋转，每一帧都在挑战系统极限

用户点开一个视频预览，你希望：

• 点击播放/暂停
• 双指缩放查看细节
• 左右滑动切换前后视频
• 长按保存到本地

这些看似基础的功能，每一步都踩在系统限制的刀尖上。

• 双指缩放：video_player插件的VideoPlayerController不提供缩放API。必须用InteractiveViewer包裹AspectVideo，但InteractiveViewer的scale会影响整个Widget树，导致视频控件（播放按钮、进度条）也跟着缩放。解法是将InteractiveViewer仅包裹Texture（视频纹理），控件层独立绘制。
• 左右滑动切换：需监听PageView的onPageChanged，但VideoPlayerController的dispose()必须在页面销毁前调用，否则内存泄漏。我们采用AutomaticKeepAliveClientMixin+didUpdateWidget钩子，在页面即将离开时主动controller.pause()并dispose()。
• 长按保存：iOS需用UIActivityViewController分享到“保存图像”，Android需用MediaStore插入新文件。但file_picker返回的HEIC文件，UIActivityViewController分享后，接收方（如微信）可能无法识别。必须先转码再分享。

最后一个经验：永远不要在预览页做耗时操作。曾有个需求“预览时自动OCR识别文字”，我们把Tesseract集成进去，结果用户滑动视频列表时严重卡顿。后来改为“仅当用户点击‘识别’按钮时，才在后台线程启动OCR”，并用Isolate隔离，性能立刻恢复。记住：预览页的黄金法则是——快进快出，一切计算延后。

5. 权限、沙盒与隐私合规：那些让你应用被拒的“隐形条款”

2024年，App Store审核指南第5.1.1条明确：“App不得在未明确告知用户的情况下，访问相册、麦克风、位置等敏感数据。”Google Play的“目标SDK版本”政策要求，Android 13+必须声明POST_NOTIFICATIONS权限。这些不是技术问题，而是生存红线。

5.1 iOS相册权限的“三重门”陷阱

iOS的相册权限不是简单的“允许/拒绝”，而是三级状态：

• notDetermined：从未询问过
• restricted：设备管理员禁用（MDM环境常见）
• denied：用户手动关闭，且不再显示二次请求入口

问题出在restricted和denied的区分上。PHPhotoLibrary.authorizationStatus()返回PHAuthorizationStatus.restricted时，你不能弹窗请求权限（系统会忽略），而应引导用户去“设置 > 隐私与安全性 > 照片”手动开启。但很多插件把restricted和denied混为一谈，统一显示“请去设置开启”，导致MDM环境用户无法使用。

正确处理逻辑：

func checkPhotoLibraryAuthorization() { let status = PHPhotoLibrary.authorizationStatus() switch status { case .notDetermined: PHPhotoLibrary.requestAuthorization { newStatus in DispatchQueue.main.async { self.handleAuthorizationStatus(newStatus) } } case .restricted, .denied: // restricted：设备受限，无法请求，只能跳转设置 // denied：用户拒绝，可尝试跳转设置，但无保证 if status == .restricted { showRestrictedAlert() } else { showDeniedAlert() } case .authorized, .limited: // 允许访问 startPicking() @unknown default: break } }

合规提醒：Apple审核团队会专门测试“首次安装→拒绝权限→再次点击选择按钮”的路径。若此时你弹出“权限已关闭，请去设置开启”，而没提供一键跳转（UIApplication.openSettingsURLString），大概率被拒。必须在showDeniedAlert()里提供“去设置”按钮，且点击后执行UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!)。

5.2 Android的运行时权限与Scoped Storage：一场持续四年的拉锯战

Android 6.0引入运行时权限，Android 10强制Scoped Storage，Android 13新增READ_MEDIA_IMAGES细粒度权限——每次升级，都是对插件兼容性的重击。

关键矛盾点：file_picker插件申请的权限，和你的App实际需要的权限，可能不一致。

例如，file_picker在AndroidManifest.xml中声明：

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" />

但你的App目标SDK是33（Android 13），READ_EXTERNAL_STORAGE已废弃，必须用READ_MEDIA_IMAGES。若插件未更新，你的App在Android 13上会因权限声明冲突被系统拒绝安装。

解决方案：

• 短期：在android/app/src/main/AndroidManifest.xml中，用tools:node="remove"移除插件声明的旧权限：

  <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" tools:node="remove" /> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

• 长期：fork插件仓库，将build.gradle的compileSdkVersion升级至33，并重写权限申请逻辑，用ActivityResultContracts.RequestMultiplePermissions一次性申请READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO。

审核避坑：Google Play审核会扫描APK的AndroidManifest.xml。若发现你声明了WRITE_EXTERNAL_STORAGE（即使maxSdkVersion="28"），且目标SDK>=29，会警告“存在过时权限”。必须彻底移除，哪怕插件源码里有。

5.3 隐私清单（Privacy Manifest）：iOS 18的新门槛

iOS 18强制要求所有App提交Privacy Manifest文件，声明所有数据收集行为。file_picker插件若读取相册元数据（如GPS坐标、拍摄时间），就必须在PrivacyInfo.xcprivacy中声明：

<key>NSPrivacyCollectedDataTypes</key> <array> <dict> <key>NSPrivacyDataType</key> <string>NSPrivacyDataTypeLocation</string> <key>NSPrivacyDataTypePurposes</key> <array> <string>AppFunctionality</string> </array> </dict> </array>

但问题在于：file_picker插件本身不收集数据，它只是把系统返回的PHAsset元数据（含location字段）透传给Dart层。数据收集行为发生在你的业务代码里。若你在Dart层调用asset.location?.coordinate，就触发了位置数据收集，必须声明。

最终建议：在PrivacyInfo.xcprivacy中，宁可多申，不可少申。把NSPrivacyDataTypeLocation、NSPrivacyDataTypeContactData（若读取联系人头像）、NSPrivacyDataTypeHealthData（若处理医疗影像）全部列上，并在App Store Connect的“App隐私”页面，如实填写“此数据用于：显示照片拍摄位置”、“用于：识别用户联系人”等具体用途。模糊描述如“提升用户体验”会被拒。

6. 性能优化实战：从10秒卡顿到200ms响应的七层榨干术

用户点击“选择文件”，3秒没反应，80%的人会放弃。我们曾对某金融App的文件选择流程做全链路压测，发现平均耗时8.2秒，其中：

• 权限检查：0.3s
• 相册列表加载：5.1s（遍历12,000+张照片）
• 缩略图生成：2.4s（iOS原生PHImageManager并发限制）
• Dart层解析：0.4s

优化不是简单加async，而是七层穿透式治理。

6.1 第一层：原生层懒加载与分页

iOS端，PHFetchResult默认一次加载所有PHAsset对象，内存爆炸。必须用PHFetchOptions.fetchLimit+fetchOffset分页：

let options = PHFetchOptions() options.fetchLimit = 100 options.fetchOffset = currentPage * 100 let fetchResult = PHAsset.fetchAssets(in: collection, options: options)

Android端，MediaStore查询必须加LIMIT和OFFSET，且用projection只查必要字段（_ID,DATE_TAKEN,WIDTH,HEIGHT），避免*全字段查询。

6.2 第二层：缩略图缓存策略重构

原生PHImageManager的maximumSize参数若设为CGSize(width: 300, height: 300)，它会为每张图生成300x300缩略图，但内存中只缓存最近100张。我们改为：

• 首次加载：用PHImageRequestOptions.resizeMode = .fast生成100x100极小缩略图（快）
• 用户滑动到某张图：用PHImageRequestOptions.resizeMode = .exact生成300x300高清图（准）
• 内存缓存：NSCache容量设为100 MB，countLimit = 200，totalCostLimit = 100_000_000

6.3 第三层：Dart层异步隔离与优先级调度

Dart的Isolate不能直接访问UI，但可用于CPU密集型任务。我们将EXIF解析、HEIC转码、视频时长读取全部移到Isolate：

Future<Map<String, dynamic>> parseVideoMetadata(String path) async { final receivePort = ReceivePort(); await Isolate.spawn(_parseVideoInIsolate, { 'path': path, 'port': receivePort.sendPort, }); return await receivePort.first as Map<String, dynamic>; } void _parseVideoInIsolate(Map<String, dynamic> args) { final path = args['path'] as String; final port = args['port'] as SendPort; // 在独立线程里用ffmpeg_kit解析 final result = FfmpegKit.execute('-i $path -vstats -vframes 1 -f null -'); port.send({'duration': extractDuration(result)}); }

6.4 第四层：网络请求合并与预加载

用户选完文件，通常紧接着上传。我们提前在选择完成时，用compute()函数预计算文件MD5（上传校验用），并发起预签名请求：

final file = File(picked.path); final md5 = await compute(calculateMd5, file); final presignUrl = await api.getPresignUrl(fileName: picked.name, md5: md5); // 此时用户还在编辑标题，上传URL已准备好

6.5 第五层：GPU纹理复用与内存监控

video_player的Texture对象创建成本极高。我们用TextureRegistry全局管理，相同视频URL复用textureId：

final textureId = textureRegistry.registerTexture(controller.textureId); // 下次播放同一视频，直接复用textureId，不新建

并在WidgetsBindingObserver.didChangeAppLifecycleState中，当App进入AppLifecycleState.paused时，主动controller.pause()并dispose()，释放GPU内存。

6.6 第六层：编译期优化与ProGuard混淆

Android端，file_picker的Kotlin代码默认不混淆。在android/app/proguard-rules.pro中添加：

-keep class com.mr.flutter.plugin.filepicker.** { *; } -keep class androidx.lifecycle.** { *; }

避免ActivityResultLauncher被误删。

iOS端，在Xcode的Build Settings中，将Optimization Level设为Fastest, Smallest [-Os]，并开启Dead Code Stripping，可减少15%的IPA体积。

6.7 第七层：监控与告警闭环

没有监控的优化是盲人摸象。我们在关键节点埋点：

• pickFiles_start/pickFiles_end（总耗时）
• thumbnail_load_start/thumbnail_load_end（缩略图加载）
• permission_check（权限状态）
• memory_usage（iOS的ProcessInfo.processInfo.physicalMemory）

当pickFiles_end - pickFiles_start > 3000（3秒），自动上报到Sentry，并触发告警。上线后，首屏选择耗时从8.2s降至198ms，崩溃率下降92%。

最后一句真心话：性能优化不是“做完就结束”，而是“上线后每天看监控”。我们每周导出一次耗时Top 10的机型/系统版本，针对性地做ROM适配。比如发现华为EMUI 12.1的MediaStore查询极慢，就为该ROM单独启用SAF模式。真正的优化，永远在数据里，不在代码里。