Ha kedden este nézi az All About Androidot a TWiT hálózatán, akkor valószínűleg elkapta ezen a héten az Android három legfontosabb vezetőjével készített interjút. A testületbe Dave Burke, az Android mérnöki alelnöke; Stephanie Saad Cuthbertson, az Android csoporttervezője; és Sameer Samat, az Android és a Google Play termékmenedzsmentjének alelnöke.
A trió áttekintést adott a Google I / O 2017-ről, valamint egy kicsit több összefüggést írt néhány új technológiáról és a főszó során elhangzott bejelentésekről. Például az Android O-ban ezúttal végrehajtott fejlesztések nagy része arra koncentrál, hogy a platform stabil legyen mind a fejlesztők, mind a felhasználók számára. Így magyarázza meg Cuthbertson:
Valójában három alapvető dologra koncentráltunk. Először volt a biztonsági program, amelyről beszéltünk, a Play Protect, amely nagyobb mértékben felfedi sok dolgot, amit már csináltunk. Különösen az a tény, hogy minden csatlakoztatott eszközön minden alkalmazást átvizsgáltunk, hogy káros alkalmazásokat keressünk.
A második változás: A meglehetősen átfogó operációs rendszer-optimalizálás helyett a rendszerindítási idő az egyik legnagyobb, amiről beszéltünk, és ezt azonnal látni fogja.
Optimalizálást végeztünk a futási időben és a fordítókban. Az alkalmazások egyszerűen csak gyorsabban és simábban fognak futni, és ennek oka a változtatások nagy várakozási oka, például az egyidejűleg összegyűjtött szemétgyűjtés. Mindezek a változások… azt jelentik, hogy az Ön alkalmazásai automatikusan gyorsabban futnak.
Az egyik téma különösen rezonáns maradt az interjú során, és ez a Google kísérlete az Android szétesett szoftverfrissítési folyamatának megjavítására. Mielőtt elmagyarázná, hogy miként tervezi javítani a folyamatot, Burke színes anekdotát ajánlott fel, hogy miért tart olyan sokáig, amíg a szoftverfrissítések elérik Önt:
A gondolkodás helyes módja olyan, mint egy csővezeték: Mindezt a kódot felírjuk, majd nyílt forráskódban engedjük el, majd a szilícium-gyártók … elviszik az Android kódot, és sok munkát végeznek a kódon, hogy optimalizálja a szilikonhoz. A mai kihívás az, hogy valójában nemcsak az alacsony szintű kódot, hanem a sok kódot is megváltoztatják. És akkor történik az, hogy azt a kódot átadják az eszközgyártóknak, akik ezután több változtatást végeznek rajta, mert rendelkeznek egy meghatározott kamerarészkel, amelyet használni akarnak, vagy egy GPS-mel, vagy mi nem. Ezután a szállítók tesztelik, majd kikerülnek a felhasználók számára.
Így folytatja a projekt Treble-t. Burke interfészként írja le, amely megkönnyíti az eszközgyártók számára a hardverükhöz kapcsolódó kód bevitelét anélkül, hogy zavarnák az Android meglévő API-ját.
Az interjút teljes egészében - körülbelül 40 perc alatt - megnézheti, hogy megkapja a lapátot, beleértve azt is, hogy miként jött az ötlet a Kotin-támogatás hozzáadásához az Android Studio-ban, és hogy az Android Go hogyan fogja befolyásolni a jelenlegi Android One-programot.
