Bon, après lecture de quelques jours avec Unity3d sur Mac j'ai enfin compris. Tout le code dans le présent guide est factice. J'ai écrit ce genre de choses dans les 15 minutes, afin de ne pas être dérangé par des erreurs et des fautes de frappe.
1) Ouvrir l'Unité, de créer un nouveau projet (Fichier -> Nouveau Projet) et de l'enregistrer quelque part
2) Lorsque le projet est généré, il a la structure suivante:
-
ProjectName/Assets (C'est ce que vous avez besoin)
-
ProjectName/Library (Passons sur ce qui est là)
-
ProjectName/ProjectSettings (Vous ne vous inquiétez pas à ce sujet)
-
ProjectName/ProjectName.sln (MonoDevelop projet)
3), Passez à l' ProjectName/Assets et créez les dossiers suivants: Plugins/iOS, si à la fin vous aurez une structure de dossier comme ceci: ProjectName/Assets/Plugins/iOS
4) Mettez votre bibliothèque compilé (.un fichier de et les en-têtes nécessaires à l'intérieur de l' ProjectName/Assets/Plugins/iOS ou copier le code source de votre bibliothèque (.mm, .h, .m, etc..). Rappelez-vous, normalement vous ne pouvez accéder à C-fonctions de C#, de sorte que vous aurez à emballer votre Objectif-C des trucs dans le code C en quelque sorte, dans mon cas, tous Objective-C, les objets étaient mis en œuvre dans une forme de Singleton, de sorte qu'il n'était pas difficile de faire un C-style enveloppe, par exemple:
CWrapper.h:
extern "C" void MySDKFooBarCFunction();
CWrapper.mm
#import "CWrapper.h"
#import "MyObjectiveCLibrary.h" // your actual iOS library header
void MySDKFooBarCFunction() {
[MyObjectiveCLibrary doSomeStuff];
}
5) Ensuite, allez à l' ProjectName/Assets et de créer un dossier pour CSharp classe wrapper(es), appelez ça comme vous voulez, par exemple: ProjectName/Assets/MySDK
6) à l'Intérieur de MySDK dossier de créer MySDK.cs fichier, le mannequin exemple de C# wrapper devrait ressembler à ceci:
using UnityEngine;
using System;
using System.Runtime.InteropServices;
public class MySDK
{
// import a single C-function from our plugin
[DllImport ("__Internal")]
private static extern void MySDKFooBarCFunction();
// wrap imported C-function to C# method
public static void FooBarCFunction() {
// it won't work in Editor, so don't run it there
if(Application.platform != RuntimePlatform.OSXEditor) {
MySDKFooBarCFunction();
}
}
}
7) Créer un script shell pack de ce genre de choses .unitypackage et de le placer près de votre dossier de projet (pas à l'intérieur). Ajuster EXPORT_PATH et PROJECT_PATH variables dans le script à vos besoins.
#!/bin/sh
WORKDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
UNITY_BIN="/Applications/Unity/Unity.app/Contents/MacOS/Unity"
EXPORT_PATH="${WORKDIR}/ProjectName.unitypackage"
PROJECT_PATH="${WORKDIR}/ProjectName"
ASSETS_PATH="Assets"
$UNITY_BIN -batchmode -quit \
-logFile export.log \
-projectPath $PROJECT_PATH \
-exportPackage $ASSETS_PATH $EXPORT_PATH
8) Lancez la création de script bash pour obtenir votre paquet de construire. Tous les trucs de l'Actif sera inclus dans le projet XCode pour votre Unité de Projet lorsque vous générez via Fichier -> Paramètres de construction dans l'Unité de l'Éditeur. Vous pouvez utiliser le paquet généré pour la distribution de votre code à d'autres développeurs afin qu'ils puissent les inclure à votre bibliothèque de leur Unité projets en double-cliquant sur le fichier de package.
N'oubliez pas de l'arrêt de l'Unité de l'Éditeur lorsque vous exécutez ce script, sinon il peut ne parviennent pas à construire un paquet.
Si vous avez quelques questions et forfait ne comprend pas, ce script permet d'imprimer le journal à l'exportation.journal
Prochaines étapes a de sens que si vous voulez faire une Démonstration de l'unité de projet pour votre bibliothèque (bon pour le test au moins)
9) Vous pouvez mettre a créé l'Unité de projet (ProjectName.l'unité) à l' Assets/MySDKDemo de sorte que vous avez une démo à l'intérieur de votre colis.
10) Créer un script simple pour votre Démo Unity3d scène à l' Assets/MySDKDemo/MySDKDemo.cs, par exemple:
using UnityEngine;
using System;
using System.Collections;
public class MySDKDemo : MonoBehaviour
{
private GUIStyle labelStyle = new GUIStyle();
private float centerX = Screen.width / 2;
// Use this for initialization
void Start ()
{
labelStyle.fontSize = 24;
labelStyle.normal.textColor = Color.black;
labelStyle.alignment = TextAnchor.MiddleCenter;
}
void OnGUI ()
{
GUI.Label(new Rect(centerX - 200, 20, 400, 35), "MySDK Demo", labelStyle);
if (GUI.Button(new Rect(centerX - 75, 80, 150, 35), "DoStuff"))
{
MySDK.FooBarCFunction();
}
}
}
11) Allez à l'Unité de l'Éditeur. Trouver la "Caméra" dans la barre latérale gauche, dans l'Unité de l'Éditeur, sélectionnez-le, et, en bas de l'Inspecteur de bord (barre de droite) cliquez sur AddComponent, sélectionnez Scripts -> MySDKDemo script
12) Construire le projet XCode et exécuter sur l'appareil.
Quelques notes
1) les Plugins ne fonctionnent pas dans l'Unité de l'Éditeur, tout simplement parce qu'ils ne sont pas compilés dans le temps réel, eh bien, pas sûr, mais probablement jusqu'à l'utilisation de C# dans vos plugins, probablement en C# les choses deviennent liés immidiately et travaille dans l'Éditeur de l'environnement.
2) Ce poste ne couvre pas le marshaling, ou de données/gestion de la mémoire entre natif <-> code managé, car il est très bien documenté.
L'interopérabilité avec les Bibliothèques Natives @ Mono projet
3) Rappels de C# C peut être transmis à l'aide de C# délégués, sur C-side vous utilisez des fonctions standard de déclarations, sur le C#, côté de vous déclarer délégués avec la même signature. Il semble que les booléens, les entiers et des chaînes de caractères (C: char*) sont rassemblés sans problème (je ne parle pas de la mémoire de la politique de gestion et qui est responsable pour libérer de la mémoire ou de la valeur de retour des politiques).
Cependant il ne fonctionne pas sur iOS construit out-of-box en raison de limitations de plate-forme, mais C#-C rappels peuvent encore être mis en œuvre à l'aide de MonoPInvokeCallbackAttribute, les liens utiles sur ce sujet:
En fait dans l'Unité 4 il y a AOT.MonoPInvokeCallbackAttribute déjà mis en œuvre, il est limité à l'électricité statique délégués qui peut être transmis à un code non managé, mais toujours mieux que rien.
4) Il y a un moyen d'obtenir l'Unité RootViewController l'aide d' UnityGetGLViewController fonction. Il suffit de déclarer cette fonction dans votre fichier de mise en oeuvre, c'est à dire:
extern UIViewController *UnityGetGLViewController();
Et utiliser UnityGetGLViewController() chaque fois que vous avez besoin pour obtenir un accès à RootViewController.
5) Il y a beaucoup plus de magie et de vilaines choses dans les détails, garder votre C interfaces aussi simple que possible, sinon de triage peut devenir un cauchemar et aussi garder à l'esprit qui a réussi à non géré est généralement coûteux.
6) Vous avez certainement utiliser certains cadres dans votre code natif et vous ne voulez pas de l'éditeur de liens de problèmes. Par exemple, si vous utilisez des porte-clés dans votre bibliothèque, alors vous devez inclure la Sécurité.cadre dans Xcode projet.
Je suggère d'essayer de XUPorter, il contribue à l'Unité d'intégrer toutes les dépendances supplémentaires dans Xcode projet.
Bonne chance!
