The beginning of the nonsense:uniAPPPackaging is compiled in the cloud, which means,app 下 iOSThe native part of the code needs to be submitted touniThe background to compile, can be understood as inuniThere’s one on the serverXcodeRun the environment, of course the cloud should be usedXcodeCommand done whenHBuilderXWhen compiling in the cloud, all native libraries are compressed and packaged in the cloud, and finally compiledipaThe package is downloaded locally so it can be installed.

First, static library Settings

You can familiarize yourself with the project structure by downloading the Demo on the UNI website.

1.HBuilder-uniPluginThe main project

It can be roughly interpreted as the entire cloud Xcode compilation environment at cloud compile time. You can look at all the dependencies of this project.

There are as many as 120+ local dependencies, because uni is concerned about the cost of cloud compilation. If all libraries are uploaded by developers, the compilation resources will be occupied, so remote third-party repositories are used, which is also known by uni backend.

This section describes the third-party library versions relied on by iOS

Therefore, when developing uni native plug-ins, it is recommended to first check whether there is a remote supported third party to avoid compiler symbol conflicts caused by repeated imports.

For example, if the plugin needs the IJKMediaFramework library (around 160MB, it is quite large), then check whether the library is available in the cloud compilation first.

If it already exists, there is no need to commit the local IJKMediaFramework library, just check the VideoPlayer under the Manifest.json configuration of HBuilderX.

The manifest.json configuration of HBuilderX tells the cloud compiler to add IJKMediaFramework to the project.

2,DCTestUniPluginStatic library engineering

When creating static libraries, you need to set up static library architecture support here.

Set under Build Setting -> Architectures

Note that at compile time, select Any iOS Device

What if static libraries need third-party libraries?

During development, there will definitely be situations where third-party library support is needed, such as AFNetWorking. Here, I checked whether the remote part of UNI supports it, but found that the corresponding static library is not improved, so local upload is required.

Because the self-made static library will eventually be loaded into the APP environment, so the strategy of the self-made static library relying on the third party is to add the third-party library. A file to the main project of HBuild-Uniplugin, because the self-made static library requires the introduction of header files, then, Add the introduction of header files in the Heard Search Paths section of the DCTestUniPlugin static library project.

HBuilder – uniPlugin main project

Static library project Heard Search Paths

2. Configure native iOS plug-inspackage.json

With all the functionality developed, the next step is to configure the local plug-in pack

Refer to the link above for specific packaging steps, and the final file directory structure is as follows:

1. WSLUniPlugin is a comprehensive file, which can contain android and ios (the official website is marked ios, not ios).

2. Ios files contain all the third-party libraries and self-made static libraries.

Package. json is the relevant configuration. The package.json internal information tells the remote compilation which libraries to load and the location of the library folder, as well as configuration such as which dynamic libraries need to be signed (although you can make your own dynamic libraries, you need to sign them).

Three,package.jsondirectory

{
    "name": "WSLUniPlugin".// Plug-in name
    "id": "WSLUniPlugin"./ / the plugin ID
    "version": "1.0"."description": "Function Description".// Function description Here is the function description, after adding it will be displayed under HBuilder
    "_dp_type":"nativeplugin".// Native component type
    "_dp_nativeplugin": {"ios": {
            "plugins": [{"type": "component".// Plug-in type, is it a functional component or a view component?
                    "name": "wsl-component".// Tag in the NVUE file
                    "class": "WSLComponent" // the iOS native object class inherits from DCUniComponent},]."integrateType": "framework".// Create library type
            "hooksClass": "", declaring the app lifecycle hook child object, which will also respond to the appDelegate event"frameworks": [
				"libAFNetworking.a".// Uni remote is not a repository and needs to be declared
				"Masonry.framework".// navigation is a remote repository for UNI. You do not need to add it to the ios folder, otherwise you will receive a symbol repetition error when compiling]."embedFrameworks": [
                "IDLFaceSDK.framework"./ / dynamic libraries]."capabilities": {
                "entitlements": {},"plists": {}},"plists": {},"assets": [
                 "WSLUniPlugin.xcassets"Wsluniplugin. xcassets is in the ios file, so write it directly.]."privacies": []."embedSwift": false."deploymentTarget": "8.0".// Support iOS version
            "validArchitectures": [
                 "arm64"/ / architecture]."parameters": {},"resources": [
                "WSLUniPlugin.bundle".Wsluniplugin. bundle is in the ios file, so write it directly.]}}}Copy the code

This is the basic configuration Settings. Because uni has a limited number of cloud compilations per day (about 10 times), and the package size is less than 40M, the number of times over is 2 yuan per time, and the volume over is 10 yuan per 100M. Is it a little bit of a pit? Well, that’s a very high cost of trial and error every day, so I’m going to write it down here.

Personal essay, Don’t laugh [fist][fist][Fist]