Scheme comparison

When many people write small procedures, they will encounter a headache function — to generate pictures to share circle of friends. There are several commonly used schemes for generating moments of friends pictures:

1. Draw and generate using canvas
2. Use the back-end drawing library to draw, return to the small program end
3. Use the server to open a browser for HTML rendering, and screenshots back to the applet side

The first solution: high requirements, canvas and pure HTML layout is far from each other, the cost of zero-based learning is high, and the effect in different wechat browsers is unpredictable, it is not easy to make beautiful and controllable generated pictures in a short time. In practice, I found a very troublesome thing: neither network pictures nor Base64 pictures could be directly rendered and displayed in canvas, so I had to download them before uploading them.

The second solution: the back-end library can complete relatively simple requirements, but the effects of font loading, shadows, rounded corners, transparency and other solutions need to be fine-tuned, if the text needs to truncate or dynamically flex length is not easy to deal with. The picture interception and expansion adaptive is also not flexible. In addition, choosing this kind of solution is equivalent to leaving the UI layout work to the back-end engineers, which is not their area of expertise and may not be good.

The third solution: page drawing can be completed by pure front-end technology with low difficulty and high completion degree. However, puppeteer needs to be opened by a Node service at the back end to control the Chrome browser on the server. The disadvantage of this scheme is that it costs too much. We have calculated with our peers in the industry, and the results are similar: The QPS of images generated by a 4-core 16G server is about 10-20, equivalent to only 10 images generated in a second, which cannot meet the sudden demand for a large number of sharing. Moreover, the server with this configuration cannot deploy other services, and running this service will use up most of its resources.

background

The first version of our project adopted the first solution — Canvas drawing. Besides the high learning cost, there was a compatibility problem when it was published online. Therefore, in the second version of development, I considered to find a plug-in written by others. I found an open source project of MP-Vue framework Painter on GitHub. If your project is built with MP-Vue, you can have a try. However, our small program used Uniapp, because we didn’t know how to introduce mp-vue components in uniapp, we gave up this solution. After looking for it again, in the DCloud plug-in market, finally found it — poster board. This plugin is very easy to use, and I will write down the steps from the beginning to use it.

Poster board using steps

1. The import plug-in

2. The plugin will be imported into your project file, uni_modules, where you need it.

3. The specific use method of the plug-in will not be described herehereAll have.

Bonus :(if you have base64 images in your poster, you need to convert them to local temporary images)

dealBase64(imageData) {
				return new Promise((reslove, reject) = > {
				    // If the image string does not contain a prefix to be emptied, the downlink code may not be executed.
					// var imageData = base64.replace(/^data:image\/\w+; base64,/, "");
					// Declare the file system
					const fs = uni.getFileSystemManager();
					// Randomly define the path name
					var times = new Date().getTime();
					var codeimg = wx.env.USER_DATA_PATH + '/share' + times + '.png';
					 
					// Write the base64 image
					var that = this;
					fs.writeFile({
						filePath: codeimg,
						data: imageData,
						encoding: 'base64'.success: (res) = > {
							// Write successfully, the new image path can be usedreslove(codeimg); }}); })}Copy the code