Le portage est un terme très largement utilisé. Généralement, il signifie l'adaptation d'un gros bloc de code à quelque chose d'autre. L'opposé de "portage" est "réécriture". Donc, la partie importante du processus de portage est que vous essayez de vous épargner beaucoup de temps lorsque vous voulez déplacer votre code.
En relisant cela, c'est très peu spécifique, et c'est le problème avec un terme qui est utilisé de manière aussi large dans notre profession. Donc, soyons spécifiques :
Disons que j'ai écrit un jeu en C++ destiné aux téléphones Android. Il fonctionne très bien et devient populaire et je reçois donc des demandes pour le même jeu sur les téléphones d'Apple. J'ai maintenant deux choix. Je peux réécrire le jeu à partir de zéro en utilisant les outils de développement d'Apple, ou je peux essayer de porter mon code sur Apple. Je dois examiner la quantité de travail impliquée dans chacun de ces choix et prendre une décision sur celui qui me coûtera le moins d'argent tout en fournissant une nouvelle source de revenus sur les téléphones Apple. Si je décide de prendre en charge les téléphones basés sur Windows, j'aurai le même choix.
Le portage peut être un processus très simple (par exemple, si je passe d'une technologie de puce à une autre, mais que je reste dans le même système d'exploitation, cela pourrait être aussi simple que d'obtenir un compilateur croisé et de corriger les bogues qui pourraient apparaître), ou cela pourrait être un processus très difficile.
Le portage entre deux environnements complètement indépendants comme le bureau Windows vers le téléphone Android comporte plusieurs obstacles que vous devez surmonter. Tout d'abord, les interfaces utilisateur de ces deux sont très différentes et beaucoup des hypothèses que votre application fait lorsqu'elle fonctionne sur le bureau Windows sont complètement invalides sur un téléphone (je n'ai pas besoin d'entrer dans les détails ici, n'est-ce pas ? les différences sont évidentes).
Deuxièmement, l'outillage est très différent (les compilateurs, les installateurs, les chaînes de distribution, etc.) donc il y a probablement une courbe d'apprentissage pour le portage entre n'importe quels deux environnements très différents. Vous pouvez même embaucher tout un groupe de développeurs qui comprennent spécifiquement le nouvel environnement pour aider à comprendre les problèmes (ou même un spécialiste du portage).
Troisièmement, les limitations physiques de l'exécution dans un téléphone (moins de mémoire, écran plus petit, pas de souris, support partiel du clavier) doivent être gérées.
De nombreuses entreprises qui ont fait ce choix ont décidé que la réécriture de l'application pour le nouvel environnement est la solution la moins chère. Souvent, elles pourraient prendre un noyau de l'application et le transformer soit en API distantes, soit en bibliothèques distribuables (ce qui signifie qu'elles ont extrait un plus petit morceau et n'ont porté que cela), puis réécrire le reste de l'application (par exemple, un jeu pourrait extraire son moteur physique dans une bibliothèque, mais réécrire tout le code de l'interface utilisateur).
Le portage est une si grosse affaire qu'il existe des entreprises qui gagnent toute leur vie en fournissant un environnement tampon sous lequel vous écrivez votre application. Ils se sont donné la peine de créer un environnement dont ils peuvent garantir (dans certaines limites) qu'il permettra à votre application de fonctionner essentiellement sans changement sur un ensemble donné de plateformes (même à travers celles aussi différentes que celles que j'ai proposées ci-dessus). Ces environnements seront toujours un compromis et impliqueront souvent des limitations très spécifiques à votre application (ces choses qui ne peuvent pas être implémentées ou simulées sur toutes les plateformes supportées). Si vous pouvez vivre dans ces limites, ces environnements peuvent être formidables, mais si vous vous battez avec les limitations, ils peuvent devenir un cauchemar.
.