Parce que CocosCreator utilise la version 3d depuisSystemJSpour charger toutes les ressources de script, mais la façon dont SystemJS charge les scripts consiste à charger des scripts via des requêtes Web (peut-être que la méthode est erronée), mais la condition préalable à la production d'annonces jouables est qu'il n'est pas autorisé à charger des ressources via des requêtes réseau, toutes les ressources associées Il doit être dans le même fichier Html, donc la première version a été chargée en modifiant SystemJS, mais après de nombreux tests (très, très longtemps), j'ai trouvé des méthodes très ingénieuses, qui peuvent être faites sans modifier SystemJS.
Une fois que CocosCreator3D a exporté le projet Web mobile, de nombreux scripts liés au système présentent les caractéristiques suivantes : le premier tableau de scripts enregistrés par SystemJS contient des dépendances, qui représentent les modules qui en dépendent, et les modules dépendants seront chargés en premier.
System.register(['dependency'], function (_export, _context) {
var dep;
return {
setters: [function (_dep) {
dep = _dep;
}],
execute: function () {
_export({
name: 'value'
});
}
};
});Ensuite, le premier paramètre de la méthode System.register peut passer une chaîne, que j'appelle un alias, généralement le nom du fichier js plus le chemin correspondant, car il existe de nombreux fichiers js avec le même nom de fichier, ceux-ci feront certains traitement correspondant, Comme le suivant, par exemple, le fichier js est PPS.js, qui peut être modifié comme suit :
System.register('./PPS.js'，['./PPY.js'], function (_export, _context) {
var dep;
return {
setters: [function (_dep) {
dep = _dep;
}],
execute: function () {
_export({
name: 'value'
});
}
};
});Ce qui précède signifie que lorsque PPS.js est chargé, le fichier PPY.js sera chargé en premier, puis PPS.js sera chargé. Ci-dessous le fichier PPYjs,
System.register('./PPY.js'，[], function (_export, _context) {
var dep;
return {
setters: [function (_dep) {
dep = _dep;
}],
execute: function () {
_export({
name: 'value'
});
}
};
});Injectez ensuite PPY.js et PPS.js dans le fichier Html, comme suit
<script>
System.register('./PPS.js'，['./PPY.js'], function (_export, _context) {
var dep;
return {
setters: [function (_dep) {
dep = _dep;
}],
execute: function () {
_export({
name: 'value'
});
}
};
});
</script>
<script>
System.register('./PPY.js'，[], function (_export, _context) {
var dep;
return {
setters: [function (_dep) {
dep = _dep;
}],
execute: function () {
_export({
name: 'value'
});
}
};
});
</script>
<script>
System.import('./PPS.js').catch(function (err) {
console.error(err);
})
</script>(Si vous voulez exécuter l'exemple normalement, le principe est d'injecter le module SystemJS, sinon il ne fonctionnera pas normalement) Le code en bas sera exécuté avec succès
Ce qui précède est un exemple simple. Le projet effectue de nombreux traitements correspondants via cette méthode, puis génère un seul fichier Html.
Etant donné que le module du moteur physique peut être requis, bien sûr, le module WASM peut également être sélectionné. Dans ce cas, vous devez modifier le code source du moteur (ouvrez "répertoire du projet/build/web-mobile/cocos-js/instantiated- **.js" similaire à ce fichier)
Rechercher des champs clés
WebAssembly.instantiate()Comme le montre la figure, vous constaterez que la méthode de récupération est utilisée dans le script, ce qui n'est pas autorisé par PlayableAD, vous ne pouvez donc modifier que la méthode de récupération correspondante et la remplacer comme suit (l'adresse du chemin provient deTraitement entrant du chemin WASM)
Il faut faire attention aux cas suivants (très importants) où l'endroit marqué doit être le même que dans fetch, car chaque compilation changera le nom de la variable correspondante
let url = "cocos-js/" + (e)
let wa = base64DecToArr(window.res[url])
WebAssembly.instantiate(wa, o).then((function (e) {
var n = e.instance.exports;
Object.assign(qJ, n),
t()
}
), n) Ce script obtient le chemin de la ressource wasm entrante, toutes les ressources de texte et les ressources binaires existent dans window.res
Ouvrez "répertoire du projet/build/web-mobile/cocos-js/bullet.wasm-****.js" similaire à ce fichier
System.register([],(function(e,t){"use strict";return{execute:function(){
e("default",new URL("assets/bullet.wasm-c98527b6.wasm",t.meta.url).href)}
}}));Remplacez tout le paramètre de 'new URL()' par 'assets/bullet.wasm-c98527b6.wasm', ce qui est très bien. Le nom du fichier wasm dans la version 3.4.1 de CocosCreator3D ne devrait pas changer lors de l'empaquetage (s'il est modifié, veuillez le remplacer par le nom de fichier correct) comme suit:
System.register([],(function(e,t){"use strict";return{execute:function(){
e("default","assets/bullet.wasm-c98527b6.wasm")
}}}));traitement de chargement wasm|Traitement entrant du chemin WASMCette opération est nécessaire, car la méthode d'opération de récupération JavaScript est utilisée et seul le code source du moteur peut être forcé à être modifié (si wasm n'est pas utilisé, il peut être ignoré)