Mòdul 1: Arquitectura i Models d'Execució Mòbil
Fonaments de hardware, software i seguretat dels dispositius mòbils moderns.
Fonaments del Hardware: L'arquitectura ARM
A diferència dels PC d'escriptori, que busquen el rendiment màxim, els dispositius mòbils prioritzen l'autonomia de bateria. Això imposa una filosofia de disseny radicalment diferent a nivell de processador.
ARM (Advanced RISC Machine)
Dissenyada sota el paradigma RISC (Reduced Instruction Set Computer). Utilitza un conjunt d'instruccions simplificat per minimitzar el nombre de transistors i, per tant, el consum d'energia i l'escalfament.
Usos principals: Smartphones, tauletes, IoT, ordinadors de placa única (Raspberry Pi).
Intel / AMD (CISC)
Els processadors de PC (Complex Instruction Set Computer) utilitzen arquitectures més pesades que prioritzen la potència de càlcul, però requereixen una alimentació constant i sistemes de refrigeració actius (ventiladors).
Usos principals: Servidors, ordinadors personals, estacions de treball.
La Convergència: ARM al PC
Fins i tot el mercat de portàtils està girant cap a ARM (com la gamma M d'Apple) per aconseguir ordinadors més silenciosos i amb bateries de llarga durada.
Conclusió: ARM ja no és exclusiu del mòbil; és el futur de l'eficiència energètica a totes les escales.
📁 Nom de la imatge suggerida: images/teoriaM03U4/arm-vs-cisc-diagram.png —
Diagrama comparatiu de les arquitectures RISC i CISC, ressaltant consum i velocitat.
El Model d'Execució en Sistemes Mòbils
L'execució d'aplicacions en un smartphone difereix de la d'un PC en tres aspectes clau que condicionen tant el disseny com la seguretat de les apps:
🧠 RAM Limitada
Tot i que ha crescut, la RAM d'un mòbil és un recurs escàs que el sistema operatiu gestiona de forma agressiva, podent matar processos en segon pla sense avís.
🔋 Gestió d'Energia
El sistema atura o destrueix aplicacions en segon pla per evitar que la bateria s'esgoti. Els serveis han d'usar mecanismes especials (WorkManager, Background App Refresh).
📲 Pantalla Única
L'usuari sol interactuar amb una sola aplicació alhora. Simplifica el focus però complica la multitasca i el flux de dades entre apps.
🔄 El Cicle de Vida de l'Activity (Android)
En Android, les "pantalles" s'anomenen Activities. Per optimitzar recursos, el sistema les mou per diferents estats:
Running
L'usuari la té en pantalla i hi interactua. S'inicia amb onCreate(). És
l'estat de màxima prioritat.
Paused
L'Activity és parcialment visible (ex: un avís a sobre) però no té el focus. Es crida
onPause().
Stopped
L'Activity ja no és visible. Es manté en memòria però és candidata a ser eliminada si
el sistema necessita RAM. Es crida onStop().
Destroyed
L'aplicació es tanca i s'allibera la RAM amb onDestroy(). El
desenvolupador ha de guardar l'estat prèviament.
Risc de seguretat/usabilitat: Pèrdua d'estat
Si el sistema destrueix una Activity per falta de RAM, el desenvolupador ha d'usar
onSaveInstanceState() per guardar les dades de l'usuari, o aquestes es
perdran en tornar a obrir l'app. Dades sensibles mai s'han de guardar en text pla en
l'estat de la instància.
Diagrama de flux oficial entre els estats (Running, Paused, Stopped, Destroyed) i els mètodes que els connecten.
Compilació i Execució: Del Codi Font al Codi Màquina
El processador (CPU) només entén codi màquina (instruccions de baix nivell en binari). Hi ha tres estratègies principals per arribar-hi:
Compilats (C / C++)
Es tradueixen directament a codi màquina per a una arquitectura específica (ex: ARM). Són els més ràpids però menys portables: cal recompilar per a cada plataforma.
Interpretats (Python, JavaScript)
Un intèrpret llegeix el codi font "al vol" durant l'execució. Són més lents però molt flexibles i fàcils de portar entre plataformes.
Màquina Virtual (Java, Kotlin, C#)
Es compilen a un estadi intermedi nombrat Bytecode, que s'executa sobre una màquina virtual. La VM traduit el bytecode a codi màquina natiu en temps d'execució.
Diagrama del flux: Codi font ➔ Compilador ➔ Arxiu Objecte ➔ Linker ➔ Executable.
☕ El cas de Java i la JVM / ART
🤖 Java Virtual Machine i Android Runtime
Java no es compila per a ARM o Intel, sinó per a la Java Virtual Machine (JVM). Això permet que el mateix codi funcioni en qualsevol dispositiu que tingui instal·lada la màquina virtual.
- JVM estàndard: Usada en escriptori i servidors (OpenJDK).
- ART (Android Runtime): La màquina virtual optimitzada d'Android. Compila el bytecode a codi nadiu ahead of time (AOT) en instal·lar l'app, fent-la més ràpida.
- Dalvik (llegat): L'antiga VM d'Android, substituïda per ART a partir d'Android 5.0 Lollipop.
📁 Nom de la imatge suggerida: images/teoriaM03U4/jvm-art-bytecode.png — Diagrama
que mostra com el bytecode Java corre sobre Intel/ARM gràcies a la JVM o l'ART.
Llenguatges de Desenvolupament i Seguretat de Memòria
L'elecció del llenguatge de programació té un impacte directe en la seguretat de l'aplicació, especialment en com es gestiona la memòria RAM.
🤖 Ecosistema Android
- Kotlin (Recomanat): Més modern i segur. Redueix la "verbositat" de Java i evita errors comuns com els NullPointerException.
- Java (Referent): El llenguatge clàssic d'Android, encara molt usat.
- C/C++ (NDK): S'usa per a jocs o aplicació sque requereixen el màxim
rendiment.
Risc: No té Garbage Collector, el que pot provocar memory leaks i forats de seguretat si el desenvolupador no gestiona bé la RAM.
🍎 Ecosistema iOS
- Swift (Recomanat): Llenguatge modern i "fortament tipat". Introduït per Apple per substituir Objective-C i fer el desenvolupament més segur.
- Objective-C (Llegat): Basat en C, sense recol·lector de memòria fins a versions recents que van introduir l'ARC (Automatic Reference Counting). Encara present en codebases antigues.
Garbage Collector vs. ARC vs. Manual
GC (Java/Kotlin): El runtime detecta i allibera memòria no usada automàticament. Còmode però pot generar pauses (GC pauses). ARC (Swift/ObjC): Compta les referències en temps de compilació; és determinista i eficient. Manual (C/C++): El programador gestiona tot: màxima eficiència però màxim risc d'errors (use-after-free, buffer overflow).
Solucions Multiplataforma: Nadiu vs. Web
Moltes empreses prefereixen desenvolupar un cop per a Android i iOS alhora, assumint certes concessions de rendiment o accés natiu al hardware:
React Native (Meta)
Codi en JavaScript que es compila per funcionar sobre components natius de cada plataforma. Ofereix bon rendiment i accés a la majoria de funcions del dispositiu.
Ús ideal: Apps socials, e-commerce, dashboards.
Flutter (Google)
Usa el llenguatge Dart i dibuixa la seva pròpia UI (no usa components natius). Resultat visualment consistent en totes les plataformes.
Ús ideal: Apps amb disseny personalitzat, fintech, productes SaaS.
Apache Cordova (PhoneGap)
L'aplicació és en realitat una web (HTML/JS) que s'executa dins d'un WebView (un navegador incrustat). Sembla una app nadiua però té el rendiment d'una web.
Ús ideal: Apps simples, prototips ràpids, migració de webs.
📁 Nom de la imatge suggerida: images/teoriaM03U4/cordova-architecture.png —
Diagrama que mostra com l'app web es comunica amb el SO mòbil a través de Plugins i un WebView.
| Framework | Llenguatge | Rendiment | Accés Natiu |
|---|---|---|---|
| React Native | JavaScript / TypeScript | Alt | Sí (via bridge) |
| Flutter | Dart | Molt alt | Sí (via channels) |
| Cordova | HTML / JS / CSS | Baix-Mig | Limitat (plugins) |