J'utilise Eclipse pour développer des applications Android. J'utilise le dernier SDK et ECLIPSE 3.6, mon ordinateur est MacBook Air avec 4 Go de RAM.
Chaque fois que je modifie un fichier de ressource (une disposition XML par exemple), il faut Eclipse entre 1MN et 2MN pour reconstruire le binaire et le déployer. Mon binaire est d'environ 10 m (c'est un jeu avec beaucoup de bitmaps).
Il est très difficile de programmer avec des temps de réponse aussi élevés, n'importe quel moyen de la rendre plus courte?
5 Réponses :
utilisez-vous Maven ou tel? Eclipse + Maven a à la fois un constructeur et ils ont tendance à se battre beaucoup si les deux sont activés.
(Honnêtement, la meilleure réponse est d'utiliser Intelli-J, et tout fonctionnera comme par magie, mais je doute que vous souhaitiez cette réponse).
Avez-vous un bon tutoriel pour le projet avec des packages multi-connectés? J'ai essayé mais après l'importation, j'ai eu (propre travail) peu de packages que certains sont des libs et d'autres types et je n'ai aucune idée de l'importation et de ce qui set.
Supprimez la version de contrôle automatiquement dans le menu Project, de cette façon, vous ne compilez pas continuellement. Dans les ressources Android, les ressources sont très optimisées afin que la compilation dans une application comme votre peut prendre du temps.
Vous pouvez compiler manuellement lorsque vous avez effectué des changements importants.
Si vous avez beaucoup de graphiques, vous voudrez peut-être lire Ceci Android-Dev Post. AAPT optimise les PNG lors d'une construction (peut-être inutilement ainsi) mais uniquement si l'extension est .png (sensible à la casse). Les renommer à .png saute l'étape d'optimisation, mais les images sont toujours utiles lorsqu'elles sont référencées.
Ils résolvent ce problème et il est disponible dans ADT 12.
http://tools.android.com/download
http://tools.android.com/recent/finercontrolveradtBuildProcess
Impressionnant, j'espère vraiment que cela se dégage bientôt!
Adt 14 va résoudre ce problème.
AFAIK, la principale raison pour laquelle il faut si longtemps, c'est que la modification des ressources entraîne essentiellement une reconstruction complète. Modification des fichiers Java ne reconstruira que ce qui est nécessaire.
Ma construction est également très lente. Et je n'ai pas beaucoup de pngs. Pour autant que je puisse voir AAPT.EXE traite des fichiers de mise en page trop longtemps. Le problème est apparu dans SDK 2.2. Si je construis avec SDK 2.1, la construction est très rapide.
La solution PNG est inutile avec moi. Je suis d'accord avec Fedor et j'ai la même expérience à ce sujet. Lorsque je passe au niveau de l'API 7, le temps de construction est beaucoup moins qu'auparavant. En attendant, vous sacrifiez également les capacités de SDK 2.2, et c'est vraiment terrible.