Questions d'entretien Android intermédiaires et avancées (avec réponses)

Optimisation du dessin

Algorithmes de chiffrement (base64, MD5, chiffrement symétrique et chiffrement asymétrique) et scénarios d'utilisation .

L'algorithme RSA est l'algorithme de cryptographie à clé publique le plus populaire, utilisant des clés dont la longueur peut varier. RSA est le premier algorithme pouvant être utilisé à la fois pour le cryptage des données et pour les signatures numériques.

Le principe de l'algorithme RSA est le suivant :

1. Sélectionnez aléatoirement deux grands nombres premiers p et q, p n'est pas égal à q, calculez N=pq ; >2. Choisir un nombre supérieur à Si 1 est inférieur à N, l'entier naturel e doit être premier relativement avec (p-1)(q-1).

3. Utilisez la formule pour calculer d : d×e = 1 (mod (p-1)(q-1)).

4. Détruisez p et q.

Les N et e finaux sont la "clé publique", et d est la "clé privée". L'expéditeur utilise N pour crypter les données, et le destinataire ne peut utiliser que d pour décrypter le contenu des données.

La sécurité de RSA repose sur la décomposition de grands nombres. N inférieur à 1024 bits s'est avéré dangereux, et comme l'algorithme RSA effectue des calculs de grands nombres, RSA est plus rapide que DES fois plus lent, c'est le plus grand. faille de RSA, il ne peut donc généralement être utilisé que pour chiffrer une petite quantité de données ou de clés de chiffrement, mais RSA reste un algorithme de haute résistance.

Scénarios d'utilisation : dans le projet, à l'exception de la connexion, du paiement et d'autres interfaces, le cryptage asymétrique rsa est utilisé et le cryptage symétrique aes est utilisé pour d'autres interfaces. Aujourd'hui, nous allons découvrir le cryptage aes.

Qu'est-ce que le cryptage MD5 ?

Le nom anglais complet de MD5 est "Message-Digest Algorithm 5", qui se traduit par "Message Digest Algorithm 5". Il a évolué à partir de MD2, MD3 et MD4. Il s'agit d'un algorithme de cryptage unidirectionnel. méthode de cryptage irréversible.

Quelles sont les caractéristiques du cryptage MD5 ?

Compressibilité : pour les données de n'importe quelle longueur, la longueur de la valeur MD5 calculée est fixe.

Facile à calculer : il est facile de calculer la valeur MD5 à partir des données originales.

Résistance à la modification : si une modification est apportée aux données d'origine, même si seulement 1 octet est modifié, la valeur MD5 résultante sera très différente.

Anti-collision puissant : étant donné les données originales et leur valeur MD5, il est très difficile de trouver des données avec la même valeur MD5 (c'est-à-dire des données falsifiées).

Scénarios d'application MD5 :

Vérification de cohérence

Signature numérique

Authentification d'accès sécurisée

Qu'est-ce que le cryptage aes ?

Advanced Encryption Standard (anglais : Advanced Encryption Standard, abréviation : AES), également connu sous le nom de méthode de cryptage Rijndael en cryptographie, est une norme de cryptage par blocs adoptée par le gouvernement fédéral américain. Cette norme est utilisée pour remplacer le DES original. Elle a été analysée par de nombreuses parties et est largement utilisée dans le monde.

Principe d'implémentation de HashMap :

HashMap est une implémentation asynchrone de l'interface cartographique basée sur des tables de hachage, qui permet d'utiliser des valeurs nulles​​comme clé et valeur. Il existe deux structures de base dans le langage de programmation Java, l'une est un tableau et l'autre est un pointeur simulé (référence). Toutes les structures de données peuvent être construites à l'aide de ces deux structures de base, et HashMap ne fait pas exception. HashMap est en fait une structure de données de « hachage de liste chaînée ». C'est une combinaison de tableau et de liste chaînée.

La couche inférieure de HashMap est une structure de données et chaque élément du tableau est une liste chaînée.

Conflit :

La méthode Hashcode() est appelée dans HashMap pour calculer la valeur Hashclde, car deux objets différents en Java peuvent avoir le même Hashcode. Cela a conduit à des conflits.

Solution :

Lorsque HashMap est mis, le code source sous-jacent peut être vu Lorsque le programme essaie de mettre un objet clé-valeur dans un HashMap, il renvoie d'abord la valeur en fonction de la valeur. hashCode() de la clé. Déterminez l'emplacement de stockage de l'entrée. Si la valeur de retour de la méthode hashCode() des deux clés d'entrée est la même, alors leurs emplacements de stockage sont les mêmes. Si les deux clés d'entrée renvoient vrai par comparaison égale. , la valeur de l'entrée nouvellement ajoutée sera Écraser la valeur de l'entrée d'origine, mais la clé ne sera pas écrasée. Au contraire, si false est renvoyé, l'entrée nouvellement ajoutée formera une chaîne d'entrée avec l'entrée d'origine dans le. collection, avec le nouveau ajouté en tête et l'ancien en queue

Le principe d'implémentation de HashMap :

1. Si des clés avec la même valeur de hachage apparaissent pendant le stockage, il existe deux situations : 1. Si les clés sont identiques, la valeur d'origine sera écrasée. 2. Si les clés sont différentes (un conflit se produit), placez-les dans la liste chaînée.
2. Lors de l'obtention, recherchez directement l'indice correspondant à la valeur de hachage, puis déterminez davantage si la clé est la même, afin d'obtenir la valeur correspondante.
3. Le cœur de Hashmap est d'utiliser un tableau pour le stockage lorsqu'un conflit de clé se produit, il est stocké dans une liste chaînée.
4. ==============================

1. ?

onCreate() -> onStart() -> onResume() -> onPause() -> onDetroy()

2. Cycle de vie du service ?

Il existe deux façons de démarrer le service, l'une consiste à démarrer via startService(), l'autre consiste à démarrer via bindService(). Différentes méthodes de démarrage ont des cycles de vie différents.

Le cycle de vie d'un service démarré via startService() est le suivant : appelez startService() --> onCreate()--> Si vous commencez de cette manière, vous devez faire attention à plusieurs problèmes. Premièrement : lorsque nous sommes appelés via startService, si nous appelons startService() plusieurs fois, la méthode onCreate() ne sera appelée qu'une seule fois, et onStartConmon() le sera. être appelé plusieurs fois. Lorsque nous appelons stopService(), onDestroy() sera appelé pour détruire le service. Deuxièmement : lorsque nous commençons par startService, transmettons la valeur via l'intention et obtenons la valeur dans la méthode onStartConmon(), nous devons d'abord déterminer si l'intention est nulle.

Lier via bindService(). Cette façon de lier le service, méthode de cycle de vie : bindService-->onCreate()-->onBind()-->unBind()- ->onDestroy( ) bingservice L'avantage de démarrer le service de cette manière est qu'il est plus pratique d'exploiter le service dans l'activité. Par exemple, il existe plusieurs méthodes pour rejoindre le service, a, b Si vous souhaitez l'appeler dans l'activité. , vous devez obtenir l'objet ServiceConnection dans l'activité. Obtenez l'objet de classe de la classe interne dans le service via ServiceConnection, puis utilisez cet objet de classe pour appeler les méthodes de la classe. Bien sûr, cette classe doit hériter de l'objet Binder.

3. Processus de démarrage de l'activité (ne répondez pas au cycle de vie)

Il existe deux situations dans le processus de démarrage de l'application La première consiste à cliquer sur l'icône de l'application correspondante depuis le lanceur de bureau, et la seconde consiste à démarrer une nouvelle activité en appelant startActivity dans l'activité.

Lorsque nous créons un nouveau projet, l'activité racine par défaut est MainActivity, et toutes les activités sont enregistrées dans la pile. Lorsque nous démarrons une nouvelle activité, elle sera placée au-dessus de l'activité précédente, et nous le ferons quand. en cliquant sur l'icône de l'application depuis le bureau, puisque le lanceur lui-même est également une application, lorsque nous cliquons sur l'icône, le système appellera startActivitySately(). Dans des circonstances normales, les informations pertinentes sur l'activité que nous démarrons seront enregistrées dans l'intention, tels que l'action, la catégorie, etc. Lorsque nous installons cette application, le système démarrera également un service de gestion PackaManagerService. Ce service de gestion analysera le fichier AndroidManifest.xml pour obtenir des informations pertinentes dans l'application, telles que le service, l'activité, la diffusion, etc., puis obtiendra des informations sur. composants associés. Lorsque nous cliquons sur l'icône de l'application, la méthode startActivitySately() sera appelée, et à l'intérieur de cette méthode, startActivty() sera appelée, et la méthode startActivity() finira par appeler la méthode startActivityForResult(). Et dans la méthode startActivityForResult(). Étant donné que la méthode startActivityForResult() renvoie un résultat, le système donne directement un -1, ce qui signifie qu'aucun résultat ne doit être renvoyé. La méthode startActivityForResult() démarre en fait l'activité via la méthode execStartActivity() dans la classe Instrumentation. La fonction principale de la classe Instrumentation est de surveiller l'interaction entre le programme et le système. Dans cette méthode execStartActivity(), l'objet proxy d'ActivityManagerService sera obtenu et l'activité sera démarrée via cet objet proxy. Une méthode checkStartActivityResult() sera appelée lors du démarrage. Si ce composant n'est pas configuré dans la liste de configuration, une exception sera levée dans cette méthode. Bien sûr, la dernière chose à appeler est Application.scheduleLaunchActivity() pour démarrer l'activité. Dans cette méthode, un objet ActivityClientRecord est obtenu, et cet ActivityClientRecord utilise le gestionnaire pour envoyer des messages. Le système utilisera l'objet ActivityClientRecord pour chaque composant d'activité. en interne. Description, et l'objet ActivityClientRecord stocke un objet LoaderApk, via lequel handleLaunchActivity est appelé pour démarrer le composant d'activité, et la méthode de cycle de vie de la page est appelée dans cette méthode.

4. Méthodes d'enregistrement de diffusion et différences

Extension ici : quand utiliser l'enregistrement dynamique

Diffusion en diffusion, il existe deux méthodes d'enregistrement principales.

Le Le premier est l'enregistrement statique, qui peut également devenir une diffusion résidente. Ce type de diffusion doit être enregistré dans Androidmanifest.xml. La diffusion enregistrée de cette manière n'est pas affectée par le cycle de vie de la page. toujours La réception d'une diffusion est généralement utilisée lorsque vous souhaitez démarrer l'ordinateur automatiquement, etc. Étant donné que la diffusion dans cette méthode d'enregistrement est une diffusion permanente, elle occupera des ressources CPU.

Le deuxième type est l'enregistrement dynamique, et l'enregistrement dynamique est enregistré dans le code. Cette méthode d'enregistrement est également appelée diffusion non-résidente. Elle est affectée par le cycle de vie. Après avoir quitté la page. En recevant la diffusion, nous l'utilisons généralement pour mettre à jour l'interface utilisateur. Cette méthode d'enregistrement a une priorité plus élevée. Enfin, vous devez le dissocier pour éviter les fuites de mémoire

La diffusion est divisée en diffusion ordonnée et diffusion non ordonnée.

5. La différence entre HttpClient et HttpUrlConnection

Extension ici : quelle méthode de requête est utilisée dans Volley (HttpClient avant 2.3, HttpUrlConnection après 2.3)

Tout d'abord, HttpClient et HttpUrlConnection prennent tous deux en charge le protocole Https. Tous deux téléchargent ou téléchargent des données sous forme de flux, ainsi que ipv6, pooling de connexions et autres. fonctions. HttpClient possède de nombreuses API, donc si vous souhaitez l'étendre sans détruire sa compatibilité, il est difficile de l'étendre. Pour cette raison, Google a directement abandonné ce HttpClient dans Android 6.0.

HttpUrlConnection est relativement léger. , possède relativement peu d'API, est facile à développer et peut répondre à la plupart des transmissions de données d'Android. Volley, framework relativement classique, utilisait HttpClient avant la version 2.3, et HttpUrlConnection après la version 2.3.

6. La différence entre la machine virtuelle Java et la machine virtuelle Dalvik

Machine virtuelle Java :

1. La machine virtuelle Java est basée sur la pile. Les machines basées sur une pile doivent utiliser des instructions pour charger et exploiter les données sur la pile, et davantage d'instructions sont nécessaires.

2. La machine virtuelle Java exécute le bytecode Java. (La classe Java sera compilée en un ou plusieurs fichiers bytecode .class)

Machine virtuelle Dalvik :

1 La machine virtuelle Dalvik est basée sur des registres

2 , Dalvik exécute un format de bytecode .dex personnalisé. (Une fois la classe Java compilée dans un fichier .class, un outil dx sera utilisé pour convertir tous les fichiers .class en un fichier .dex, puis la machine virtuelle Dalvik en lira les instructions et les données

3. Pool constant Il a été modifié pour utiliser uniquement des index 32 bits pour simplifier l'interpréteur

4. Une application, une instance de machine virtuelle et un processus (tous les threads d'application Android correspondent à un thread Linux. , tous exécutés dans Dans son propre bac à sable, différentes applications s'exécutent dans différents processus. Chaque application Android Dalvik reçoit un PID Linux indépendant (app_*))

7. Processus maintenu en vie (processus mort-vivant) )

Extension ici : quelle est la priorité du processus

Les méthodes de maintien des processus Android de l'industrie actuelle sont principalement divisées en trois types : noir, blanc et gris. Leur mise en œuvre approximative L'idée est la suivante :

Maintien en vie noir : différents processus d'application utilisent des diffusions pour se réveiller (y compris en utilisant les diffusions fournies par le système pour se réveiller)

Maintien en vie blanc : démarrez le service de premier plan

Grey keep-alive : utilisez les vulnérabilités du système pour démarrer le service de premier plan

Black keep-alive

Le soi-disant black keep-alive consiste à utiliser différents processus d'application pour se réveiller les uns les autres en utilisant des diffusions. Voici trois comparaisons courantes :

Scénario 1 : Utiliser la diffusion générée par le système pour réveiller l'application lorsque vous allumez le téléphone, changez de réseau, prenez des photos ou filmez des vidéos

Scénario 2 : La connexion à un SDK tiers réveillera également l'application correspondante. Le processus d'application, tel que le SDK WeChat, réveillera WeChat et le SDK Alipay réveillera Alipay. À partir de là, le scénario 3 suivant. sera déclenché directement

Scénario 3 : Si Alipay et Taobao sont installés sur votre téléphone, Tmall, UC et d'autres applications basées sur Alibaba, alors après avoir ouvert une application basée sur Alibaba, vous pouvez en réveiller d'autres. Soit dit en passant, les applications basées sur Alibaba (utilisez simplement Alibaba comme exemple, en fait, le système BAT est similaire

Maintenir la vie blanche

La méthode de maintien de la vie blanche est très simple). Il s'agit d'appeler l'API système pour démarrer un processus de service de premier plan. Cela générera une notification dans la barre de notification du système pour informer l'utilisateur qu'une telle application est en cours d'exécution, même si l'application actuelle passe en arrière-plan. montré ci-dessous pour LBE et QQ Music :

Grey keep-alive

Gray keep-alive, ce type de méthode keep-alive est l'application la plus large. Elle utilise les vulnérabilités du système pour démarrer. un processus de service au premier plan. La différence avec la méthode de démarrage ordinaire est qu'il n'apparaît pas de notification dans la barre de notification du système et qu'il semble qu'un processus de service en arrière-plan soit en cours d'exécution. L'avantage est que l'utilisateur ne peut pas détecter que vous êtes en cours d'exécution. exécuter un processus de premier plan (car la notification n'est pas visible), mais la priorité de votre processus est supérieure à celle des processus d'arrière-plan ordinaires. Alors, comment exploiter les vulnérabilités du système ? Les idées et codes généraux d'implémentation sont les suivants :

Idée 1 : API Idée 2 : API >= 18, démarrer deux services front-end avec le même identifiant en même temps, puis arrêter le service démarré plus tard

Les enfants qui connaissent le système Android savent que le système est en fonction de l'expérience et des considérations de performances, le système ne tuera pas le processus lorsque l'application reviendra en arrière-plan, mais le mettra en cache. Plus vous ouvrez d'applications, plus les processus sont mis en cache en arrière-plan. Lorsque la mémoire système est insuffisante, le système commence à déterminer les processus à supprimer en fonction de son propre ensemble de mécanismes de recyclage de processus afin de libérer de la mémoire pour fournir les applications nécessaires. Ce mécanisme de destruction de processus et de récupération de mémoire est appelé Low Memory Killer. Il est basé sur le mécanisme OOM Killer (Out-Of-Memory killer) du noyau Linux.

L'importance du processus est divisée en 5 niveaux :

Processus de premier plan (Processus de premier plan)

Processus visible (Processus visible)

Processus de service ( Processus de service) )

Processus d'arrière-plan

Processus vide

Après avoir compris Low Memory Killer, apprenons-en plus sur oom_adj. Qu'est-ce que oom_adj ? Il s'agit d'une valeur attribuée par le noyau Linux à chaque processus système, représentant la priorité du processus. Le mécanisme de recyclage des processus détermine s'il faut recycler en fonction de cette priorité. Concernant le rôle de oom_adj, il vous suffit de retenir les points suivants :

Plus le oom_adj du processus est grand, plus la priorité du processus est faible et plus il est facile à tuer et à recycler, plus il est petit ; Autrement dit, plus la priorité du processus est élevée. Plus la valeur est élevée, moins il est susceptible d'être tué et recyclé

Le oom_adj du processus d'application ordinaire> = 0, seul le oom_adj du processus système peut be

Certains fabricants de téléphones mobiles ont intégré ces applications bien connues dans leur propre liste blanche, cela garantit que le processus ne meurt pas pour améliorer l'expérience utilisateur (comme WeChat, QQ et Momo sont tous dans Liste blanche de Xiaomi). S'ils sont supprimés de la liste blanche, ils pourront toujours échapper au sort d'être tués comme les applications ordinaires. Afin d'éviter autant que possible d'être tués, il est préférable de faire un travail d'optimisation honnêtement.

Ainsi, la solution fondamentale pour maintenir le processus en vie revient en fin de compte à l'optimisation des performances. L'immortalité du processus est une proposition complètement fausse après tout !

8. Expliquez le contexte

Le contexte est une classe de base abstraite. Lorsqu'il est traduit par contexte, il peut également être compris comme environnement, qui fournit des informations de base sur l'environnement d'exécution de certains programmes. Il existe deux sous-classes sous Context. ContextWrapper est la classe d'encapsulation des fonctions contextuelles et ContextImpl est la classe d'implémentation des fonctions contextuelles. ContextWrapper a trois sous-classes directes, ContextThemeWrapper, Service et Application. Parmi eux, ContextThemeWrapper est une classe d'encapsulation avec un thème, et l'une de ses sous-classes directes est Activity, donc le contexte d'activité, de service et d'application est différent. Seule l'activité nécessite un thème et le service ne nécessite pas de thème. Il existe trois types de contexte, à savoir l'application, l'activité et le service. Bien que ces trois classes jouent des rôles différents, elles appartiennent toutes à un type de Context et leurs fonctions de Context spécifiques sont implémentées par la classe ContextImpl. Par conséquent, dans la plupart des scénarios, Activité, Service et Application, ces trois types de Context sont tous universels. Cependant, il existe plusieurs scénarios spéciaux, tels que le démarrage d'une activité et l'affichage d'une boîte de dialogue. Pour des raisons de sécurité, Android ne permet pas qu'une activité ou un dialogue apparaisse de nulle part. Le démarrage d'une activité doit être basé sur une autre activité, qui est la pile de retour formée par celle-ci. La boîte de dialogue doit apparaître sur une activité (sauf s'il s'agit d'une boîte de dialogue de type alerte système), donc dans ce scénario, nous ne pouvons utiliser que le contexte de type activité, sinon une erreur se produira.

Les objets obtenus par les méthodes getApplicationContext() et getApplication() sont le même objet d'application, mais les types d'objets sont différents.

Nombre de contextes = Nombre d'activités + Nombre de services + 1 (1 est une application)

9. Comprendre la relation entre l'activité, la vue et la fenêtre

Cette question est vraiment déroutant Bonne réponse. Voici donc une métaphore plus appropriée pour décrire leur relation. L'activité est comme un artisan (unité de contrôle), Window est comme une fenêtre (portant le modèle), View est comme une grille de fenêtre (affichant la vue), LayoutInflater est comme des ciseaux et la configuration XML est comme un dessin de grille de fenêtre.

1 : Lorsque Activity est construit, une fenêtre sera initialisée, PhoneWindow pour être précis.

2 : Cette PhoneWindow a un "ViewRoot", et ce "ViewRoot" est une View ou ViewGroup, qui est la vue racine initiale.

3 : "ViewRoot" ajoute les vues une par une via la méthode addView. Par exemple, TextView, Button, etc.

4 : La surveillance des événements de ces Views est effectuée par WindowManagerService pour recevoir des messages et rappeler la fonction Activity. Par exemple, onClickListener, onKeyDown, etc.

10. Quatre LaunchModes et leurs scénarios d'utilisation

Extension ici : la différence entre la pile (First In Last Out) et la file d'attente (First In First Out)

Stack et The différence entre les files d'attente :

1. La file d'attente est première entrée, première sortie, et la pile est première entrée, dernière sortie

2. "Limitations" des opérations d'insertion et de suppression. Une pile est une liste linéaire qui limite les opérations d'insertion et de suppression à une seule extrémité de la liste. Une file d'attente est une liste linéaire qui limite les insertions à une extrémité du tableau et les suppressions à l'autre.

3. La vitesse de parcours des données est différente

mode standard

C'est le mode par défaut Chaque fois que l'activité est activée, une instance d'activité sera créée et placée dans. la pile de tâches. Scénarios d'utilisation : la plupart des activités.

mode singleTop

S'il y a une instance de l'Activity en haut de la pile de tâches, l'instance sera réutilisée (onNewIntent() de l'instance sera appelée), sinon une nouvelle instance sera créée et placée. En poussant vers le haut de la pile, même si une instance de l'activité existe déjà sur la pile, une nouvelle instance sera créée tant qu'elle n'est pas en haut de la pile. Les scénarios d'utilisation incluent des pages de contenu d'actualités ou des applications de lecture.

Mode singleTask

S'il existe déjà une instance de l'Activity dans la pile, l'instance sera réutilisée (onNewIntent() de l'instance sera appelée). Lorsqu'elle est réutilisée, l'instance sera renvoyée en haut de la pile, de sorte que les instances situées au-dessus seront supprimées de la pile. Si l'instance n'existe pas sur la pile, une nouvelle instance sera créée et placée sur la pile. Le scénario d'utilisation est tel que l'interface principale du navigateur. Quel que soit le nombre d'applications à partir desquelles vous démarrez le navigateur, l'interface principale ne sera démarrée qu'une seule fois. Dans d'autres cas, onNewIntent sera utilisé et les autres pages de l'interface principale seront effacées.

Mode singleInstance

Crée une instance de l'activité dans une nouvelle pile et permet à plusieurs applications de partager l'instance d'activité dans la pile. Une fois qu'une instance d'activité de ce mode existe déjà dans une pile, toute application qui active l'activité réutilisera l'instance dans la pile (onNewIntent() de l'instance sera appelée). L'effet est équivalent à plusieurs applications partageant une seule application. Peu importe qui active l'activité, elles entreront dans la même application. Utilisez des scénarios tels que des rappels d'alarme pour séparer les rappels d'alarme des paramètres d'alarme. N'utilisez pas singleInstance pour les pages intermédiaires. Si vous l'utilisez pour des pages intermédiaires, il y aura des problèmes avec les sauts, tels que : A -> B (singleInstance) -> .

11. Afficher le processus de dessin

Contrôles personnalisés :

1. Ce type de contrôle personnalisé ne nécessite pas que nous le dessinions nous-mêmes, mais un nouveau contrôle composé de contrôles natifs. Comme la barre de titre.

2. Hériter du contrôle d'origine. Ce type de contrôle personnalisé peut ajouter certaines méthodes par lui-même en plus des méthodes fournies par le contrôle natif. Comme créer des coins arrondis et des images circulaires.

3. Contrôles entièrement personnalisés : Tout le contenu affiché sur cette vue est dessiné par nous-mêmes. Par exemple, créez une barre de progression en forme d'ondulation de l'eau.

Processus de dessin de la vue : OnMeasure()——>OnLayout()——>OnDraw()

Première étape : OnMeasure() : Mesurez la taille de la vue. La méthode de mesure est appelée de manière récursive depuis la vue parent de niveau supérieur vers la vue enfant, et la méthode de mesure rappelle OnMeasure.

Étape 2 : OnLayout() : Déterminez la position d'affichage et mettez en page la page. Le processus d'appel récursif de la méthode view.layout de la vue parent de niveau supérieur à la vue enfant signifie que la vue parent place la vue enfant dans la position appropriée en fonction de la taille de la mise en page et des paramètres de mise en page obtenus en mesurant la vue enfant dans le étape précédente.

Étape 3 : OnDraw() : Dessinez la vue. ViewRoot crée un objet Canvas puis appelle OnDraw(). Six étapes : ①, dessinez l'arrière-plan de la vue ; ②, enregistrez le calque de canevas (Couche) ; ③, dessinez le contenu de la vue ; ④, dessinez la sous-vue de la vue, sinon, ne l'utilisez pas ; 🎜>⑤, restaurez le calque ⑥, dessinez la barre de défilement.

12. Les événements View et ViewGroup sont divisés en

1. Il n'y a que deux protagonistes dans la distribution des événements Touch : ViewGroup et View. ViewGroup contient trois événements associés : onInterceptTouchEvent, dispatchTouchEvent et onTouchEvent. La vue contient deux événements liés : dispatchTouchEvent et onTouchEvent. Parmi eux, ViewGroup hérite de View.

2. ViewGroup et View forment une structure arborescente, et le nœud racine est un ViwGroup contenu dans l'activité.

3. Les événements tactiles sont composés d'Action_Down, Action_Move et Aciton_UP. Dans un événement tactile complet, il n'y a qu'un seul Down et Up, et il y a plusieurs Moves, qui peuvent être nuls.

4. Lorsqu'Activity reçoit l'événement Touch, il traverse la sous-vue pour distribuer l'événement Down. Le parcours ViewGroup peut être considéré comme récursif. Le but de la distribution est de trouver la vue qui gère réellement cet événement tactile complet. Cette vue renverra true dans le résultat onTouchuEvent.

5. Lorsqu'une sous-vue renvoie vrai, la distribution de l'événement Down sera arrêtée et la sous-vue sera enregistrée dans le ViewGroup. Les événements Move et Up suivants seront gérés directement par la sous-vue. Étant donné que la sous-vue est enregistrée dans ViewGroup, dans la structure de nœuds ViewGroup multicouche, le ViewGroup de niveau supérieur enregistre l'objet ViewGroup là où se trouve la vue qui gère réellement l'événement : par exemple, dans la structure ViewGroup0-ViewGroup1. -TextView, TextView renvoie true, qui sera enregistré dans ViewGroup1, et ViewGroup1 renverra également true et sera enregistré dans ViewGroup0. Lorsque les événements Move et UP arrivent, ils seront d'abord transmis de ViewGroup0 à ViewGroup1, puis de ViewGroup1 à TextView.

6. Lorsque toutes les sous-vues du ViewGroup ne capturent pas l'événement Down, l'événement onTouch du ViewGroup lui-même sera déclenché. La façon de déclencher consiste à appeler la fonction super.dispatchTouchEvent, qui est la méthode dispatchTouchEvent de la classe parent View. Lorsque toutes les sous-vues ne sont pas traitées, la méthode onTouchEvent d'activité est déclenchée.

7. onInterceptTouchEvent a deux fonctions : 1. Intercepter la distribution des événements Down. 2. Arrêtez la transmission des événements Up et Move à la vue cible, afin que le ViewGroup où se trouve la vue cible capture les événements Up et Move.

13. L'état de sauvegarde de l'activité

onSaveInstanceState(Bundle) sera appelé avant que l'activité n'entre dans l'état d'arrière-plan, c'est-à-dire avant la méthode onStop() et après la méthode onPause

14. Plusieurs animations sous Android

Animation d'image : elle fait référence à la lecture ordonnée de l'image et au temps de lecture de chaque image pour former un effet d'animation, tel que la barre de rythme que vous souhaitez entendre.

Animation d'interpolation : elle fait référence à la transformation de graphiques via une série d'algorithmes en spécifiant l'état initial, l'heure de changement et la méthode de la vue pour former des effets d'animation. Il existe principalement quatre effets : Alpha, Échelle, Traduire, et Rotation . Remarque : L'effet d'animation est uniquement implémenté dans le calque de vue et ne modifie pas réellement les propriétés de la vue, telles que le glissement de la liste et la modification de la transparence de la barre de titre.

Animation d'attribut : elle n'est prise en charge que dans Android 3.0. L'effet d'animation est formé en modifiant continuellement les attributs de la vue et en la redessinant constamment. Par rapport à l'animation de vue, les propriétés de View sont vraiment modifiées. Par exemple, affichez la rotation, le zoom avant et le zoom arrière.

15. Plusieurs méthodes de communication inter-processus dans Android

La communication entre processus Android, telle que l'intention, le fournisseur de contenu, la diffusion et le service, peut toutes communiquer entre les processus.

intention : cette méthode inter-processus n'est pas une forme d'accès à la mémoire. Elle nécessite la transmission d'un URI, comme passer un appel.

contentProvider : ce formulaire utilise le partage de données pour le partage de données.

service : service à distance, aidl

diffusion

16. Compréhension de l'AIDL

Extension ici : Brève description de Binder

AIDL : Chaque processus possède sa propre instance de Dalvik VM, possède sa propre mémoire indépendante, stocke ses propres données dans sa propre mémoire, effectue ses propres opérations et termine sa propre vie dans son propre petit espace. Aidl est comme un pont entre deux processus, permettant aux données d'être transmises entre les deux processus. Il existe de nombreuses options de communication entre processus, telles que BroadcastReceiver, Messenger, etc., mais BroadcastReceiver utilise plus de ressources système. la communication de processus n'est évidemment pas souhaitable ; lorsque Messenger effectue une communication entre processus, la file d'attente des requêtes est exécutée de manière synchrone et ne peut pas être exécutée simultanément.

Une compréhension simple du mécanisme Binde :

Dans le mécanisme Binder du système Android, il est composé des pilotes Client, Service, ServiceManager et Binder, parmi lesquels Client, service et Service Manager s'exécute dans l'espace utilisateur, le pilote Binder s'exécute dans l'espace noyau. Binder est le ciment qui lie ces quatre composants ensemble. Le composant principal est le pilote Binder qui fournit des fonctions de gestion auxiliaires, et le client et le service sont basés sur le pilote Binder et le gestionnaire de services implémentent la communication entre C/S sur l'installation. Parmi eux, le pilote Binder fournit le fichier de périphérique /dev/binder pour interagir avec le contrôle utilisateur

Le client, le service et le gestionnaire de services communiquent avec le pilote Binder via les méthodes correspondantes d'opérations de fichiers ouverts et ioctl. La communication inter-processus entre le client et le service est mise en œuvre indirectement via le pilote Binder. Le Binder Manager est un processus démon qui gère le service et offre au client la possibilité d'interroger l'interface du service.

17. Le principe de Handler

Le thread principal d'Android ne peut pas effectuer d'opérations fastidieuses et le sous-thread ne peut pas mettre à jour l'interface utilisateur. Il existe donc un gestionnaire, son rôle est d'implémenter la communication entre les threads.

Gestionnaire Il y a quatre objets principaux dans l'ensemble du processus, le gestionnaire, Message, MessageQueue et Looper. Lorsque l'application est créée, l'objet gestionnaire sera créé dans le thread principal

Nous enregistrons le message à envoyer au Message. Le gestionnaire envoie le Message au MessageQueue en appelant la méthode sendMessage, et le gestionnaire. L'objet Looper continuera à appeler la méthode loop()

pour supprimer continuellement les messages de MessageQueue et les transmettre au gestionnaire pour traitement. Cela permet la communication entre les threads.

18. Principe du mécanisme Binder

Dans le mécanisme Binder du système Android, il est composé du client, du service, du ServiceManager et du pilote Binder, parmi lesquels le client, le service et le gestionnaire de services s'exécutent. espace utilisateur, le pilote Binder s'exécute dans l'espace du noyau. Binder est le ciment qui lie ces quatre composants ensemble. Le composant principal est le pilote Binder qui fournit des fonctions de gestion auxiliaires, et le client et le service sont basés sur le pilote Binder et le gestionnaire de services implémentent la communication entre C/S sur l'installation. Le pilote Binder fournit le fichier de périphérique /dev/binder pour interagir avec les contrôles utilisateur, le client, le service et le gestionnaire de services communiquent avec le pilote Binder via les méthodes correspondantes d'opérations de fichiers ioctl. La communication inter-processus entre le client et le service est mise en œuvre indirectement via le pilote Binder. Le Binder Manager est un processus démon qui gère le service et offre au client la possibilité d'interroger l'interface du service.

19. Le principe de la réparation à chaud

Nous savons que la machine virtuelle Java - JVM charge le fichier de classe, tandis que la machine virtuelle Android - Dalvik/ART VM charge le fichier dex. de la classe,

et ils ont tous besoin de ClassLoader lors du chargement des classes. ClassLoader a une sous-classe BaseDexClassLoader, et il y a un tableau

sous BaseDexClassLoader - DexPathList, qui est utilisé pour stocker les fichiers dex When. BaseDexClassLoader passe Lors de l'appel de la méthode findClass, elle parcourt en fait le tableau,

trouve le fichier dex correspondant et le renvoie directement s'il est trouvé. La solution pour la réparation à chaud est d'ajouter le nouveau dex à la collection, et il se trouve devant l'ancien dex,

, il sera donc retiré en premier et restitué.

20. Fuites et gestion de la mémoire Android

(1) La différence entre le débordement de mémoire (MOO) et la fuite de mémoire (l'objet ne peut pas être recyclé).

(2) Causes des fuites de mémoire

(3) Outil de détection des fuites de mémoire------>LeakCanary

Dépassement de mémoire hors mémoire : fait référence à Quand le programme demande de la mémoire, il n'y a pas assez d'espace mémoire pour qu'il puisse l'utiliser, et un manque de mémoire apparaît ; par exemple, s'il demande un nombre entier, mais stocke un nombre qui ne peut être enregistré que par un long, c'est une mémoire. débordement. En termes simples, le débordement de mémoire signifie qu'il n'y a pas assez de mémoire.

Fuite de mémoire : une fuite de mémoire signifie qu'une fois que le programme a demandé de la mémoire, il ne peut pas libérer l'espace mémoire alloué. Les dommages causés par une fuite de mémoire peuvent être ignorés, mais les conséquences de l'accumulation de fuites de mémoire sont graves. peu importe la quantité de mémoire, tôt ou tard elle sera occupée Lumière

Causes des fuites de mémoire :

1. Fuite de mémoire causée par le gestionnaire.

Solution : Déclarez Handler comme une classe interne statique, afin qu'il ne contienne pas de référence à la classe externe SecondActivity, et son cycle de vie n'a rien à voir avec la classe externe

If context. est nécessaire dans Handler, vous pouvez référencer des classes externes via des références faibles

2. Fuites de mémoire causées par le mode singleton.

Solution : le contexte est ApplicationContext. Étant donné que le cycle de vie d'ApplicationContext est cohérent avec l'application, cela ne provoquera pas de fuites de mémoire

3. Fuites de mémoire causées par des classes internes non statiques créant de la statique. cas.

Solution : Modifier la classe interne pour qu'elle soit statique pour éviter les fuites de mémoire

4. Fuites de mémoire causées par des classes internes anonymes non statiques.

Solution : définissez la classe interne anonyme sur statique.

5. Fuites de mémoire causées par une utilisation non appariée de l'enregistrement/désenregistrement.

Enregistrez le récepteur de diffusion, EventBus, etc., n'oubliez pas de dissocier.

6. Fuites de mémoire causées par la non-fermeture des objets ressources.

Lorsque ces ressources ne sont pas utilisées, pensez à appeler les méthodes correspondantes telles que close(), destroy(), recycler(), release(), etc. pour les libérer.

7. Fuites de mémoire causées par l'incapacité de nettoyer les objets de collection à temps.

Habituellement, certains objets sont chargés dans une collection lorsqu'ils ne sont pas utilisés, vous devez penser à nettoyer la collection à temps afin que les objets associés ne soient plus référencés.

21. Comment Fragment communique avec Fragment et Activity

1. Appelez directement la méthode dans un autre Fragment dans un Fragment

2. Utilisez le rappel d'interface

. 3. Utilisez la diffusion

4.Fragment appelle directement la méthode publique dans l'activité

22 Adaptation de l'interface utilisateur Android

Pour les polices, utilisez sp, utilisez dp, utilisez plus match_parent, wrap_content. , poids

ressources d'images, la résolution des différentes images peut être remplacée par un pourcentage lorsqu'elles sont placées dans le dossier correspondant.

23. Optimisation de l'application

Optimisation de l'application : (Outil : outil de mise en page de l'analyse de la visionneuse de hiérarchie : l'analyse des tests TraceView prend du temps)

Optimisation du démarrage de l'application

Optimisation de la mise en page

Optimisation de la réponse

Optimisation de la mémoire

Optimisation de l'utilisation de la batterie

Optimisation du réseau

Optimisation du démarrage de l'application (pour démarrage à froid)

Il existe trois façons de démarrer l'application :

Démarrage à froid : l'application n'a pas été démarrée ou le processus d'application a été interrompu et le processus d'application n'existe pas dans le système. L'application en ce moment est un démarrage à froid.

Démarrage à chaud : le démarrage à chaud signifie que le processus de votre application est uniquement en arrière-plan et que le système le fait simplement passer de l'arrière-plan au premier plan et l'affiche à l'utilisateur.

C'est entre le démarrage à froid et le démarrage à chaud. De manière générale, cela se produit dans les deux situations suivantes :

(1) L'utilisateur quitte l'application puis la redémarre. peut-être encore. Il est en cours d'exécution, mais l'activité doit être reconstruite.

(2) Une fois que l'utilisateur a quitté l'application, le système peut tuer l'application pour des raisons de mémoire, et le processus et l'activité doivent être redémarrés. Cependant, l'état de l'instance enregistré du verrou d'arrêt passif peut être redémarré. être restauré dans onCreate .

Optimisation :

OnCreate de l'application (en particulier l'initialisation du SDK tiers) et le rendu de l'activité sur le premier écran n'ont pas besoin d'effectuer des opérations fastidieuses. Si tel est le cas, ils peuvent être placés dans. threads enfants ou IntentServices

Optimisation de la mise en page

Essayez de ne pas effectuer d'imbrication trop complexe. Vous pouvez utiliser , ,

Optimisation de la réponse

Le système Android enverra un signal VSYNC toutes les 16 ms pour redessiner notre interface (Activité).

Raisons du décalage de page :

(1) Mise en page trop complexe.

(2) Opérations complexes sur le fil de l'interface utilisateur

(3) Fréquent là-bas Il y a deux raisons pour les GC fréquents : 1. La gigue de la mémoire, c'est-à-dire qu'un grand nombre d'objets sont créés et libérés immédiatement dans un court laps de temps. 2. La génération d'un grand nombre d'objets en un instant occupera sérieusement la zone mémoire.

Optimisation de la mémoire : reportez-vous à la section Fuite de mémoire et débordement de mémoire

Optimisation de l'utilisation de la batterie (utiliser les outils : Batterystats & bugreport)

(1) Optimiser les requêtes réseau

(2) Lorsque vous utilisez le GPS pour le positionnement, n'oubliez pas de l'éteindre à temps

L'optimisation du réseau (l'impact des connexions réseau sur les utilisateurs : trafic, alimentation, attente des utilisateurs) peut être détectée par l'outil Moniteur réseau à côté de Logcat sous Android Studio

Conception de l'API : la conception de l'API entre l'application et le serveur doit prendre en compte la fréquence des requêtes réseau, l'état des ressources, etc. afin que l'application puisse répondre aux exigences commerciales et à l'interface. afficher avec moins de requêtes.

Compression Gzip : utilisez Gzip pour compresser les requêtes et les réponses, réduisant ainsi la quantité de données transmises, réduisant ainsi la consommation de trafic

Taille de l'image : vous pouvez informer le serveur. de la largeur et de la hauteur requises de l'image lors de l'obtention de l'image, afin que le serveur puisse donner les images d'image appropriées pour éviter le gaspillage

Mise en cache réseau : une mise en cache appropriée peut non seulement rendre notre application plus rapide, mais également. éviter une consommation de trafic inutile.

24. Optimisation de l'image

(1) Opérer sur l'image elle-même. Essayez de ne pas utiliser setImageBitmap, setImageResource, BitmapFactory.decodeResource pour définir une grande image, car une fois le décodage terminé, ces méthodes sont finalement complétées via createBitmap de la couche Java, ce qui nécessite plus de mémoire.

(2) La mise à l'échelle rapport de l'image. Le SDK recommande que la valeur soit une valeur exponentielle de 2. Plus la valeur est grande, plus la valeur sera grande, l'image ne sera pas claire.

(3) N'oubliez pas d'appeler la méthode recycle() des images lorsqu'elles ne sont pas utilisées

25 Interaction entre HybridApp WebView et JS

Android et JS s'appellent mutuellement. via WebView. En fait, oui :

Android appelle le code JS

1. Grâce à loadUrl() de WebView, l'utilisation de cette méthode est plus simple et plus pratique. Cependant, le rendement est relativement faible et il est difficile d’obtenir la valeur de retour.

2. Grâce à évaluerJavascript() de WebView, cette méthode est très efficace, mais elle n'est prise en charge que par les versions supérieures à 4.4 et non par les versions inférieures à 4.4. Il est donc recommandé d’utiliser un mélange des deux.

JS appelle le code Android

1. Le mappage d'objets est effectué via addJavascriptInterface() de WebView. Cette méthode est simple à utiliser et mappe uniquement les objets Android et les objets JS, mais elle présente des failles relativement importantes. .

La raison de la vulnérabilité est la suivante : lorsque JS obtient l'objet Android, il peut appeler toutes les méthodes de l'objet Android, y compris la classe système (classe java.lang.Runtime), exécutant ainsi du code arbitraire.

Solution :

(1) Google stipule dans Android 4.2 que les fonctions appelées soient annotées avec @JavascriptInterface pour éviter les attaques de vulnérabilité.

(2) Utilisez intercept prompt() pour corriger la vulnérabilité avant la version Android 4.2.

2. Interceptez l'URL via le rappel de la méthode ShouldOverrideUrlLoading () de WebViewClient. Les avantages de cette méthode : il n'y a pas de failles dans la méthode 1 ; inconvénients : l'obtention par JS de la valeur de retour de la méthode Android est compliquée. (ios utilise principalement cette méthode)

(1) Android intercepte l'url via la méthode de rappel ShouldOverrideUrlLoading () de WebViewClient

(2) Analyse le protocole de l'url

( 3) Si un protocole préalablement convenu est détecté, appelez la méthode correspondante

3. Interceptez la boîte de dialogue JS alert(), confirm() via la méthode onJsAlert(), onJsConfirm(), onJsPrompt() rappels de WebChromeClient ), message prompt()

Avantages de cette méthode : Il n'y a pas de faille dans la méthode 1 Inconvénients : L'obtention par JS de la valeur de retour de la méthode Android est compliquée ;

26. Principe JAVA GC

L'idée principale de l'algorithme de récupération de place est d'identifier l'espace mémoire disponible de la machine virtuelle, c'est-à-dire les objets dans l'espace du tas. l'objet est référencé, alors appelez-le C'est un objet survivant

Au contraire, si l'objet n'est plus référencé, c'est un objet poubelle, et l'espace qu'il occupe peut être recyclé pour réallocation. Le choix de l'algorithme de garbage collection et l'ajustement raisonnable des paramètres du système de garbage collection affectent directement les performances du système.

27. ANR

Le nom complet de l'ANR est Application Not Responding, qui signifie "Application Not Responding". Lorsque l'opération ne peut pas être traitée par le système dans un délai donné, un ANR. comme celui illustré ci-dessus apparaîtra au niveau du système.

Cause :

(1) Impossible de répondre aux événements de saisie de l'utilisateur (tels que la saisie au clavier, l'écran tactile, etc. ) dans les 5 s.

(2) BroadcastReceiver dans 10 s Impossible de se terminer dans les 20 secondes

(3) Le service ne peut pas se terminer dans les 20 s (faible probabilité)

Solution :

(1) N'effectuez pas d'opérations fastidieuses dans le thread principal, mais doit être implémenté dans un thread enfant. Par exemple, effectuez le moins d'opérations de création possible dans onCreate() et onResume().

(2) Les applications doivent éviter d'effectuer des opérations ou des calculs fastidieux dans BroadcastReceiver.

(3) Évitez de démarrer une activité dans le récepteur d'intention, car cela créerait un nouvel écran et détournerait le focus du programme actuellement exécuté par l'utilisateur.

(4) Le service s'exécute sur le thread principal, les opérations fastidieuses du service doivent donc être placées dans des threads enfants.

28. Modèle de conception

Extension ici : une double vérification doit être écrite.

Mode cas unique : divisé en style méchant et style paresseux

Style méchant :

public class Singleton 
{ 
    private static Singleton instance = new Singleton(); 
     
    public static Singleton getInstance() 
    { 
        return instance ; 
    } 
}

Style paresseux :

public class Singleton02 
{ 
    private static Singleton02 instance; 
 
    public static Singleton02 getInstance() 
    { 
        if (instance == null) 
        { 
            synchronized (Singleton02.class) 
            { 
                if (instance == null) 
                { 
                    instance = new Singleton02(); 
                } 
            } 
        } 
        return instance; 
    } 
}

29, RxJava

30. MVP, MVC, MVVM

Extension ici : exemple mvp manuscrit, différence entre mvc et mvc, avantages du mvp

Mode MVP, correspondant au Model--Business Modèles logiques et d'entités, vue - correspond à l'activité, est responsable du dessin de la vue et de l'interaction avec l'utilisateur, Présentateur - est responsable de l'interaction entre la vue et le modèle. Le mode MVP est basé sur le mode MVC, complètement séparé. le modèle et la vue pour que le couplage du projet soit encore plus faible. Dans MVC, l'activité dans le projet correspond au contrôleur C dans MVC, et le traitement logique dans le projet est traité dans ce C. En même temps. Au fil du temps, l'interaction entre View et Model est également dit que toutes les interactions logiques et les interactions utilisateur dans mvc sont placées dans le contrôleur, c'est-à-dire dans l'activité. La vue et le modèle peuvent communiquer directement. Le modèle MVP est plus complètement séparé et a une division du travail plus claire. Le modèle - logique métier et modèle d'entité, vue - est responsable de l'interaction avec les utilisateurs, et le présentateur est responsable de compléter l'interaction entre la vue et le modèle. La plus grande différence entre MVP. et MVC est que dans MVC permet au modèle et à la vue d'interagir, et il est évident dans MVP que l'interaction entre le modèle et la vue est complétée par le présentateur. Un autre point est que l'interaction entre Presenter et View se fait via l'interface

31. Algorithme d'écriture manuscrite (il faut savoir choisir le bullage)

JNI

(1 ) Installez et téléchargez Cygwin, téléchargez Android NDK

(2) Conception de l'interface JNI dans le projet ndk

(3) Utilisez C/C++ pour implémenter des méthodes locales

(4 ) JNI génère le fichier .so de la bibliothèque de liens dynamiques

(5) Copiez la bibliothèque de liens dynamiques dans le projet Java, appelez-la dans le projet Java et exécutez le projet Java

33. RecyclerView et ListView La différence

RecyclerView peut compléter les effets de ListView et GridView, ainsi que l'effet du flux en cascade. Dans le même temps, vous pouvez également définir le sens de défilement de la liste (vertical ou horizontal) ;

La réutilisation des vues dans RecyclerView ne nécessite pas que les développeurs écrivent eux-mêmes le code, le système l'a déjà empaqueté pour vous.

RecyclerView peut effectuer une actualisation partielle.

RecyclerView fournit une API pour implémenter des effets d'animation d'éléments.

En termes de performances :

Si vous devez actualiser fréquemment les données et ajouter des animations, RecyclerView présente un plus grand avantage.

S'il est simplement affiché sous forme de liste, la différence entre les deux n'est pas très grande.

34. Comparaison d'Universal-ImageLoader, Picasso, Fresco et Glide

Fresco est un outil de mise en cache d'images open source lancé par Facebook. Ses principales fonctionnalités incluent : deux caches mémoire plus la formation de cache natif. une mise en cache à trois niveaux,

Avantages :

1. Les images sont stockées dans la mémoire partagée anonyme du système Android, plutôt que dans la mémoire tas de la machine virtuelle. de l'image est également stockée dans la mémoire de tas locale, de sorte que l'application utilise davantage de mémoire, ne provoquera pas de MOO en raison du chargement de l'image et réduit également le décalage d'interface provoqué par les appels fréquents du garbage collector pour recycler Bitmap, ce qui entraîne performances supérieures.

2. Chargement progressif des images JPEG, prenant en charge le chargement des images du flou au clair.

3. L'image peut être affichée dans ImageView à n'importe quel point central, pas seulement au centre de l'image.

4. Le redimensionnement des images JPEG se fait également de manière native, et non dans la mémoire tas de la machine virtuelle, ce qui réduit également le MOO.

5. Très bon support pour l'affichage des images GIF.

Inconvénients :

1. Le framework est volumineux, ce qui affecte la taille de l'Apk

2 Il est fastidieux à utiliser

Universal-ImageLoader : ( On estime que HttpClient est remplacé par Google. Si vous abandonnez, l'auteur renoncera à maintenir ce framework)

Avantages :

Prend en charge le suivi de la progression du téléchargement

2. . Le chargement de l'image peut être suspendu pendant le défilement de la vue via l'interface PauseOnScrollListener.

3. Implémentez plusieurs algorithmes de mise en cache de mémoire par défaut. Ces caches d'images peuvent tous être configurés avec des algorithmes de mise en cache, mais ImageLoader implémente de nombreux algorithmes de mise en cache par défaut, tels que la taille la plus grande en premier, la suppression la moins utilisée et la moins récemment utilisée. , premier entré, premier sorti, le plus long entré, premier sorti, etc.

4. Prise en charge de la définition des règles de nom de fichier de cache local

Avantages Picasso

1. Livré avec une fonction de surveillance statistique. Prend en charge la surveillance de l'utilisation du cache d'images, y compris le taux de réussite du cache, la taille de la mémoire utilisée, le trafic enregistré, etc.

2. Prise en charge du traitement prioritaire. Avant que chaque tâche ne soit planifiée, une tâche avec une priorité plus élevée sera sélectionnée. Par exemple, cela est très approprié lorsque la priorité de la bannière dans la page de l'application est supérieure à celle de l'icône.

3. Prise en charge du délai jusqu'à ce que le calcul de la taille de l'image soit terminé et le chargement

4. Prise en charge du mode vol, le nombre de threads simultanés change en fonction du type de réseau. Lorsque le téléphone passe en mode avion ou que le type de réseau change, le nombre maximum de simultanéité du pool de threads sera automatiquement ajusté. Par exemple, le nombre maximum de simultanéité du wifi est 4, 4g est 3 et 3g est 2. Ici, Picasso détermine le nombre maximum de simultanéités en fonction du type de réseau, et non du nombre de cœurs de processeur.

5. Cache local "Aucun". "Pas" de cache local ne signifie pas qu'il n'y a pas de cache local, mais Picasso lui-même ne l'a pas implémenté et l'a confié à une autre bibliothèque réseau de Square, okhttp, pour l'implémenter. L'avantage est que l'image peut être contrôlée. en demandant Cache-Control et Expired dans l'en-tête de réponse

Avantages de Glide

1 Il peut non seulement mettre en cache des images mais également mettre en cache des fichiers multimédias. cache, il prend en charge Gif, WebP et même Video. , il doit donc être utilisé comme cache multimédia

2. Prise en charge du traitement prioritaire

3. Conformément au cycle de vie de l'activité/du fragment. , Glide prend en charge trimMemory pour maintenir un RequestManager pour chaque contexte. , via FragmentTransaction, il reste cohérent avec le cycle de vie Activity/Fragment, et il existe une implémentation d'interface trimMemory correspondante disponible pour l'appel

4. Prend en charge okhttp et. Volley. Glide obtient les données via UrlConnection par défaut et peut être utilisé avec okhttp ou Volley. En fait, ImageLoader et Picasso prennent également en charge okhttp et Volley 5. Le cache mémoire de Glide a une conception active. cache, ce n'est pas comme l'implémentation générale de get. Utilisez Remove, puis placez ces données mises en cache dans une carte activeResources dont la valeur est une référence logicielle, et comptez le nombre de références une fois l'image chargée, elle sera jugée. Si le nombre de références est vide, l'image la plus petite sera recyclée et Glide mettra en cache l'image la plus petite. Utilisez l'url, view_width, view_height, la résolution de l'écran, etc. comme clés communes pour mettre en cache l'image traitée dans le cache mémoire au lieu de l'original. image pour enregistrer une taille cohérente avec le cycle de vie d'activité/fragment. TrimMemory est pris en charge par défaut pour les images RGB_565 au lieu de ARGB_888, bien que la définition soit pire, l'image est plus petite et peut également être configurée sur ARGB_888

. 6. Glide peut prendre en charge l'expiration de l'URL via la signature ou sans utiliser le cache local

42. Comparaison de Xutils, OKhttp, Volley, Retrofit

Xutils est un framework très complet qui peut effectuer des requêtes réseau, des images chargement, stockage des données et annotation des vues. Il est très pratique d'utiliser ce framework, mais il présente des inconvénients. Il est également très évident que l'utilisation de ce projet rendra le projet très dépendant de ce framework une fois qu'il y aura un problème avec. ce cadre, cela aura un grand impact sur le projet. ,

OKhttp : dans le développement Android, vous pouvez utiliser directement l'API prête à l'emploi pour effectuer des requêtes réseau. Utilisez simplement HttpClient et HttpUrlConnection pour fonctionner. Pour les programmes Java et Android, okhttp encapsule une bibliothèque de requêtes http hautes performances qui prend en charge la synchronisation et l'asynchronisme. De plus, okhttp encapsule également le pool de threads, la conversion des données, l'utilisation des paramètres, la gestion des erreurs, etc. L'API est plus pratique à utiliser. Mais lorsque nous l'utilisons dans le projet, nous devons toujours créer nous-mêmes une couche d'encapsulation, afin qu'elle puisse être utilisée plus facilement.

Volley : Volley est une petite et élégante bibliothèque de requêtes asynchrones officiellement publiée par Google. Le framework est hautement évolutif et prend en charge HttpClient, HttpUrlConnection et même OkHttp, encapsule également ImageLoader. Il n'est même pas nécessaire d'utiliser un framework de chargement d'images. Cependant, cette fonction n'est pas aussi puissante que certains frameworks de chargement d'images spécialisés. Elle peut être utilisée pour des besoins simples, mais des exigences plus complexes nécessitent toujours l'utilisation d'un framework de chargement d'images spécialisé. Volley présente également des défauts, tels que le fait de ne pas prendre en charge la publication de données volumineuses, il n'est donc pas adapté au téléchargement de fichiers. Cependant, l'intention initiale de la conception de Volley elle-même est de répondre à des requêtes réseau fréquentes avec de petits volumes de données.

Retrofit : Retrofit est un framework de requête réseau RESTful basé sur l'encapsulation OkHttp par défaut produit par Square. RESTful est un style de conception d'API actuellement populaire et n'est pas un standard. L'encapsulation de Retrofit peut être considérée comme très puissante. Elle implique un certain nombre de modèles de conception. Les requêtes peuvent être configurées directement via des annotations. Bien que http soit utilisé par défaut, différents convertisseurs Json peuvent être utilisés pour sérialiser les données. En même temps, fournir un support pour RxJava, en utilisant Retrofit + OkHttp + RxJava + Dagger2 On peut dire qu'il s'agit d'un framework relativement tendance à l'heure actuelle, mais il nécessite un seuil relativement élevé.

Volley VS OkHttp

L'avantage de Volley est qu'il est mieux encapsulé, alors qu'en utilisant OkHttp, vous devez avoir suffisamment de capacité pour encapsuler à nouveau. L'avantage d'OkHttp est des performances plus élevées. Parce qu'OkHttp est basé sur NIO et Okio, les performances sont plus rapides que Volley. IO et NIO sont deux concepts en Java. Si je lis des données à partir du disque dur, la première méthode consiste à ce que le programme attende que les données soient lues avant de continuer. C'est la plus simple et est également appelée blocage d'IO. lisez vos données, le programme continue de s'exécuter et vous m'informez une fois les données traitées, puis gérez le rappel. La deuxième méthode est NIO, qui est non bloquante, donc bien sûr NIO a de meilleures performances que IO. Okio est une bibliothèque créée par Square basée sur IO et NIO qui est plus simple et plus efficace dans le traitement des flux de données. Théoriquement, si vous comparez Volley avec OkHttp, vous êtes plus enclin à utiliser Volley, car Volley prend également en charge l'utilisation d'OkHttp en interne, donc l'avantage en termes de performances d'OkHttp a disparu, et Volley lui-même est plus facile à utiliser et a une meilleure évolutivité.

OkHttp VS Retrofit

Il ne fait aucun doute que Retrofit est un package basé sur OkHttp par défaut. Il n'y a pas de comparaison à cet égard, et Retrofit est définitivement préféré.

Volley VS Retrofit

Les deux bibliothèques sont bien encapsulées, mais Retrofit est plus complètement découplé, surtout lorsque Retrofit 2.0 est sorti, Jake a abordé les aspects déraisonnables de la conception 1.0 précédente. Beaucoup de refactorisation. , les responsabilités sont plus subdivisées et Retrofit utilise OkHttp par défaut, ce qui présente un avantage sur Volley en termes de performances. De plus, si votre projet utilise RxJava, vous devez utiliser Retrofit. Par conséquent, par rapport à ces deux bibliothèques, Retrofit présente plus d'avantages. Si vous maîtrisez les deux frameworks, vous devez d'abord utiliser Retrofit. Cependant, le seuil de Retrofit est légèrement supérieur à celui de Volley. Il faut un certain effort pour comprendre ses principes et ses diverses utilisations. Si vous souhaitez bien le comprendre, il est recommandé d'utiliser Volley dans des projets commerciaux.

Java

1. La différence entre sleep et wait dans les threads

(1) Ces deux méthodes proviennent de classes différentes, sleep vient de Thread et wait vient d'Object. ;

(2) La méthode sleep ne libère pas le verrou, mais la méthode wait libère le verrou.

(3) wait, notify, notifyAll ne peut être utilisé que dans les méthodes de contrôle de synchronisation ou les blocs de contrôle de synchronisation, tandis que sleep peut être utilisé n'importe où.

2. Quelle est la différence entre les méthodes start() et run() dans Thread ?

La méthode start() est utilisée pour démarrer un thread nouvellement créé, et start() en interne appelle la méthode run(), ce qui est différent de l'appel direct de la méthode run(). Si la méthode run() est appelée directement,

n'est pas différente de la méthode ordinaire.

3. Comment utiliser les mots-clés final et static.

final :

1. La variable finale est une constante et ne peut se voir attribuer une valeur qu'une seule fois.

2. La méthode finale ne peut pas être remplacée par les sous-classes.

3. Les classes finales ne peuvent pas être héritées.

statique :

1. Variables statiques : il n'y a qu'une seule copie des variables statiques en mémoire (économie de mémoire) La JVM n'alloue qu'une seule fois,

lors du chargement. une classe L'allocation de mémoire des variables statiques est complétée dans le processus et est accessible directement par nom de classe (pratique, bien sûr, elle est également accessible via des objets (mais ce n'est pas recommandé).

2. Bloc de code statique

Le bloc de code statique est automatiquement exécuté lors de l'initialisation lorsque la classe est chargée.

3. Méthode statique

La méthode statique peut être appelée directement via le nom de la classe, et n'importe quelle instance peut également être appelée, de sorte que les mots-clés this et super ne peuvent pas être utilisés dans la méthode statique,

Vous ne pouvez pas accéder directement aux variables d'instance et aux méthodes d'instance de la classe à laquelle vous appartenez (c'est-à-dire aux variables membres et aux méthodes membres sans statique), vous ne pouvez accéder qu'aux variables membres statiques et aux méthodes membres de la classe à laquelle vous appartenez.

4. Différences entre String, StringBuffer et StringBuilder

1. La vitesse d'exécution des trois : StringBuffer > être recréé lors de l'épissage d'un nouvel objet).

2. StringBuffer est thread-safe et StringBuilder n'est pas thread-safe. (Parce que StringBuffer a un tampon)

5. La différence entre la surcharge et la réécriture en Java :

1 Surcharge : Il peut y avoir plusieurs méthodes avec le même nom dans une classe, mais les paramètres. Le type et le nombre sont différents. C'est une surcharge.

2. Réécriture : Si une sous-classe hérite de la classe parent, la sous-classe peut implémenter les méthodes de la classe parent, de sorte que la nouvelle méthode écrase l'ancienne méthode de la classe parent.

6. La différence entre Http et https

Extension ici : le principe de mise en œuvre de https

1 Le protocole https nécessite de demander un certificat à partir de ca. Il y a moins de certificats gratuits, cela nécessite donc un certain coût.

2. http est un protocole de transfert hypertexte et les informations sont transmises en texte brut, tandis que https est un protocole de transmission sécurisé et crypté SSL.

3. http et https utilisent des méthodes de connexion complètement différentes et utilisent des ports différents. Le premier est 80 et le second est 443.

4. La connexion http est très simple et sans état ; le protocole HTTPS est un protocole réseau construit à partir du protocole SSL+HTTP qui peut effectuer une transmission cryptée et une authentification d'identité, et est plus sécurisé que le protocole http.

Principe de mise en œuvre https :

(1) Le client utilise l'URL https pour accéder au serveur web et nécessite qu'une connexion SSL soit établie avec le serveur web.

(2) Après avoir reçu la demande du client, le serveur Web transmettra une copie des informations du certificat du site Web (le certificat contient la clé publique) au client.

(3) Le navigateur du client et le serveur Web commencent à négocier le niveau de sécurité de la connexion SSL, qui est le niveau de cryptage des informations.

(4) Le navigateur du client établit une clé de session en fonction du niveau de sécurité convenu par les deux parties, puis utilise la clé publique du site Web pour crypter la clé de session et la transmet au site Web.

(5) Le serveur Web utilise sa propre clé privée pour déchiffrer la clé de session.

(6) Le serveur Web utilise la clé de session pour crypter la communication avec le client.

7. À quelle couche du modèle TCP/IP se trouve HTTP ? Pourquoi HTTP est-il un protocole de transfert de données fiable ?

Modèle TCP/IP à cinq couches :

De bas en haut : couche physique->couche de liaison de données->couche réseau->couche de transport->couche d'application

Parmi eux, tcp/ip est situé au niveau de la couche réseau dans le modèle, et ICMP (Network Control Message Protocol) est également au niveau de la même couche. http est situé dans la couche application dans le modèle

Étant donné que tcp/ip est un protocole fiable orienté connexion et que http est basé sur le protocole tcp/ip dans la couche transport, http est donc une transmission de données fiable protocole.

8. Caractéristiques des liens HTTP

La caractéristique la plus importante des connexions HTTP est que chaque requête envoyée par le client nécessite que le serveur renvoie une réponse une fois la requête terminée, la connexion est établie. sera activement publié.

Le processus allant de l'établissement d'une connexion à la fermeture de la connexion est appelé « une connexion ».

9. La différence entre TCP et UDP

tcp est orientée connexion Étant donné que la connexion TCP nécessite trois poignées de main, elle peut minimiser le risque et garantir la fiabilité de la connexion.

udp n'est pas orienté connexion. Udp n'a pas besoin d'établir une connexion avec l'objet avant d'établir une connexion. Aucun signal de confirmation n'est envoyé, qu'il soit en envoi ou en réception. UDP n'est donc pas fiable.

Étant donné qu'UDP n'a pas besoin de confirmer la connexion, UDP a moins de surcharge et un taux de transmission plus élevé, le fonctionnement en temps réel est donc meilleur.

10. Étapes permettant à Socket d'établir une connexion réseau

L'établissement d'une connexion Socket nécessite au moins une paire de sockets, dont l'une s'exécute avec le client --ClientSocket, et l'autre avec le client. server--ServiceSocket

1. Surveillance du serveur : le socket côté serveur ne localise pas le socket client spécifique, mais est en état d'attente de connexion, surveillant l'état du réseau en temps réel et attendant le demande de connexion du client.

2. Requête client : fait référence au socket du client faisant une demande de connexion, et la cible à connecter est le socket du serveur. Remarque : Le socket du client doit décrire le socket du serveur auquel il souhaite se connecter.

indique l'adresse et le numéro de port du socket serveur, puis fait une demande de connexion tout comme le socket côté serveur.

3. Confirmation de connexion : lorsque le socket côté serveur surveille la demande de connexion du socket client, il répond à la demande du socket client, établit un nouveau thread et connecte le socket côté serveur au socket client. La description du mot

est envoyée au client Une fois que le client confirme cette description, les deux parties établissent formellement une connexion. Le socket serveur reste à l'état d'écoute et continue de recevoir des demandes de connexion d'autres sockets clients.

11. Prise de contact à trois voies TCP/IP, quatre vagues

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!