2017-02-08 2 views
0

Ich habe Firebase für Unity verwendet und ich weiß, dass es noch experimentell ist.Einheit Firebase Speicher Mscorlib Stripping

Wenn ein APK Aufbau und das Niveau Strippen Mscorlib gesetzt ist, kommt Fehler heraus logisch, dass

NotSupportedException: ..... etc. 
    System.Net.WebRequest.GetCreator (System.String prefix) [0x00000]in <filename unknown>:0 
    I/Unity (16919): at System.Net.WebRequest.Create (System.Uri requestUri) [0x00000] in <filename unknown>:0 
    I/Unity (16919): at Firebase.UnityHttpRequest+<SendUnityRequest>c__Iterator0.MoveNext() [0x00000] in <filename unknown>:0 

Aber wenn auf Disabled Upload/Download zur Lagerung verhindert es hier ist der Fehler ist OK. Aber ich brauche das, um die Dateigröße zu verringern. Ich habe linker.xml verwendet, um "System.Net.HttpRequestCreator" beizubehalten, aber ich glaube, das funktioniert nur für iOS?

Meine Frage ist, ist es wirklich notwendig, die Abisolierstufe zu deaktivieren, damit der Firebase-Speicher in Unity funktioniert?

Antwort

0

Sie sollten IL2CPP mit iOS verwenden, das immer Striping auf Byteebene aktiviert. Es gibt keine Möglichkeit, Byte-Stripping mit IL2CPP zu deaktivieren. Siehe https://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html. Byte Level Stripping sollte mit Firebase Storage arbeiten.

Wenn Sie aus irgendeinem Grund IL2CPP nicht verwenden, können Sie zur direkten Beantwortung Ihrer Frage micro-mscorlib nicht mit Firebase Storage verwenden, da Firebase Storage einige Funktionen von .Net erfordert. Sie sollten die anderen Optionen (Byte- oder Modulebene) verwenden können.

Wenn Sie Stripe auf Byteebene verwenden (mit IL2CPP oder nicht), sollten Sie keine link.xml-Datei angeben müssen, da die Einheit die Verwendung jeder Klasse ableiten soll.

--EDIT-- In unserer nächsten Version haben wir eine Lösung für Byte- und Assembly-Level-Stripping. Wenn Sie eine Problemumgehung versuchen möchten, sind mehrere zusätzliche link.xml-Einträge erforderlich, um zu verhindern, dass Einheit verwendete Klassen entfernt. Diese Einträge sind unten und werden automatisch zu unserer nächsten SDK-Version hinzugefügt.

<assembly fullname="mscorlib"> 
    <namespace fullname="Mono.Security.Cryptography" preserve="all"/> 
    <namespace fullname="System.Security" preserve="all"/> 
    <namespace fullname="System.Security.Cryptography" preserve="all" /> 
    <namespace fullname="System.Security.Cryptography.X509Certificates" preserve="all" /> 
</assembly> 
<assembly fullname="Mono.Security"> 
    <namespace fullname="Mono.Security.Protocol.Tls" preserve="all"/> 
    <namespace fullname="Mono.Security.X509" preserve="all"/> 
</assembly> 
<assembly fullname="System"> 
    <namespace fullname="System" preserve="all"/> 
    <namespace fullname="System.ComponentModel" preserve="all"/> 
    <namespace fullname="System.ComponentModel.EnumConverter" preserve="all"/> 
    <namespace fullname="System.Configuration" preserve="all"/> 
    <namespace fullname="System.Net" preserve="all"/> 
    <namespace fullname="System.Net.Configuration" preserve="all"/> 
    <namespace fullname="System.Net.NetworkInformation" preserve="all"/> 
    <namespace fullname="System.Net.Sockets" preserve="all"/> 
    <namespace fullname="System.Net.Security" preserve="all"/> 
    <namespace fullname="System.Runtime.ConstrainedExecution" preserve="all"/> 
    <namespace fullname="System.Runtime.InteropServices" preserve="all"/> 
    <namespace fullname="System.Runtime.Serialization" preserve="all"/> 
    <namespace fullname="System.Security.Cryptography" preserve="all" /> 
    <namespace fullname="System.Security.Cryptography.X509Certificates" preserve="all" /> 
</assembly> 
<assembly fullname="System.Core"> 
    <namespace fullname="System.Security.Cryptography" preserve="all" /> 
</assembly> 
<assembly fullname="System.Configuration"> 
    <namespace fullname="System.Configuration" preserve="all" /> 
</assembly>