Après un ingénieur avec 5 ans d'expérience en développement iOS a désespérément travaillé et affecté au développement Android pendant environ six mois Je voulais donner mes impressions.
Comme un point sur lequel les ingénieurs iOS sont tombés par hasard lorsqu'ils se sont lancés dans le développement Android
-Conception de conception d'interface utilisateur et comment gérer UIKit --Manipulation des facultatifs --Fichier source
Si ce point est supprimé, je pense que nous pouvons surmonter les trois premiers mois même à grande échelle (optimiste). Le fichier de ressources contient également des changements de couleur à partir du code source.
Je pense que ce sera un peu plus facile si vous surmontez les 5 points ci-dessus, Le prochain grand mur, ou la petite différence, est
--Comment concevoir la conception de l'interface utilisateur --Spécifications linguistiques
Je pensais que c'était à propos de ça. Après m'être habitué à cela, je peux désormais développer Android en toute confiance en tant qu'ingénieur iOS.
Regardons chacun d'eux.
| iOS | Android |
|---|---|
| UILabel | TextView |
| UIButton | Button / ImageButton / etc |
| UIImageView | ImageView |
| UIView | View |
| UITextView | TextView |
| UISwitch | Switch |
| UIWebView | WebView |
| UITableView | ListView |
| UICollectionView | RecyclerView |
| UIScrollView(Défilement vertical) | ScrollView |
| UIScrollView(Défilement horizontal) | ViewPager |
Est-ce quelque chose comme ça? N'est-il pas bon de maintenir ces points?
Cependant, pour la conception iOS, considérez le modèle de conception généré à partir du code et de la composition avec Storyboard et xib, etc. Il existe plusieurs modèles. Par contre, dans le cas d'Android, je ne peux penser qu'aux modèles d'édition de fichiers XML.
Vous ne devriez donc pas avoir à vous soucier du modèle de conception de votre conception. D'un autre côté, si un ingénieur Android touche iOS, il y a un gros obstacle appelé Autolayout. Par conséquent, je pense qu'iOS-> Android a peu de résistance au développement, mais Android-> iOS Je suppose que c'est assez difficile.
De plus, étant donné qu'Android est Kotlin / Java, c'était un gros avantage qu'il n'y avait aucun coût pour être au courant des pointeurs. Si le pointeur est impliqué dans le développement de l'application, le taux de frustration augmentera (histoire d'expérience).
J'ai appris la langue dans l'ordre Ojbc → Swift → Java → Kotlin, Après tout, la gestion de Java Optional était très difficile.
Si vous écrivez Java après vous être habitué à Swift's Optional, il deviendra "Optional Mendokusei" d'un seul coup. C'est à quel point Swift's Optional est incroyable.
Une fois que vous vous êtes habitué à écrire en option, c'est normal.
La gestion des ressources pour iOS est différente pour chaque application, mais Android a une directive pour «faire cela» Je n'avais pas trop à m'inquiéter car c'était décidé. Cependant, il existe plusieurs façons de faire référence aux fichiers couleur et image à partir des ressources. Il y avait un inconvénient que j'avais oublié d'écrire en fonction du design. C'est déjà dur.
Développement Android, réglage de la luminosité de la couleur RVB au HSV
Cependant, l'inconvénient d'Android réside dans l'implémentation de coins arrondis, d'ombres portées, de bordures et de dégradés. Il est très difficile de gérer le fichier XML car il est nécessaire de créer et de définir le fichier XML un par un. Au contraire, iOS était assez excellent.
Si possible, je veux que vous puissiez l'implémenter rapidement avec quelques lignes de code comme iOS. Je regrette souvent de recevoir des demandes de bordures, de coins arrondis et d'ombres portées sur iOS. Si vous créez un fichier XML, le fichier ne prend-il pas de l'espace?
Sans parler de l'animation, iOS c'est mieux, et j'ai l'impression qu'Android ne veut pas trop s'impliquer.
Afin d'ajouter MotionLayout à Android récent et de l'implémenter, il est nécessaire de préparer un fichier XML.
Je veux que vous puissiez implémenter une telle chose avec juste du code.
MotionLayout (Android Developer)
Je me suis peu à peu impliqué dans le développement Android depuis Android Studio 1.0, donc J'ai compris le concept d '«activité», mais il était difficile de comprendre «Fragment». (Au départ, d'autres ingénieurs Android semblaient avoir le même avis)
Cependant, cela est facile à comprendre, et si vous voulez dire à un ingénieur iOS
C'est comme un fichier UIView Xib.
(Activity est une classe qui correspond à ʻUIViewController`)
Une fois que vous savez cela, la politique de conception ultérieure est presque la même.
Il semble être enseigné que "View a un cycle de vie ajouté",
C'est la même chose qu'après avoir connecté Xib et ʻUIView`.
C'était difficile d'y arriver.
Par exemple,
Fichier de mise en page Android = mise en page automatique iOS
C'est similaire à. Je pensais que ce serait facile à transmettre si je disais cela.
Pour Android, la politique de conception change en fonction de la mise en page utilisée pour placer les pièces.
Cependant, si vous n'utilisez pas correctement la mise en page, le fichier XML sera foiré (histoire d'expérience).
Si vous le considérez comme un LinearLayout (Vertical), l'ingénieur iOS l'interprète comme" Ah, la contrainte verticale de la pièce ".
Cela conduit à un malentendu.
La façon de penser était assez différente d'iOS, donc Placer des mises en page en XML était une tâche ardue.
Au-delà de cela, la mise en page automatique n'est pas requise, donc Android est plus facile à concevoir. Il fait également une bonne marge après la rotation.
J'ai essayé de résumer les impressions du développement d'Android pendant environ six mois comme ça. Au-delà de cette partie, je pense que les ingénieurs iOS pourront couvrir Android. (Ah, il y avait un autre contraste entre Closure et Lambda.)
J'aimerais faire du développement Android en tant qu'ingénieur iOS, mais j'ai peur. Si vous réfléchissez, vous devriez pouvoir voir le mur à surmonter dans cet article. Si vous vous concentrez sur cela, vous pourrez utiliser Android relativement rapidement.