Csevegj a saját kezeddel
Csevegj a saját kezeddel +4
- 02.06.17 07:08 •
- SSul •
- # 330044 •
- Habrahabr •
- 0 •
- 2600
- ugyanaz, mint Forbes, csak jobb.
Ebben a cikkben leírjuk a csevegés írásának finomságait.
Tudomásul veszem, hogy már elég készen állnak a megoldások. A határtalan hátsó utcák mentén vándorolva néhány hasznos könyvtárat találtak, amelyek csevegést biztosítanak "a dobozból". Ebben a cikkben nem kerülnek felsorolásra. Tehát a kész megoldás megteremtésének lehetősége csábítónak tűnt. De ismét az elgondolandó feladatok összetettségére gondolva, úgy döntöttünk, hogy a semmiből írunk.
A feladat nem teljesen jellemző, és a projekt követelményei nem teljesen meg vannak határozva. Kockázatos, hogy egy fel nem használt könyvtár keretébe vezet. Természetesen nem mondhatjuk, hogy a harcban teszteltek, mint például az RxDataSources, amelyeket határozottan úgy döntöttünk, hogy használjuk. Előfordul, hogy a fejlesztés bármely szakaszában könnyedén helyettesíthető a cellákkal való írásbeli logika. Emellett volt egy "úriember iOS-fejlesztők" is: RxSwift, Realm, Alamofire és Kingfisher. Csatlakoztattuk őket a projekthez.
Az üzenetek listája az UICollectionView segítségével háromszoros rugalmasság miatt valósult meg. Az UIKit animált gyűjteménye pedig szebb, mint az asztal. Ezzel az animációval vezérelhető. A Storyboard'a-tól a chaten belül azonnal visszautasítottak, mert mint az Autolayout és a teljesítmény - a dolgok, ha nem a különböző galaxisokból, akkor legalábbis egymás nem tud egymásról.
Mindez arra utal, hogy az üzenetarchitektúrát különös gonddal kell megtervezni.
A tartalom a képernyő egy bizonyos széléhez közelebb kerül, attól függően, hogy milyen típusú "saját-valaki más" üzenet. A magasság a sabloncellával történik, a fenti konfigurációtól függően. Itt kiszámolják a sejtek közötti távolságot. A CollectionViewLayout-ban nulla, a távolság egyszerűen hozzáadódik a cella magasságához, így a logikát nem hordja az objektumok körül.
A technikai összetettség az oldal betöltésében nyilvánult meg. Egy tucat üzenetet töltöttek fél másodpercre az iPhone 6-on - ez egy nagyon gyenge eredmény. Valójában semmi meglepő: a sejtek nehézek, és az egész folyamat létrehozása és feltöltése a cellForRow-ban történt. Ettől kezdve a Main-szál katasztrofálisan szenvedett. Elég gyorsan eljött az a gondolat, hogy a tartalom tartalmát közvetlenül a Háttérfonalban lévő üzenetek fogadása után hozzuk létre. Egyesek azt mondják, hogy lehetetlen, és igazuk lesz. UILabel a háttérben létrehozni és nem működött, az alkalmazás csak összeomlik. A fennmaradó UIView-primitívek csendben lehetővé teszik, hogy létrehozzanak magatokat a háttérben, és különösen az UIView osztályt hozhatjuk létre a hivatalos dokumentáció hátterében.
A gyakorlat azt mutatja, hogy az objektumok keretei is beállíthatók a háttérből. Ez elegendő volt ahhoz, hogy egy cellát létrehozzunk egy üzenettel, és a háttérben a cellaméret kiszámításának logikáját értelmezzük. Érdemes megjegyezni azt is, hogy az összes bemutató áthelyezése a cellába az isDisplayCell-ben, jelentősen növeltük a terhelés simaságát. Ebben az eljárásban, akkor ad egyértelmű tartalommal Vyuha hogy végül bekerült a Main-patak, így beállíthatja a piacok (create UILabel'y) és helyettesítő azok tartalmát. Valójában, közvetlenül az üzenet átvétele után, a cellaméret a háttérben van kialakítva, majd ennek a méretnek a generációja és a megjelenítés előtti legutolsó pillanatban az összes tartalmának megjelenése:
A celláknak minimális átláthatósággal kell rendelkezniük. A hardvereszközök számára nehéz a vegyes rétegek megemésztése, ezért az áttetsző vizek a termelékenység súrlódása, és minden összetett komponensnek szabadulnia kell. A látószögek lekerekítése még áttetszővé teszi őket. Az egyértelműség érdekében koppintson a színkevert rétegekre az eszközszimulátorban, és vörösre húzza őket. Semmi sincs, amit legalább rövid idő alatt el lehet gondolni.
A megközelítés egyetlen hátránya a tartalommal kapcsolatos hivatkozások tárolása.
A létrehozás után a nézetet soha nem osztották le, kivéve, ha elhagyta a képernyőt. Ez a döntés tudatosan történt. Ez megóvott minket a teljesítményproblémáktól. Ritay Vyuh megengedte, hogy kiszámítsa a méretét, és csak egyszer és a háttérben készítse el őket. A memóriában ez szinte nem befolyásolta, a fő elv nem húzza el a mögöttes képeket. Az UIImageView képmezőjének szükségszerűen vissza kell állítania a didEndDisplayingCell-re, és csak értékre veszi, ha a cellát újra feltérképezi.
Voila, és minden rendben van! Ez vicc. Finoman a Telegramban. De a mi feltételek, nagyon jó teljesítményt. Még egy minimálisan támogatott eszközön is a terhelés alig észrevehető, és a modern eszközökön egyáltalán nem látható. Az üzenettípusok további kiegészítése nem befolyásolta a terhelés teljesítményét.
És semmi sem mutatott bajot, amikor hirtelen megtört a CollectionViewLayout. Nos, tudja, hogy ez általában történik: eltévedt tartalom ágy, a sejtek láthatatlanná válik, stb, és nem reloadData () ebben az esetben nem segít ... és ez az eltört \ _ _ /? (?). Ez egy határozatlan időpontban történt, amikor csevegést görgetett. Megpróbáltuk megváltoztatni a beiktatása egyedülálló sejtek teljes újraindítás gyűjtemény, megszabadulni a RxDataSources, elhalasztja létrehozását ötletek a fő stream - mindhiába. Nagyszámú fióktelep után történt, ezért nem tudták pontosan, hogy mi okozta a szünetet. Az ügy kíváncsi volt, és az igazsághoz akartam jutni. Az ügyfél a szerelést akarta.
"TableView, haver, annyira hiányoztunk ... ... árulóként?"
Néhány órával a gyűjtemény előtt teljesen lecserélték a táblát. Nem volt abszolút bizonyosság, hogy ez megoldja a problémát. De a TableView tökéletesen működött. Úgy tűnt, még egy kicsit gyorsabban dolgozott, mint a kollekció. A betétcellák animációja azonban sok kívánnivalót hagy maga után. A csevegésben egyáltalán nem tűnik elfogadhatónak, ezért úgy döntöttek, hogy frissítik a listát a reloadData () segítségével. És a CollectionView meghibásodása továbbra is rejtély maradt: az UIKit egyik legnehezebb eleme, és a hétvégén nem lehetett megérteni. A lényeg az, hogy a feladat befejeződött - a csevegési adatbázis a megfelelő szinten valósul meg.
A teljesítmény egy mély és érdekes téma. De nem az egyetlen, akivel találkoztunk. Volt néhány kíváncsi árnyalat. Ugyanaz a forradalom az asztalnál.
Mint mindenki tudja, a csevegőüzenetek alulról indulnak, és a gyűjtemények és táblák nem rendelkeznek megfelelő funkcióval a cellák ilyen megjelenítéséhez. Itt használtuk a CGAffineTransform-ot: az asztalt fejjel lefelé fordítottuk, és a cellákat újra megfordítottuk - minden tökéletes, minden lehetséges hiba és teljesítményprobléma nélkül.
A dátumot megnyomó szöveget úgy hajtották végre, hogy az üzenet szövegével nem törődő szóközöket adtak hozzá, ami kissé hosszabb, mint a címke hossza a dátummal. Ha a rések egyre szélén üzenetek - így az eredeti szöveg a dátum és ebben az esetben a szöveg a következő sorban növelésével a magassága a sejt, amely viszont, húzta meg a címkén a dátumot. Ezzel a chipgel az üzenetek sokkal kompaktabbak:
Érdemes megemlíteni néhány szót az AutoresizeMaskról. Néhányan alábecsülik annak fontosságát, és az elrendezés elkészítésekor hasznos megérteni, hogyan működik ez a technológia. Esetünkben olyan sejtek voltak, amelyeket az esemény lefeszített és tömörített. És annak érdekében, hogy minden alkalommal ne helyreállítsák a keretet, a maszkok úgy lettek beállítva, hogy a nézetek méretüket a szüleik méretének megfelelően módosították. Egyetlen állítás és egy kódsor, tiszta varázslat nélkül. Az alábbiakban egy példát a felhasználásra: kezdetben egy sejt, akkor növelje a magasságát (a tartalom használata nélkül maszkok és maradna ebben a helyzetben), majd a jobb alsó sarokban, húzta fel a dátumot, és a többi tartalom megnyúlik:
A következő árnyalat: ha a billentyűzet úgy tűnik, hogy képes lesz látni az alá eső üzeneteket, az alábbi táblázat alacsonyabb beillesztést mutatott. Azt is ki vannak téve a felső, ha lebegett hal hiányában az internet, és az alsó, ha a mező adja meg az üzenet változik a magassága, minden, ami nem számítva a tetején és alján INSET alapértelmezés szerint. Abból, hogy kivonjuk és hozzáadjuk az egyes helyeket, a szükséges konstans meglehetősen törékeny megoldás, és megszakad, ha legalább egy módszert hívunk újra. Megoldásként egy csomagot írtak az UITableView számára, amely minden okból tartalmazott egy sor struktúrát, amelyek beillesztéssel vannak ellátva. Az okok leírása a felsorolásban szerepelt, és minden alkalommal, amikor a tömb megváltozott, minden behúzást hozzáadtak és hozzárendeltek az asztalhoz. Így lehetővé vált az egyes beágyazások kezelése anélkül, hogy megtörnék a többieket. Érdemes megemlíteni: az esetünkben szereplő összes behúzást a korábban alkalmazott átalakítások miatt fejjel lefelé fordítottuk az asztalra, így a felső beesés alacsonyabb volt, és fordítva.
A fejlődésben furcsa pillanatok és felfedezések elégek, nem emlékszenek. Ismét be tudsz fektetni egy végtelen számú órát, így az alkalmazás még sima, gyors és rugalmas. De ez a vizuális rész mellett az első lépés, amely a chat sikeres végrehajtásához szükséges minimum. A következő lépés a felhasználás tapasztalatának egyedisége. Mi a messze, menjünk a natív iMessage iOS messengerre. A válaszadóképesség mellett a messenger sok "divatos zsetonnal" rendelkezik, amelyek legtöbbje egyszerűen sehol nem található meg. A kommunikációhoz nem annyira fontosak, de ha a beszélgetést különálló egységnek tekintjük, akkor az ilyen "zsetonok" tulajdonosa tökéletesebbnek és a többiek hátterének megfelelően fejlődik. Az ilyen jellegzetességek végrehajtásának fázisa ritka esetekben az alkalmazás első változatának tulajdonítható. Ezért, miután kiadta a csevegés első verzióját, reméljük, hogy a jövőben folytatjuk a munkát és kitöltjük a csevegést egyedi funkciókkal.
Segíthet és pénzt küldhet a fejlesztéshez