前段时间开发端内h5我的项目，用到了h5上传图片，现记录下遇到的坑。
端内h5上传图片问题演绎：
1、Webview中应用原生h5 input file上传图片时android只能单选、ios只能多选；android上还存在的一个问题为：点击上传按钮进入图片抉择页后，如果勾销抉择，返回我的项目，则无奈再次上传，会波及到整个webview，其余h5页面也无奈上传，只有敞开此webview从新进入才能够上传——此问题需端原生批改办法笼罩；
2、Jsdk chooseImage办法抉择图片，android抉择相册和拍照时无返回数据；
3、Android局部机型（Galaxy S8 Android 7.0）上传图片数量过多时导致整个app奔溃、重启——此问题是webview申请渲染内存失败导致，端原生增加android:hardwareAccelerated=“false”配置，敞开硬件加速后解决；
上传图片倡议：
1、交互优化：缩略图与预览图别离展现，抉择后即上传，上传实现后显示网络图片；本地缩略图应用压缩后base64，上传实现后应用又拍云配置url!percent20(需依据配置确定)
2、上传File文件格式：倡议应用File格局上传，因为文件转为base64后大小会变为原来的4/3倍
3、前端适当压缩：压缩会减少局部解决工夫、减低清晰度，但能够缩小上传工夫、回显工夫，晋升用户体验，具体可依据我的项目状况确定，以下为不同压缩比例清晰度比照，可供参考(办公wifi)：
| 压缩比例 | 压缩清晰度（canvas） | 图片 | 尺寸 | 大小 | 上传工夫 | 上传格局 | 缩略图 | 尺寸 | 大小 |
|---|---|---|---|---|---|---|---|---|---|
| 100% | - | 图片 | 3264*2448 | 2.75MB | 6.5s | File | 图片 | 652*489 | 111.08KB |
| 91.6% | 0.8 | 图片（原图-同上） | 3264*2448 | 3.3MB | 上传失败，server对图片大小限度缘故 | Base64 | - | - | - |
| 100% | 1 | 图片 | 2000*1500 | 4.11MB | 上传失败，server对图片大小限度缘故 | Base64 | - | - | - |
| 28.6% | 0.8 | 图片 | 2000*1500 | 1.03M-754.93 KB | 2.2s | Base64 | 图片 | 400*300 | 43.73KB |
| 13.1% | 0.5 | 图片 | 2000*1500 | 515.04KB-369.38 KB | 1.4s | Base64 | 图片 | 400*300 | 43.77 KB |
| 7.1% | 0.3 | 图片 | 2000*1500 | 280.21 KB-202.35 KB | 979ms | Base64 | 图片 | 400*300 | 44.31 KB |
| 4.9% | 0.1 | 图片 | 2000*1500 | 190.39 KB-138.56 KB | 763ms | Base64 | 图片 | 400*300 | 43.95 KB |
| 12.4% | 0.8 | 图片 | 1500*1125 | 493.32 KB-351.12 KB | 1.3s | Base64 | 图片 | 300*225 | 25.62 KB |
| 3.5% | 0.3 | 图片 | 1500*1125 | 139.22 KB-100.92 KB | 589ms | Base64 | 图片 | 300*225 | 25.80 KB |
| 8.97% | 0.8 | 图片 | 1000*750 | 277.03KB-196.37 KB | 866ms | Base64 | 图片 | 200*150 | 12.84KB |
| 30% | 1 | 图片 | 1000*750 | 1.08MB-759.61 KB | 2.3s | Base64 | 图片 | 200*150 | 12.92KB |
| 3.6% | 0.5 | 图片 | 1000*750 | 135.75 KB-96.66 KB | 612ms | Base64 | 图片 | 200*150 | 12.81 KB |
备注：图片清晰度影响因素较多，表中数据仅供参考
倡议：适当减小图片尺寸能够大幅升高图片大小，canvas清晰度配置0.5、0.3时性价比比拟高，但最终还是须要依据场景和业务须要确定适合的压缩参数
4、不同我的项目能够针对性配置又拍云缩略图，拜访形式参照url!percent20，端内目前还不反对webp格局，端外可配置webp益处