Forum Programmation.autre Programmation native sous Android ?

Posté par .
Tags : aucun
2
6
avr.
2010
Salut à tous,

Je suis potentiellement intéressé par le développement sous Android, mais pour des applis gourmandes en performances et demandeuses d'accès relativement bas niveau au matériel (type jeux 3D). Or, j'ai eu l'occasion de lire dans ce commentaire http://linuxfr.org/comments/1117720,1.html une remarque plutôt acerbe sur le Native Development Kit d'Android, qui permet comme son nom l'indique de programmer sur un téléphone sous Android sans passer par la machine virtuelle Dalvik comme c'est le cas avec le SDK traditionnel.

Est-ce que quelqu'un peut détailler un émettre des critiques précises du NDK ? Qu'en est-il des performances avec le SDK natif ?

Merci !
  • # Fonctions accessibles.

    Posté par (page perso) . Évalué à 3.

    Avec le NDK, tu n'as accès qu'à une chose "externe", c'est l'opengles.
    Donc toutes les entrées/sorties doivent être gérées dans une glue java.
    Après, doit y avoir moyen de faire une glue plus ou moins universelle, et une fois qu'elle est faite, tout devrait être portable, mais pour l'instant c'est pas génial.
    Celle utilisée par ScummVM vaut le coup d'oeil, mais il manque encore plein de choses, qui sont inutiles pour ScummVM, qui devrait être utile pour la plupart des applis.
  • # Le NDK

    Posté par . Évalué à 5.

    En gros, le NDK offre les APIs suivantes: libc, zlib, logging, OpenGL ES, et un sous-ensemble du C++, plus JNI pour lier le code natif à ton application. Android ne supporte pas les processus natifs, bionic fournit bien les appels fork et exec* mais le noyau tue les processus non lancés par le système Android.
    En comparaison, c'est bien pauvre même face à un iPhone SDK déjà bien restrictif, et le choix de JNI est débile (JNA aurait plus pertinent) car rendant la tâche plus compliqué qu'elle ne l'est déjà.

    Par rapport à ta problématique, le NDK a été conçu pour permettre d'optimiser certaines routines gourmandes en calculs dont les jeux vidéos. Je soupçonne même que la seule raison d'être du NDK est d'aider le décollage d'Android dans le domaine ludique où il est particulièrement à la traine face à l'iPhone.

    Le point faible du NDK, c'est le portage d'application existantes natives, même si on peut réutiliser une partie du code, ça revient à réécrire une bonne partie du code. Pour un smartphone à mi-chemin entre le téléphone et l'ordinateur portable, ça constitue un point négatif.
    • [^] # Re: Le NDK

      Posté par (page perso) . Évalué à 2.

      Le point faible du NDK, c'est le portage d'application existantes natives, même si on peut réutiliser une partie du code, ça revient à réécrire une bonne partie du code.

      Ton expérience m'intéresse, que ce soit iPhone ou Android, pour mon appli, écrite en C++.

      Si je comprend bien ton commentaire, ce n'est pas simple de porter tel quel, et il faut absolument passer par Java pour coder le GUI?
      Est-ce la même chose avec l'iPhone?

      En fait, j'aimerai savoir si j'ai à refaire le GUI "seulement" dans chacun des cas (android ou iPhone).
      • [^] # Re: Le NDK

        Posté par . Évalué à 5.

        Dans les deux cas, tu devras retravailler l'IHM.
        Pour Android, si tu as bien architecturé ton application, tu peux récupérer la partie traitement et wrapper ça via JNI, mais t'auras à réécrire la partie applicative qui est très différente. Tu peux récupérer certaines bibliothèques Java quitte à les retoucher un peu (par exemple, pour le XMPP).
        Je pense que ce guide devrait t'intéresser.
        http://developer.android.com/guide/practices/design/performa(...)

        Pour l'iPhone, tu as la possibilité de réutiliser une bonne partie des bibliothèques disponibles sous Unix (Boost, GLib, SDL, Qt Core, X11, etc ...), et l'écosystème des frameworks Mac.
        Pour l'IHM, Apple fournit CocoaTouch, même si il existe des efforts de portage pour différents toolkits (wxWidgets, Qt, etc ...), tu n'auras pas beaucoup le choix (excepté la SDL).
        Pour un jeu basé sur la SDL, tu dois adapter la partie entrée (gestures, accéléromètre) et adapter l'affichage à la taille de l'écran. Même pas besoin de réécrire ton point d'entrée, le port iPhone fournit un délégué qui s'en charge.
        Reste que l'iPhone avec toutes ses restrictions (pas de multitâches, pas de langages de scripts, SDK Mac only, licence payante pour déployer, etc ...) ce n'est pas la panacée.
  • # Pour les jeux 3D

    Posté par . Évalué à 2.

    Je ne sais pas si c'est facile à faire, mais il serait intéressant d'avoir un portage de la bibliothèque LWJGL qui assez populaire pour le développement de jeux libres dans le monde Java ( http://www.lwjgl.org/projects.php ).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.