2015-03-25 7 views
12

Poiché Xamarin.iOS non supporta la generazione del codice in fase di runtime, perché Compile() e DynamicInvoke() funzionano come previsto?Perché LambdaExpression.Compile() funziona su iOS (Xamarin)?

Ad esempio, il seguente codice funziona bene:

var lambda = Expression.Lambda(
          Expression.Add(
           Expression.Constant(1), 
           Expression.Constant(2) 
         ) 
      ); 

var f = lambda.Compile(); 
var result = f.DynamicInvoke(); 

// result==3 at this point 

Is Xamarin valutare l'albero di espressione in fase di esecuzione, invece di emettere il codice IL?

risposta

12

Sulle piattaforme che supportano la generazione del codice, viene utilizzato il LambdaCompiler basato su Reflection.Emit.

Se ciò non è disponibile, l'espressione è interpretata utilizzando the interpreter. Ad esempio, esistono classi che interpretano Constant e Add.

+0

Sospettavo qualcosa del genere. È documentato da qualche parte? –

+0

Mentre la tua risposta ha un senso, mi piacerebbe sapere se c'è un riferimento o documentazione che lo conferma. –

+0

@PhilippeLeybaert Non sono riuscito a trovarne nessuno, motivo per cui ho guardato la fonte. – svick

2

The details of the Xamarin limitations are here.

Lei non sembra essere utilizzando qualsiasi cosa nello spazio dei nomi Reflection.Emit, che è il grande no-no. Il tuo codice deve essere ancora AOT'd. Altrimenti, immagino che non funzionerebbe.

Ma ci sono stati esempi di sviluppatori [nativi] che ostacolano lo strumento di analisi statica iOS e aggirano la limitazione dinamica del codice. Ho provato a localizzare l'articolo, ma non sono riuscito a trovarlo.

In ogni caso, non penso che il tuo scenario sia un esempio. Il tuo esempio di codice sarà ancora compilato con AOT.

Ma si pone una domanda davvero buona: a che ora viene valutata l'espressione?

EDIT:

Un altro SO rispondere sullo stesso argomento: What does Expression.Compile do on Monotouch?

C'è anche alcune utili informazioni su Expression.Compile() e "full AOT" qui: http://www.mono-project.com/docs/advanced/aot/

EDIT: Dopo aver letto un po 'di più, penso di sapere cosa sta succedendo qui. Non è che Expression.Compile() non sia lavoro ... è che quando il pacchetto di app iOS viene sottoposto allo strumento di analisi statica iOS quando lo si invia all'app store, non passa l'analisi, perché sta generando dinamicamente il codice. Quindi, certo, puoi usare Expression.Compile(), ma non aspettarti che venga accettato nell'app store. Ma come menzionato da @svick, se si utilizza l'opzione di compilazione "full AOT", il tuo Expression.Compile() probabilmente fallirà in fase di runtime, o forse fallirà anche la compilazione.

+2

Stai dicendo che "Espressione" sarà AOT? Come potrebbe funzionare, considerando che l'espressione 'Expression' è costruita in fase di runtime? – svick

+0

@svick: un'altra risposta SO sullo stesso argomento sembra suggerire, come ho fatto, che le espressioni vengano precompilate dal compilatore AOT quando si trova in un'app Xamarin.iOS: http://stackoverflow.com/questions/24977939/what -does-expression-compile-do-on-monotouch – NovaJoe

+0

@svick: Per ripetere, quello che sto dicendo è che la mia comprensione è che Expression NON è costruito in fase di esecuzione quando si utilizza il compilatore AOT di Mono. È costruito in fase di compilazione. – NovaJoe