mPaaS最佳實踐之《H5選圖預覽到上傳》

一 背景

在金融性質的App裡，選擇本地相冊圖檔或者拍照，然後預覽并且上傳是一個典型的使用場景，比如常見的身份證資訊上傳。在最近接觸的幾家銀行客戶裡，都回報有類似的場景，并且在使用上都或多或少的遇到一些問題，最後找到我們，希望我們提供一些最佳實踐。在這裡分享下對應場景的一些優化解決方案。

二 方案介紹

我們先介紹下各個銀行的傳統方案都是怎麼做的，以及存在的問題。

1. 選圖方案

1.1 方案1：使用Android原生Webview

方案介紹：前端通過input标簽，指定type=file，通過原生webview的支援實作選擇檔案。

Android原生webView并不支援選擇檔案上傳，需要外殼自己擴充WebChromeClient裡的openFileChooser或者onShowFileChooser，然後去喚起系統選擇檔案彈框，選擇檔案會使用系統提供的元件或者其他支援的app，傳回的uri有的直接是檔案的url，有的是contentprovider的uri，需要統一處理一下傳回uri格式。這種方案存在以下問題

1. 外殼定制實作的邏輯較多，還需要對系統不同檔案選擇器傳回的位址做相容，容易有相容性問題
2. 選擇檔案實作依賴系統的檔案選擇器，不同手機實作不一緻，無法做到統一

1.2 方案2：使用mPaas的H5容器

如果業務使用了mPaas的H5容器後，雖然容器内已經内置了喚起檔案選擇器的一系列操作，但是還是一樣存在系統檔案選擇器不可控的風險。比如如果業務希望選擇的是一張圖檔，但是喚起後的效果可能是下面這個樣子，很多客戶也是無法接受的。

1.3 方案3：實作jsapi喚起Native自定義的選圖頁面

這種方案就是利用H5容器提供的自定義jsapi的能力，自定義一個選圖的jsapi，然後前端去調用，去喚起Native自己實作的選圖頁面，最後結果通過base64的形式傳回給前端做顯示。這樣就解決了前面提到系統選擇檔案不可控的問題。

但是當這個方案上線後，還是遇到了一些問題，主要因為通過jsbridge隻能傳回json，是以圖檔資料是通過base64的形式傳回的。但是因為有多選的場景，如果使用者選擇了多張圖檔後，傳回的base64資料會特别大，導緻在一些低端裝置上有一些OOM的問題，同時大量base64轉JSON的過程中，也會出現ANR。 是以也是不能上線的。

1.4 方案4：選圖傳回本地路徑，webview攔截通路本地資源

為了解決前面提到的傳回base64存在的穩定性問題，是以我們在選圖的時候，是傳回了一個本地的位址，然後Native子產品攔截webview的資源通路，去本地拿到對應的圖檔傳回給webview顯示。比如選圖後傳回給webview的位址是：

https://www.mPaas.com.cn/mpaas.jpg

，

www.mPaas.com.cn

是我們自定義的一個域名，我們攔截這個特定自定義域名，然後去本地相冊去找

mpaas.jpg

對應的圖檔攔截傳回。通過這樣的一個轉換邏輯，解決了base64傳遞的問題。

2. 檔案上傳方案

通過以上的描述，我們對比了各種選圖方案實作的優缺點，最後沉澱了最佳實踐。選圖實作了後，下一步就是上傳。對于上傳也經曆了類似的方案演進。

2.1 方案1：使用RPC接口上傳

對于使用了mPaas的使用者，第一步想到的肯定是通過RPC接口實作檔案的上傳，但是在實際驗證過程中，我們發現對于一些比較大的圖檔上傳，RPC接口直接傳回了403的報錯，Http Transport error[413] : Request Entity Too Large]. 很明顯是因為檔案過大導緻服務端挂掉了。主要因為RPC的定位是用做業務資料通道，一般建議的大小是200K以内，對于直接上傳大檔案的資料，會有穩定性風險，甚至因為這個把整個網關打挂。

2.2 方案2：使用OSS方案上傳

對于類似的檔案上傳場景，建議是直接使用OSS的方案進行上傳，比如常見的阿裡雲OSS方案：

https://help.aliyun.com/product/31815.html

。OSS是專門為解決檔案存儲整條鍊路設計的一套方案，解決了檔案上傳的各種場景，使用者可以內建對應的Android和iOS的SDK實作對本地檔案的上傳。

三 總結

僅僅是一個選圖上傳預覽這樣一個場景，就可以有這麼多不同的方案演進，沒有最好的方案，隻有最合适的方案。阿裡雲金融線專家服務團隊為金融App提供最佳解決方案，歡迎大家了解。