Presentation Credits (thanks to): Santiago Agüero

Transcripción

1 Presentation Credits (thanks to): Santiago Agüero 1

2 2

3 SoC Z2460 -> 1x2 1.6 GHz HyperThreading Since start of the year when we teamed Google we have collaborated several SP ers and OEM and delivered 6 Intel phones based on the Medfield Z2460 reference platform into the market. This is just the start! Lava Launched the Xolo X900 on May 21 st in stores across India Lenovo Launched the K800 on May 30 th in China Orange Launches the San Diego Phone on June 6 th in the UK Orange launches the Orange avec Intel Inside phone on June 7 th in France Motorola has stated they are hoping to launch a Medfield based program in 2012 Additional customers will be announced throughout 2012 Intel is committed to this business and intends to offer a full portfolio going forward REF: Atom Z2460 (platformmedfield) Atom Z2480 (platformmedfield) Atom Z2420 (Lexington) Atom Z2760 (Cloverview platform Clover Trail) 3

4 Atom Z2520 (Clover Trail+) Atom Z2560 (Clover Trail+) Atom Z2580 (Clover Trail+) (Bay Trail) Comming soon Q GHz Quad-core!! 3

5 4

6 5

7 Merrifield-officially-unveiled 6

8 7

9 Embedded OS based on the Linux kernel for core system services, but it is not embedded Linux. Standard Linux utilities such as X Windows and GNU C libraries are not supported. Android applications are written using the Java framework, but Android is not Java. Standard Java libraries such as Swing are not supported. Libraries such as Timer are not preferred and they have been replaced by Android s own libraries, which are optimized for usage in a resource-constrained, embedded environment. The Android OS is open source, but devices do contain some proprietary software that is inaccessible to developers GPS navigation. 8

10 Framework API contains: Core set of packages and classes, set of XML elements and attributes for Manifest and resources, Intents and permissions 9

11 10

12 Activity Lifecycle Managed by Activity Manager: responsible for creating, destroying, and managing activities and improves the speed of the user interface creates once, reuse many times as possible As a developer, manage the response to the application state by overriding lifecycle callback s methods 11

13 Not UI component It can be configured to run on the foreground to avoid the system to kill it Service Lifecycle Services don t spawn its own thread Should implement operations in threads to avoid ANR 12

14 13

15 14

16 15

17 16

18 17

19 18

20 Dalvik Dalvik es la maquina virtual que traduce vm bytecode en instrucciones especificas de la plataforma en la que corre. Una VM es una abstraccion comun a traves de las distintas plataformas de hardware. Dalvik esta optimizada para Intel x86 platform. Apps que dependen del SDK de Android/dalvik bytecode automaticamente se benefician de las optimizaciones especificas para la plataforma, como SSE. Dx tool: Dalvik reduce la redundancia de variables. Dalvik es el runtime encagado de ejecutar las aplicaciones. Esta optimizada para dispositivos de poco recursos de hardware. Optimizacion del rendimiento, consumo de energia y mayor performance. Ejecución de múltiples instancias de DVM. Una instancia de DVM por cada aplicación que se inicializa. ART Nuevo runtime disponible para Android 4.4 de forma experimental. AOT: Ahead-of-Time compiler para procesar instrucciones de la aplicacion previo a que se necesiten 19

21 Este tipo de aplicaciones, si bien se empaquetan en un APK como las dalviks Apps, utilizan librerias nativas compiladas en binarios. Las librerias nativas luego del proceso de compilacion se encuentran en libs/cpu_abi, donde CPU_ABI depende de la arquitectura de la plataforma a compilar, que puede ser arm, mips y x86. Una NDK app esta constituida por java bytecode (.class resultados de la compilacion), dex files como resultado de la compression y pre procesado del bytecode a dalvik, los recursos de la app como imagenes y xml files y las librerias nativas linkeadas dinamicamente junto a jni files como bridge de comunicacion. Las aplicaciones NDK pueden contruirse y depender completamente en funciones nativas de las librerias dinamicas compiladas o bien, realizer algunas llamadas a funciones nativas y tener codigo hibrido entre java y c/c++. Esto quiere decir que pueden ser generadas desde codigo nativo de la aplicacion, game engines o librerias requeridas por librerias de terceros. Una de las principals ventajas de poder escribir codigo nativo en aplicaciones para Android es que permite accede a funciones de la plataforma en particular con el objetivo de mejorar la performance, entre otros. Es importante tener en cuenta, es que no existen aplicaciones 100% nativas en Android. No haber escrito codigo en java para desarrollar una aplicacion en Android, y si en c/c++ solamente no implica que la app sea 100% native. Las apps de android corren en el contexto e instancia de dalvik virtual machine, y el application layer como 20

22 platform layer de android estan construidos en base a la API de Java. Para lograr comunicar codigo java en el context de la virtual machine con funciones y librerias nativas, ya sean las nuestras o frameworks, game engines y sus dependencias, se utiliza Java Native Interface como bridge. No existe una aplicacion 100% nativa: el runtime de Android es Dalvik, y toda aplicacion corre en el contexto de ejecucion de una DVM A traves de codigo nativo c/c++ o assembly se acceden a features particulares de la plataforma. Utilidades: native_app_glue Permite escribir una aplicacion android completamente en codigo nativo y dependiendo de librerias Abstrae callbacks de Activity para developers NativeActivity 20

23 21

24 Optimización es importante! 22

25 Aumento de la performance no está garantizado Puede ser peor Agrega complejidad Intecomunicación entre Java y C/C++ Múltiples plataformas Dificil de debuggear 23

26 24

27 25

28 Dersarrollada por Google Soportada por x86l, ARM y MIPS NetBSD (libc) + FreeBSD (libm) No es compatible con POSIX Thread No soporta System-V IPCs y wchar 26

29 27

30 Tenemos nuestra libreria nativa Código de nuestra app Librería de terceros Configuramos la variable APP_ABI en el makefile ubicado en jni/application.mk APP_ABI:= all APP_ABI:= armeabi armeabi-v7a x86 mips Ejecutar ndk-build NDK genera código optimizado para todos los targets ABIs Ejecutar script ndk-build y especificar la arquitectura target pasandole los targes ABIs como parámetros ndk-build APP_ABI:= x86 28

31 29

32 30

33 31

34 32

35 33

36 34

37 Reutilizar código Extender API de la aplicación implementando funciones nativas, Performance

38 36

39 37

40 38

41 39

42 40

43 - classpath: directorio de los archivos.class - d: directorio donde se guardan los headers generados - nombre completo de la Clase que declara la función nativa 41

44 This is the recommended approach, but not the only approach. Explicit registration is not required, nor is it necessary that you provide a JNI_OnLoad function. You can instead use "discovery" of native methods that are named in a specific way (see the JNI spec for details), though this is less desirable because if a method signature is wrong you won't know about it until the first time the method is actually used. One other note about JNI_OnLoad: any FindClass calls you make from there will happen in the context of the class loader that was used to load the shared library. Normally FindClass uses the loader associated with the method at the top of the interpreted stack, or if there isn't one (because the thread was just attached) it uses the "system" class loader. This makes JNI_OnLoad a convenient place to look up and cache class object references. Proven method: That s how native code is integrated in AOSP itself : You get all the native methods registration issues during the load of the library instead of during further function calls You get rid of functions with a lengthy name that will break when refactoring other parts of the code You can add/remove native functions easily (you don t need to write error prone names by hand or re-run javah and copy/paste parts of it) There is no more potential issue with symbol table (really useful when you want to 42

45 mix C/C++ code) It is also the best spot to cache Java class/objects references 42

46 Es un buen punto para tomar todas las referencias necesarias de objetos como main activity u otras clases y la JavaVM para cachearlas. En este método se aplica el mapping definido previamente. Retornar la version de JVM para el cual fue implementada la lib static JNINativeMethod exposedmethods[] = { {"stringfromjni","()ljava/lang/string;",(void*)stringfromj NI}, } ()Ljava/lang/String; is the JNI signature of the Java * method, you can retrieve it using the javap utility: > javap -s -classpath bin\classes -p com.example.hellojni.hellojni Compiled from "HelloJni.java public native java.lang.string stringfromjni(); Signature: ()Ljava/lang/String; 43

47 43

48 You may be limited to 16 local references within your JNI environment: you can call DeleteLocalRef() when you don t need a local reference anymore. When the execution returns to Java, all local references are freed. 44

49 En C env es un puntero, (*env)-> doble derreferencia al puntero para acceder a los métodos En C++ env es un objeto: «call the method that belongs to the object pointed by env» C y C++ son isomórficos (basicamente) la diferencia es la sintaxis: el primer parametro de una funcion JNI en C es el puntero a env 45

50 46

51 47

52 48

53 49

54 Android framework provides an android.app.nativeactivity.java class to help us create a "native" activity. In a typical Java activity, we extend android.app.activity and overwrite the activity lifecycle methods. NativeActivity is also a subclass of android.app.activity and does similar things. At runtime, NativeActivity will invoke these native callback methods when the corresponding events occurred. In a word, NativeActivity is a wrapper that hides the managed Android 50

55 51

56 Un sólo APK que contiene todas las libs nativas para cada ABI target soportada, la aplicación es filtrada durante el proceso de instalación 52

57 Google Play soporta múltiples APK para la misma aplicación. Se recomienda ordenan el version code de forma tal que el APK para x86 tengo el mayor version code, seguido por ARMv7 y luego ARMv5TE. Los binaries de x86 van a ser los utilizados para dispositivos x86 y ARMv7 para dispositivos ARMv7. Intel sugiere usar un version code de al menos 8 digitos. Integers que representan las confiuraciones soportadas estan con el mayor orden de bits y el version name en el mas bajo orden de bits. For example, when the application version name is 3.1.0, the recommended version code for ARMv7 ABI and an API level 11 APK would be As another example, when the application version name is 3.1.0, version code for X86 and an API level 11 APK would be The first digit indicates the supported ABI, the second and third digits are reserved for the API level, the fourth and fifth digits are for either screen sizes or GL texture formats (not used in these examples), and the last three digits are for the application's version number (3.1.0). Figure 1 shows two examples that are split based solely on the ABI with the same platform version (API Level), screen size, and application version. Es importante recorder que el downgrade no esta soportado, es por eso que tener un versioncode correspondiente y bien armado es muy importante! 53

58 ABI: Application Binary Interface Many devices support multiple ABIs, for example both ARMv7 and ARMv5TE. Many x86 ABI devices can also run ARMv7 and ARMv5TE binaries. Developers should order the version codes so that the binary with best performance runs on each device. For example, order the version codes so that the x86 APK has the highest version code, followed by ARMv7, then ARMv5TE. Thus x86 binaries will be preferred for x86 devices and ARMv7 binaries preferred for ARMv7 devices. By following these guidelines, you can make sure that your users get the best performance out of the device they own. Furthermore, you may avoid users trying to run applications on specific devices due to code translation problems. To make use of this new feature developers must enable Advanced Mode in the Google Play Android Developer Console which will allow Multiple APKs to be active for a single application. For specific instructions and future details regarding Multiple APK support review the Developer Publishing documentation on Google s website. Note: You should generally use multiple APKs to support different device configurations only when your APK is too large (greater than 50MB) due to the alternative resources needed for different device configurations. Using a single APK to support different configurations is always the best practice, because it makes the path for application updates simple and clear for users (and also makes your life simpler by avoiding development and publishing complexity). Conclusión Siguiendo el esquema que propone Google en su documentación, agregamos a este entero un dígito para distinguir ABI de cada device, poniendo el mayor a x86. La razón de incrementar el número es debido a que dispositivos x86 suportan apps ARM, y ARMv7 soporta ARMv5. Sin hacer esto, no permitiriamos una correcta distinción para Google Play a la hora que el usuario baje nuestra aplicación. Esto es necesario para pasar las reglas que google impone en Google Play Developer Console y también para facilitar el upgrade en caso que solo queramos corregir algo de nuestra applicación para un ABI en particular. Este entero representa el Version Code a través del manifest android:versioncode, solo de uso interno. El que ve el usuario final es android:versionname 53

59 Tip: En tu dispositivo Android, usando un terminal, podes ver ABI haciendo getprop ro.product.cpu.abi. (Terminal para Android) List of ARM Devices (5, 6 y 7) 53

60 54

61 55

62 56

63 57

64 Porting de Dalvik Apps Aplicaciones Dalvik corren directamente en dispositivos con procesadores Intel Atom. Si es necesario, los ajustes a realizer son los siguientes: La UI neceista ser ajustada a los dispositivos target que tinene una mayor resolucion como tablets de 1280 * 800 o mas La Alocacion de memoria por default puede no cumplir con los requerimientos de la aplicacion, resultando en la inhabilidad de lanzar la aplicacion, por lo tanto se recomenida aumentar la alocacion de memoria por default para dispositivos de alta resolucion Poner XDK, Cordova, frameworks 58

65 59

66 Resultado del trabajo en conjunto entre Intel y Google para asegurar que aplicaciones nativas funcionan en Intel Atom Powered Devices sin costo y esfuerzo adicional de porting por parte de los desarrolladores Provee una User Experience comparable con el resto de los dispositivos Android existentes

67 Las apps Android desarrolladas con java se ejecutan en la JVM dalvik para el codigo en java y aquellas apps NDK que contienen dependencias o se basan en librerias nativas para la arquitectura ARM se traducen a Atom a traves de BT. El impacto en la performance es minimo para la mayoria de las aplicaciones y esta traduccion utilizando BT es transparente para los usuarios finales e incluso el desarrollador, el cual no tiene que implementar ningun esfuerzo ni costo para compatibilizar su aplicacion ARM para Intel Atom. Si las apps NDK no fueron recompiladas para la plataforma x86, BT tranduce codigo ARM a x86. Lo mismo aplica para apps Dalvik que requiren librerias JNI basadas en ARM. E El proceso de traduccion es optimizado y completamente transparente para los usuarios finales. La combinacion de estos esfuerzos resultan en un 90% de apps de Google Play que funcionan correctamente en x86 sin necesidad de esfuerzos de compilacion/migracion. El 10% de las aplicaciones restantes necesitan configuracion adicional para ser completamente funcionales. Si bien la mayoria de las aplicaciones funcionan utilizando BT, no hay que confundir que es una herramienta y es preferable recompilar la aplicacion para x86 obteniendo una mejora en la performance de un 40% comparado con BT. 61

68 62

69 Migrar apps NDK es más complicado que la migración de una app Dalvik. Como vimos antes, las aplicaciones NDK se pueden divider en tres tipos de acuerdo a las propiedades del codigo nativo con las que fueron desarrolladas: Solamente codigo C/C++ que no esta relacionado al Hardware Dependencia con librerias dinamicas de terceros Incluye codigo assembler que esta fuertemente relacionado a plataformas no Intel Architecture Native code that consists of C/C++ code only that is not related to hardware En el caso de que la App consiste en codigo C/C++ no dependiente de la plataforma, los pasos a realizer son los siguientes: 1 Recompilar el codigo nativo para que la app corra en la plataforma Intel Atom, para lo cual es necesario agregar un nuevo Application Binary Interface al makefile. Abrir el proyecto NDK, buscar el makefile Android.mk y agregar APP_ABI := armeabi armeabi-v7a x86 luego re-buildear el proyecto con la tool ndk-build. Si no existe el makefile Android.mk, re-buildear el proyecto utilizando el commando ndk-build y pasandole como parametros los valores de ABI incluyendo x86, ndk-build APP_ABI="armeabi armeabi-v7a x86 63

70 2 Empaquetar la aplicacion nuevamente con la libreria dinamica generada para soportar x86 If native code uses a third-party dynamic linked library, the shared library must be recompiled into x86 version for the Intel Atom platform. If native code includes assembly code that is highly related to non-ia platforms, code must be rewritten with IA assembly or C/C++. 63

71 64

72 65

73 Las aplicaciones de Android se clasifican en las siguientes categorías de acuerdo al lenguaje de programación utilizado, las APIs consumidas y la dependencia con librerías externas: Aplicaciones Dalvik: se desarrollan en Java y HTML5, acceden a la mayor parte de la API del framework de Android a través del SDK. Puede depender de librerías de terceros en Java y/o HTML5. Estas aplicaciones corren directamente en Dalvik y funcionan sin esfuerzo alguno de porting en la plataforma Android x86 de Intel. Para optimizarlas para x86 se debe analizar y detectar aquellas funcionalidades que son candidatas a ser desarrolladas con APIs nativas C/C++ que puedan tomar ventaja de la performance y migar el código. Aplicaciones NDK: son aquellas aplicaciones desarrolladas con Native Development Kit (NDK) permitiendo acceder a las APIs nativas en C/C++ de Android, comunicando código Java y C/C++ a través de Java Native Interface. Estas aplicaciones no acceden a funciones particulares de la plataforma hardware como ARM o MIPS. Corren en la plataforma x86 con una performance aceptable debido a Intel Binary Translator (A.K.A Houdini). Se recomienda recompilar para x86 con el objetivo de mejorar la performance en la plataforma. Aplicaciones NDK ARM: aplicaciones desarrolladas en C/C++ con instrucciones específicas de la plataforma como ARM. Para que estas aplicaciones sean 66

74 compatibles con x86 es necesario re-escribir aquellas funciones específicas de ARM para Intel Atom. Un ejemplo es migrar de ARM NEON a Intel SSE. Aplicaciones NDK con librerias dinamicas de terceros: Si la libreria dinamica esta compilada para x86, estas aplicaciones funcionan en la plataforma. En caso contrario es necesario recompilar la libreria para x86. Aplicaciones NDK con librerias: En el caso de aplicaciones NDK desarrolladas en base a librerias y framewoks, hay dos alternativas dependiendo de si la librería es open source y con posibilidad de modificarse, o si es de código privativo: Open Source: en este caso, es necesario verificar si la librería tiene binarios para x86, en caso negativo es necesario compilarla para la plataforma Intel Atom e incorporar el binario para x86 al proyecto. Privativo: si la librería no es de código abierto y no es compatible con x86, es necesario migrar a otras librerías alternativas compatibles con la plataforma x86. Para migrar y optimizar la aplicación Android a la plataforma x86 es necesario identificar el tipo de la aplicación de acuerdo a las categorías definidias previamente, y luego: Actualizar Target CPU Agregar Intel Atom como target CPU en el archivo make file Application.mk APP_ABI := armeabi armeabi-v7a x86 ó APP_ABI := all Optimizar Agregar los siguientes flags al compilador GCC: -march=atom -msse4 -mavx -maes Compilar Ejecutar el comando ndk-build en la consola y observar que genera un binario para las arquitecturas definidas y para x86. Empaquetar 66

75 67

76 68

77 LibGDX Generar binarios para x Lib generada para x86 de forma oficial

78 LibGDX Generar binarios para x Lib generada para x86 de forma oficial Project Anarchy by Havok - FREE Cross-Platform Engine and Toolkit for Mobile Game Developers Develop and release titles on ios, Android and Tizen for free. Extendible C++ plugin based architecture Includes Havok s Vision Engine together with Havok s leading Physics, Animation Studio and AI tools Available now GameMaker by YoYo Games - 2D Cross platform game engine with support for ios, Android, HTML5, Mac OS, Windows 8, Ubuntu and Windows Phone 8 70

79 Integrated Development Environment that manages fonts, sounds, game objects, etc. Use GameMaker scripting language to write game logic. Free for Mac and Windows export, license required for Android export. Has native x86 Android support. Examples: ousefree, descent More games: Corona Game Edition - 2D cross platform (ios, Android, Kindle and Nook) engine. Write games in scripting language Lua. Animated sprites, Social API integration, native device features integrated. Also used for application and ebook development. C++ based engine that should easily port to x86 Android devices. Starter license available for free and allows publishing. Additional features available with a paid license. le.com/store/apps/details?id=com.frozengun.freeze Unity 3D 2D/3D cross platform (ios, Android, PC) with full-featured integrated editor. PhysX physics engine, C#, javascript or Boo scripting language, multiplayer and network support, streaming assets, etc. License purchase required for phone publishing, try for free. No Android x86 support in current version. Cocos2D - A port to C++ of the popular iphone Cocos2D engine. Cross platform (Android, iphone, Win32) 2D engine C++ based engine that supports x86 Android devices. Free engine with full source code. Example: jpct-ae- A java 3D engine optimized for Android. Nice set of features including 3DS, OBJ and other file support, skeletal animations, shader support, texture compression, collision detection, various lighting modes, transparency, fog, and more. An all java game engine that supports x86 Android devices. Free for personal and commercial use. Example: Libgdx

80 Cross platform (Windows, Linux, OSX and Android) 2D/3D Android engine. Build, run and iterate on the PC before deploying to phone. C++ and Java based engine that easily ports to x86. Box2d physics, TMX tile map, shaders, 2D particle system, sprite support, camera apis, OBJ and MD5 model loaders. Full source code available for free. C++/Java based engine that with a few minor changes I was able to run on x86 Android devices. PlayN Cross-platform game abstraction library for writing games. Compiles to, Desktop Java, HTML5 Browsers, Android, ios and Flash Include APIs for graphics, assets, Box2d physics, and more Free and open source. Examples: d, More demo and example links: gameplay Open-source cross-platform 3D engine aimed at the indie game developer ecosystem. Supports BlackBerry 10 and PlayBook, Apple ios 5+, Android NDK 2.3+, Microsoft Windows 7, Apple MacOS X, Linux Full featured rendering system, node-based scen graph system, particle system, Bullet physics engine, audio and UI systems, etc. Open sourced under the Apache 2.0 license Adobe AIR Use Action Script and Flash to build 2D/3D cross platform (ios, Android, PC, BlackBerry and TV) apps and games. There are several engines built on top of Flash that provide APIs to build games easily, see a list herehttp:// Hardware accelerated graphics, native extensions, Android Licensing Service support, and more. Adobe authoring tool purchase required. No Android x86 support in current version. Andengine - 2D Android game engine SplitScreen support, network multiplayer apis, live wallpaper support Primarily a Java engine with some C++ that includes x86 native libraries. Full source code available for free. 70

81 tion.bunnyshooter Esenthel Engine - Modern 2D/3D C++ based game engine (Windows, Mac, Android and ios) Available for unlimited trial if used non-commercially Scripting and C++ support, multiple renderers, animation system, physics engine, streaming game engine, GUI, etc. DirectX 9,10,11, OpenGL, OpenGL ES 2.0, PhysX 3, PhysX 2, Bullet physics integration Tools include a world editor, model editor, data browser, code editor and more. One-click cross platform publishing Android native x86 support Linderdaum Engine - Cross platform (Windows, Android) 2D/3D engine Free engine with full source code C++ based engine that supports ARM and x86 Android devices (precompiled x86-libs are also included). ShadingZen - A 2D/3D Engine for Android Open Source (MIT License) with full source code Java based and heavily optimized for mobile, supports multi-core CPUs. Kivy - Open source Python library Cross platform, running on Linux, Windows, MacOSX, Android and IOS. Kivy is 100% free to use, under LGPL 3 licence. Suport for getures, multi-touch, graphics and shaders Marmalade SDK (previously Airplay SDK) - Cross platform (ios, Android, BlackBerry PlayBook OS, bada, Windows Desktop, Mac OS, WindowsPhone 8) 3D C++ game engine. Free to try for 30 days, license purchase required to publish. C++ based engine that should easily port to x86 Android devices. Gideros Studio - 2D cross platform (iphone ipad, Android) game engine. Write Lua code in provided IDE, iterate on PC with simulator. Features include Box2d physics engine, fonts, sprites, tile maps and sensor integration. 70

82 Free version includes Gideros Splash screen, licensed version removes it. App game kit - Cross platform (ios, Windows, MacOS, Android, BlackBerry) A 2D OpenGL based game engine with Box2D. Include support for Sprites, particles, input APIs, sound and music. Looks like it is a C++ based engine that should easily port to x86 Android devices. Write game code in BASIC or has an available upgrade option for writing native C++ code. Free to try, license purchase required to publish. ShiVa3D - Multi-platform 3D game engine, which handles advanced shading systems, physics engine, HUD rendering and the sound library. Cross platform (Windows, Mac OS, Linux, iphone, Android, Palm, Wii, ipad, BlackBerry) Write code in Lua or C++ C++ based engine that should easily port to x86 Android devices. Orx - Orx is an open source, portable, lightweight, plugin-based, data-driven and extremely easy to use 2D-oriented game engine. Cross platform (iphone, ipad, Mac, Windows, Linux, Android) game engine. Camera APIs, animations, sound, sprite rendering and data driven for fast and easy prototyping and development. Free open source. C++ based engine that should easily port to x86 Android devices. Example: DX Studio - 3D game engine with editor. Android limited features now supported. C++ based engine that should easily port to x86 Android devices. Currently offered for free. SIO2 Engine 2D/3D cross platform (ios, Android, bada, WebOS, WIN32 ) game engine. Iterate via simulator on PC Features lua support, exporters for various 3d modeling tools, Bullet physics engine, path finding, sound apis, shader support, animation and networking support. C++ based engine that should easily port to x86 Android devices. Various licenses available for purchase, free to trial. Papaya Social Game Engine

83 Cross platform (ios and Android) 2D engine. Write games in scripting language, includes social APIs, physics, and particle effects. C/C++ based OpenGL engine that should easily port to x86 Android devices. Engine is free to download. moai - Open-source game framework for Android, ios and Chrome (via NaCl). Lua scripting language based development engine that has integrated cloud services available. Engine is open source and free to use, pay for cloud services. Unigine - 3D cross platform (Windows, Linux, Max, PS3, ios, Android) Physics, scripting, etc. Unclear what features are supported for mobile. Evaluation available to companies working on commercial projects. License purchase required. C++ based engine that should easily port to x86 Android devices. Example: Candroidengine - 2D Java engine. Sprites, tile animation, background APIs, etc. Dalvik only engine that should work on all architectures. Full source code available for free. Mages Engine - multiplayer client/server game engine Java engine that should work on all architectures. Full source code available for free. Unreal Development kit - No Android support in UDK. The full license on Unreal Engine needed for Android support. This is the free edition of Unreal Engine 3 that provides access to the 3D game engine. UDK supports ios and Windows only. Free to use UDK for noncommercial and educational use Rokon - 2D engine no longer being updated, suggests the libgdx engine as an alternative. Cuttlefish Engine - Site is no longer working 2D cross platform (Windows Phone, Android, iphone, Windows PC) game 70

84 Project Anarchy is a free mobile game engine for ios, Android (including X-86), and Tizen. It includes Havok s Vision Engine along with Havok Physics, Havok Animation Studio and Havok AI. It has an extensible C++ architecture, optimized mobile rendering, a flexible asset management system, and Lua scripting and debugging. There are also complete game samples included with the SDK along with extensive courseware on the Project Anarchy site that game developers can use to quickly get up to speed with the engine and bring their game ideas to life. Ship for FREE on ios, Android (including X-86) & Tizen Includes Havok Vision Engine together with access to Havok s industry-leading suite of Physics, Animation and AI tools as used in cutting-edge franchises such as The Elder Scrolls, Halo, Assassin s Creed, Uncharted and Skylanders. Extensible C++ plugin-based architecture Comprehensive game samples with full source art and source code Focus on community with forums for support, Q&A, feedback and hands-on training NO commercial restrictions on company size or revenue Upgrades for additional platforms and products, source and support available Includes FMOD, the industry s leading audio tool Some tools included with it: 71

85 vresourceviewer vsceneviewer vfontgenerator Visual Debugger (VDB) Script Debugger (vrsd) Prototyping tools: Remote Input Accelerometer input Touch input LUA access HTML5 GUI on device vfileserve

86 72

87 73

88 74

89 Forced Memory Alignment Debido a la existencia de diferencias entre arquitecturas, plataformas y compiladores, el tamaño de datos de la misma estructura de datos en diferentes plataformas puede ser diferente. Sin el forzado de la alineacion de memoria, pueden existir errorers al momento de cargar aplicaciones debido a tamaños inconsistentes de datos. El siguiente ejemlo explica el tamaño de datos en difernetes estrucutra de datos en diferentes plataformas: La primera imagen representa una Struct con tres variables, mvar1 es un int, por lo que ocupa 4 bytes mvar2 es un long long int el cual ocpua 8 bytes mvar3 es tambien un int y ocupa 4 bytes Cuanto espacio es necesario en la plataforma ARM e Intel Atom? El tama;o de los datos compilados para ARM e Intel Platform por default sin modificar flags de compilacion se muestran en la siguiente figura. ARM automaticamente adopta el doble de alineacion de memoria y ocupa 24 bytes en total mientras que x86 adopta el tama;o que las variables necesitan de acuerdo al tipo de datos, esto es, un total de 16 bytes. Al haber una variable diferente con respect al resto, 8-bytes mvar2, resulta en un layout 75

90 de memoria distinto ya que ARM require 8 bytes de alineamiento para variables de 64 bits. En la mayoria de los casos, esto no genera problemas ya que bulidear para x86 y ARM require un full rebuild. Sin embargo, se puede producer una diferencia en tama;os de datos si la aplicacion serialize clases o estructuras. Por ejemplo, creamos un archivo en una app para ARM y escribe TestScrut al archive. Si mas adelante cargamos datos del archive serializado en ARM en una plataforma x86, el tama;o de la Clase en la ap pes diferente en la del archive. Problemas similares de alineacion de memoria pueden ocurrir durante el trafico de la red cuando se espera un layout de memoria especifico. Para evitar estos problemas y tener compatibilidad entre ARM e Intel Atom, existen dos alternativas. La primera consiste en utilizer el flag -malign-double para el compilador GCC, el cual genera el mismo layout de memoria (alineacion de memoria) en ambas plataformas. La segunda opcion consiste en utilizer attribute ((aligned(8))) para cada variable de 8 bytes de nuestro codigo. Figure 11: Memory allocated when -malign-double flags are added 75

91 La misma instrucción es ejecutada de manera sincronizada por todas las unidades de procesamiento CPUs actuales soportan instrucciones SIMD para mejorar la performance en multimedia Un unidad de control despacha instrucciones a diferentes unidades de procesamiento. Todas reciben la misma instrucción, pero operan sobre conjuntos de datos diferentes 76

92 ARM NEON NEON* is an ARM* technology primarily used in multimedia (smartphones, HDTV, etc) applications. ARM* documents that its 128 bit SIMD engine based technology, which is an ARM* Cortex* A Series extension, has at least 3x performance over ARM* v5 architecture and at least 2x over the follow on, the ARM* v6. The key idea is that registers are chunked together as a vector, where each register in the vector is an element that matches the data type of the other elements. Then, operations are performed in such a way that they are performed across lanes, making the methodology known as Packed SIMD. Modern ARM CPU widely used in mobile devices ( iphone, ipad, Microsoft Surface, Samsung devices and millions of others) have the bit SIMD instruction set (aka NEON or "MPE" Media Processing Engine) defined as part of the ARM Architecture, Version 7 (ARMv7). NEON is used by numerous developers for performance critical tasks via assembler or NEON intrinsics set supported by modern compilers like gcc, rvct and Microsoft. NEON could be found in such famous open source projects as FFMPEG, VP8, OpenCV, etc. For such projects achieving the maximal performance on x86 causes the need to port ARM NEON instructions or intrinsics to Intel SIMD (SSE). Namely tointel SSSE3 for the first generation of Intel Atom CPU based devices and to Intel SSE4 for the second generation launched in However x86 SIMD and NEON instructions sets and therefore intrinsic functions are 77

93 different, there is no one-to-one correspondence between them, so the porting task is not trivial. Or, to be more precise it was not trivial before this post publication. 77

94 Diferencias clave al comparar el código ensamblador NEON y SSE: Capacidades Endian. Intel es compatible solo con el ensamblaje de marcadores littleendian, mientras que ARM es compatible con el orden de marcadores endian grandes "big" o pequeños "little" (ARM acepta ambos, es bi-endian). En los ejemplos de código proporcionados, el código ARM es little-endian similar a Intel. Nota: Es posible que existan algunas implicaciones con el compilador de ARM. Por ejemplo, la compilación para ARM utilizando GCC incluye marcadores mlittle-endian y mbig-endian. Granularidad. En el caso de los ejemplos de código de ensamblaje simple a los que hacemos referencia, compare las instrucciones de ADDPS para SSE (Intel) con VADD.ix para NEON tales como x = 8 ó 16. Observe que este último valor agrega cierta granularidad a los datos que se administrarán como parte del mnemotécnico al que se hace referencia. Nota: Estas diferencias no son todas las que existen. Puede ver otras diferencias entre NEON y SSE De NEON a SSE a nivel de C/C++ Pueden presentarse muchas dificultades de la API durante la migración del código C/C++ y NEON a SSE. Tenga en mente que asumimos que no se utilizará ensamblador inline, que en su lugar se utilizará el código C/C++ verdadero. Las instrucciones NEON también proveen algunas bibliotecas C nativas. Aunque estas instrucciones son código 78

95 C, no pueden ejecutarse en la plataforma Intel Atom y deben volver a escribirse. There are three ways to implement SIMD code. C/C++ language-level intrinsic functions, defined with emmintrin.h. Until now, few open source libraries have used it except for WEBP. If SIMD code is implemented in this way, it s easy to adapt to all hardware platforms. (It becomes interchangeable with NEON code for the ARM platform, for example.) Inline assembler (the most widely used). It doesn t require separate assembly and link steps and is more convenient than a separate assembler. Separate assembler. It has many styles (NASM, TASM, MASM, and so on), and the file extension.s,.asm. (An assembler with the file extension.asm cannot be compiled normally by the Android NDK; you must use the patch that is provided in the earlier section, How to Use Yasm. ) 78

96 79

97 80

98 81

99 Utiliza Intel VT disponible en los procesadores Intel del entorno de desarrollo Emulación acelerada por hardware para AVDs Intel x86 82

100 83

101 84

102 La optimización de la performance es uno de los objetivos que todo developer persigue en el transcurso del desarrollo de su aplicación. En el caso de dispositivos móviles, aún es más importante ya que los recursos son limitados, desde el espacio hasta el tiempo de procesamiento, sumado a restricciones como el cuidado de la batería. Vamos a definir tres categorías de optimización de performance, enfocado en Android: Optimización de la velocidad de ejecución de la App Tamaño del código compilado Bajo consumo de energía Como queremos optimizar aplicaciones que corren en la plataforma Intel Atom, y sabemos que el espacio y costo de almacenamiento no es un problema, no nos vamos a enfocar en el tamaño del codigo por ejemplo, pero si en hacer que nuestras aplicaciones corran mas rapido en la plataforma. 85

103 El objetivo que vamos a perseguir con la optimizacion de la performance es de lograr reducir el tiempo en que se ejecutan determinadas tareas y de forma accurately de acuerdo a lo especificado. Como se logra esto? Se logra ya sea con ajustes estructurales, refactoring de acuerdo al software y al hardware. Algunos resultados son Igual Valor: no hay cambio en la performance de la app Eficacia: luego de realizar los ajustes de performance, se nota un aumento de la velocida dde ejecucion. Combinado: En algunos puntos vemos un aumento de performance y en otro se degrada. Esto nos lleva a pensar, siempre es necesario realizar ajustes de performance? Sabiendo que el intento de aumentar la performance puede llevarnos a degradar el rendimiento de nuestra aplicacion, no es un tema menor y requiere realizar analisis y estudios. Aislar código, analizar features candidatas a optimizar, realizar POCs, probar la integracion, testear en multiples dispositivos y luego integrar esos cambios en la version final. Que implica optimizar? Optimizacion es un tema de horas y días, pero vamos a mencionar algunas cosas importantes. 86

104 En muchos casos optimizar implica seleccionar instrucciones que se ejecuten con mayor rapidez, si la plataforma target soporta paralelismo, como es e lcaso de intel Atom, es bueno tenerlo en mente y aprovechar las features. Esto nos lleva a ver que existen distintas tecnicas y metodos para lograr optimizar la perfomance. Un ejemplo es modificar el codigo asi corre mas rapido. Con este enfoque nos encontramos que existen dos tecnicas, una es optimizacion dependiente de la plataforma y optimizacion independiente de la plataforma. Para la primera, una forma de lograrlo es cambiar instrucciones vectorizadas comunes a instrucciones SSE para intel atom, la cual dpenede de detalles de bajo nivel del procesador permitiendonos sacar el mayor provecho del hardware. No es simple de implementar este tipo de optimizacion en otras arquitecturas, pero mas dificil es aun lograr optimizacion independiente a la plataforma. 86

105 tools de dev - optimizacion manual, librerias de alta performance [codigo fuente] compiler optimization En un escenario ideal el compilador es el que tiene que ser capaz de compilar y optimizar el código que desarrollamos de la forma más eficiente. Pero los compiladores pueden realizar una parte de las optimizaciones ya que otras son bloqueadas por default por el optimization blocker. Entonces vamos a identificar algunos enfoques a partir de cuanto interviene el rol del developer o las tools en el proceso: Optimizacion de la performance realizada automaticamente por el compilador Optimizacion realizada por la asistencia/ayuda de herramientas de desarrollo Optimizacion realizada manualmente por el developer A continuacion vamos a ver estas metodologías o más bien enfoques que pueden seguir los desarrolladores para lograr la performance optimization. Opimización de la performance realizada automaticamente por el compilador Como ya vimos, los compiladores optimizan a partir de opciones que indicamos, que son los flags, tambien extensiones o switches. En android por lo general y por default usamos el GNU C/C++ compiler. Lo vamos a ver a continuacion en un poco mas de detalle. 87

106 Android NDK nos permite utilizar otros compiladores, uno de ellso que vamos a estar vienod es el Intel C/C++ Compiler, que tambien especifica flags para disparar optimización. Este compilador no es gratis, solo lo es a modo de prueba pero es una alternativa más y muy buena. Optimizacion realizada por la asistencia/ayuda de herramientas de desarrollo Este enfoque de optimizacio depende mucho del compilador que estamos usando, por suerte Intel desarrollo una suite de herramientas para optimizar para la plataforma IA. Algunas de estas herramientas son Intel Profiler, Graphics Performance Analayzer, Power Monitoring tool entre otros que en conjunto ayudan y permiten analizar la performance general de la app y detectar areas de optimizacion. Vtune y GPA son partes de los productos de Intel para desarrollo y solo se pueden utilizar en procesadores Intel Atom. Intel Profiler es un chain tool de GNU que puede utilizarse para todos los procesadores. GNU profiler: se utiliza para crear un profile de la app que muestra las zonas areas del programa que son ejecutadas con mas frecuencia y el uso de recursos de computo, como aquellas areas que se utilizan con menor frecuencia. Esta herramienta provee informacion al desarrollador que permite completa el proceso de optimizacion, tomar decision en base a información real y de esa forma evitar en mayour medida degradar la performance en lugar de optimizarla. Un ejemplo interesante de optimizacion guiada por profile (PGO) es la optimizacion del Switch (switch-case). De acuerdo a la ejecucion de la app y la info recolectada, se detecta la frecuencia en la que se ejecutan las instrucciones en cada case, y esots switch case statement son ordenados de forma tal de colocar primero los accedidos con mayor frecuencia, de este modo se disminiuye la cantidad de comparaciones realiazadas. Vtune es capaz de detectar hotspots en el programa, estos son zonas, secciones de codigo que toman mucho tiempo de ejecucion, lo cua lse traduce en mayor potencia de computo. Vtune tiene mayor granuladidad que GNU profiler, por ejemplo podemos ver el codigo assembler. Intel GPA fue desarrollado originalmente para GPUs. Ahora se utiliza para analizar la velocidad de CPU, customizacion, consumo de neergia del dispositivo. Es una guia para el desarrollador para optimizar la app especialmente relacionado a multithreading y consumo de energia. Con la asistencia de herramientas de optimizacion, lo sdesarrollaores no necesitamos inventar y perdernos en el proceso de optimizacion y deteccion de areas a optimizar y 87

107 con eso arriesgar la performance en total de nuestra app. Estas herramientas nos permiten localizar areas que realmente necesitan optimizacion con menor tiempo y esfuerzo. Esto no quiere decir que la optmizacion es mas sencilla, no, simplemente son herramientas que nos sirven como guia y nos dan soporte para detectar areas en menor tiempo y esfuerzo. La optimziacion real la termina haciendo el compilador o el desarrollador manualmente. Otras herramientas utiles para el desarrollador son las librerias de alta perofrance. Por lo general son desarrolladas por fabricantes de hardware y combinan features del procesador de manera eficiente y proveen unc onjuneto de pracitcas comunmente usadas en la plataforma. Un ejemplo es Intel Integrated Performance Primitives, optimizada basado en instrucciones SSE. Es una libreria potente, optimizada para caluclos matematicos, procesamiento de señales, multimedia, graficos, calculos vectoriales, etc. Permite ahorrar energía.s Optimizacion realizada manualmente por el developer Algunas optimizaciones de algoritmos y estructuras de datos no pueden ser realizadas automaticamente por el compilador y deben ser realizadas por el developer. Buenas practicas del developer. Algunos niveles de optimizacion que puede realizar el developer: Source code level optimization: lenguajes de alto nivel. Assembly language level optimization: cuando no es suficiente optimizar a partir de lenguajes de alto nivel, es necesario modificar codigo ensamblador. Compiling instruction-level optimization: Directivas al compilador ocmo pragma o aumentando el grado de paralelismo como en OpenMP. A medida que bajamos el nivel de abstraccion con respecto a la optimizacion se requieren skills mas especificas relacionadas al hardware, la plataforma, etc y tecnicas. En android recomendamos que el nivel de optimizacion que se aplique sea a nivel de codigo fuente. Resumiendo, los tres tipos de optimizaciones (enfoques) se complementan. Antes de comenzar la optmizacion, es necesario analizar e identificar los hotspots candidatos a optimizacion, antes de modificar el código e indicar y setear flags al compilador. 87

108 El compilador de Intel soporta generacion de codigo avanzada que incluye autovectorizacion. Vectorizacion es loop-unrolling con la generacion de instrucciones SIMD ejecutandose en multiples elementos de datos a la vez. El desarrollador puede hacer loop unrolling manualmente e insertar las llamadas a funciones mas apropiadas, pero no es una solucion escalable, ya que no es unafeature que esta soportada por todos los procesadores de intel de la misma forma por lo que implic aun costo de mantenimiento y conocimiento de cada arquitectura de procesadores. Por lo tanto se utiliza auto vectorizacion que simplifica la tarea del developer ya que no tiene que aprender cada set de instrucciones paritculares para cada CPU. La opción vec activa la vectorizacion al nivel de optimizacion por default para procesadores de arquitecta IA32, tanto intel como no intel. Para mejorar la calidad de la vectorizacion es necesario especificar el target del procesador. Para Android smartphones IA, recomendado utilizar xssse3_atom. Intel C/C++ Compiler -O2 o más. Por lo general el compilador aplica vectorizacion generando código óptimo, en otras ocasiones es necesario la guía del developer. Aquí entra en juego la estimación de las dependencias de datos lo más preciso posible. Una de las restricciones de las instrucciones SIMD es que los punteros a memoria no 88

109 pueden superponerse, esto lo indicamos al compilador con el qualifier restrict. 88

110 89

111 90

112 GCC Core GNU compiler es la tool principal del NDK para completer la compilacion de codigo Fuente C/C++. GCC es el standard compiler en linux y puede compilar C, C++, Fortran, etc. Tambien puede hacer cross-compiling. Esta feature es la que usa Android NDK y otras herramientas de desarrollo. GCC cross-compiling es compatible con compilacion native, esto es que commandos y switches localmente compilados pueden ser porteados sin modificar el codigo cross-compilado. Para sistemas basados en intel x86, el compilador Intel C/C++ es una Buena tool com opcion. El codigo compilado con el compilador de intel es mucho major ya que aplica y utiliza las features (tiene en cuenta) de la plataforma x86, la optimzacion del codigo resulta mucho major. Ambos son opciones buenas para compilar codigo NDK. A continuacion, vamos a ver como realizar optimizacion de compilacion de modulos C/C++ para aplicaciones Android. La optimizacion de GCC es controlada a partir de flags de optimizacion (opciones). Alguna de estas opciones son independientes de la plataforma y otras estan asociadas a la plataforma. 91

113 -0 or -01 Level 1 optimization, which is the default level of optimization, uses the -O option. The compiler tries to reduce code size and execution time. For large functions, it needs to spend more compiling time and use a large amount of memory resources for optimizing compiling. When the -O option is not used, the compiler s goal is to reduce the overhead of compiling, so that results can be debugged quickly. In this compilation mode, statements are independent. By inserting a breakpoint interrupt program run between the two statements, a user can reassign variables or modify the program counter to jump to other currently executing statements, so you can precisely control the running process. The user can also get results when they want to debug. In addition, if the - O option is not used, only declared variables of a register can have register allocation. When you specify the -O option, the -fthread-jumps and -fdefer-pop options are turned on. On a machine with a delay slot, the -fdelayed-branch option is turned on. Even for machines that support debugging without a frame pointer, the -fomit-framepointer option is turned on. Some machines may also activate other options. -02 Optimizes even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff. When compared to -O, this option increases compilation time and the performance of the generated code. -03 Optimizes yet more. The option -O3 turns on all optimizations specified by -O2 and also 92

114 turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-afterreload, -ftree-vectorize, -fvect-cost-model, -ftree-partial-pre, and -fipa-cp-clone options. -00 Reduces compilation time and makes debugging produce the expected results. This is the default. An automatic inline function is often used as a function optimization measure. C99 (C language ISO standard developed in 1999) and C++ both support the inline keyword. The inline function is a reflection of thinking of using inline space in exchange for time. The compiler does not compile an inline-described function into a function, but directly expands the code for the function body, thereby eliminating the function call, returning the call ret instruction and the parameter s push instruction execution. 92

115 The compiler automatic vectorization. Use or not use MMX, SSE, SSE2 instructions. For example, -msse represents programming into instruction, and mno-sse means not programmed into the SSE instruction -march is the CPU type of the machine, and -mtune is the CPU type that the compiler wants to optimize (by default it is the same as with -march). The -march option is tight constraint, and -mtune is loose constraint. The -mtune option can provide backward compatibility. Compiler optimization options with -march = i686, -mtune = pentium4 is optimized for the Pentium 4 processor, but can be run on any i686 as well. For -mtune = pentium-mmx compiled procedures, the Pentium 4 processor can be run. -march=cpu-typethis option will generate cpu-type instructions that specify the type of machine. The -mtune = cpu-type option is available only for optimizing code generated for cpu-type. By contrast, -march = cpu-type generates code not run on non-gcc for the specified type of processor, which means that -march = cpu-type implies the -mtune = cpu-typeoption. 93

116 94

117 95

118 96

119 97

120 98

121 99

122 Enable the GPU acceleration in the AVD Manager for your image. The HAXM driver executes most CPU instructions natively through Intel Virtualization Technology in the processor and the GPU acceleration offloads the OpenGL calls to the host GPU. As of SDK release 19, the GPU acceleration is considered experimental by Google. Launch the emulator from the command line to get more verbose output. Use the following command to launch the emulator: emulator-x86 avd <avd name> -partition-size 1024 gpu on verbose A partition size of 1024 allows 1GB of apps to be installed. This is different from the SDCard size option in the AVD manager, which specifies how much storage for storing media files is allotted inside of the emulator. Setting the GPU to on will provide better graphics performance. Make sure the Path environment variable to the GPU emulation libraries is set in Control Panel System Advanced System Settings Environment Variables. You can also set it manually each time a new command prompt is launched. Setting it manually is recommended if you are using multiple SDK installs. The following <sdk install location> typically refers to: "c:\users\<your username>\android-sdk" set PATH=%PATH%;<sdk install location>\tools\lib When installing Intel HAXM, set the driver to use half of the available RAM in the system. For example, if your system has 6GB of installed memory, then use 3GB for the Intel HAXM driver. This allows for a good balance of memory for the HAXM driver as compared to the system memory. 100

123 When creating the image, don t set the Device RAM Size option larger than the amount of RAM allocated to the Intel HAXM driver. In the previous example, the Device RAM Size should not be larger than 3GB since only 3GB were allocated to Intel HAXM. The maximum memory for the Intel HAXM driver that can be chosen for a 32-bit system is 1.6 GB. For a 64-bit system, the maximum is 8GB. 100

124 Enable the GPU acceleration in the AVD Manager for your image. The HAXM driver executes most CPU instructions natively through Intel Virtualization Technology in the processor and the GPU acceleration offloads the OpenGL calls to the host GPU. As of SDK release 19, the GPU acceleration is considered experimental by Google. Launch the emulator from the command line to get more verbose output. Use the following command to launch the emulator: emulator-x86 avd <avd name> -partition-size 1024 gpu on verbose A partition size of 1024 allows 1GB of apps to be installed. This is different from the SDCard size option in the AVD manager, which specifies how much storage for storing media files is allotted inside of the emulator. Setting the GPU to on will provide better graphics performance. Make sure the Path environment variable to the GPU emulation libraries is set in Control Panel System Advanced System Settings Environment Variables. You can also set it manually each time a new command prompt is launched. Setting it manually is recommended if you are using multiple SDK installs. The following <sdk install location> typically refers to: "c:\users\<your username>\android-sdk" set PATH=%PATH%;<sdk install location>\tools\lib When installing Intel HAXM, set the driver to use half of the available RAM in the system. For example, if your system has 6GB of installed memory, then use 3GB for the Intel HAXM driver. This allows for a good balance of memory for the HAXM driver as compared to the system memory. 101

125 When creating the image, don t set the Device RAM Size option larger than the amount of RAM allocated to the Intel HAXM driver. In the previous example, the Device RAM Size should not be larger than 3GB since only 3GB were allocated to Intel HAXM. The maximum memory for the Intel HAXM driver that can be chosen for a 32-bit system is 1.6 GB. For a 64-bit system, the maximum is 8GB. 101

126 102

127 For analyzing games running on Android* OS platforms, Intel GPA offers the following components: Intel GPA System Analyzer: Intel GPA System Analyzer for Android* OS devices is intended for optimizing OpenGL* ES workloads. When connected to an Android* OS device, the Intel GPA System Analyzer provides OpenGL* ES API, CPU, and GPU performance metrics, as well as multiple graphics pipeline state overrides that can help you analyze OpenGL* ES application performance. Intel GPA Frame Analyzer: Intel GPA Frame Analyzer for Android* OS devices allows deep analysis of OpenGL* ES games for Android* OS. Intel GPA Platform Analyzer: This new version of Intel GPA Platform Analyzer becomes the default tool for timeline analysis. The new Intel GPA Platform Analyzer has similar functionality to the original product and includes some additional features. With the new Intel GPA Platform Analyzer you can: Use the new GPU Queue representation to analyze a software queue for GPU engines at each moment of time. Use new VSync markers to see how game rendering is aligned with VSync events. This newly-added feature is useful for profiling latency-critical applications, since you can clearly see if frame is rendered during the VSync interval. Use new CPU context switches to check CPU threads execution over time: see when a thread is active and when it is waiting for a synchronization object. Correlate Intel GPA System Analyzer HUD metrics, which are represented as 103

128 graph charts, with other data. Intel Frame Debugger (Beta): Create and explore frame captures of OpenGL* ES workloads running on Intel Atom-based phones and tablets including art and other assets as well as OpenGL* ES error detection, and more with the latest companion to the Intel GPA tool set. 103

129 104

130 Dispositivo: Lenovo K900 Intel Atom z2580 Arquitectura de CPU Dual-Core 4ghz 4 Cores Board: Covertrail Plus Android GB RAM 105

131 Intel IPP es una librería extensiva de funciones (building blocks) optimizadas para el procesamiento de multimedia y datos Optimized for Performance: Intel IPP software building blocks are highly optimized usingintel Streaming SIMD Extensions (Intel SSE) and Intel Advanced Vector Extensions (Intel AVX) instruction sets so your application will perform faster than what an optimized compiler can produce alone. Intel Engineered to Save You Time: Because Intel has done the engineering on these ready-to-use, royalty-free functions, you ll not only have more time to develop new features for your application, but in the long run you ll also save development, debug and maintenance time while knowing that the code you write today will run optimally on future generations of Intel processors. Thousands of Frequently Used Functions: Intel IPP offers thousands of optimized functions covering frequently used fundamental algorithms including those for creating digital media, enterprise, data, embedded, communications, and scientific / technical applications. 106

132 107

133 108

134 109

135 110

136 What is Intel INDE? The Intel Integrated Native Developer Experience (Intel INDE) is a beta release of Intel's cross-platform development suite to quickly & easily create applications targeting Android* and Windows* devices with native performance, outstanding battery-life, and exposure to unique platform capabilities. INDE provides a complete and consistent set of C++/Java* tools, libraries & samples for environment setup, code creation, compilation, debugging and analysis on Intel architecture-based devices and select capabilities on ARM*-based Android* devices

137 112

138 113

139 114

140 115

141 116

142 117

143 118

144 119