企业官网建设流程全解析

1. H5获取手机图片的两种主流姿势，先分清再动手

做Hybrid App开发这几年，几乎每个项目都会遇到同一个需求：H5页面要传图片，用户点击按钮，要么直接调起相机拍照，要么打开系统相册选图。Android这边如果用的是WebView，还得让原生层把图片数据送回JS回调。这个需求听起来简单，但实际踩坑一堆，尤其是“多张照片回传H5”这个环节，很多人被卡在这里。

先梳理一下H5获取相机或相册图片的整体思路，主要就两条路线：

第一条：纯H5方案，直接在页面里写<input type="file" accept="image/*">，通过给input加capture属性控制是打开相机还是相册，再由WebView自身或者系统浏览器处理后续选择流程。这个方案实现代价最低，H5页面不用跟原生交互，但控制力最弱，尤其是Android WebView里，不同机型、不同WebView版本对capture属性的解析天差地别，还会遇到“点按钮没反应”、“选完照片拿不到回调”这类问题。

第二条：原生接管方案，H5通过JSBridge调用Android原生方法，原生自己拉起相机拍照或打开相册选图，拿到图片之后转成base64字符串或者可访问的路径，再通过WebView的loadUrl或evaluateJavascript执行一段JS回调函数，把数据传给H5。这条路线灵活度高，能自定义拍照界面、控制图片压缩、支持一次选多张，几乎所有成熟App最后都走到这条路上来。

不过很多刚接触这块开发的人会纠结：既然input标签就能搞定，为什么还要让原生参与？我的建议是：如果你的H5页面只是临时用、对体验要求不高，用input方案最快；但如果这是长期迭代的业务功能，建议一开始就做原生接管，因为后续一定会遇到图片压缩、多选、权限适配、文件路径获取这些单靠H5躲不掉的硬需求，到时候再改造成本更高。

下面我把两条路线的实现细节分别拆开讲，重点放在Android通过WebView把图片数据回传给H5的完整流程上。无论你是做Android原生开发的，还是写H5页面的，按这个思路做都能少走弯路。

2. 纯H5方案靠谱吗？input标签的兼容性真相

2.1input capture属性在不同Android机型上的表现

纯H5方案之所以简单，就是因为不用碰原生代码，一个<input>标签全搞定。但Android WebView并不是标准浏览器，capture属性在这里经常失灵。

先说标准用法：

<!-- 只调起相机拍照 --> <input type="file" accept="image/*" capture="environment" id="cameraInput"> <!-- 打开相册选图 --> <input type="file" accept="image/*" id="albumInput"> <!-- 支持多选 --> <input type="file" accept="image/*" multiple id="multiInput">

capture属性的官方语义是：当值为environment时，直接打开系统相机App（后置摄像头），值为user时打开前置摄像头；如果完全不加capture，系统通常会弹出选择框让用户二选一，或者直接打开相册。

但实测下来，这个逻辑在国产ROM的WebView里根本不受控。有些定制系统浏览器（比如华为、小米、OPPO的某些版本）无论capture设置成什么值，都只打开相册；另一些系统即使写对了environment，用户点击一次后仅仅出现“相机/相册/文件”的系统底部弹窗，根本不是预期行为。这就是为什么很多H5开发者抱怨“我明明写了capture，但就是调不起相机”。

2.2 WebView如何感知input选择结果

如果坚持用纯H5方案，WebView端得做一件事才能拿到结果：重写onShowFileChooser方法。这个方法在用户点击<input type="file">时被WebView回调，由这个方法返回的ValueCallback<Uri[]>最终承载用户选择的图片Uri。

webView.setWebChromeClient(new WebChromeClient() { @Override public boolean onShowFileChooser(WebView webView, ValueCallback<Uri[]> filePathCallback, FileChooserParams fileChooserParams) { if (mFilePathCallback != null) { mFilePathCallback.onReceiveValue(null); } mFilePathCallback = filePathCallback; // 根据fileChooserParams判断是否支持多选 boolean isMultiple = fileChooserParams.getMode() == FileChooserParams.MODE_OPEN_MULTIPLE; // 创建Intent拉起系统选择器 Intent intent = fileChooserParams.createIntent(); intent.addCategory(Intent.CATEGORY_OPENABLE); intent.setType("image/*"); try { startActivityForResult(Intent.createChooser(intent, "选择图片"), REQUEST_CODE_CHOOSE); } catch (ActivityNotFoundException e) { mFilePathCallback = null; return false; } return true; } });

这样处理后，用户在H5页面点击上传按钮时确实是系统选择器接管，选完图片后ActivityResult会返回一个Uri数组。但注意，这里拿到的数据还在原生层，H5的input事件并没有自动触发，你还需要在onActivityResult里把图片数据“喂”回WebView，让H5感知到用户已经选了图。

这一步有两个选择：一是手动构造一个JS事件或者调用H5暴露出来的回填函数；二是利用filePathCallback.onReceiveValue(uris)回传Uri数组，系统自带的WebView会自动触发Input标签的change事件，H5的onchange就能拿到File对象。第二种是大多数情况下最省事的实现，但有个Bug隐患：如果提前把onShowFileChooser拦截了又没正确回调，H5的onchange永远不触发，页面一直转圈。

纯H5方案还有一个问题：拿不到高清大图的真实路径。即使onchange事件里能获取到File对象，也只是一个临时拷贝，而且这个File对象受Android私有目录限制，业务方想把它直接传到服务端，经常遭遇“文件不存在”或者“路径无效”的异常。这就是为什么后来我逐步放弃纯H5方案，转向原生接管。

3. 原生接管方案：先搭好WebView与JSBridge环境

3.1 用addJavascriptInterface还是evaluateJavascript？

原生接管的本质，就是让H5通过JSBridge调原生方法，原生完成拍照/选图后回传数据。选型上最常见的有两种：addJavascriptInterface注入Java对象，以及WebViewClient拦截prompt方法模拟通信。

addJavascriptInterface是官方推荐方式，优点是简单、容易理解，JS端直接调用注入对象的方法即可。但它有个臭名昭著的漏洞史——Android 4.2之前存在严重的安全风险，所以现在高版本强制要求方法必须用@JavascriptInterface注解暴露给JS端，低版本设备干脆不要用这个方案。

更推荐的姿势其实是evaluateJavascript。原生拍照选图完成后，通过webView.evaluateJavascript("javascript:window.callbackName('" + json + "')", null)直接把数据注入到页面的JS回调函数里。这个方案不用注入Java对象，安全性和兼容性都更好，而且evaluateJavascript是异步执行的，不会阻塞UI线程，大字符串传参也不会像loadUrl那样被截断。

但要注意，evaluateJavascript在Android 4.4以下不可用，如果你的App还需要兼容老设备，只能退回到loadUrl("javascript:...")，这个方案对超长字符串支持不好，图片base64动辄几百KB，可能会被浏览器拦掉，所以老设备上要么限制传参大小，要么改用路径回传（后面细讲）。

3.2 Native与H5的通信协议怎么设计

通信协议这个事，看起来简单，但没设计好会被坑哭。我给你一个直接用得上的协议结构。H5侧定义一个全局回调函数：

// H5注册的回调函数 window.NativeBridge = { onImageSelected: function(result) { // result是一个JSON字符串 // 格式：{"status":"success","data":[{"name":"xxx.jpg","data":"base64..."},...]} var json = JSON.parse(result); if (json.status === 'success') { // 处理图片数据 var images = json.data; for (var i = 0; i < images.length; i++) { uploadImage(images[i]); } } } };

原生端定义一个方法，拉起相机或相册，等结果返回后组装JSON并回调：

@JavascriptInterface public void chooseImages(String callbackName, boolean multiple) { // 先保存回调函数名 this.mCallback = callbackName; // 根据multiple决定单选还是多选 if (multiple) { openAlbumMulti(); } else { openAlbumSingleOrCamera(); } }

这里最关键的一个设计原则：JS回调函数名不要写死。很多团队图省事，直接在原生代码里写死window.onImageSelected，后来H5页面改成Vue或者React后，函数作用域一变，回调就直接失效。正确做法是让H5把回调函数名作为参数传进来，原生只负责拼接并执行这段JS。

3.3 Manifest权限与Android版本适配

原生方案最头疼的就是权限。Android 6.0以下只需要在Manifest里声明：

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

Android 6.0到12，运行时权限动态申请跑不掉，READ_EXTERNAL_STORAGE和CAMERA都需要在代码里请求。Android 13及以上更狠，READ_EXTERNAL_STORAGE被拆成了细化权限，读图片需要单独申请READ_MEDIA_IMAGES：

if (Build.VERSION.SDK_INT >= 33) { requestPermissions(new String[]{Manifest.permission.READ_MEDIA_IMAGES, Manifest.permission.CAMERA}, REQUEST_PERMISSION); } else { requestPermissions(new String[]{Manifest.permission.READ_EXTERNAL_STORAGE, Manifest.permission.CAMERA}, REQUEST_PERMISSION); }

这块不处理好，用户点了相册按钮却看到一片空白列表，或者点了拍照相机直接闪退，都是权限没适配到位的典型症状。

还有一点容易忽略：Android 11（API 30）开始，系统强化了包可见性限制。如果你的App要显式拉起系统相机App或系统相册App，必须在Manifest里声明<queries>，否则startActivityForResult可能抛ActivityNotFoundException:

<queries> <intent> <action android:name="android.media.action.IMAGE_CAPTURE" /> </intent> <intent> <action android:name="android.intent.action.GET_CONTENT" /> </intent> <intent> <action android:name="android.intent.action.OPEN_DOCUMENT" /> </intent> </queries>

少写这块，很多开发者会在Android 11+的模拟器上遇到“点击没反应”，看了半天代码找不到原因，其实只是包可见性问题。

4. 原生拍照与相册选图的完整链路

4.1 拍照：FileProvider与临时Uri的正确处理

调用系统相机拍照的核心代码不复杂，复杂度全在文件Uri的适配上。Android 7.0（API 24）之后，file://协议的Uri直接跨应用传递会被系统拦截并抛FileUriExposedException，所以必须用FileProvider生成content://协议的Uri。

第一步，在Manifest里注册FileProvider：

<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：

<?xml version="1.0" encoding="utf-8"?> <paths> <cache-path name="cache" path="." /> <external-cache-path name="external_cache" path="." /> <external-files-path name="external_files" path="." /> </paths>

第三步，拉起相机：

private Uri mCameraUri; private void openCamera() { Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE); if (intent.resolveActivity(getPackageManager()) != null) { File photoFile = createImageFile(); if (photoFile != null) { mCameraUri = FileProvider.getUriForFile(this, getPackageName() + ".fileprovider", photoFile); intent.putExtra(MediaStore.EXTRA_OUTPUT, mCameraUri); intent.addFlags(Intent.FLAG_GRANT_WRITE_URI_PERMISSION); startActivityForResult(intent, REQUEST_CODE_CAMERA); } } }

这里有一个细节：createImageFile()生成的文件要确保父目录存在，我用的是getExternalCacheDir()，因为这是应用私有的缓存目录，不需要额外的存储权限，而且不会被用户在其他文件管理器里乱翻到。

拍照回调里，相机可能把照片旋转过，也可能直接返回一个缩略图（取决于OEM实现）。稳妥做法是用BitmapFactory.Options读取inSampleSize压缩后再做旋转矫正，这个细节我会在第五节详细写。

4.2 相册选图：单选与多选的分歧点

相册选图我一般推荐直接用系统相册的ACTION_GET_CONTENT或者ACTION_OPEN_DOCUMENT。区别在于：

• ACTION_GET_CONTENT：老API，返回的Uri是临时的，App结束可能失效，但兼容性最好。
• ACTION_OPEN_DOCUMENT：Android 4.4引入，返回的Uri可以通过takePersistableUriPermission持久化，业务需要长期访问这个文件时更好用。

单选和多选的代码几乎一样，只是多传一个EXTRA_ALLOW_MULTIPLE：

private void openAlbumMulti() { Intent intent = new Intent(Intent.ACTION_OPEN_DOCUMENT); intent.addCategory(Intent.CATEGORY_OPENABLE); intent.setType("image/*"); intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); startActivityForResult(intent, REQUEST_CODE_ALBUM); }

注意：ACTION_OPEN_DOCUMENT配合EXTRA_ALLOW_MULTIPLE，在部分老机型上可能会失效，用户只能选一张。这种情况要么在代码里判断返回的ClipData是不是null，如果是null就提示用户重新选择，要么干脆自己做一套图片选择器。如果项目对多选体验要求高，强烈建议集成成熟的开源图片选择框架（比如PictureSelector、Matisse），省很多适配功夫。

4.3 拿到Uri后怎么解析成可用的图片数据

这是原生方案最核心的环节。onActivityResult拿到的Uri分两种情况：

一种情况，拍照返回的Uri是我们自己创建的mCameraUri，这个Uri指向我们创建的临时文件，直接用ContentResolver打开即可。

另一种情况，相册返回的Uri是系统返回的content://协议Uri（也可能在某些老机型上是file://），这个Uri直接传给H5往往不可用，因为H5没有系统级别的读取权限。所以正确的做法是：在原生层解析这个Uri，拿到图片数据，处理成H5能用的格式。

解析Uri的标准姿势：

private Bitmap decodeUriToBitmap(Uri uri) throws IOException { BitmapFactory.Options options = new BitmapFactory.Options(); options.inJustDecodeBounds = true; ContentResolver resolver = getContentResolver(); BitmapFactory.decodeStream(resolver.openInputStream(uri), null, options); // 计算压缩比例，限制最大尺寸为1280px int maxSize = 1280; int sampleSize = 1; while (options.outWidth / sampleSize > maxSize || options.outHeight / sampleSize > maxSize) { sampleSize *= 2; } options.inJustDecodeBounds = false; options.inSampleSize = sampleSize; return BitmapFactory.decodeStream(resolver.openInputStream(uri), null, options); }

注意decodeStream有个坑：第一次inJustDecodeBounds解码时对InputStream有消耗，第二次真正解码时如果还用同一个InputStream会返回null。要么重新openInputStream，要么先把流读成字节数组再解码。上面代码示范的是重新open的方式。

5. 多张照片回传H5：Base64大法 vs 路径回传

5.1 Base64回传的实现思路与体积控制

拿到Bitmap之后，最直接的回传方式就是转成base64字符串，拼到JSON里送给H5。好处是H5侧不用再考虑文件路径问题，拿到字符串直接new Image()就能预览或者传给服务端。

代码不复杂：

private String bitmapToBase64(Bitmap bitmap) { ByteArrayOutputStream baos = new ByteArrayOutputStream(); // 80%质量压缩 bitmap.compress(Bitmap.CompressFormat.JPEG, 80, baos); byte[] bytes = baos.toByteArray(); return Base64.encodeToString(bytes, Base64.NO_WRAP); }

然后组装结果：

JSONObject result = new JSONObject(); JSONArray dataArray = new JSONArray(); for (Bitmap bitmap : bitmaps) { JSONObject item = new JSONObject(); item.put("name", System.currentTimeMillis() + ".jpg"); item.put("data", bitmapToBase64(bitmap)); dataArray.put(item); } result.put("status", "success"); result.put("data", dataArray); // 回调H5 String js = "javascript:" + mCallback + "('" + result.toString() + "')"; webView.post(() -> webView.evaluateJavascript(js, null));

但base64方案有两个痛点。第一个是体积爆炸：一张1MB的图片转成base64会膨胀到1.37MB左右，如果一次选5张，一个JSON字符串将近7MB，通过JSBridge传到H5，WebView的JS引擎处理起来会明显卡顿，低端机上甚至直接OOM。第二个是传参被截断：某些WebView版本对javascript:协议的长度有限制，超长字符串传过去的直接被截断，JS端解析报错。

针对这两个痛点，我的经验是：如果图片数量少（3张以内）且单张压缩后控制在200KB以内，用base64没问题；如果图片数量多或者原图本身很大，走路径回传更稳。

5.2 路径回传方案与WebView资源拦截

路径回传的思路是：原生层把选中的图片压缩后保存到本地的缓存目录，然后把图片的HTTP地址（加载本地服务器）或者content://Uri传给H5，H5用这个地址直接渲染或上传。

这里有两种落地方式。

方式一：在原生层起一个轻量级的本地静态文件服务，比如通过NanoHTTPD库，把图片存到指定目录，然后拼成http://127.0.0.1:8080/image/xxx.jpg这样的地址回传给H5。H5拿到地址后充其量只能预览，真正上传的时候还是要依赖原生去读取文件二进制再传给服务端，所以这种方式更适合“预览+上传联动”的场景。

方式二：用WebViewAssetLoader或自定义WebViewClient拦载特殊协议。定义一个如hybrid://image/xxx.jpg的scheme，当WebView加载这个地址时，shouldInterceptRequest被回调，原生在这个方法里从本地文件读数据并返回给WebView。这个方案不需要起网络服务，不占端口，但要求H5侧把图片的src设置成这个自定义协议地址，图片才能展示出来。

这里说句实在话：路径回传适合的典型场景是“原生拿到原图路径，H5只负责展示预览图，最终上传由原生把字节流传给服务端接口”。如果你们的业务是纯Web服务端直接收H5的multipart文件，那路径方案反而绕了一圈，base64反而直接。

5.3 大文件上传的优化技巧

不管用哪种回传方式，大图问题躲不掉。拍照返回的图片动辄3MB以上，不压缩直接进内存，低端机瞬间OOM。我自己总结了一套压缩策略，按顺序执行：

• 采样压缩：用inSampleSize先把Bitmap解码到长边不超过2048px
• 质量压缩：转输出流时quality值从85起步，如果文件仍然超过300KB，降到70再试
• 尺寸压缩：如果质量压缩后还是太大，把长边再压到1280px
• 格式选择：带透明通道的图片用PNG，纯照片一律用JPEG

还有个小技巧：压缩后把图片保存到getCacheDir()下的upload目录，文件名用UUID.randomUUID().toString()拼接时间戳，避免多张图片重名导致的覆盖问题。等到图片成功上传到服务端之后，再把缓存文件删掉，防止存储空间膨胀。

6. 常见问题与排查技巧实录

6.1 H5页面onChange不回调，图片选了但页面没反应

这种现象多半是onShowFileChooser被拦截后没有正确回调filePathCallback。我要重点提醒：filePathCallback.onReceiveValue(null)这个空回调很重要，它相当于告诉WebView“这次请求被取消了”，如果不写，下一次点击上传按钮时onShowFileChooser携带的filePathCallback还是上一次的残留对象，可能直接导致第二次选的图片回传给第一次的请求，页面表现完全错乱。

正确写法是每次进入onShowFileChooser先把旧的回调置空并覆盖：

@Override public boolean onShowFileChooser(WebView webView, ValueCallback<Uri[]> filePathCallback, FileChooserParams fileChooserParams) { if (mFilePathCallback != null) { mFilePathCallback.onReceiveValue(null); } mFilePathCallback = filePathCallback; // 后续逻辑 }

6.2 图片Uri拿到了但读流返回FileNotFoundException

这个坑主要是相册返回的Uri即使授权了也不可能一直有效。ACTION_GET_CONTENT返回的临时的读权限只维持到当前Activity的任务栈结束，如果App在后台被回收，或者H5侧延迟了一段时间再去读这个Uri，就会抛FileNotFoundException。

解决方案有两种：一是在拿到Uri后立刻把文件复制到应用私有目录，后续全部基于本地文件操作；二是使用ACTION_OPEN_DOCUMENT并调用contentResolver.takePersistableUriPermission(uri, Intent.FLAG_GRANT_READ_URI_PERMISSION)获取持久化访问权限，这样才能在下次启动App时继续读这个文件。

实测下来，第一种最省心，毕竟复制文件后就不依赖外部Uri了，后续逻辑全部在自家沙盒里跑。

6.3 多张图片回调时JS报错：Unexpected token or SyntaxError

这个问题我排查过好几次，根子都在JSON字符串转义上。图片base64串里天然包含+、/、=号，这些字符在拼接JS代码时如果没做转义，生成的JS代码就变成了callback('data:image/jpeg;base64,/9j/4AAQ...')，浏览器解析时遇到特殊字符直接报SyntaxError。

解决办法是统一对JSON字符串做JS转义，最稳的做法是转成JSON字符串之后再把字符串里反斜杠转义一遍，或者用JSONObject.toString()后用TextUtils.htmlEncode处理一遍，再包进单引号里。更省心的方案是用evaluateJavascript传参，因为它本质不是拼接字符串，只要参数本身格式正确就不会被截断或转义。

6.4 WebView没有网络权限导致本地图片加载失败

很多H5页面本身需要联网，但原生WebView没开INTERNET权限或者H5的图片不走网络只是本地资源，结果图片一直转圈加载不出来。这里分两种情况：

• H5里的远程图片加载不了，检查Manifest里有没有<uses-permission android:name="android.permission.INTERNET" />
• 原生回传的图片地址是content://或者自定义scheme，H5的<img>标签默认不会加载这种协议，需要WebView做资源拦截

这个坑在Android 9以下不突出，Android 9以后默认禁止明文HTTP流量，如果在本地起了HTTP服务回传图片路径，H5加载http://地址会被拦，需要配置android:usesCleartextTraffic="true"或设置NetworkSecurityPolicy。

6.5 最后整理一张速查表

7. 一些实操中的个人体会

原生和H5的图片交互，说到底是一个“信任边界”问题。H5环境可控性低，能做的事有限；原生环境能力大但协作成本高。设计通信协议时，我一直坚持的原则是：原生只负责“取图”和“回传”，不负责“解析”和“上传”。把职责边界划清楚，后续业务迭代才不会互相牵制。

另一个体会是，能压缩就趁早压缩，不要等H5那边去压缩。JS里做压缩看似方便，但性能比原生差一个量级，而且H5侧的Canvas压缩在部分Android WebView上会生成全黑的图片，排查起来让人崩溃。原生用BitmapFactory和Matrix处理，稳定且可控。

我用这套方案落地过好几个项目，从最早纯input标签的简易版，到后来原生多选、拍照压缩、base64与路径双轨回传的完整版，整体链路已经比较成熟了。如果你们项目里也需要这个能力，完全可以按这篇文章的思路先搭一个最小可用版本，再在业务推进中逐步补上权限适配、图片压缩和异常兜底。过程中遇到具体问题，欢迎在评论区把报错信息发出来，我看到了会回复。