Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Unity3D
  3. Génération et déploiement de package
Extrait - Unity3D Développer en C# des applications 2D/3D multiplateformes (iOS, Android, Windows...)
Extraits du livre
Unity3D Développer en C# des applications 2D/3D multiplateformes (iOS, Android, Windows...)
1 avis
Revenir à la page d'achat du livre

Génération et déploiement de package

Le player et les builds : concepts de base

1. Définition

Unity3D est capable de cibler de nombreuses plateformes. Pour chacune d’elle, il est nécessaire de générer un ensemble de fichiers spécifiques appelé une "build". Celle-ci contiendra alors tout le nécessaire permettant d’exécuter l’application 2/3D développée sur la cible.

Une build est constituée de deux choses :

  • les fichiers spécifiques (images, sons, ressources, etc.) de l’application 2/3D compilés dans un format Unity "binaire",

  • le player (que l’on peut traduire "lecteur" en français) d’Unity capable de lire ces fichiers et de jouer les scènes pour la plateforme ciblée.

2. Différents formats de builds

En fonction de la plateforme, Unity générera différentes choses :

  • Pour Android, un fichier au format APK (Android Application Package) sera généré. Celui-ci pourra être soumis directement sur le Store Google (le Play Store) ou installé sur un périphérique de test. Unity est aussi capable de générer l’ensemble des projets à utiliser avec le SDK Android.

  • Pour Windows Phone 8.0, Windows 8.1, Windows Phone 8.1, Unity générera un ensemble de projets utilisable dans Visual Studio pour générer un package (fichier...

Configuration du player

1. Description

La configuration du player est peut-être la phase la plus fastidieuse car il y a beaucoup de paramètres à vérifier mais c’est sûrement la plus excitante car on est dans la dernière étape avant la génération finale de l’application.

Unity permet tout d’abord de configurer les paramètres généraux de l’application directement dans l’Inspector. Voici la procédure pour afficher cet écran :

 Cliquez sur Edit dans le menu général d’Unity.

 Sélectionnez Project Settings puis Player.

images/12_02_01.png

Les paramètres généraux sont situés dans la partie haute de l’Inspector :

  • Le nom de la société créatrice de l’application 2/3D.

  • Le nom du produit (l’application) développé. C’est cette valeur qui est affichée dans la barre de titre sous Windows par exemple.

  • Les icônes par défaut. Unity déclinera son utilisation sur toutes les plateformes où cela est possible.

La partie basse de l’Inspector permet de configurer spécifiquement le player par plateformes. À noter que les configurations des différentes consoles ne sont disponibles que si le SDK associé est installé sur la machine de développement. Pour chacune, les paramètres sont regroupés en plusieurs catégories :

  • Resolution and Presentation : permet de configurer la façon dont est affiché le player : plein écran, mode fenêtré, orientations supportées et celle par défaut, affichage ou non de la barre de statut.

  • Icon : permet de définir des icônes spécifiques, différentes de celles des paramètres généraux. Certaines plateformes nécessitent aussi des icônes spécifiques aux tailles bien précises ou encore de définir des paramètres associés (nom affiché sur les tuiles, tailles possibles, etc.).

  • Splash Image : choix de l’image de chargement initial du player Unity.

  • Other Settings : tous les paramètres spécifiques à chaque plateforme tels que les runtimes supportés, des informations de définition de l’identité du package, l’optimisation...

Génération du package

1. Fenêtre de configuration et génération d’une build

Une fois le player configuré, il est maintenant temps de le générer. Cela se passe au travers de la fenêtre Build Settings d’Unity. Voici la manipulation permettant d’afficher cette fenêtre :

 Ouvrir le menu File.

 Sélectionnez le menu Build Settings....

images/12_03_01.png

a. Choix des scènes à inclure

La partie haute de la fenêtre sert à la configuration des scènes. Il est obligatoire d’ajouter au moins une scène pour que la compilation puisse avoir lieu.

Il y a deux manières d’ajouter une scène à une build : via le bouton Add Current qui ajoute la scène actuellement ouverte dans l’éditeur dans la liste des scènes à compiler ou en faisant un glisser-déposer du fichier représentant une scène depuis la vue Project vers la fenêtre Build Settings.

Unity assigne un index (commençant à 0) à chaque scène ajoutée et il sera possible de s’y référer pour les charger pendant l’exécution de l’application bien qu’il soit plus maintenable de s’y référer par leur nom. Il est possible de réordonner les scènes par glisser-déposer dans la liste.

La scène avec l’index...

Génération plateforme par plateforme

Pour chacune des plateformes, Unity va générer un livrable spécifique : package précompilé, projet de développement et/ou les deux en même temps.

1. Génération d’un package Android

Unity permet de créer directement le binaire final correspondant à l’application ou de générer des projets de développements utilisables dans l’environnement de développement Google (Android Studio).

a. Installation du SDK et configuration d’Unity

Afin de pouvoir générer un package Android, il est nécessaire d’installer le SDK Android ainsi que l’environnement de développement Java (JDK). Les dernières versions de ceux-ci peuvent être téléchargées à cette adresse : http://developer.android.com/sdk

Une fois installé, il faut indiquer à Unity où se trouve le SDK en suivant cette manipulation :

 Cliquez sur le menu Edit puis choisissez Preferences.

 Dans la fenêtre qui s’ouvre, choisissiez External Tools.

 Dans le bas de l’écran, renseignez le chemin vers les répertoires racines du SDK d’Android et du JDK.

images/12_04_01.png

b. Génération du package

La génération du package se fait au niveau de l’écran Build Settings en cliquant sur le bouton Build. En cochant la case Google Android Project, Unity générera un projet de développement Android. En la laissant décochée, il produira directement un binaire final (.APK).

images/12_04_02.png

Unity vous demandera alors l’emplacement de stockage des éléments générés pour commencer la génération. Une fois celle-ci terminée, Unity ouvre l’emplacement de génération.

c. Signature du package

Lorsque vous souhaitez publier sur le Store Google, il est nécessaire de signer votre package avec un certificat. Unity vous seconde dans cette tâche qui se passe en deux étapes : la création du magasin de clés (Keystore) protégé par mot de passe et la création d’une clé en elle-même dans ce magasin.

Voici la manipulation permettant de générer une clé dans un nouveau magasin :

 Rendez-vous dans les paramètres...

Personnaliser le processus de build

Lorsque vous utilisez le bouton Build de l’écran Build Settings, Unity va faire ce que l’on appelle une build standard. Cela peut être intéressant pour plusieurs raisons :

  • exécuter un utilitaire avant ou après que le player ne soit généré par Unity,

  • copier-coller des fichiers à côté du player, par exemple une documentation ou une procédure d’installation de l’application,

  • modifier des assets utilisés par l’application finale : icônes, etc.

Par exemple, lors de la génération d’une build Windows Phone 8.0, Unity va créer pour vous un fichier de manifest et des icônes, un splash screen par défaut car cela n’est pas configurable au niveau du player. Il est possible de les écraser ensuite sur votre poste de développement au moment de générer le package final mais si un autre développeur génère une build depuis Unity, il n’aura pas vos modifications. Une solution consiste à stocker les fichiers nécessaires sur le gestionnaire de code source et de personnaliser la build pour les copier-coller à chaque build.

1. Déclencher le processus de build

a. Création d’un élément de menu

Pour déclencher le processus de build, il est nécessaire de créer un élément de menu dans Unity. Pour cela, nous allons suivre la procédure décrite dans le chapitre Éditeur, pièce maîtresse en utilisant les attributs MenuItem :

 Dans la vue Projects, faites un clic droit puis sélectionnez Create - C# script.

 Nommez ce fichier CustomBuild et double-cliquez sur ce fichier pour l’ouvrir dans l’éditeur de code.

 Dans le script, supprimez tout le contenu de la classe et ajoutez une méthode statique BuildGame ne prenant rien en paramètre et ne retournant rien...

Créer son propre plugin

La création de plugin est un sujet bien trop complexe pour être abordé dans son intégralité dans ce livre. La vocation de cette partie est de vous en donner un aperçu.

1. Le principe des plugins

Un Plugin Unity est un composant n’étant utilisable que sur une plateforme cible donnée écrit dans le langage natif de celle-ci :

  • Sur Android, un plugin sera par exemple réalisé à l’aide du Native SDK (NDK).

  • Sur iOS, un plugin sera réalisé à l’aide de C++ (.cpp) ou d’Objective-C (.mm).

  • Sur Windows Phone 8.0, un plugin sera réalisé en Silverlight pour Windows Phone.

Par défaut, il est recommandé de placer les fichiers correspondants aux plugins dans le dossier /Assets/Plugings/[NomDeLaPlateforme]/. Dans ce cas, Unity va automatiquement détecter la plateforme ciblée par le plugin. Le plugin ne sera alors disponible que sur le player ciblé. Depuis Unity 5.0, il est possible de placer les plugins à n’importe quel niveau de la hiérarchie de dossier du projet mais il devient alors nécessaire de spécifier manuellement la plateforme ciblée. Un formulaire dédié à cette tâche apparaît alors dans l’Inspector :

images/12_06_01.png

2. Utilisation d’un plugin Android

Afin de pouvoir utiliser une méthode déclarée...

Exécution des scripts : que se passe-t-il sous le capot ?

1. Jusqu’à présent : Mono

Jusqu’à sa dernière version Unity utilisait Mono sur ces différents players afin de permettre l’exécution des scripts C#. Cela signifie que sur les 23 plateformes supportées, les équipes Unity se chargeaient de proposer une plateforme d’exécution (CLR - Common Language Runtime) du code .NET supporté par Mono. Cela est assez spectaculaire mais présente certaines limitations reconnues par les équipes Unity :

  • Les performances de .NET ne sont pas aussi bonnes que celles du code natif C++.

  • Mono étant un portage de la CLR sur les plateformes, il a toujours un train de retard par rapport aux versions actuelles de .NET : toutes les dernières fonctionnalités ne sont pas présentes. À titre d’exemple, à l’heure actuelle, Unity ne supporte que la version 3.5 du framework .NET.

  • Le garbage collector spécifique à .NET peut provoquer des problèmes de performances dans des applications de type 2/3D.

Pour répondre à ces problématiques, Unity a décidé de mettre en branle un nouveau chantier audacieux : IL2CPP.

2. Le futur : IL2CPP

Concrètement cela consiste en un compilateur AOT (Ahead Of Time) et une machine virtuelle qui correspondent à une implémentation...

Réduction de la taille du package

Il est toujours intéressant de réduire la taille du package correspondant à l’application afin de faciliter les solutions de déploiement ou ne pas dépasser les limites imposées par les Stores (un package de plus de 99 Mo ne peut pas être téléchargé en 3G sur un iPhone). À titre d’information, un package Unity vide ciblant iOS fera au minimum 22 Mo et 12 Mo si les différentes optimisations de code sont appliquées.

1. Déterminer la répartition du poids en fonction des composants

La première des actions à faire est de déterminer d’où provient la taille de votre package. Unity donne cette information par catégorie de composants dans le fichier de logs de l’éditeur (editor.log). Ce fichier est accessible après la génération d’une build en utilisant le menu contextuel de la vue Console.

images/12_08_01.png

Voici un exemple de fichier produit par Unity lors de la génération d’une build PC. Vous remarquerez aussi qu’Unity indique les fichiers prenant le plus de place.

images/12_08_02.png

Dans ce cas, 1,8 mb (25,6 % de la taille du package) proviennent du fichier CustomAsset.png et 713,2 kb (9,7 %) proviennent d’un fichier Unity-builtin-extra. Le reste est réparti entre différents fichiers média (.wav), des librairies tierces (.dll) ainsi que des fichiers de code (.cs).

2. Le stripping

a. Le principe

Le stripping est une technique consistant à enlever...