Je pense que vous devriez penser à qui est destinée votre classe ou méthode, et si elle peut être trouvée après obscurcissement. Par exemple, les activités, les services, etc. sont enregistrés dans le fichier manifeste, puis le système les appelle. par réflexion. Il ne peut donc pas être confondu. Il en va de même pour les contrôles personnalisés, qui apparaîtront dans le fichier de mise en page et seront appelés par le système lors du lancement, afin qu'ils ne puissent pas être confondus. Il existe également des méthodes natives, qui ne peuvent être confondues en se référant aux règles de dénomination de la méthode. Vous pouvez vous référer à ce blog : http://blog.csdn.net/dai_zhen.... S'il y a une erreur, vous devez toujours réfléchir à ce qui ne doit pas être confondu. Par exemple, j'ai utilisé ionic auparavant, et la confusion a continué à générer des erreurs. Plus tard, j'ai découvert qu'il existe une classe de code local appelée par javascript (can). Je ne me souviens plus de son nom). Cette classe se trouve dans Ce qui est déclaré dans le fichier de configuration est probablement appelé par réflexion, il ne peut donc pas être confondu.
La chose la plus importante à laquelle il faut prêter attention lors de l'obscurcissement est la partie du code qui utilise la réflexion. Puisque l'utilisation de la réflexion est principalement basée sur les noms de méthodes ou d'attributs, il est nécessaire de s'en assurer. ces noms ne sont pas confondus avant de pouvoir être utilisés. Le code s'exécute normalement. Généralement, lorsque des responsables Android ou des tiers fournissent des packages, ils donnent également des règles d'ignorance déroutantes. Bien que ces spécifications soient différentes, le concept de base de presque toutes les règles est le même, à savoir éviter de confondre le code qui utilise la partie réflexion.
Le code réfléchi, les interfaces système, les interfaces jni, la sérialisation et la désérialisation et les javabeans qui interagissent avec le serveur ne peuvent pas être confondus. Si vous utilisez des packages tiers, vous devez vérifier les règles de confusion de ces packages. Je ne sais pas, ne le dissimulez pas. Après tout, les packages tiers couramment utilisés sont open source, et peu importe qu'ils soient obscurcis ou non.
Un bug que j'ai rencontré auparavant dans un projet était dû à une confusion. Écrivez le nom d'une classe dans String. Après obscurcissement, le nom de la classe change et la classe est introuvable. Il m'a fallu beaucoup de temps pour trouver la cause du bug, qui est très déroutant.
Je pense que vous devriez penser à qui est destinée votre classe ou méthode, et si elle peut être trouvée après obscurcissement. Par exemple, les activités, les services, etc. sont enregistrés dans le fichier manifeste, puis le système les appelle. par réflexion. Il ne peut donc pas être confondu. Il en va de même pour les contrôles personnalisés, qui apparaîtront dans le fichier de mise en page et seront appelés par le système lors du lancement, afin qu'ils ne puissent pas être confondus. Il existe également des méthodes natives, qui ne peuvent être confondues en se référant aux règles de dénomination de la méthode. Vous pouvez vous référer à ce blog : http://blog.csdn.net/dai_zhen.... S'il y a une erreur, vous devez toujours réfléchir à ce qui ne doit pas être confondu. Par exemple, j'ai utilisé ionic auparavant, et la confusion a continué à générer des erreurs. Plus tard, j'ai découvert qu'il existe une classe de code local appelée par javascript (can). Je ne me souviens plus de son nom). Cette classe se trouve dans Ce qui est déclaré dans le fichier de configuration est probablement appelé par réflexion, il ne peut donc pas être confondu.
La chose la plus importante à laquelle il faut prêter attention lors de l'obscurcissement est la partie du code qui utilise la
réflexion
. Puisque l'utilisation de la réflexion est principalement basée sur les noms de méthodes ou d'attributs, il est nécessaire de s'en assurer. ces noms ne sont pas confondus avant de pouvoir être utilisés. Le code s'exécute normalement. Généralement, lorsque des responsables Android ou des tiers fournissent des packages, ils donnent également des règles d'ignorance déroutantes. Bien que ces spécifications soient différentes, le concept de base de presque toutes les règles est le même, à savoir éviter de confondre le code qui utilise la partie réflexion.Le code réfléchi, les interfaces système, les interfaces jni, la sérialisation et la désérialisation et les javabeans qui interagissent avec le serveur ne peuvent pas être confondus. Si vous utilisez des packages tiers, vous devez vérifier les règles de confusion de ces packages. Je ne sais pas, ne le dissimulez pas. Après tout, les packages tiers couramment utilisés sont open source, et peu importe qu'ils soient obscurcis ou non.
Un
bug
que j'ai rencontré auparavant dans un projet était dû à une confusion.Écrivez le nom d'une classe dans
String
. Après obscurcissement, le nom de la classe change et la classe est introuvable.Il m'a fallu beaucoup de temps pour trouver la cause du
bug
, qui est très déroutant.