Android WebView混合开发：H5调用相机与相册的两种落地路线

做Android WebView混合开发这几年，我接手过好几个被H5调用相机/相册折磨过的项目。最常见的现象是：同一个页面放到微信里、系统浏览器里都正常，一放进自家App的WebView里，点input文件选择框要么毫无反应，要么直接闪退。另一类问题出现在图片数据回传上——原生侧辛辛苦苦拿到了多张图片的Uri，传回H5后页面崩溃或者图片转圈出不来，低端机上尤为明显。

今天这篇不聊PPT方案，全部是能落地的路子。我会把"H5通过Android WebView获取手机相机或相册图片"这件事拆成两条完整路线：一条是让WebView自己弹系统文件选择器，另一条是原生接管拍照/选图后用JSBridge把多张照片数据回传给H5。两条路线各自的实现代码、踩坑点、权限适配、性能参数，一次讲透。

1. 先想清楚需求：系统选择器与原生接管，两条路线的分岔点

很多人一上来就找代码，其实第一步应该想清楚你到底是哪种业务场景。因为"H5要图片"这句话，在不同场景下对应的实现方案完全不一样。

1.1 路线A：让WebView自己弹系统选择器（input file + onShowFileChooser）

如果H5页面本身就写好了<input type="file" accept="image/*" multiple>，并且页面逻辑依赖input事件来读取文件、预览图片、走FormData上传，那你要做的事很明确：让Android WebView支持input弹窗。

默认情况下，Android WebView是不处理input type="file"点击事件的。用户在H5页面里点击input，什么都不发生，连系统文件选择器都不会弹出。原因在于WebView没有默认实现文件选择回调，需要我们在WebChromeClient里重写onShowFileChooser方法，自己接管"选择文件"这个动作，然后把结果回传给页面。

这条路线的核心特征是：H5页面自己拿文件、自己处理文件。原生侧只负责把系统文件选择器拉起来，再把用户选中的Uri集合原样返回给WebView内核，剩下的预览、上传、压缩全是H5自己的事。

1.2 路线B：原生负责拍照/选图，通过JSBridge把多张图片数据回传

另一类业务是H5页面里放了自定义UI，比如一排"添加图片"的九宫格，点一下由App弹ActionSheet，里面有"拍照"和"相册"两个选项。H5并不使用input标签，而是通过JSBridge调用原生方法，等原生处理完后把结果传回H5。

这种场景下原生侧要处理的事更多：弹拍照页或相册选择器、处理多图选择结果、压缩图片、选一种H5能识别的数据格式、调用JS回调把数据推回给H5页面。数据流完全掌控在原生手里，H5只是被动接收结果。

它的核心特征是：数据和流程由原生主导，H5只做展示和后续交互。

1.3 决策对照：三种真实项目场景该选哪条

不是所有项目都能随便选路线，业务场景和团队分工决定了选择。我列一张对比表，你可以直接对自己项目的情况：

我个人判断标准很简单：如果页面是通用表单、上传逻辑H5已经写好了，直接走路线A，原生代码量小；如果涉及社区、电商这种对图片数量、体积、UI都有要求的场景，强烈建议路线B。很多大厂App的H5页面，虽然看起来是页面里的上传按钮，背后其实是路线B，因为这样可以统一压缩策略、限制张数、照顾低端机性能。

2. 路线A实现：重写onShowFileChooser，把input file的弹窗从"没反应"变成可用

先说清楚：onShowFileChooser是API 21（Android 5.0）引入的方法，如果你们App最低支持版本低于5.0，还需要处理已经废弃的openFileChooser。我按主流情况直接讲onShowFileChooser，低版本兼容方案后面提。

2.1 核心代码框架与两个必须注意的"老旧回调"

看代码：

public class MyWebChromeClient extends WebChromeClient { private ValueCallback<Uri[]> mFilePathCallback; private static final int REQUEST_CODE_CHOOSER = 0x1001; @Override public boolean onShowFileChooser(WebView webView, ValueCallback<Uri[]> filePathCallback, FileChooserParams fileChooserParams) { // 关键点1：如果上一次回调还没被消费，必须先回调null，否则页面那个input的Promise永远挂起 if (mFilePathCallback != null) { mFilePathCallback.onReceiveValue(null); } mFilePathCallback = filePathCallback; Intent intent = fileChooserParams.createIntent(); // 关键点2：显式加上临时读权限，部分ROM上不加会拿不到相册返回的Uri intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION); startActivityForResult(intent, REQUEST_CODE_CHOOSER); return true; } }

createIntent()是系统提供的便捷方法，它会根据H5页面input标签上的accept和multiple属性自动生成合适的Intent：单选还是多选、图片还是文件，都帮你处理好了。这是最省事的做法，比手动拼Intent可靠得多。

但注意，这里有个初学者容易忽略的点：onShowFileChooser返回true表示"原生接管了这个选择动作"，如果返回false，系统会按自己的默认方式处理——而实际结果是什么都不弹。所以一定不要忘了return true。

2.2 相机拍照：需要准备临时文件+FileProvider

上面那段基础代码处理相册选择没问题，但如果input带了capture="camera"属性，或者在文件选择器里用户选择相机，系统相机拍完照后需要往一个预先指定的位置写入。这个位置不能随便用file://路径，Android 7.0开始强制要求用content://Uri，也就是FileProvider。

先配置FileProvider，AndroidManifest.xml里加：

<provider android:name="androidx.core.content.FileProvider" android:authorities="${applicationId}.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider>

res/xml/file_paths.xml里声明一个缓存目录：

<paths> <cache-path name="camera" path="camera/" /> <external-cache-path name="external_camera" path="camera/" /> </paths>

给onShowFileChooser增加拍照分支，完整一点：

@Override public boolean onShowFileChooser(WebView webView, ValueCallback<Uri[]> filePathCallback, FileChooserParams fileChooserParams) { if (mFilePathCallback != null) { mFilePathCallback.onReceiveValue(null); } mFilePathCallback = filePathCallback; Intent intent = fileChooserParams.createIntent(); if (fileChooserParams.isCaptureEnabled()) { // input标签带了capture属性，直接唤起相机 takeCameraPhoto(); } else { intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION); startActivityForResult(intent, REQUEST_CODE_CHOOSER); } return true; } private void takeCameraPhoto() { try { File photoFile = createCameraFile(); mCurrentPhotoFile = photoFile; Uri photoUri = FileProvider.getUriForFile(mContext, mContext.getPackageName() + ".fileprovider", photoFile); Intent cameraIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE); cameraIntent.putExtra(MediaStore.EXTRA_OUTPUT, photoUri); cameraIntent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION); startActivityForResult(cameraIntent, REQUEST_CODE_CHOOSER); } catch (IOException e) { mFilePathCallback.onReceiveValue(null); mFilePathCallback = null; } } private File createCameraFile() throws IOException { File dir = new File(mContext.getCacheDir(), "camera"); if (!dir.exists() && !dir.mkdirs()) { throw new IOException("create camera dir failed"); } String timestamp = new SimpleDateFormat("yyyyMMdd_HHmmss", Locale.US).format(new Date()); return File.createTempFile("IMG_" + timestamp + "_", ".jpg", dir); }

注意:isCaptureEnabled()在不同WebView版本上实现有差异，部分ROM即使input标签没写capture，也可能返回true。所以如果你的H5里这个input本来就是既允许拍照又允许选相册的，不要强行依赖这个方法判断，继续用createIntent()更有保障。如果createIntent()返回Intent的Action是ACTION_IMAGE_CAPTURE，则它内部已经帮我们把EXTRA_OUTPUT设置好了，直接启动就行。

2.3 收结果：单Uri、ClipData、拍照返回的三种分支

接下来是收尾环节，在Activity的onActivityResult里拿用户选择的结果。这里的坑在于：不同选择器、不同图片数量，返回的数据结构不一样。

@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { if (requestCode != REQUEST_CODE_CHOOSER || mFilePathCallback == null) { return; } if (resultCode != RESULT_OK) { mFilePathCallback.onReceiveValue(null); mFilePathCallback = null; return; } Uri[] results = null; if (data != null && data.getClipData() != null) { // 多选：系统通过ClipData返回一组Uri int count = data.getClipData().getItemCount(); results = new Uri[count]; for (int i = 0; i < count; i++) { results[i] = data.getClipData().getItemAt(i).getUri(); } } else if (data != null && data.getData() != null) { // 单选：直接返回一个Uri results = new Uri[]{data.getData()}; } else if (mCurrentPhotoFile != null && mCurrentPhotoFile.length() > 0) { // 拍照返回：data可能为null或者不带data，通过之前保存的临时文件构造Uri results = new Uri[]{FileProvider.getUriForFile(mContext, mContext.getPackageName() + ".fileprovider", mCurrentPhotoFile)}; } // 无论有没有结果，都必须回调，不能漏 mFilePathCallback.onReceiveValue(results); mFilePathCallback = null; }

这里要特别强调：onActivityResult里无论什么情况，最后都要调用mFilePathCallback.onReceiveValue(results)，哪怕结果是null。如果漏调，H5页面的input事件回调永远不会触发，用户会以为页面卡死了。

2.4 真实踩坑：重复点击导致H5 Promise悬空、ROM兼容差异

路线A的问题多发生在细节上。我列几个真实踩过的：

第一个坑：快速重复点击input选择框，回调对象覆盖。用户手滑点两次，onShowFileChooser被调用两次，第二次进来时第一次的mFilePathCallback还没被消费。解决方式就是第一节代码里写的：每次进来先把上一个callback回调null。

第二个坑：部分国产ROM（尤其是华为和早期的vivo）在用户取消选择时，既不返回RESULT_OK也不返回RESULT_CANCELED，而是直接不回调。我在老EMUI机型上遇到过，结果就是H5页面的input事件一直挂着。稳妥做法是加一个超时保护：启动选择器后开一个几秒钟的Handler，如果超时还没有回调结果，主动回调null并清空引用。

第三个坑：某些ROM自带文件管理器的"图片"入口不支持多选。即便input里写了multiple，它也只返回一张。这个问题没法靠代码根治，只能接受现状。所以如果你的业务对多选有硬性要求，还是看路线B。

第四个坑：onActivityResult在Fragment里时要记得分发给WebView所在的那个Fragment或Activity。如果WebView被包在Fragment里，回调写在Activity里但Activity没有转发，选择结果就丢了。我建议直接把onShowFileChooser的逻辑写在WebView所在Activity里，或者把mFilePathCallback用接口下沉到Fragment可控的生命周期内处理。

3. 路线B实现：原生选完图后用JSBridge把多张图片安全送回H5

路线B比路线A多了一个核心任务：把原生侧拿到的图片数据转换成H5能直接用的格式，并且安全地送过去。H5拿到的可能是base64字符串、本地URL或者虚拟域名URL，每一种都有不同的坑。

3.1 JSBridge约定：注入NativeBridge+注册全局回调函数

路线B的第一步是搭建一个双向通信通道。我通常的做法是：原生注入一个带@JavascriptInterface的Java对象，H5挂载一个全局回调函数。

原生侧：

webView.addJavascriptInterface(new NativeBridge(mActivity, webView), "AndroidNative"); public class NativeBridge { private final WeakReference<MainActivity> mActivityRef; private final WeakReference<WebView> mWebViewRef; public NativeBridge(MainActivity activity, WebView webView) { mActivityRef = new WeakReference<>(activity); mWebViewRef = new WeakReference<>(webView); } @JavascriptInterface public void selectImages(final int maxCount) { Handler mainHandler = new Handler(Looper.getMainLooper()); mainHandler.post(new Runnable() { @Override public void run() { MainActivity activity = mActivityRef.get(); if (activity != null) { activity.startImagePicker(maxCount); } } }); } }

H5侧：

window.selectImages = function(maxCount) { if (window.AndroidNative && window.AndroidNative.selectImages) { window.AndroidNative.selectImages(maxCount ? maxCount : 9); } }; // 原生完成选图后调用这个全局方法 window.onReceiveImages = function(jsonStr) { var images = JSON.parse(jsonStr); // images: [{base64: 'data:image/jpeg;base64,...', width: 1280, height: 960}, ...] console.log('收到图片：' + images.length); };

addJavascriptInterface有一个老生常谈的安全问题：API 17以下存在被注入JS代码后远程执行Java代码的漏洞，如果你们最低支持版本在4.2以下，建议改用evaluateJavascript回调方式或者自定义JsPrompt协议。现在大部分项目最低版本都在5.0以上，用addJavascriptInterface问题不大，但页面如果会跳转到不可信链接，记得在onPageStarted里处理一下。

3.2 拍照/相册返回的Uri先处理后发送：避免OOM的完整链路

原生侧拿到用户选择的图片之后，不能直接转base64发出去。一张4000x3000的原图转成base64，字符串长度轻松超过6MB，在evaluateJavascript里传给V8引擎时，内存峰值非常吓人，低端机大概率崩。

正确链路应该是：采样压缩 -> EXIF旋转校正 -> JPEG质量压缩 -> Base64编码 -> JSON封装 -> 回调JS。

核心方法：

private String compressToBase64(Uri uri, int reqWidth, int reqHeight, int quality) throws IOException { // 1. 采样压缩 Bitmap bitmap = decodeSampledBitmap(uri, reqWidth, reqHeight); // 2. EXIF旋转校正 Bitmap rotated = fixExifRotation(uri, bitmap); if (rotated != bitmap) { bitmap.recycle(); bitmap = rotated; } // 3. 质量压缩 ByteArrayOutputStream output = new ByteArrayOutputStream(); bitmap.compress(Bitmap.CompressFormat.JPEG, quality, output); bitmap.recycle(); // 4. Base64编码 byte[] bytes = output.toByteArray(); output.close(); return Base64.encodeToString(bytes, Base64.NO_WRAP); }

你可能会问：为什么不直接BitmapFactory.decodeStream然后compress？因为一张1200万像素的照片解码成Bitmap，在RGBA_8888下大约占48MB内存（4032x3024x4），如果你同时处理好几张，内存就爆了。所以必须先用inSampleSize采样，把图片缩小到合理尺寸后再解码。

3.3 压缩与方向修复：采样率、EXIF旋转、JPEG质量一个不能少

采样率计算是重点，常见做法是先读尺寸再计算inSampleSize：

private Bitmap decodeSampledBitmap(Uri uri, int reqWidth, int reqHeight) throws IOException { BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; try (InputStream is = mContext.getContentResolver().openInputStream(uri)) { BitmapFactory.decodeStream(is, null, options); } int sampleSize = 1; while (options.outWidth / sampleSize > reqWidth * 2 || options.outHeight / sampleSize > reqHeight * 2) { sampleSize *= 2; } options.inSampleSize = sampleSize; options.inJustDecodeBounds = false; try (InputStream is = mContext.getContentResolver().openInputStream(uri)) { return BitmapFactory.decodeStream(is, null, options); } }

你可能会问为什么是reqWidth * 2而不是直接> reqWidth就翻倍。因为后续还要做质量压缩和EXIF旋转，多少会损失一点画质，留一倍余量让最终输出更清晰。实际调到reqWidth * 2的阈值后，解码出来的Bitmap通常就是最终尺寸的两倍，压缩后尺寸正好接近目标值，不会过度损失细节。

EXIF旋转是另一个经典大坑。相机拍了竖图，存进JPEG时会带一个Orientation信息（通常为90度），BitmapFactory.decodeStream不会自动处理这个方向。如果你直接编码输出，用户会在H5页面里看到一张横过来的照片。

private Bitmap fixExifRotation(Uri uri, Bitmap bitmap) throws IOException { int orientation = ExifInterface.ORIENTATION_NORMAL; try (InputStream is = mContext.getContentResolver().openInputStream(uri)) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) { ExifInterface exif = new ExifInterface(is); orientation = exif.getAttributeInt(ExifInterface.TAG_ORIENTATION, ExifInterface.ORIENTATION_NORMAL); } } Matrix matrix = new Matrix(); switch (orientation) { case ExifInterface.ORIENTATION_ROTATE_90: matrix.postRotate(90); break; case ExifInterface.ORIENTATION_ROTATE_180: matrix.postRotate(180); break; case ExifInterface.ORIENTATION_ROTATE_270: matrix.postRotate(270); break; default: return bitmap; } Bitmap rotated = Bitmap.createBitmap(bitmap, 0, 0, bitmap.getWidth(), bitmap.getHeight(), matrix, true); if (rotated != bitmap) { bitmap.recycle(); } return rotated; }

这里有个兼容性说明：ExifInterface(InputStream)构造器是API 24新增的，低版本建议先拿到文件路径再new ExifInterface(path)。如果你们项目还在兼容Android 7.0以下，可以把Uri转成File路径再处理。

图片处理完成后的数据组装很简单：

JSONArray jsonArray = new JSONArray(); for (Uri uri : uriList) { String base64 = compressToBase64(uri, 1280, 1280, 80); JSONObject obj = new JSONObject(); obj.put("base64", "data:image/jpeg;base64," + base64); obj.put("width", 1280); obj.put("height", 960); jsonArray.put(obj); } String jsonStr = jsonArray.toString();

3.4 推送JS时的转义和线程问题：JSONObject.quote是真的好用

数据在子线程里压缩处理完后，要切回主线程再调用JS。这里有两个细节：

细节一：线程切换。evaluateJavascript必须在主线程调用，而压缩处理如果放在主线程会卡UI，所以整个链路是：子线程压缩 ->runOnUiThread->evaluateJavascript。

细节二：字符串转义。最让人头大的其实是JSON字符串嵌入JS代码时的转义。base64字符串包含+、/、=，JSON里有双引号，如果你直接拼字符串，大概率在某台机器上突然崩。我推荐用org.json.JSONObject.quote()来做转义，它能安全地输出一个带双引号的JSON字符串字面量：

String quotedJson = JSONObject.quote(jsonStr); String js = "window.onReceiveImages(" + quotedJson + ")"; webView.evaluateJavascript(js, null);

JSONObject.quote(jsonStr)返回的是"..."形式的字符串，里面的双引号、反斜杠都被正确转义了。H5侧拿到的就是原始的JSON字符串，直接JSON.parse即可。

另外要防止WebView已经被销毁时还在执行JS：

if (webView == null || webView.getUrl() == null) { return; }

4. 数据格式的取舍：content://、file://、base64为什么不能随手用

很多新手问：为什么不直接传Uri或者本地路径给H5，非要转base64？这里涉及WebView对几种协议的加载限制，我按实际踩坑经验展开。

4.1 把content://直接塞给img src会出现什么

路线A里H5拿到的就是content:// Uri，系统通过临时授权让页面可以读取。但我们自己写代码时，如果直接把content://字符串传给H5，让HTML里的<img src="content://...">去加载，在WebView里兼容性极差。content协议不属于WebView网络栈默认支持的协议，部分系统WebView版本可以加载，但很多国产内核（以及某些系统应用）会直接拒绝：Not allowed to load local resource: content://...。

即使能加载，content:// Uri还有一个致命问题：临时授权是会失效的。系统通过Intent授予的读权限，在Activity销毁或进程被杀后可能就没了。H5如果是在用户选完图很久之后才异步拿这个Uri去读取，很可能提示Permission Denial。这是路线上一个非常隐蔽的崩溃点：页面首次打开选图是好的，切后台再回来图片就挂了。

4.2 https页面里加载file://会被拦截

那把图片复制到本地，传file:///storage/emulated/0/...这种路径给H5呢？也不行。WebView对file://的管控一直很严，尤其是H5页面本身是https://加载的情况下，页面里加载file://图片会被当作Not allowed to load local resource直接拦截。这本质上不是混合内容问题（mixed content），而是WebView的本地资源访问限制。

如果WebView加载的本身就是本地页面（file:///android_asset/index.html），那加载file://图片是可以的。但业务环境里H5基本都是从线上加载的，所以不要赌这个。

4.3 base64膨胀率实测：一张原图的内存有多吓人

那为什么最后大家都用base64？因为data URI是纯字符串，不涉及任何本地资源协议限制，跨协议、跨域都能加载。代价是体积膨胀和内存开销。

base64规则是把3字节二进制变成4个ASCII字符，体积膨胀约33%。但真正吓人的是内存：一张相机原图如果是5MB，转成base64字符串约6.7MB；Java字符串是UTF-16编码，在栈上每个字符占2字节，也就是说这段字符串在Java层就要占用约13MB；再通过JNI传给V8，JS引擎解析和存储又复制一份，峰值内存轻松超过30MB。如果你一次性传10张原图的base64，不用走完流程就OOM了。

所以路线B里base64不是不能用，而是必须先压缩再编码。压缩到长边1280、质量80后，一张图通常150~400KB，base64后约200~550KB，10张的字符串总量也能控制在5MB以内，WebView扛得住。

5. 权限适配：从Android 6到Android 13，三代权限变化一次说清

权限问题在Android开发里永远绕不开。针对图片选择场景，最容易被搞混的就是"到底要不要申请存储权限"。

5.1 只走系统选择器时，其实不用申请存储权限

很多人一听到"从相册选图"就本能地去申请READ_EXTERNAL_STORAGE，然后被用户拒绝后整个功能瘫痪。实际上，如果我们的代码只是通过ACTION_GET_CONTENT或ACTION_PICK拉起系统选择器，用户选完后通过onActivityResult拿到的Uri来读取数据，完全不需要存储权限。

原理是：系统自带的选择器是由另一个App（比如系统相册）提供的，用户在这个App里选择图片，选择器会把读取权限通过FLAG_GRANT_READ_URI_PERMISSION临时授予给我们的App。我们拿到Uri后，系统保证我们在一段时间内可以读取这颗Uri的数据。

所以如果你的H5页面用的是input标签（路线A），原生侧不要画蛇添足去申请存储权限。多申请一个权限意味着多一次弹窗，转化率就掉一截。

5.2 自定义相册必须申请权限：13上的新规则变了

如果是路线B中自己写相册列表页（遍历MediaStore展示所有图片），那就必须要存储权限。

• Android 12及以下：申请READ_EXTERNAL_STORAGE。
• Android 13及以上：存储权限被拆分，必须申请READ_MEDIA_IMAGES，同时READ_EXTERNAL_STORAGE不再生效。

AndroidManifest.xml需要在对应节点声明：

<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />

动态申请时也要分开处理：

private void requestImagePermission() { String permission; if (Build.VERSION.SDK_INT >= 33) { permission = Manifest.permission.READ_MEDIA_IMAGES; } else { permission = Manifest.permission.READ_EXTERNAL_STORAGE; } ActivityCompat.requestPermissions(this, new String[]{permission}, PERMISSION_REQUEST_CODE); }

还有一个容易踩的坑：如果targetSdkVersion升到33，在Android 13设备上继续只声明READ_EXTERNAL_STORAGE，系统会当作没声明；反过来，如果App还targetSdk 32，即使声明了READ_MEDIA_IMAGES，系统也不会认识这个新权限。所以升级targetSdk时，这个权限迁移一定要同步做。

5.3 国内ROM上的权限差异与"系统选择器绕路"方案

就算按规范申请了权限，国内ROM上还是可能出幺蛾子。最常见的表现是：权限弹窗已经授权，但自定义相册列表还是空白。原因通常是某些ROM（如MIUI）还有独立的"相册权限"开关，跟标准权限弹窗是两个体系，用户得去设置里单独打开"允许访问所有照片"。

更麻烦的是Android 14上又有"选择的照片"这种部分授权模式。如果你不想跟这些ROM权限纠缠，我可以给一个非常实用的绕路方案：放弃自定义相册界面，直接使用系统选择器。Android 13开始有系统级Photo Picker，不需要任何存储权限，多选体验也比老式ACTION_GET_CONTENT好得多：

if (Build.VERSION.SDK_INT >= 33) { Intent pickIntent = new Intent(Intent.ACTION_PICK_IMAGES); pickIntent.putExtra(Intent.EXTRA_PICK_IMAGES_MAX, maxCount); startActivityForResult(pickIntent, REQUEST_CODE_PICKER); } else { Intent intent = new Intent(Intent.ACTION_GET_CONTENT); intent.setType("image/*"); intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); startActivityForResult(intent, REQUEST_CODE_PICKER); }

ACTION_PICK_IMAGES是Android 13新增的系统Photo Picker入口，系统会提供一个多选图片的UI，支持限制数量、不支持自定义UI。但它最大的价值是不需要任何存储权限、不需要做厂商适配。如果你只是想要一个稳定的选图入口，优先考虑这条路。国内厂商也陆续在推进系统Photo Picker的统一体验，长期来看是主流方向。

6. 多图场景的性能实测与参数建议

最后单独聊聊性能。因为"H5获取多张照片"这件事，最大的拦路虎不是功能能不能通，而是通完之后低端机还扛不扛得住。

6.1 一组真机数据：压缩后体积、耗时、内存

我在一次项目中实测了几台典型机型。测试条件：选择10张1200万像素照片（4032x3024），压缩参数为长边1280、JPEG质量80，统计从拿到Uri到完成base64封装的耗时和峰值内存：

可以看到，压缩处理整体耗时在低端机上可能接近4秒。如果你在UI上不给任何反馈直接等结果，用户大概率会认为功能坏了。所以路线B在实际项目里必须配合一个loading提示，而且最好是在用户点击"确定"后立刻弹出一个"图片处理中"的遮罩。

6.2 参数建议：单张最长边、压缩质量、图片数量上限

经过多次测试，我给出的默认参数是：

• 单张最长边：1280px。这个尺寸在手机屏幕上足够清晰，在PC端看也基本可用。如果你的业务是头像、证件照这种不需要展示大图的场景，可以进一步压到800px。
• JPEG压缩质量：80。低于70时色彩过渡区域会出现可感知的条带感，高于90时体积增长明显但画质提升有限，80是性价比比较高的点。
• 图片数量：最多9张。9宫格是社区产品多年验证过的阈值，而且9张压缩后的base64字符串总量大约2~3MB，对网络上传和内存都是可接受的。如果你要支持更多张数，建议从base64方案迁移到第6.3节的URL方案。

另外建议在上传阶段就限制图片大小，比如单张压缩后不能超过500KB。超了就逐级降低质量重新压缩，最多降两次。这样能保证不管用户选什么图，最终传到服务器上的图片体积在一个稳定范围内，后端存储和CDN成本都可控。

6.3 图片量再大怎么办：WebViewAssetLoader方案与调用链

当图片数量超过9张、单张体积又压不下来时，base64字符串的传输链路就会很吃力了。这时候更合理的方案是原生把压缩好的图片保存为本地文件，然后通过WebViewAssetLoader把本地缓存目录映射成一个H5可访问的虚拟域名，H5拿到的图片地址是https://appassets.androidplatform.net/web_img/xxx.jpg这种URL，加载方式跟普通网络图片一样，但实际数据来自本地文件。

实现思路拆解：

1. 初始化WebViewAssetLoader，注册一个PathHandler，把/web_img/路径映射到App的缓存目录。
2. 在WebViewClient.shouldInterceptRequest中把请求交给AssetLoader处理。
3. 原生压缩图片后保存到getCacheDir()/web_img/目录，把https://appassets.androidplatform.net/web_img/文件名.jpg传给H5。
4. H5直接用这个URL渲染。

这个方案的好处是H5拿到的URL是标准https协议，不涉及base64内存膨胀，图片再多也只是磁盘占用；坏处是实现复杂度高一点，而且这个虚拟域名是受限的——如果H5里用了Canvas去读图片像素（比如做二次剪裁、压缩），会触发跨域安全限制，读不到数据。所以它更适合"只展示、只上传原始数据"的场景。

我在实际项目中是这么取舍的：普通业务（9张以内）用base64方案，简单直接；如果未来要做类似"批量上传相册"这种一次性几十张图片的需求，再切AssetLoader方案。

这套东西写下来，核心就是一句话：把选择器拉起来并不难，难的是你清楚每条路线背后的数据流和边界条件。拿到图片之后该压缩的压缩、该转义的转义、该申请的权限别多申请、不该有的内存别硬扛。照着上面这几章操作，至少不会在半夜收到用户反馈"你们App选图闪退"的工单。