Ebben a cikkben megosztom, hogyan lehet elkerülni azokat a hibákat, amelyeket elkövettem az Electron.js megismerésekor? ♂️. Remélem, segít!
Megjegyzés : Ez nem egy kódolási oktatóanyag, hanem inkább egy beszélgetés a személyes elvihetőségeimről.
Pár hónapja úgy döntöttem, hogy inkább a melléktermékem, a taggr . Arra inspiráltam, hogy elkészítsem, mert hány fénykép van a számítógépemen.
Azok számára, akik biztonsági másolatot tartanak a képeikről, ezek a gyűjtemények gyakran olyan nagyok és összetettek, hogy teljes munkaidős munkává válnak. A mappák és az almappák keveréke tartalmazhat azonnali üzenetküldő képmentéseket, nagy felbontású képeket a Balira tett utadról, a nagybátyád esküvőjéről vagy a tavalyi legénybúcsúról.
Az ilyen gyűjtemények mindig rendben tartása unalmas (hidd el, évek óta próbálkozom). Ez is nehézhogy felfedezze azokat a felvételeket, amelyeket a legjobban szeret, a mappák mélyén elrejtve.
Tehát taggregy asztali alkalmazás, amely megoldja ezt a problémát. Ez lehetővé teszi a felhasználók számára, hogy újból felfedezzék emlékeiket, miközben megőrzik magánéletüket .
Építek taggr mint egy cross-platform asztali alkalmazás. Itt megosztok néhány dolgot, amit a cross-platform alkalmazás fejlesztéséről tanultam az Electron.js-szel, és amelyeket bárcsak a kezdetektől fogva ismernék. Kezdjük el!
Háttér
Mielőtt bemutatnám az elvihető anyagokat az Electronnal folytatott utazásomról, szeretnék még egy kis hátteret adni magamról és a taggr követelményeiről .
Minden fejlesztő más háttérből származik, és az általuk fejlesztett alkalmazások követelményei is.
A projektre tett döntéseim kontextusba helyezése segíthet a jövőbeli fejlesztőknek kiválasztani a megfelelő eszközöket igényeik és szakértelmük alapján (ahelyett, hogy odakinn élnek - GitHub?, Rád nézek).
Mint korábban említettük, a kezdetektől fogva a taggramot több platformra kiterjedő alkalmazásként képzeltem el . Az alkalmazás az összes szükséges előfeldolgozási és gépi tanulási számítást elvégzi a kliens oldalon, a magánéletre összpontosítva.
Egyszemélyes show-ként azt szerettem volna tudni, hogy egyszer megírhatom az alkalmazásomat, és különféle rendszerekbe szállíthatom anélkül, hogy elveszíteném a józan eszemet.
A magam oldaláról egy elülső mérnök vagyok, szerelmes az internetbe és a JavaScriptbe. Korábban dolgoztam a Java-val és a C # -val, de élvezem a web rugalmasságát és élénk ökoszisztémáját.
Korábban tapasztaltam azt a fájdalmat, hogy korábban olyan eszközöket használtam, mint az Eclipse RCP kliensoldali alkalmazások készítéséhez, és tudtam, hogy nem akarok többet együtt dolgozni ezzel a technológiával.
Röviden: a taggrammal kapcsolatos követelményeim a következőkhöz hasonlítottak:
- Platformok közötti támogatást kell nyújtania , ideális esetben a keretrendszer szintjén. ?
- Lehetővé teszi számomra, hogy egyszer megírjam a kódot , és ha szükséges, minden platformra csípjek. ? ️
- Lehetővé kell tennie a gépi tanulási képességekhez való hozzáférést, a fogadó környezettől függetlenül, külön futásidejű telepítés nélkül. Beállításának fájdalommentesnek kell lennie. ?
- Ha megvalósítható, webes technológiákat kell használnia . Nagyon jó lenne kihasználni a meglévő tudásomat. ?
Amint láthatja, a követelmények nem így hangzanak: a React with Redux, az observable és a WebSockets alkalmazást kell használnom . Ezek alacsonyabb szintű végrehajtási részletek, és ezekről akkor kell dönteni, amikor és amikor szükség van rá.
Válassza ki a megfelelő eszközt a munkához, ahelyett, hogy az elejétől kezdve válogatna egy halmot, figyelmen kívül hagyva a problémákat.
Dühös guglizás után úgy döntöttem, hogy kipróbálom az Electron-t. Korábban még nem használtam ezt a keretrendszert, de tudtam, hogy sok vállalat sikeresen használja olyan termékekben, mint az Atom, a VS Code, a Discord, a Signal, a Slack és még sok más.
Nyílt forráskódú, és a JS és a Node ökoszisztémákkal együttesen elérhető kompatibilitással (az Electron felépítése Chromium és Node használatával történik) az Electron.js vonzó eszköz volt a szóban forgó munkához.
Nem részletezem túl részletesen a verem többi részét, mivel szükség esetén többször is megváltoztattam az alaprészeket (perzisztencia és nézetrétegeket), és ez nem tartozik a cikk hatálya alá.
Szeretném azonban megemlíteni a Tensorflow.js fájlt, amely lehetővé teszi az edzés futtatását és az ML modellek telepítését közvetlenül a böngészőben (WebGL-lel) és a Node-ban (C összerendeléssel), anélkül, hogy az ML-hez meghatározott futási időket telepítenénk a gazdagépre.
Tehát vissza az Electronhoz - azt gondolva, hogy tökéletes, elkezdődött a móka. ??
Elég beszélni a háttérről. Merüljünk el az elvihetőkben.
1. Kicsiben (és lassan) kezdeni?
Ez nem új koncepció, de érdemes rendszeresen felvetni. Csak azért, mert rengeteg fantasztikus kezdő projekt áll rendelkezésre az Electron-nal, ez nem jelenti azt, hogy azonnal ki kellene választania egyet.
Várjon. Mit?
A lassú sima és a sima gyors. - Haditengerészet mondásaA kényelemmel együtt jár a bonyolultság
Míg ezek a kezdők sok hasznos integrációt tartalmaznak (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), megvannak a maguk problémái is.
Electron újoncként úgy döntöttem, hogy egy sovány sablont választok, amely tartalmazza az „Electron alkalmazások létrehozásának, közzétételének és telepítésének” alapjait a különféle harangok és sípok nélkül. Kezdetben még Webpack sem.
Azt javaslom, hogy kezdjünk valami hasonlóhoz, mint az elektron-hamisítás, hogy gyorsan fel tudjunk állni, és lehetállítsa be a függőségi grafikonját és szerkezetét a tetején, hogy megtanulja az Electron köteleit.
Amikor megjelennek a problémák (és meg is fognak történni), akkor jobban jársz, ha elkészíted az egyéni indítóprojektet, nem pedig +30 npm parancsfájlokkal és +180 függőséggel választasz egyet.
Mindazonáltal, ha jól érzi magát az Electron alapjaival, nyugodtan fokozza a játékot a Webpack / React / Redux / TheNextHotFramework segítségével. Fokozatosan és szükség esetén csináltam . Ne adjon hozzá valós idejű adatbázist a todo alkalmazásához, csak azért, mert valahol olvasott róla egy jó cikket.
2. Gondosan strukturálja az alkalmazását? ♂️
Ennek egy kicsit több időbe telt, mire örülök, hogy bevallom. ?
Az elején csábító lehet az UI és a Backend kód összekeverése (fájlhozzáférés, kiterjesztett CPU-műveletek), de a dolgok meglehetősen gyorsan bonyolódnak. Amint az alkalmazásom jellemzői, mérete és összetettsége egyre nőtt, az összekuszált UI + Backend kódbázis fenntartása bonyolultabbá és hibára hajlamosabbá vált. A kapcsolás megnehezítette az egyes részek izolált tesztelését.
Olyan asztali alkalmazás készítésekor, amely nem csak beágyazott weboldalt végez (DB-hozzáférés, fájlhozzáférés, intenzív CPU-feladatok ...), akkor azt javaslom, hogy az alkalmazást modulokba vágja és csökkentse a csatolást. Az egység tesztelése szellővé válik, és a modulok között egyértelmű út vezet az integrációs tesztelés felé. A taggr esetében lazán követtem az itt javasolt struktúrát.
Ráadásul van teljesítmény . Az ezzel kapcsolatos követelmények és a felhasználói elvárások nagyban változhatnak az épülő alkalmazástól függően. De a fő vagy a render szálak blokkolása drága hívásokkal soha nem jó ötlet.
3. Tervezzen a menetes modellt szem előtt tartva?
Nem részletezem itt túlságosan a részleteket - csak főleg megduplázom azt, amit félelmetesen elmagyaráznak a hivatalos dokumentumok.
A taggr konkrét esetben sok régóta futó CPU, GPU és IO intenzív művelet van. Amikor ezeket a műveleteket az Electron fő vagy renderelő szálában hajtja végre, az FPS számlálás 60-ról süllyed, így a felhasználói felület lassúnak tűnik.
Az Electron számos alternatívát kínál ezeknek a műveleteknek a fő és a renderelő szálakból való eltávolítására , például a WebWorkers, a Node Worker Threads vagy a BrowserWindow példányokról. Mindegyiknek megvannak a maga előnyei és figyelmeztetései, és az Ön által tapasztalt felhasználási eset meghatározza, hogy melyik a legmegfelelőbb.
Függetlenül attól, hogy melyik alternatívát választja a műveletek kitöltéséhez a fő és a renderelő szálakból (ha szükséges), fontolja meg , hogy milyen lesz a kommunikációs felület . Eltartott egy ideig, mire egy olyan kezelőfelülettel készültem, amellyel elégedett voltam, mivel ez nagyban befolyásolja az alkalmazás felépítését és működését. Hasznosnak találtam a különböző megközelítések kísérletezését, mielőtt kiválasztottam egyet.
Például, ha úgy gondolja, hogy a WebWorkers üzenetátviteli felületét nem lehet a legkönnyebb hibakeresni, próbálja meg a comlinket.
4. Tesztelje, tesztelje és tesztelje ✔️
Régi hír, igaz? Ezt akartam hozzáadni utolsó pontként, néhány anekdotikus „probléma” miatt, amelyekkel nemrégiben szembesültem. Szorosan kapcsolódva az első és a második ponthoz, az egyéni indító projekt megalkotása és a hibák korai hibázása értékes hibakeresési időt takarít meg a fejlesztésben.
Ha betartotta az alkalmazás kezelőfelületének és a háttérprogramnak a kettő közötti tiszta felülettel rendelkező modulokra bontására vonatkozó ajánlásaimat, akkor az automatizált egység- és integrációs tesztek létrehozásának egyszerűnek kell lennie. Amint az alkalmazás lejár, érdemes hozzáadnia az e2e tesztelés támogatását is.
GPS helymeghatározás? ️
Két nappal ezelőtt, amikor végrehajtottam a GPS helymeghatározási funkcióját a taggr számára , miután az egység tesztjei zöldek voltak, és a funkció működött a fejlesztés során (a Webpack segítségével), úgy döntöttem, hogy kipróbálom a termelési környezetben.
Míg a szolgáltatás jól működött a fejlesztésben, a gyártásban csúfosan megbukott. A képekből származó EXIF-információkat binárisként olvasták és egy harmadik fél által készített könyvtár dolgozta fel. Míg a bináris információkat mindkét környezetben helyesen töltötték be (a diff-rel ellenőrizték), a harmadik fél könyvtárának kudarcot vallott az ilyen adatok elemzése a termelési buildben. Elnézést, ??
Megoldás : Megtudtam, hogy a Webpack által beállított fejlesztési és gyártási környezetek kódolási beállításai nem ugyanazok. Ez azt eredményezte, hogy a bináris adatokat UTF-8-ként elemezték a fejlesztésben, de a gyártásban nem. A problémát úgy oldották meg, hogy beállították a megfelelő kódoló fejléceket az Electron által betöltött HTML fájlokba.
Funky képek?
Képekkel való manipulálás és munka közben azt gondolhatja, hogy ha egy JPEG „csak működik” a számítógépén, akkor az érvényes JPEG. Rossz .
Miközben a Node képfeldolgozó könyvtárával élesen dolgozott, néhány JPEG kép átméretezése összeomlotta az alkalmazást. Alapos megnézés után az ok a Samsung firmware által generált hibás JPEG-képek voltak. ? ♂️
Megoldás : javított hibahatárok beállítása az alkalmazásban (pl. Try-catch blokkok), a JPEG elemző modul módosítása és mindenre gyanakvás. ? ️
Összegzés
A Node és a JavaScripts ökoszisztémák virágoznak, sok hatékony eszközt hoznak létre és osztanak meg minden nap.
Az opciók száma megnehezíti az egyértelmű útvonalat az új fantasztikus Electron alkalmazás építésének megkezdéséhez. A választott kerettől függetlenül azt javaslom, hogy a következőkre összpontosítson:
- Kezdje kicsiben, és fokozatosan adja hozzá a bonyolultságot.
- Gondosan strukturálja az alkalmazását , megtartva a háttérprogramot és a moduláris felhasználói felületet.
- Tervezzen a menetes modellt szem előtt tartva , még akkor is, ha kis alkalmazásokat épít.
- Teszteljen és teszteljen újra , hogy a hibák nagy részét már korán elkapja és megspórolja a fejfájást.
Köszönöm, hogy kitartottál a végéig! ?
A taggr egy platformon átívelő asztali alkalmazás, amely lehetővé teszi a felhasználók számára, hogy újból felfedezzék digitális emlékeiket a magánéletük megőrzése mellett . Az Open-alfa hamarosan Linuxra, Windowsra és Mac OS-re érkezik. Tehát figyelemmel kíséri a Twitteret és az Instagramot, ahol fejlesztési frissítéseket, közelgő szolgáltatásokat és híreket teszek közzé.