Android Studio v1.3 Preview introduce il supporto al linguaggio C/C++

29 Maggio 2015 81

Il Google I/O è un evento per sviluppatori e il Keynote è solo una sorta di introduzione delle novità e sessioni che si susseguono nei due giorni di incontri. Come abbiamo visto, oltre ad Android M, sono stati presentati una serie di importanti novità per gli sviluppatori. Alcune riguardano le applicazioni, altre API e possibilità di interazione e altre ancora gli strumenti veri e propri per realizzare i programmi.

Android Studio v1.3 Preview è probabilmente il software più importante aggiornato in queste ore in quanto è stato introdotto il supporto al linguaggio C/C++. Si tratta di un'ottima notizia per tutti gli sviluppatori che adesso avranno a disposizione ulteriori strumenti per realizzare app su Android.

Nessun compromesso per durata batteria a parità di prezzo? Lenovo P2, in offerta oggi da Tiger Shop a 245 euro oppure da Amazon a 289 euro.

81

Commenti

Regolamento Commentando dichiaro di aver letto il regolamento e di essere a conoscenza delle informazioni e norme che regolano le discussioni sul sito. Clicca per info.
Caricamento in corso. Per commentare attendere...
root

A me il java non piace, premettendo questo, c'è da dire che in alcuni casi è preferibile il C++ ed in altri il Java, Java ad esempio è molto più semplice da sviluppare, da scrivere e soprattutto da debuggare, inoltre uno sviluppatore Java normalmente lo paghi meno di uno sviluppatore C++ perché di sviluppatori Java ce ne sono molto di più, i progetti Java sono più facilmente mantenibili ed adattabili, e sono portabili senza ricompilare il codice mille volte, insomma, Java costa meno da sviluppare e mantenere, il C++ ha prestazioni ovviamente maggiori, il tutto si riduce come sempre nel valutare il rapporto costi/benefici, vale la pena spendere di più per fare l'applicazione in C++ piuttosto che Java, o usare Java rinunciando ad un po' di prestazioni e quindi dovendo comprare hardware più potente ?

Inoltre il Java è notoriamente più sicuro, nel senso, nel C++ hai il rischio di commettere errori del tipo non controllare la dimensione di un buffer ed andare in buffer overflow, quindi il Java è solitamente usato in tutti quegli ambiti dove è richiesto un elevato livello di sicurezza (sostanzialmente applicazioni per banche, aziende che trattano dati critici, ecc)

Federico Fontana

...no, Java non è stato scelto perché era il più diffuso, java stava morendo.
Java viene tradotto in un linguaggio intermediario appunto in bytecode, che nella dalvik viene compilata in run-time, ma da un po su android c'è ART che compila alcune cose prima, per rendere almeno l'apertura delle app un pò piu veloce. tra codice nativo e java c'è un abisso. Su android le ndk(quindi codice nativo) sono utilizzate praticamente solo per giochi e applicazioni specifiche, il motivo è che è scomodissimo usarle.

Zoolander

Mi fa strano leggere commenti di chi preferisce Java a C++. Un vero programmatore (che sa usare entrambi bene) sa benissimo che il C++ è da preferire in diversi ambiti.

crissstian96

Sapete quanto conta il linguaggio utilizzato in android? Zero, cioè proprio nulla. E' solo una questione di comodità, infatti Java è stato scelto non tanto per le sue proprietà ma perché è il più diffuso, e chi ha sviluppato l'SDK non voleva che i developer imparassero un linguaggio da zero. Alla fine comunque Java non viene esattamente "compilato" ma viene "tradotto" in un altro linguaggio a basso livello, che verrà poi letto dalla dalvik machine o chi per lui (ad esempio art).
Conclusioni? Non importa se scrivete in Java, C++, Assembly, ebraico o greco antico, i risultati in termini di ottimizzazioni e prestazioni saranno gli stessi.
E non capisco le vostre preoccupazioni, nessuno ha detto che Java scomparirà, si parla solo di supporto.

ErCipolla

Tecnicamente si può, ad esempio le librerie JUICE e KDE_Necessitas lo fanno. Però ho idea che non sia molto richiesto, tipicamente ciò che si fa è lasciare la GUI in Java nativo (molto più semplice) e delegare le computazioni pesanti dove serve efficienza a librerie c++

ErCipolla

Si chiaro, ho usato un termine inappropriato, un linguaggio è solo una definizione sintattico/semantica, poi può essere implementato in maniera compilata, interpretata, mista, ecc. Però diciamo che lo "scenario tipico" quando si parla di C++ è quello compilato.

M3r71n0

Aprire a nuovi linguaggi lasciando fuori IL linguaggio.
OrmaI C++ lo insegnano alle superiori.
Non è proprio una mossa intelligente la tua, per me. Cmq...

In merito all'interpretazione del tuo discorso...etc. etc.
Si si, ok!!!
XD

sergio

Era una ovvia provocazione, leggi TUTTO IL MESSAGGIO, non estrapolare parti a tuo uso e abuso. la mia critica COSTRUTTIVA a differenza dei molti troll che infestano l'ambiente era rivolta al fatto che speravo che Google per incentivare gli sviluppatori decidesse di aprire l'sdk a linguaggi più moderni, o ne creasse uno da zero come Swift.

sergio

Al di là del fatto che pure il salumiere sa che il c++ è ad oggetti, ma lo stesso salumiere sa anche che non può certo competere con linguaggi NATI per quello come Java, objective c, Python
Se non credi che sia uno sviluppatore mi vuoi fare un test? Vuoi il link delle mia app così mi faccio pure pubblicità? Dimmi sono a tua disposizione....

bazzilla

Credo proprio di si.

EG

Ok grazie, ho capito che si possono sviluppare parti di app dove si necessita di particolari performance ma è possibile creare una app intera con UI (trascurando le difficoltà che ciò comporta)?

bazzilla

Ehm...non proprio...
Leggi qui così capisci di cosa si sta parlando:
https:// developer. android. com/tools/sdk/ndk/index.html

EG

In quel caso allora è un cross-compiler ma sul fatto che poi si possano sviluppare app con UI, installarle ed eseguirle su android quello non mi è ancora del tutto chiaro.

marco80

Primo: ARM non converte istruzioni in Java e non converte istruzioni in C. ARM è un'architettura, che ha un set di istruzioni. A convertire le istruzioni in Java o in C in codice nativo (ossia in istruzioni che fanno parte del suddetto set) ci pensa il compilatore.

Secondo: Che in Java non si possa gestire direttamente la memoria di sistema mentre si può farlo in codice nativo ARM, non impedisce di tradurre codice Java in codice nativo ARM. Il compilatore è in grado di tradurre il codice Java "char[] mioarray ={ 'a', 'b', 'c' };" in un codice nativo ARM che contiene le dovute istruzioni per accedere direttamente alla memoria. Stessa cosa che viene fatta per tradurre il codice C "char mioarray[3]; mioarray[1]='a'; mioarray[2]='b'; mioarray[3]='c';", che non usa istruzioni per gestire direttamente la memoria (come malloc, aritmetica dei puntatori ed amenicoli vari) in codice nativo ARM.

Terzo: Codice scritto in linguaggi di alto livello può (e sottolineo "può", perchè dipende sia dal codice sia da quanto è ottimizzato il compilatore del primo linguaggio rispetto a quello del secondo) essere tradotto in un codice nativo meno efficiente di codice scritto in linguaggi di più basso livello. Per intenderci, un 2+2 scritto in un linguaggio di alto livello può essere tradotto in qualcosa di più lontano da quello che scriveresti direttamente in assembly rispetto alla traduzione effettuata a partire dal linguaggio di più basso livello. Ma ciò non toglie che il codice che ottieni è codice nativo, scritto in una serie di 1 e 0 che codificano istruzioni appartenenti al set di istruzioni ARM. E viene eseguito direttamente dal processore del tuo telefono, non viene eseguito indirettamente da una macchina virtuale come accade per codice tradotto in bytecode.

bazzilla

Ho corretto il mio commento sopra.
Non parlavo di compilare C++ SU android, ma di compilare C++ PER android.
App che hanno parti native scritte in C/C++ (e di conseguenza compilate) esistono per Android da che esiste Android stesso.

M3r71n0

Sarò provocatorio: quindi regolatevi di conseguenza.

Io, personalmente sviluppo/avo in VB6, quindi su questa notizia l'unica cosa che posso dire è che sono contento per la maggior compatibilità di linguaggio di questo SDK (magari inserissero il vecchio VB6). Le uniche app android sviluppate (per uso personale) le ho fatte con l'appinventor e ammetto di essere ign0rante in fatto di java, etc.

Ma sinceramente leggere tutto e il contrario di tutto in fatto di sviluppo, linguaggio, compilazione, etc. qui sotto, mi ha fatto venire un bel volt..........aco.

Per chiunque "come me inizialmente" creda di apprendere qualcosa in più sul come funziona un app per android (assolutamente OT con l'articolo). LASCI PERDERE...
...e chiedo scusa anche per il tempo perso a leggere questo stesso commento.

Presidente

ci sei vicino, ma mi dispiace che sbagli sul fatto di nativo...per farti capire bene la cosa ad esempio in java non ci sono metodi per andare a manovrare la memoria vera del sistema, mancano proprio tali istruzioni primitive, quindi ARM può provare a convertirle, può provare a decodificarle in codice nativo ma non è codice nativo vero perché un "2+2" potrebbe essere un "2+2-2-2+2-2+2+2" ...poi ci sono chiamate al kernel che non le converte proprio ARM...quindi ti ribadisco che se vuoi un qualcosa di scritto in nativo non c'è altra via oltre al vecchio e buon C

marco80

Alcune sono caricate nello store in diverse versioni, una per ciascuna architettura supportata. Altre sono caricate in un'unica versione e contengono una piccola parte in java che controlla quale architettura usa il telefono e esegue il binario compilato per quell'architettura (questo può essere contenuto nell'app insieme a quelli per le altre architetture o può essere scaricato alla prima esecuzione dell'app se per motivi di spazio non vuoi inserire nell'app binari compilati per diverse architetture).

M3r71n0

Sergio, calma. Seriamente non ho alcuna intenzione di intossicarmi in questo splendido fine settimana di sole. Calmo, calmo.
C'è stato un equivoco? Bene. Lo troviamo e lo risolviamo?
cit. "Tornare a combattere con i puntatori?"

Qui mi hai disorientato.
Perchè ipotizzi "il tornare a combattere"?
Scrivi in java, bene, che te frega che ora è compatibile con c++, ma se sei uno sviluppatore, non può non farti piacere che ora quell'sdk compili anche linguaggio c/c++.
Alcune cose che dovresti fare in altro linguaggio (studiando il come), lo fai in c++, visto che già lo conosci.

BadFox

Se sei davvero uno sviluppatore dovresti sapere che C++ è un linguaggio orientato agli oggetti.

EG

La vedo dura, anche se esistesse un compilatore arm v8 su android e si compilasse una app da 100mb penso che impiegherebbe diverso tempo.

bazzilla

Basta l'ultima riga di questo commento a far capire come tu sia completamente fuori strada.
Fai un favore a te stesso e agli altri lettori del blog: leggi la news PER INTERO.

marco80

Secondo me quello che non capite voi due è che non è che siccome una cosa è scritta in java allora serve una vm e se è scritta in c non serve. Un conto è un linguaggio, un conto è il modo di trasformare quel linguaggio in una forma eseguibile dal calcolatore. Uno può compilare in codice nativo del codice java come faceva gcj e come fa ora dex2oat o può eseguire in vm del codice c come fa emscripten. In Lollipop su ogni terminale è installato il compilatore dex2oat che prende il bytecode dex presente nell'apk che scaricate dal play store e lo compila in un eseguibile oat che viene salvato nella partizione dove prima venivano salvati file di cache di dalvik. Quel file contiene codice nativo che viene eseguito direttamente dal sistema, non dalla vm che esegue bytecode dex non codice nativo arm (piuttosto che x86 o altro).

bazzilla

Correggo il mio commento sopra: " ma programmare e compilare in C/C++ LE APP Android è possibile da tempo immemore"

Mica so io quali sono le app che hanno parti sviluppate in C/C++. Sicuramente i giochi o le app di benchmark sono le maggiori candidate, ma ne esisteranno sicuramente altre di altre categorie che non conosco.

sergio

Estrema che??? Sai che caxxo me ne può fregare se gli sviluppatori tornano ad usare un linguaggio senza stringhe.... E non orientato ad oggetti. Non può f0ttermene di meno :)

sergio

Ma voi l'italiano lo capite oppure no???? Chi diavolo parlava di Android! Io stavo parlando dell'sdk che sicuramente conosco meglio di te e altri come te.
Brutta cosa la totale ignoranza.... Android in C..... Bah

M3r71n0

Lascia stà.
Si sarà fatto prendere da un attimo di estrema frustrazione XD XD XD XD

Alberto

no. Art non rende il codice nativo. E' pur sempre codice java che bisogna di vm. Con art cambia solo che le app vengolo compilate una volta sola.

Presidente

vengono eseguite nativamente solo quelle interamente scritte in c/c++... se provi ed è semplice, capirai meglio di se ti informi qua e là...

EG

Ok quindi ammettendo che molte app siano sviluppate in c++ e tu le scarichi dal play store secondo come funzionerebbero sul tuo terminale, sono già compilate o vengono compilate sul dispositivo?

EG

Davvero? Fammi un esempio di app sviluppata in c++ (escluse le librerie) grazie

EG

Ok che si sviluppano librerie e kernel in c++, il problema è se si possono sviluppare app con UI in c++.

Max

Sono sbalordito dal tuo sapere della cosa e da come l'hai spiegato perfettamente, complimenti. Di Java però bisogna dire che è veramente problematico con le prestazioni e quando usi più app aperte sul sistema operativo (qualunque esso sia) esso va in affanno prestazionale. Trovo che il fatto che si possa programmare in c/c++ + solo un vantaggio, il problema è che poi sarà anche in questo caso una vm a far girare tale programma, almeno su android.

marco80

L'esecuzione del codice nativo non avviene in vm. Si chiama codice nativo proprio perchè viene eseguito nativamente. Nel caso dell'interpretazione (prima di Froyo) viene eseguito il bytecode in vm, nel caso della compilazione jit (da Froyo a Jelly Bean) vengono determinati a run time gli "hot spot" del codice, questi vengono compilati ed eseguiti nativamente mentre il resto viene eseguito in forma di bytecode in vm, nel caso della compilazione aot (da Lollipop) l'applicazione viene interamente compilata ed eseguita nativamente.

bazzilla

Ma le leggete le notizie oppure no?
Non è ANDROID che da oggi supporta C/C++, ma è ANDROID STUDIO!
Android Studio è un AMBIENTE DI SVILUPPO.

Il C/C++ è supportato da Android da quando è nato.

bazzilla

????

ale

Si però poi devi anche rilasciare più versioni, bel casino, per di più integrare un app in C/C++ in android è parecchio complesso, la parte dell'interfaccia utente dovrà essere sempre in java e poi da li puoi richiamare il programma in C, quindi hai un app metà in java metà in C, e poi devi fare affidamento alle librerie di linux per la parte in C, e non è nemmeno sicuro che siano uguali ovunque, magari il produttore ha usato quella libreria vecchia o ha usato delle particolari opzioni di compilazione che la rendono incompatibile con la tua app, quindi magari ti trovi un app che su un certo telefono non va semplicemente, e poi non è nemmeno sicuro che una stessa app si comporti allo stesso modo su sistemi diversi, insomma complicazione assurda per guadagnare poco nulla di prestazioni, perchè tanto con ART anche le app java vengono compilate all'installazione...

sergio

Per me è un passo indietro. Notevole. Nessuno mette in dubbio il valore del C soprattutto, ai tempi dell'amiga 500 facevo cose con quel linguaggio che se ci penso oggi... Ma i tempi cambiano, avrei apprezzato qualcosa alla Apple, con Swift. Magari un pieno supporto alla programmazione in Python, quello si che avrebbe acceso le mie fantasie. Tornare a combattere con i puntatori? No grazie, nel 2015 proprio no. Ripeto, parere persona di sviluppatore senza alcuna pretesa.

marco80

Ecchissenefrega, i passaggi in più li fa l'IDE, che non si lamenta per dover compilare più volte la stessa applicazione. A lamentarsi sono gli utenti finali se notano dei lag o gli sviluppatori se devono riscrivere daccapo del codice esistente perchè il codice esistente è stato scritto in un linguaggio non supportato dall'sdk.

krzh

"Compilato per definizione", se intendi in codice nativo, non direi... ad esempio c'è il C++ managed di Microsoft che gira sul .NET Framework.

Alberto

no. ART in lollipop serve solo a compilare l'app una volta installata. invece che compilarla ogni volta. L'esecuzione avviene sempre tramite vm

ale

Già, però si tratta sempre di fare passaggi in più, non puoi rilasciare 10 versioni della stessa app...

marco80

L'esecuzione avviene nella vm per quella parte che non è stata compilata, nel caso del jit di Froyo. Nel caso di Lollipop l'app viene interamente compilata ed eseguita nativamente.

Alberto

??

Alberto

resta il fatto che l'esecuzione passa sempre attraverso vm

marco80

Non bisogna scrivere un'app diversa per ogni architettura disponibile, bisogna scriverne una sola e l'IDE compilare in automatico la compila per tutte le architetture disponibili.

ale

Ma che senso ha sviluppare app android in C/C++, si perde la portabilità e quindi bisogna fare una versione per ogni architettura disponibile, solo per avere un minimo aumento di prestazioni, non ne vale la pena

ale

Comunque con ART le app sono compilate all'installazione, e non interpretate, e questo spiega anche perchè quando installi un app o aggiorni il sistema ci mette una vita, perchè deve compilare l'app...

In realtà poi anche dalvik non compilava ogni volta ma si generava una cache, per cui le prestazioni non sono poi così ridotte.

Fra l'altro l'usare linguaggi di alto livello porta un sacco di vantaggi, portabilità, sicurezza, semplicità di sviluppo, in confronto ad un minimo decremento di prestazioni, se guardi ormai tutti stanno puntando su linguaggi di alto livello, anche microsoft con ili .NET, insomma i programmi classici sono destinati a sparire secondo me...

marco80

I binari aot non passano per la macchina virtuale, come non ci passano le parti scritte in c/c++ caricate tramite jni.

bazzilla

Non credo proprio. La parte in C/C++ per Android gira nativamente senza passare dalla VM Java.
In Java c'è solo la parte che lo "incapsula".
Vedi Java Native Interface per approfondire; per Android sarà una cosa identica, ma forse con un nome diverso.

LG: avevo un ASSO ma ho sbagliato scala | Editoriale

LG V30 è lo smartphone 2017 da battere? | Recensione

Huawei Mate 10 PRO: Kirin 970, 6" 18:9 e doppia cam LEICA a 849 euro | Anteprima

Guida Acquisto Smartphone Xiaomi: garanzia, limiti e potenzialità #report