Selecting a local photo album or taking a photo, then previewing and uploading it is a typical usage scenario in mobile applications, such as uploading common ID card information.
Many customers reported that they had similar scenarios and encountered some problems more or less in use. Finally, they found mPaaS and hoped that we could provide some best practices. Share some optimization solutions for the corresponding scenarios here.
Picture selection scheme
Option 1: Use Android native Webview
The front end specifies type=file through the input tag, and selects the file through the support of native webview.
Android native webView does not support file upload selection. You need to extend the openFileChooser or onShowFileChooser in WebChromeClient by the shell itself, and then call up the system to select the file popup. Selecting the file will use the components provided by the system or other supported apps. Some of the returned uris are direct It is the url of the file, and some is the uri of the contentprovider, which needs to be processed in a unified manner to return the uri format.
This scheme has the following problems:
There are many logics for customizing the shell, and it is also necessary to make compatibility with the addresses returned by different file selectors in the system, which is prone to compatibility problems;
The file selection implementation depends on the file selector of the system, and the implementation of different mobile phones is inconsistent and cannot be unified;
Option 2: Use mPaas' H5 container
If the business uses the mPaas H5 container, although a series of operations to evoke the file selector are built in the container, there is still the same risk that the system file selector is uncontrollable. For example, if the business wants to select a picture, but the effect after the arousal may look like the following, some customers are also unacceptable.
Option 3: Implement jsapi to evoke Native custom selection page
This solution is to use the ability of custom jsapi provided by the H5 container to customize a jsapi for selecting pictures, and then call it by the front end to evoke the selection page implemented by Native itself, and finally the result is returned to the front end for display in the form of base64. This solves the previously mentioned problem of uncontrollable system selection.
But when this solution went online, there were still some problems, mainly because jsbridge can only return json, so the image data is returned in the form of base64. However, because there are multiple selection scenarios, if the user selects multiple pictures, the returned base64 data will be very large, resulting in some OOM problems on some low-end devices. At the same time, a large number of base64 will be converted to JSON. ANR. So it cannot go online.
Solution 4: Select the picture to return to the local path, and WebView intercepts access to local resources
In order to solve the stability problem of returning to base64 mentioned earlier, when we selected the picture, we returned a local address, and then the Native module intercepted the resource access of the WebView, went to the local to get the corresponding picture and returned it to the WebView to display .
For example, the address returned to WebView after selecting a picture is: https://www.mPaas.com.cn/mpaas.jpg, www.mPaas.com.cn is a domain name that we customize, we intercept this specific custom domain name, Then go to the local album to find the corresponding picture of mpaas.jpg to intercept the return. Through such a conversion logic, the problem of base64 transmission is solved.
File upload scheme
Through the above description, we compared the advantages and disadvantages of various image selection schemes, and finally precipitated the best practices. After the image selection is implemented, the next step is to upload. The upload has also undergone a similar evolution.
Solution 1: Upload using RPC interface
For users who use mPaas, the first step is definitely to upload files through the RPC interface, but in the actual verification process, we found that for some relatively large image uploads, the RPC interface directly returned a 403 error: Http Transport error[413]: Request Entity Too Large]. Obviously, the server crashed because the file was too large.
The main reason is that RPC is positioned as a business data channel. Generally, the recommended size is less than 200K. For data directly uploading large files, there will be stability risks, and even the entire gateway will be suspended because of this.
Scheme 2: Upload using OSS scheme
For similar file upload scenarios, it is recommended to directly use the OSS solution for uploading, such as the common Aliyun OSS solution: help.aliyun.com/product/31815.html.
OSS is a set of solutions designed specifically to solve the entire file storage link. It solves various scenarios of file upload. Users can integrate the corresponding Android and iOS SDKs to upload local files.
Conclusion
Just a selection of pictures, uploading and previewing such a scene, there can be so many different solutions evolution, there is no best solution, only the most suitable solution.
- END -
