gradlew lefagy [MEGOLDVA]

> Igen, könnyen lehet, hogy a Google ezzel foglalkozó mérnökei mind balfaszok és a közösségből sincs egyetlen értő ember sem, aki küldene patch, ha már nyílt forrású az egész.

A nyílt forrás arra jó, hogy ha van egy bug, akkor azt ki tudja javítani aki megtalálja. Azonban alapvető tervezési szintű problémákat nem lehet így megoldani, mert aki átalakítaná az mindent fel kellene, hogy forgasson, és már inkább akkor ír egy újat.

Hogy mondjak egy konkrét példát: amikor Java-t buildelünk, akkor a folyamat valami ilyesmi - jócskán egyszerűsítve:

 * Források parszolása

 * Függőségek betöltése

 * fordítás

 * És ennek az ismételgetése fordítás egységenként, amit bundle, modul, satöbbi néven szokás nevezni.

Ha van egy sok fordítási egységből álló projekt, akkor ezeket ismételgeti a rendszer fordítási egységenként. Miközben a függőségek jelentős része ugyanaz, ráadásul legtöbbször a függőség az, amit éppen az előbb fordított le a rendszer. Tehát felesleges volna újratölteni, de a build rendszerek megteszik. Hiába van még esetleg benn a memóriában az adott függőség, mivel a fordítót modulonként újraparaméterezve indítjuk, nem lesz lehetősége újrahasznosítani a betöltött dolgokat. A cache-ben persze benne lesz a fájl, gyorsabb lesz betölteni, de a munka jelentősebb része a fájl értelmezése és ez alapján a publikus interfészek szerkezetének, keresőfáknak satöbbiknek a felépítése. Ezt mindig újra kell csinálni.

Az Eclipse beépített buildere egyébként úgy tud működni, hogy egyetlen fordító objektumban dolgozza fel az összes modult, a fordítás köztes eredményeit memóriában tartja, és valóban inkrementálisan tud működni, ezért meg tudja azt csinálni, hogy ctrl-s után egyetlen pillanattal (saccra 1s-nél rövidebb idő alatt) már az új kód indítható, vagy nyitott debug session esetén már automatikusan aktiválva is van. (Kivétel csak az amikor egy óriás projektben a függőségi fa gyökerénél változtatunk, akkor is gyors, de akkor lehet néhány másodperc is a fordítás.) Aztán ugyanazokat a bundle-ket parancssorból fordítani sok perces tortúra. És ha Maven vagy gradle projekt van Eclipse alatt, nem a saját natív formátuma, akkor megintcsak lassú lesz (ez régebbi tapasztalatom, de nem vagyok szakértő ebben), ezért mondják a userek, hogy az Eclipse lassú, miközben én annyira gyorsnak tapasztalom, hogy érzésre 0 idő alatt van meg a legtöbb build.

Projektenkénti (bundle, modul stb, sokféle neve van) ismételgetés helyett meg lehet csinálni azt, hogy egyszerre töltünk be és fordítunk mindent. És ez a megoldás valóban sokszor gyorsabb. Csak éppenséggel az egész build logikája teljesen más, nem is nagyon lehet iteratív lépéseken keresztül a meglévő megoldásokon keresztül elérni, eleve így kell nekiállni. Egy-két összetett projekten játékból összeraktam ilyen parancssori buildet, ami egy lépésben fordít sok modult (ami annyi, hogy összegereblyézzük a források és függőségek listáját és direkben meghívjuk a például a javac parancsot - ezt manapság a legtöbb Java fejlesztő el sem tudja képzelni, pedig még mindig működik csak akarni kell), és valóban sokkal gyorsabb lett, de már nincsenek meg a számaim.

A példát azért hoztam fel, hogy nagyon nem mindegy, hogy hogyan van megtervezve a build folyamata, és ha már az elv lassú, akkor abból nem lehet optimalizálgatással gyorsat csinálni, csak gyökeres átalakítással.

Közben picit utánanéztem a gradle doksinak. Elég sok mindent lehet hangolni rajta, valszeg a kérdező is simán tudna csökkenteni a memória igényén.
Hogy a mobil fejlesztéshez miért kell ennyi erőforrás azt továbbra se "érzem" de nem is értek hozzá és nem is érdekel :)