Strange redessiner? émission html application dans webview sur android

Question

J'ai fait une simple application html nixie horloge et l'envelopper dans un WebView à utiliser sur Android. Pas de trucs fantaisie. Juste un fichier HTML, un fichier JS et un fichier css (et des images à dix chiffres). Après quelques heures, il y a des bandes au centre de l'écran (où se trouve l'animation et au-delà) et l'écran est complètement illisible. Le menu est également "endommagé" car une partie de l'écran est corrompue. Voir image ci-dessous (excuses pour la mauvaise qualité de ces images = webcam):

Est-ce un bug connu? Après un redémarrage de l'application, tout redevient normal.

L'appareil J'utilise est un Samsung Galaxy S3 GT-I9300 fonctionnant sur Android 4.3 I9300BUUGNF1

Pour animer les chiffres que je créé un script qui définit une classe sur le récipient avec 10 chiffres pour montrer un nombre. Toutes les images sont complètement transparentes (opacité: 0) lorsqu'aucune classe n'est définie. C'est parce que j'utilise une transition en douceur de 250ms pour lui donner un joli fondu en entrée (à l'opacité: 1).

Y a-t-il un problème avec l'utilisation des fonctionnalités CSS3? Ce est le css:

.nixie,.clock  { position:fixed; width:80%; height:80%; text-align:center; margin:0 10%; } 
.clock    { top:36px; } 
.clock .digit  { display:inline-block; min-height:800px; width:12.2%; margin-top:8%; padding:0; font-size:0; overflow:hidden; background:#000 url(../img/nixietube.png) top center no-repeat; background-size:100%; } 
.clock .digit img { opacity:0; position:absolute; width:12%; margin-left:-2.4%; margin-top:0.2%; } 
.clock .digit img.dot { margin-left:1.8%; margin-top:-0.2%; } 

body.seg6 .clock .digit.seg8 { display:none; } 
body.seg6 .clock .digit   { width:16.6%; margin:0; margin-top:8%; } 
body.seg6 .clock .digit img  { width:16%; margin-top:0; margin-left:-3.2%; } 
body.seg6 .clock .digit img.dot { margin-left:1.8%; margin-top:-0.1%; } 


.clock .digit.d0 img.d0, 
.clock .digit.d1 img.d1, 
.clock .digit.d2 img.d2, 
.clock .digit.d3 img.d3, 
.clock .digit.d4 img.d4, 
.clock .digit.d5 img.d5, 
.clock .digit.d6 img.d6, 
.clock .digit.d7 img.d7, 
.clock .digit.d8 img.d8, 
.clock .digit.d9 img.d9, 
.clock .digit.dot img.dot, 
.clock .digit.slash img.slash { opacity:1; -moz-transition: all 250ms ease; } 

Toutes les idées?

Answer 1

Android n'est pas exempt de bugs, à coup sûr, en particulier les anciennes versions de l'OS/SDK. Le problème était une combinaison de choses. Au début, je crée dynamiquement WebView et définir certains paramètres. J'utilise également un bitmap (ImageView) comme une sorte d'écran d'accueil. Ainsi, lorsque le WebView est créé, il couvre l'ImageView. Ce ralentissement de la réponse de la WebView (parce que l'ImageView est toujours visible) et causé aussi un autre problème comme le clavier logiciel ne fera pas de popup. En raison de la réponse lente des animations WebView et stutter, j'ai décidé d'appliquer une accelaration matérielle ou logicielle en utilisant WebView.setLayerType.

La version du logiciel setLayerType(View.LAYER_TYPE_SOFTWARE, null) n'est pas exempte de bugs. Il ne peut pas gérer la transparence sans effets secondaires étranges (pépins) comme une image avec transparence, un fond avec transparence ou transparence sur la transparence. Il a également des problèmes avec les éléments placés absolus qui peuvent être défilés (apparaissent sur la mauvaise position). Lorsque j'ai désactivé l'accélération logicielle et masqué le bitmap de démarrage, tout est revenu à la normale.

Il y avait aussi une erreur dans le code de décider d'appliquer le logiciel/l'accélération matérielle, donc je l'ai changé à ceci:

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) // HONEYCOMB instead of KITKAT 
    { 
     this.webView.setLayerType(View.LAYER_TYPE_HARDWARE, null); 
    } 
    else { 
      // UPDATE: DO NOTHING, BUGS IN SOFTWARE LAYER 
      // older android version, enable software acceleration 
      //this.webView.setLayerType(View.LAYER_TYPE_SOFTWARE, null); 
     } 

J'ai changé le CSS pour Android WebView, pas ou moins de transparence et de non (CSS) car le WebView est trop lent pour cela même lorsque l'accélération matérielle est utilisée. Alors soyez prudent en utilisant des trucs de fantaisie.

Il est vraiment triste que le WebView soit de mauvaise qualité, il doit être le même que le navigateur d'actions Android, mais il est à certains égards très différent. Si vous voulez éviter tous ces problèmes et que vous pouvez cibler votre logiciel pour KITKAT ou supérieur, vous pouvez utiliser le WebView basé sur Chrome (voir aussi: https://developer.chrome.com/multidevice/webview/overview). Chrome WebViews inclut une version mise à jour du moteur JavaScript V8 et la prise en charge des normes Web modernes précédemment manquantes dans les anciens WebViews.