Dezvoltator de cacao, constructor Lego, model proprietar de cale ferată.

iKenndac pentru majoritatea serviciilor pe care ați dori să le menționați.

8 februarie 2015

Eliminarea arhitecturilor nedorite din bibliotecile dinamice în Xcode

De când a fost anunțat iOS 8, dezvoltatorii au putut profita de avantajele bibliotecilor dinamice pentru dezvoltarea iOS.

Pentru dezvoltarea generală, este minunat să aveți o singură bibliotecă dinamică pentru toate arhitecturile necesare, astfel încât să puteți rula pe toate dispozitivele și pe iOS Simulator fără a schimba nimic.

În proiectul meu și diferitele sale extensii, folosesc Reactive Cocoa și îl am în proiectul meu ca o bibliotecă dinamică precompilată cu felii i386 și x86_64 pentru Simulator și armv7 și arm64 pentru dispozitive.

Cu toate acestea, există un dezavantaj al acestei abordări - deoarece acestea sunt conectate la runtime, atunci când o bibliotecă dinamică este compilată separat de aplicația în care ajunge, este imposibil să se spună ce arhitecți vor fi de fapt necesari. Prin urmare, Xcode va copia doar totul în pachetul de aplicații la momentul compilării. În afară de spațiul pe disc pierdut, în teorie nu există nici un dezavantaj real. Cu toate acestea, în practică, iTunes Connect nu-i place să adăugăm felii binare neutilizate:

kennett

Deci, cum lucrăm în această privință?

Am putea folosi în schimb biblioteci statice. Cu toate acestea, cu mai multe ținte și extensii în proiectul meu, pare o prostie să-mi umfl toate executabilele cu copii ale acelorași biblioteci.

Am putea compila biblioteca de la sursă de fiecare dată, generând o nouă bibliotecă dinamică cu numai arhitecții necesari pentru fiecare construcție. Câteva lucruri mă deranjează în legătură cu acest lucru - în primul rând, pare risipitor să recompilez tot acest cod care nu se schimbă tot timpul, iar al doilea este că îmi place să-mi păstrez dependențele statice și să creez noi versiuni de fiecare dată înseamnă că nu sunt rularea în mod necesar a unui cod stabil, mai ales dacă încep să învârt în beta-uri Xcode. Ce se întâmplă dacă o modificare a compilatorului provoacă bug-uri ciudate în bibliotecă? Este un lucru foarte rar să se întâmple, dar se întâmplă și nu știu destul de bine baza de cod a bibliotecii pentru a o depana.

Dacă nu avem sursa de început, ei bine, am cam cam noroc.

Am putea să ne dăm seama cum să ne ocupăm de acest lucru la momentul construirii, apoi să nu ne mai gândim niciodată la asta. Sună mai degrabă!

Cei care pot, fac. Cei care nu pot, scrie scripturi Shell

Astăzi, am pregătit un mic scenariu în timp de construcție pentru a rezolva problema, așa că nu trebuie să-mi mai pese niciodată.

În dosarul meu de proiect:

După ce ați apăsat „build”:

Fără alte întrebări, iată scenariul. Adauga o Rulați Script treceți la pașii de compilare, puneți-l după pasul dvs. pentru a încorpora cadre, setați-l să folosească/bin/sh și introduceți următorul script:

Scriptul va căuta prin folderul Frameworks al aplicației construite și se va asigura că numai arhitecții pentru care construiți sunt prezenți în fiecare Framework.

Mult mai bine! Acum pot arunca biblioteci dinamice grase asupra proiectului meu care conține toți arhitecții de care voi avea nevoie vreodată, iar procesul meu de construcție se va ocupa de arhitecții care sunt adecvați în orice moment dat.