Smart layouts, ways to avoid reverse engineering.

[scoiatael]

In GitLab by @nikitamironov on Mar 16, 2020, 14:53

hardcore-full.sketch

Nejvyssi komplexita, trva asi 4 minuty: 16 artboardu s 100 smart layout instancemi v kazdem. Kazda instance ma 3 urovne layoutu.

time sketchtool detach --output=h.sketch ./hardcore.sketch 

real    3m50.566s
user    3m17.710s
sys 0m10.035s

hardcore-8a.sketch

Same, ale 8 artboardu misto 16.

time sketchtool detach --output=h.sketch ./hardcore-8a.sketch 

real    1m33.686s
user    1m32.168s
sys 0m3.689s

hardcore-4a.sketch

Same, ale 4 artboardu misto 16.

time sketchtool detach --output=h.sketch ./hardcore-4a.sketch 

real    0m45.574s
user    0m45.008s
sys 0m1.529s

hardcore-2a.sketch

Same, ale 2 artboardu misto 16.

time sketchtool detach --output=h.sketch ./hardcore-2a.sketch 

real    0m48.779s
user    0m47.261s
sys 0m1.722s

hardcore-1a.sketch

Same, ale 1 artboard misto 16.

time sketchtool detach --output=h.sketch ./hardcore-1a.sketch 

real    0m11.728s
user    0m11.409s
sys 0m0.458s

hardcore-1a-half.sketch

time sketchtool detach --output=h.sketch ./hardcore-1a-half.sketch 

real    0m5.985s
user    0m5.887s
sys 0m0.219s

hardcore-1a-quart.sketch

time sketchtool detach --output=h.sketch ./hardcore-1a-quart.sketch 

real    0m2.893s
user    0m2.880s
sys 0m0.131s

hardcore-1a-three.sketch

time sketchtool detach --output=h.sketch ./hardcore-1a-three.sketch 

real    0m1.749s
user    0m1.543s
sys 0m0.112s

hardcore-full-reduced-complexity.sketch

Cely design (vsichni artboardy), ale detachnuta jedna uroven layoutu (pred celym detachem).

time sketchtool detach --output=h.sketch ./hardcore-full-reduced-complexity.sketch 

real    1m33.397s
user    1m34.134s
sys 0m4.407s

hardcore-full-reduced-complexity-3.sketch

Cely design (vsichni artboardy), ale detachnute dve urovne layoutu (pred celym detachem).

time sketchtool detach --output=h.sketch ./hardcore-full-reduced-complexity-3.sketch 

real    0m46.004s
user    0m44.815s
sys 0m1.498s

Z toho vyplyva, ze pro designy aktivne vyuzivajici smart layouty to urcite nebude rychly, orientacne to bude trvat 1-2 minuty jenom pro detach. Zkouseli jsme s @jakubzitny i jine realne designy, vetsinou jejich specifika je to, ze soubory jsou mnohem vetsi (pro srovnani tohle je 1.5mb, kdyz jsme zkouseli designy zakazniku na 200-300mb testovacich souborech), ale presto jsou rychlejsi pro detach - ono to tolik nezalezi na rozmeru sobouru kolik na jeho algoritmicke komplexite. Ty velke soubory pro srovnani nam trvali 15-20s.

Vyparsovat ale potom ty data je opravdu rychla operace. Na ten nejvic komplexni soubor mi Nodejs potreboval pohych 250ms - s tim, ze jsem nedelal ani moc velke filtrace: skutecne jsem vyextrahoval vsichni bounds vsech vrstev a dokonce i dal do JSON.stringify.

Takze jedina pomalejsi operace je ten detach, ale uprimne, imo my nebudeme mit v praxi az natolik obtizne designy. Napriklad ten CBS (200mb) trva pouhych 8 sekund. Samozrejmne teoreticky muzeme narazit i na extremne komplexni designy, ale vetsinou to zakazniky delat ani nemohou z duvodu "rozbitosti" smart layoutu a obtiznosti praci s takovymi.

tl;dr: vetsinou zakazniky nebudou chtit velkou komplexitu layoutu, ktera je prave jedinym duvodem pomaleho detache. Detach sam o sebe je ale jedinym bottleneck mistem, takze celkove sance pomaleho zpracovani v navrzenem flow je nizka.