Android. Mis selle platvormi juures ei meeldi? See on tasuta, see on kohandatav, see on kiiresti kasvav ja see pole saadaval mitte ainult telefonis või tahvelarvutis, vaid ka nutikellas, teleris ja autos.

Viimastega Pulgakomm värskendus, Androidi programmeerimine paraneb jätkuvalt. Platvorm on algusest peale üsna palju küpsenud AOSP vabastamise ja seadis kasutaja ootuste riba üsna kõrgeks. Vaata, kui hea uus on Materjal kujundusmuster näeb välja!

Seal on tuhandeid erinevatest seadmetest, erineva ekraanisuuruse, kiibiarhitektuuri, riistvarakonfiguratsioonide ja tarkvaraversioonidega. Kahjuks on segmenteerimine avatuse eest makstav hind ja teie rakendusel võib tuhandeid võimalusi ebaõnnestuda erinevates seadmetes, isegi kui arenenud Android-programmeerija .

Vaatamata sellisele tohutule segmenteerimisele, on suurem osa vigadest tegelikult sisse toodud loogikavigade tõttu. Neid vigu saab hõlpsasti ära hoida, kui meil on põhitõed õiged!

Siin on Androidi programmeerimisõpetus, mis käsitleb kümmet levinumat viga, mida Androidi arendajad teevad.

Üldine viga nr 1: iOS-i arendamine

Minu suureks rõõmuks on see Androidi viga tänapäeval palju vähem levinud (osaliselt seetõttu, et kliendid hakkavad mõistma, et ajad, mil Apple kehtestas kõik disainistandardid, on ammu möödas). Kuid ikkagi näeme aeg-ajalt rakendust, mis on iOS-i kloon.

Ärge saage valesti aru, ma ei ole Androidi programmeerimise evangelist! Austan kõiki platvorme, mis liigutavad mobiilimaailma sammu edasi. Kuid käes on 2014. aasta ja kasutajad on Androidi juba mõnda aega kasutanud ning nad on platvormiga harjunud. IOS-i disainistandardite poole surumine on kohutav strateegia!

Välja arvatud juhul, kui selle rikkumiseks on eriti hea põhjus suunised , ära tee seda. (Google teeb seda kogu aeg, kuid mitte kunagi koopiate abil.)

Siin on mõned selle Androidi vea kõige levinumad näited:

1. Te ei tohiks teha staatilisi vahelehti ja need ei kuulu põhja (ma osutan teie poole Instagram ).
2. Süsteemi teadete ikoonidel ei tohiks olla värvi.
3. Rakenduse ikoone ei tohiks asetada ümardatud ristküliku sisse (välja arvatud juhul, kui see on teie tegelik logo, nt facebook).
4. Pritsmekraanid on üleliigsed peale esialgse seadistuse / sissejuhatuse. Ärge kasutage neid muudel juhtudel.
5. Loenditel ei tohiks olla vaipu.

Need on vaid mõned neist palju teisi väikesed asjad, mis võivad kasutajakogemuse rikkuda.

Levinud viga nr 2: arendamine teie Android-seadme jaoks

Kui te ei loo kioskit / reklaamirakendust ühe tahvelarvuti jaoks, on tõenäoline, et teie Androidi rakendus ei tundu igas seadmes hea. Siin on mõned Androidi programmeerimise näpunäited, mida meeles pidada:

• Tihedusest sõltumatud pikslid (dp) erinevad tavalistest pikslitest (px).
• Ressursid lisatakse mitu korda, et võtta arvesse erinevat tihedust ja suunda.
• 9 plaastriga tõmmatavad on ekraanile sobivaks venitatud.

Võimalikke stsenaariume on sõna otseses mõttes tuhandeid, kuid mõne aja pärast tekib mõte neid kõiki a-ga katta käputäis juhtumeid .

Kas teil pole tuhandeid seadmeid? Pole probleemi. Android-emulaator on füüsiliste seadmete paljundamisel ülihea. Veelgi parem, proovige Genymotion , see on välkkiire ja sisaldab palju erinevaid populaarseid eelseadistatud seadmeid.

Kas olete proovinud ka oma seadet pöörata? Kurat võib lahti minna ...

Üldine viga nr 3: kavatsuste mittekasutamine

Kavatsused on üks Androidi põhikomponentidest. See on viis andmete edastamiseks rakenduse erinevate osade või, veelgi parem, süsteemi erinevate rakenduste vahel.

Oletame, et teil on galeriirakendus, mis saab jagada SMS-i teel mõne pildi allalaadimislingi. Kumb kahest võimalusest tundub loogilisem?

Valik 1:

• Taotlege SEND_SMS-i luba.

  SmsManager
• Sisestage oma kood SMS-ide saatmiseks Intent sendIntent = new Intent(Intent.ACTION_VIEW); sendIntent.setData(Uri.parse('sms:' + telephoneNumber)); sendIntent.putExtra('sms_body', x); startActivity(sendIntent); abil.
• Selgitage oma kasutajatele, miks teie galeriirakendus vajab juurdepääsu teenustele, mis võivad raha maksta, ja miks peavad nad teie rakenduse kasutamiseks selle loa andma.

2. võimalus:

• Käivitage SMS-i kavatsus ja laske SMS-i jaoks loodud rakendusel tööd teha

  AndroidManifest.xml

Kui teil on mingeid kahtlusi, on parim lahendus 2. võimalus!

Seda lähenemist saab rakendada peaaegu kõigele. Sisu jagamine, pildistamine, video salvestamine, kontaktide valimine, sündmuste lisamine, linkide avamine kohalike rakendustega jne.

Kui pole kohandatud rakenduse (nt kaamera, mis kasutab filtreid) tegemiseks head põhjust, kasutage nende stsenaariumide jaoks alati Intentsit. See säästab palju programmeerimisaega ja riba memory_needed_in_bytes = 4 * image_width * image_height; tarbetuid õigusi.

Levinud viga nr 4: fragmentide mittekasutamine

Mõni aeg tagasi Honeycombis tutvustas Android kontseptsiooni killud . Mõelge neist kui eraldi ehitusplokkidest, millel on oma (üsna keerukad) olelustsüklid, mis eksisteerivad tegevuse sees. Need aitavad palju erinevate ekraanide jaoks optimeerimisel, neid saab vanemate tegevus hõlpsasti hallata, neid saab uuesti kasutada, kombineerida ja oma äranägemise järgi paigutada.

Igale rakenduse ekraanile eraldi tegevuse käivitamine on kohutavalt ebaefektiivne, kuna süsteem püüab neid nii kaua mälus hoida. Ühe tapmine ei vabasta teiste kasutatavaid ressursse.

Välja arvatud juhul, kui soovite süveneda Androidi tuuma ja lugeda see artikkel , propageerides fragmentide kasutamist, peaksite fragmente kasutama igal võimalusel. Põhimõtteliselt öeldakse, et killud ja kursorilaadurid sihtotstarve on hea, kuid rakendamine halb.

Üldine viga nr 5: peaniidi blokeerimine

Peamisel lõimel on üks eesmärk: hoida kasutajaliides reageerivana.

Ehkki kaadrisageduse mõõtmise taust, mida meie silmad / aju tajuvad, on keeruline ja mõjutatud paljudest teguritest, on üldreegel, et kõike, mis on alla 24 kaadrit sekundis ja mille viivitus on üle 100 ms, ei peeta sujuvaks.

See tähendab, et kasutaja toimingutel on hilinenud tagasiside ja teie programmeeritud Androidi rakendus lõpetab reageerimise. Kasutaja juhtimise eemaldamine rakenduse üle põhjustab pettumust, pettunud kasutajad kipuvad andma väga negatiivset tagasisidet.

Veelgi hullem, kui peatükk on mõneks ajaks blokeeritud (5 sekundit tegevuste jaoks, 10 ringhäälingu vastuvõtjate jaoks), ANR juhtub.

See oli Android 2.x-s nii tavaline, et uuemate versioonide korral ei lase süsteem teil seda teha võrgukõned peaniidis.

Peamise lõime blokeerimise vältimiseks kasutage alati töötaja / taustaniite: 1. võrgukõnedeks 2. bitikaardi laadimiseks 3. piltide töötlemiseks 4. andmebaasi päringuteks 5. SD lugemiseks / kirjutamiseks

Üldine viga nr 6: ratta uuesti leiutamine

'OK, ma ei kasuta peaniiti. Ma kirjutan oma koodi, mis suhtleb minu serveriga taustalõimes. '

Ei! Palun ärge tehke seda! Võrgukõned, piltide laadimine, juurdepääs andmebaasile, JSON-i sõelumine ja sotsiaalne sisselogimine on teie rakenduses kõige tavalisemad asjad. Mitte ainult teie, kõik seal olevad rakendused. On parem viis. Kas mäletate, kuidas Android on platvormina küpsenud ja kasvanud? Siin on kiire loetelu näidetest:

1. Kasutage gradle ehitussüsteemina.
2. Kasutage Uuendamine / Võrkpall võrgukõnede jaoks.
3. Kasutage Picasso pildi laadimiseks.
4. Kasutage Gson / Jackson JSON-i sõelumiseks.
5. Kasutage ühised rakendused sotsiaalse sisselogimise jaoks.

Kui vajate midagi rakendatut, on tõenäoline, et see on juba kirjutatud, testitud ja laialdaselt kasutusel. Tehke mõned põhiuuringud ja lugege mõnda Androidi programmeerimise õpetused enne oma koodi kirjutamist!

Üldine viga nr 7: edu ei eeldata

Suurepärane. Oleme õppinud, et pikaajaliste ülesannete lahendamiseks on parem viis ja kasutame selleks hästi dokumenteeritud teeke. Kuid kasutaja peab ikkagi ootama. See on paratamatu. Pakette ei saadeta, töödelda ega saada koheselt. Seal on edasi-tagasi viibimine, esineb võrgutõrkeid, pakid kaovad ja unistused hävivad.

Kuid see kõik on mõõdetav. Edukad võrgukõned on palju tõenäolisem kui ebaõnnestunud. Miks siis oodata serveri vastust enne eduka päringu käsitlemist? Lõputult parem on eeldada edu ja hakkama saada ebaõnnestumistega. Seega, kui kasutajale postitus meeldib, suureneb meeldimiste arv kohe ja ebatõenäolisel juhul, kui kõne ebaõnnestub, teavitatakse sellest kasutajat.

Selles kaasaegses maailmas on oodata kohest tagasisidet. Inimestele ei meeldi oodata. Lapsed ei taha istuda klassiruumis ja omandada teadmisi, mille tulevane tasuvus on ebakindel. Rakendused peavad vastama kasutaja psühholoogiale.

Üldine viga nr 8: bittkaartidest aru ei saa

Kasutajad armastavad sisu! Eriti kui sisu on hästi vormindatud ja näeb kena välja. Näiteks kujutised on äärmiselt kena sisu, peamiselt tänu oma omadusele edastada pildi kohta tuhat sõna. Samuti tarbivad nad palju mälu. Palju mälu!

Enne kui pilti ekraanil kuvatakse, tuleb see mällu laadida. Kuna bitikaardid on selleks kõige tavalisem viis, pakume kogu protsessi jaoks Androidi programmeerimisjuhendi:

Oletame, et soovite ekraanil kuvada pildi, mille olete just kaameraga teinud. Selleks vajalik kogu mälu arvutatakse järgmise valemiga: ARGB_8888

Miks 4? Noh, kõige tavalisem / soovitatav bittikaardi konfiguratsioon on RGB_565. See tähendab, et iga joonistatud piksli jaoks peame mälus hoidma alfa-, punase, ahnuse ja sinise kanali jaoks 8 bitti (1 bait), et seda korralikult kuvada. On ka alternatiive, näiteks ARGB_8888 konfiguratsioon, mis nõuab pool mälu kui 4 bytes * 4000 * 3000 = 48 MB, kuid kaotab läbipaistvuse ja värvi täpsuse (lisades võib-olla ka rohelise tooni).

Oletame, et teil on täiesti uus HD-ekraaniga ja 12 MP kaameraga seade. Äsja tehtud pilt on 4000x3000 pikslit suur ja selle kuvamiseks vajalik kogu mälumaht: 4 * 1920 * 1080 = 8.3 MB

48 megabaiti RAM-i ainult ühe pildi jaoks !? See on palju!

Nüüd võtame arvesse ekraani eraldusvõimet. Proovite kuvada 4000x3000 pilti ekraanil, millel on 1920x1080 pikslit, halvimal juhul (pildi kuvamine täisekraanil) ei tohiks eraldada rohkem kui LinearLayout mälu.

Järgige alati Androidi programmeerimisnõuandeid bitikaartide tõhus kuvamine :

1. Mõõda vaade, milles oma pilte näidatakse.
2. Suurendage / kärpige vastavalt suurt pilti.
3. Kuva ainult see, mida saab kuvada.

Levinud viga nr 9: sügava vaate hierarhia kasutamine

Küljendustel on Androidis XML-esitlus. Sisu joonistamiseks tuleb XML-i sõeluda, ekraani mõõta ja vastavalt sellele paigutada kõik elemendid. See on ressursse ja aega nõudev protsess, mida tuleb optimeerida.

Nii on Loendivaade (ja hiljuti ka RecyclerView ) töötab.

Kui paigutus on üks kord paisutatud, kasutab süsteem seda uuesti. Kuid ikkagi peab paigutuse paisutamine mingil hetkel juhtuma.

Oletame, et soovite teha piltidega 3x3 ruudustiku. Üks viis seda teha on vertikaalne LinearLayout sisaldab võrdse kaaluga 3 ImageViews s, millest igaüks sisaldab 3 RelativeLayout võrdse kaaluga.

Mida me selle lähenemisega saame? Hoiatus, et „pesastatud kaalud on jõudlusele kahjulikud”.

Androidi programmeerimismaailmas on ütlus, mille ma just välja mõtlesin: 'Vähese vaevaga saab kogu hierarhiat tasandada' .

Sel juhul GridLayout või LinearLayouts asendab tõhusalt pesastatud minSdkVersion

Üldine viga nr 10: minSdkVersioni seadistamata jätmine 14-le

Noh, see pole viga, kuid see on halb tava.

Android 2.x oli selle platvormi väljatöötamisel tohutu verstapost, kuid mõned asjad tuleks maha jätta. Vanemate seadmete toetamine muudab koodihoolduse keerukamaks ja piirab arendusprotsessi.

Numbrid on selged, kasutajad on edasi liikunud, ei tohiks arendajad maha jääda.

Olen teadlik, et see ei kehti mõnel vanade seadmetega suurtel turgudel (nt India) ja seadistage

kuni 14, tähendab Facebooki rakenduses paar miljonit kasutajat ilma oma lemmik suhtlusvõrgustikuta. Kuid kui alustate värskelt ja proovite oma kasutajatele ilusat kogemust luua, kaaluge mineviku kõrvaldamist. Kasutajatel, kellel pole ressursse või kes tunnevad vajadust oma seadet / operatsioonisüsteemi uuendada, pole motivatsiooni proovida oma Androidi rakenduse kõrgemat versiooni ja lõpuks sellele raha kulutada.

Pakkima

Android on võimas platvorm, mis areneb kiiresti. Võib-olla pole mõistlik eeldada, et kasutajad tempot jätkavad, kuid Androidi arendajatele on see ülioluline.

Veelgi olulisem on teada, et Android pole ainult meie telefonides või tahvelarvutites. See on randmel, elutoas, köögis ja autos. Põhitõdede õigeks saamine on enne laienemise alustamist ülitähtis.