Libraries are wri4en in C/C++ and compiled for the par>cular hardware.

Transcription

1 marakana.com 1

2 marakana.com 2

3 marakana.com 3

4 marakana.com 4

5 Libraries are wri4en in C/C++ and compiled for the par>cular hardware. marakana.com 5

6 The Dalvik virtual machine is a major piece of Google's Android plaiorm for mobile devices. It runs Java plaiorm applica>ons which have been converted into a compact Dalvik Executable (.dex) format suitable for systems that are constrained in terms of memory and processor speed. It was wri4en by Dan Bornstein, who named it aser the fishing village of Dalvík in EyjaVörður, Iceland, where some of his ancestors lived. Unlike most virtual machines and true Java VMs which are stack machines, the Dalvik VM is a register based architecture. Like the CISC vs. RISC debate, the rela>ve merits of these two approaches is a subject of con>nuous argument but the underlying technology some>mes blurs the ideological boundaries. Moreover, the rela>ve advantages of the two approaches depend on the interpreta>on/compila>on strategy chosen. Generally, however, stack based machines must use instruc>ons to load data on the stack and manipulate that data and thus require more instruc>ons than register machines to implement the same high level code. However, the instruc>ons in a register machine must encode the source and des>na>on registers and therefore tend to be larger. This difference is primarily of importance to VM interpreters for whom opcode dispatch tends to be expensive and other factors are relevant for JIT compila>on. A tool called dx is used to convert Java.class files into the.dex format. Mul>ple classes are included in a single.dex file. Duplicate strings and other constants used in mul>ple class files are included only once in the.dex output to conserve space. Java bytecode is also converted into an alternate instruc>on set used by the Dalvik VM. An uncompressed.dex file is typically a few percent smaller in size than a compressed.jar (Java Archive) derived from the same.class files. The Dalvik executables may be modified again when they get installed onto a mobile device. In order to gain further op>miza>ons, byte order may be swapped in certain data, simple data structures and func>ons libraries may be linked inline, and empty class objects may be short circuited, for example. Being op>mized for low memory requirements, Dalvik has some specific characteris>cs that differen>ate it from other standard VMs[3]: * The VM was slimmed down to use less space. * Dalvik has no Just in >me compiler * The constant pool has been modified to use only 32 bit indexes to simplify the interpreter. * It uses its own bytecode, not Java bytecode. marakana.com 6

7 marakana.com 7

8 marakana.com 8

9 marakana.com 9

10 marakana.com 10

11 marakana.com 11

12 marakana.com 12

13 marakana.com 13

14 marakana.com 14

15 marakana.com 15

16 marakana.com 16

17 marakana.com 17

18 An ac>vity has essen>ally three states: * It is ac>ve or running when it is in the foreground of the screen (at the top of the ac>vity stack for the current task). This is the ac>vity that is the focus for the user's ac>ons. * It is paused if it has lost focus but is s>ll visible to the user. That is, another ac>vity lies on top of it and that ac>vity either is transparent or doesn't cover the full screen, so some of the paused ac>vity can show through. A paused ac>vity is completely alive (it maintains all state and member informa>on and remains a4ached to the window manager), but can be killed by the system in extreme low memory situa>ons. * It is stopped if it is completely obscured by another ac>vity. It s>ll retains all state and member informa>on. However, it is no longer visible to the user so its window is hidden and it will osen be killed by the system when memory is needed elsewhere. marakana.com 18

19 oncreate() Called when the ac>vity is first created. onrestart() Called aser the ac>vity has been stopped, just prior to it being started again. onstart() Called just before the ac>vity becomes visible to the user. onresume() Called just before the ac>vity starts interac>ng with the user. onpause() Called when the system is about to start resuming another ac>vity. onstop() Called when the ac>vity is no longer visible to the user. ondestroy() Called before the ac>vity is destroyed. marakana.com 19

20 Resources are an integral part of an Android applica>on. In general, these are external elements that you want to include and reference within your applica>on, like images, audio, video, text strings, layouts, themes, etc. Every Android applica>on contains a directory for resources (res/) and a directory for assets (assets/). Assets are used less osen, because their applica>ons are far fewer. You only need to save data as an asset when you need to read the raw bites. The directories for resources and assets both reside at the top of your project directory, alongside your source code directory (src/). The difference between "resources" and "assets" isn't much on the surface, but in general, you'll use resources to store your external content much more osen than you'll use assets. The real difference is that anything placed in the resources directory will be easily accessible from your applica>on from the R class, which is compiled by Android. Whereas, anything placed in the assets directory will maintain its raw file format and, in order to read it, you must use the AssetManager to read the file as a stream of bytes. So keeping files and data in resources (res/) makes them easily accessible. Example class: package com.android.samples; public final class R { public sta>c final class string { public sta>c final int gree>ng=0x e; public sta>c final int start_bu4on_text=0x ; public sta>c final int submit_bu4on_text=0x ; public sta>c final int main_screen_>tle=0x a; }; public sta>c final class layout { public sta>c final int start_screen=0x ; public sta>c final int new_user_pane=0x ; public sta>c final int select_user_list=0x ; }; public sta>c final class drawable { public sta>c final int company_logo=0x ; public sta>c final int smiling_cat=0x ; public sta>c final int yellow_fade_background=0x ; public sta>c final int stretch_bu4on_1=0x ; }; }; marakana.com 20

21 marakana.com 21

22 marakana.com 22

23 Android is a mul> process system, in which each applica>on (and parts of the system) runs in its own process. Most security between applica>ons and the system is enforced at the process level through standard Linux facili>es, such as user and group IDs that are assigned to applica>ons. Addi>onal finer grained security features are provided through a "permission" mechanism that enforces restric>ons on the specific opera>ons that a par>cular process can perform, and per URI permissions for gran>ng ad hoc access to specific pieces of data. Example of seung permissions in AndroidManifest.xml: <manifest xmlns:android="h4p://schemas.android.com/apk/res/android" package="com.android.app.myapp" > <uses permission android:name="android.permission.receive_sms" /> </manifest> marakana.com 23

24 marakana.com 24