Deze pagina is vertaald door de Cloud Translation API.

Webaudio, autoplay-beleid en games

Tom Greenaway

Hongchan Choi

In september 2017 hebben we een aanstaande wijziging aangekondigd in de manier waarop audio zou worden afgehandeld met het gedragsbeleid voor automatisch afspelen in Chrome. De beleidswijziging werd in mei 2018 uitgebracht met Chrome 66 Stable.

Na feedback van de Web Audio-ontwikkelgemeenschap hebben we de release van het Web Audio-gedeelte van het autoplay-beleid uitgesteld om ontwikkelaars meer tijd te geven om hun websites bij te werken. We hebben ook enkele wijzigingen aangebracht in de implementatie van het beleid voor webaudio, waardoor het aantal websites dat hun code moet aanpassen (vooral webgames) zal afnemen en daardoor een betere ervaring voor onze gebruikers zal worden geboden.

Het is nu de bedoeling dat deze beleidswijziging in december 2018 wordt uitgerold voor Chrome 71 .

Wat houdt de beleidswijziging precies in?

Autoplay is de naam die wordt gegeven aan een stukje inhoud dat onmiddellijk wordt afgespeeld bij het laden van een webpagina. Voor websites waarvan werd verwacht dat ze hun inhoud automatisch konden afspelen, zal deze wijziging het afspelen standaard voorkomen. In de meeste gevallen wordt het afspelen hervat, maar in andere gevallen is een kleine aanpassing aan de code nodig. Concreet moeten ontwikkelaars code toevoegen die hun inhoud hervat als de gebruiker interactie heeft met de webpagina.

Als de gebruiker echter op een pagina terechtkomt met automatisch afgespeelde inhoud en naar die pagina is genavigeerd vanaf een pagina van dezelfde oorsprong, wordt die inhoud nooit geblokkeerd. Lees onze eerdere blogpost over het autoplay-beleid voor meer gedetailleerde voorbeelden .

Daarnaast hebben we een heuristiek toegevoegd om te leren van het eerdere gedrag van gebruikers met betrekking tot websites die audio automatisch afspelen. We detecteren wanneer gebruikers tijdens de meeste bezoeken aan een website regelmatig audio langer dan zeven seconden laten afspelen, en schakelen automatisch afspelen in voor die website.

We doen dit met een index die lokaal per Chrome-profiel op een apparaat wordt opgeslagen. Deze wordt niet gesynchroniseerd tussen apparaten en wordt alleen gedeeld als onderdeel van de geanonimiseerde gebruikersstatistieken. Deze index noemen we de Media Engagement Index (MEI) en je kunt deze bekijken via chrome://media-engagement.

MEI houdt bij hoeveel bezoeken aan een site een audioweergave bevatten die langer dan 7 seconden duurt. Op basis van de MEI van een gebruiker denken we te kunnen begrijpen of een gebruiker audio van een bepaalde website verwacht of niet – en te kunnen anticiperen op de bedoelingen van de gebruiker in de toekomst.

Als de gebruiker het domein van een website vaak langer dan 7 seconden audio laat afspelen, gaan we ervan uit dat de gebruiker in de toekomst verwacht dat deze website het recht heeft om audio automatisch af te spelen. Daarom verlenen we die website het recht om audio automatisch af te spelen zonder dat de gebruiker interactie heeft met een tabblad van dat domein.

Dit recht is echter niet voor onbepaalde tijd gegarandeerd. Als het gedrag van de gebruiker verandert – bijvoorbeeld het stoppen van het afspelen van audio of het sluiten van het tabblad binnen de drempel van zeven seconden in de loop van meerdere bezoeken – verwijderen we het recht van de website om automatisch af te spelen.

Zowel het gebruik van media-HTML-elementen (video en audio) als webaudio (door JavaScript geïnstantieerde AudioContext-objecten) zullen bijdragen aan de MEI. Ter voorbereiding op de uitrol van dit beleid zal gebruikersgedrag met betrekking tot webaudio vanaf Chrome 70 en later gaan bijdragen aan de MEI. Dit zorgt ervoor dat we al kunnen anticiperen op de gewenste intentie van de gebruiker met betrekking tot autoplay en de websites die ze vaak bezoeken.

Opgemerkt moet worden dat iframes alleen het recht kunnen krijgen om automatisch af te spelen zonder tussenkomst van de gebruiker als de bovenliggende webpagina die het iframe insluit , dat recht uitbreidt naar het gegeven iframe .

Veranderingen uitstellen om de gemeenschap te ondersteunen

De Web Audio-ontwikkelaarsgemeenschap (met name de webgame-ontwikkelaars en WebRTC-ontwikkelaarsgedeelten van deze community) merkte op toen deze wijziging verscheen in het Chrome Stable-kanaal.

De feedback van de community was dat veel webgames en webaudio-ervaringen negatief zouden worden beïnvloed door deze verandering; met name veel sites die niet waren bijgewerkt, zouden niet langer audio afspelen voor gebruikers. Als gevolg hiervan besloot ons team dat het de moeite waard was om deze wijziging uit te stellen, zodat webaudio-ontwikkelaars meer tijd krijgen om hun websites bij te werken.

Daarnaast hebben we deze tijd gebruikt om:

Overweeg serieus of deze beleidswijziging de beste handelwijze was of niet.
Ontdek manieren waarop we kunnen helpen het aantal websites met audio dat hierdoor wordt beïnvloed, te verminderen.

Voor het eerstgenoemde hebben we uiteindelijk besloten dat de beleidswijziging inderdaad noodzakelijk is om de gebruikerservaring voor de meerderheid van onze gebruikers te verbeteren. Meer details over welk probleem de beleidswijziging oplost, kunt u lezen in het volgende gedeelte van dit artikel.

Voor dit laatste hebben we een aanpassing gedaan in onze implementatie voor Web Audio, waardoor het aantal websites dat oorspronkelijk getroffen werd, zal afnemen. Van de sites waarvan we wisten dat ze kapot waren door de verandering – waarvan er vele als voorbeeld werden gegeven door de gemeenschap van webgame-ontwikkelaars – betekende deze aanpassing dat meer dan 80% ervan automatisch zou werken. Onze analyse en testen van deze voorbeeldsites kunt u hier bekijken . Deze nieuwe aanpassing wordt hieronder nader beschreven.

We hebben ook een wijziging aangebracht om WebRTC-applicaties te ondersteunen; zolang er een actieve opnamesessie is, is autoplay toegestaan.

Welk probleem wil deze gedragsverandering oplossen?

Browsers zijn van oudsher slecht in het helpen van de gebruiker bij het beheren van geluid. Wanneer gebruikers een webpagina openen en geluid ontvangen dat ze niet hadden verwacht of gewenst, hebben ze een slechte gebruikerservaring. Deze slechte gebruikerservaring is het probleem dat we proberen op te lossen. Ongewenste ruis is de belangrijkste reden dat gebruikers niet willen dat hun browser inhoud automatisch afspeelt.

Soms willen gebruikers echter dat inhoud automatisch wordt afgespeeld, en vervolgens wordt een aanzienlijk aantal geblokkeerde autoplays in Chrome door de gebruiker afgespeeld.

Daarom geloven wij dat we door van de gebruiker te leren – en per website te anticiperen op hun intentie – de beste gebruikerservaring kunnen creëren. Als gebruikers de neiging hebben om inhoud van een website af te spelen, zullen we in de toekomst de inhoud van die site automatisch afspelen. Omgekeerd, als gebruikers de neiging hebben om het automatisch afspelen van inhoud van een bepaalde website te stoppen, zullen we het automatisch afspelen van die inhoud standaard voorkomen.

Eén voorstel van de community is om de audio van een tabblad te dempen in plaats van het automatisch afspelen te onderbreken. Wij zijn echter van mening dat het beter is om de autoplay-ervaring te stoppen, zodat de website weet dat de autoplay is geblokkeerd en de website-ontwikkelaar hierop kan reageren. Terwijl sommige ontwikkelaars bijvoorbeeld de audio simpelweg willen dempen, geven andere ontwikkelaars er misschien de voorkeur aan dat hun audio-inhoud wordt gepauzeerd totdat de gebruiker actief met de inhoud bezig is – anders mist de gebruiker mogelijk een deel van de audio-ervaring.

Nieuwe aanpassingen om ontwikkelaars van webgames te helpen

De meest voorkomende manier waarop ontwikkelaars de Web Audio API gebruiken, is door twee soorten objecten te maken om audio af te spelen:

Een audiocontext
En AudioNodes , die aan een context zijn gekoppeld

Webaudio-ontwikkelaars zullen een AudioContext creëren voor het afspelen van audio. Om hun audio te hervatten nadat het autoplay-beleid hun AudioContext automatisch heeft opgeschort, moeten ze de CV()-functie op dit object aanroepen nadat de gebruiker interactie heeft gehad met het tabblad:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

Er zijn veel interfaces die overerven van AudioNode, waarvan er één de AudioScheduledSourceNode- interface is. AudioNodes die de AudioScheduledSourceNode-interface implementeren, worden gewoonlijk bronknooppunten genoemd (zoals AudioBufferSourceNode, ConstantSourceNode en OscillatorNode). Bronknooppunten implementeren een start() -methode.

Bronknooppunten vertegenwoordigen doorgaans individuele audiofragmenten die games afspelen, bijvoorbeeld: het geluid dat wordt afgespeeld wanneer een speler een munt verzamelt of de achtergrondmuziek die in de huidige fase wordt afgespeeld. Het is zeer waarschijnlijk dat game-ontwikkelaars de functie start() op bronknooppunten aanroepen wanneer een van deze geluiden nodig is voor het spel.

Toen we dit algemene patroon in webgames herkenden, besloten we onze implementatie aan te passen aan het volgende:

Een AudioContext wordt automatisch hervat als aan twee voorwaarden is voldaan:

De gebruiker heeft interactie gehad met een pagina.
De start()-methode van een bronknooppunt wordt aangeroepen.

Als gevolg van deze wijziging hervatten de meeste webgames nu hun audio wanneer de gebruiker de game begint te spelen.

Het web vooruit helpen

Om het webplatform vooruit te helpen, is het soms nodig om wijzigingen aan te brengen die de compatibiliteit kunnen verstoren. Helaas is het automatisch afspelen van audio complex en valt het in deze categorie van veranderingen. Maar deze verschuiving is van cruciaal belang om ervoor te zorgen dat het web niet stagneert of zijn innovatieve voorsprong verliest.

Niettemin erkennen we dat het toepassen van oplossingen voor websites om verschillende redenen niet altijd op de korte termijn haalbaar is:

Webontwikkelaars kunnen gefocust zijn op een nieuw project en onderhoud aan een oudere website is niet direct mogelijk.
Webgameportals hebben mogelijk geen controle over de implementatie van de games in hun catalogus en het updaten van honderden – zo niet duizenden – games kan tijdrovend en duur zijn voor uitgevers.
Sommige websites zijn misschien gewoon heel oud en worden – om de een of andere reden – niet meer onderhouden, maar worden nog steeds gehost voor historische doeleinden.

Hier is een kort JavaScript-codefragment dat de creatie van nieuwe AudioContext-objecten onderschept en de hervattingsfunctie van deze objecten automatisch activeert wanneer de gebruiker verschillende gebruikersinteracties uitvoert. Deze code moet worden uitgevoerd voordat er AudioContext-objecten op uw webpagina worden gemaakt. U kunt deze code bijvoorbeeld toevoegen aan de tag van uw webpagina:

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

Opgemerkt moet worden dat dit codefragment niet zal helpen bij het hervatten van AudioContexts die binnen een iframe zijn geïnstantieerd, tenzij dit codefragment is opgenomen binnen de reikwijdte van de inhoud van het iframe zelf.

Onze gebruikers beter van dienst zijn

Ter begeleiding van de beleidswijziging introduceren we ook een mechanisme waarmee gebruikers het autoplay-beleid kunnen uitschakelen voor gevallen waarin het automatische leren niet werkt zoals verwacht, of voor websites die door de wijziging onbruikbaar worden gemaakt. Deze wijziging wordt met het nieuwe beleid in Chrome 71 uitgerold en is te vinden in de Geluidsinstellingen; sites waar de gebruiker autoplay wil toestaan, kunnen worden toegevoegd aan de lijst Toestaan.

Hoe is de MEI opgebouwd voor nieuwe gebruikers?

Zoals eerder vermeld, bouwen we de MEI in de loop van de tijd automatisch op, op basis van het gedrag van de gebruiker, om te anticiperen op de gewenste intentie met betrekking tot een bepaalde website met autoplay-inhoud. Elke website heeft een score tussen nul en één in deze index. Hogere scores geven aan dat de gebruiker verwacht dat inhoud van die website wordt afgespeeld.

Voor nieuwe gebruikersprofielen of als een gebruiker zijn browsegegevens wist, wordt in plaats van autoplay overal te blokkeren, een pre-seed-lijst op basis van geanonimiseerde, door gebruikers verzamelde MEI-scores gebruikt om te bepalen welke websites autoplay kunnen gebruiken. Deze gegevens bepalen alleen de initiële status van de MEI bij het aanmaken van het gebruikersprofiel. Terwijl de gebruiker op internet surft en interactie heeft met websites met autoplay-inhoud, overschrijft zijn persoonlijke MEI de standaardconfiguratie.

De vooraf geplaatste sitelijst wordt algoritmisch gegenereerd in plaats van handmatig samengesteld, en elke website komt in aanmerking om te worden opgenomen. Sites worden aan de lijst toegevoegd als voldoende gebruikers die die site bezoeken autoplay op die site toestaan. Deze drempel is gebaseerd op een percentage, om grotere sites niet te bevoordelen.

Balans vinden

We hebben nieuwe documentatie geplaatst om meer inzicht te geven in ons besluitvormingsproces en de ontwerpgrondslag achter dit beleid. Evenals nieuwe documentatie over hoe de vooraf geplaatste sitelijst werkt .

We stellen onze gebruikers altijd op de eerste plaats, maar we willen ook de webontwikkelingsgemeenschap niet in de steek laten. Soms betekent het feit dat je de browser bent, dat deze twee doelen zorgvuldig met elkaar in evenwicht moeten worden gebracht. We zijn van mening dat we met onze aanpassingen aan de implementatie van het beleid en de extra tijd die we webaudio-ontwikkelaars hebben gegeven om hun code bij te werken, dit evenwicht zullen bereiken met Chrome 71.

Feedback

Tom Greenaway

Hongchan Choi

Het is nu de bedoeling dat deze beleidswijziging in december 2018 wordt uitgerold voor Chrome 71 .

Wat houdt de beleidswijziging precies in?

Veranderingen uitstellen om de gemeenschap te ondersteunen

De Web Audio-ontwikkelaarsgemeenschap (met name de webgame-ontwikkelaars en WebRTC-ontwikkelaarsgedeelten van deze community) merkte op toen deze wijziging verscheen in het Chrome Stable-kanaal.

Daarnaast hebben we deze tijd gebruikt om:

Overweeg serieus of deze beleidswijziging de beste handelwijze was of niet.
Ontdek manieren waarop we kunnen helpen het aantal websites met audio dat hierdoor wordt beïnvloed, te verminderen.

We hebben ook een wijziging aangebracht om WebRTC-applicaties te ondersteunen; zolang er een actieve opnamesessie is, is autoplay toegestaan.

Welk probleem wil deze gedragsverandering oplossen?

Soms willen gebruikers echter dat inhoud automatisch wordt afgespeeld, en vervolgens wordt een aanzienlijk aantal geblokkeerde autoplays in Chrome door de gebruiker afgespeeld.

Nieuwe aanpassingen om ontwikkelaars van webgames te helpen

De meest voorkomende manier waarop ontwikkelaars de Web Audio API gebruiken, is door twee soorten objecten te maken om audio af te spelen:

Een audiocontext
En AudioNodes , die aan een context zijn gekoppeld

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

Toen we dit algemene patroon in webgames herkenden, besloten we onze implementatie aan te passen aan het volgende:

Een AudioContext wordt automatisch hervat als aan twee voorwaarden is voldaan:

De gebruiker heeft interactie gehad met een pagina.
De start()-methode van een bronknooppunt wordt aangeroepen.

Als gevolg van deze wijziging hervatten de meeste webgames nu hun audio wanneer de gebruiker de game begint te spelen.

Het web vooruit helpen

Niettemin erkennen we dat het toepassen van oplossingen voor websites om verschillende redenen niet altijd op de korte termijn haalbaar is:

Webontwikkelaars kunnen gefocust zijn op een nieuw project en onderhoud aan een oudere website is niet direct mogelijk.
Webgameportals hebben mogelijk geen controle over de implementatie van de games in hun catalogus en het updaten van honderden – zo niet duizenden – games kan tijdrovend en duur zijn voor uitgevers.
Sommige websites zijn misschien gewoon heel oud en worden – om de een of andere reden – niet meer onderhouden, maar worden nog steeds gehost voor historische doeleinden.

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

Opgemerkt moet worden dat dit codefragment niet zal helpen bij het hervatten van AudioContexts die binnen een iframe worden geïnstantieerd, tenzij dit codefragment is opgenomen binnen de reikwijdte van de inhoud van het iframe zelf.

Onze gebruikers beter van dienst zijn

Hoe is de MEI opgebouwd voor nieuwe gebruikers?

Zoals eerder vermeld, bouwen we de MEI automatisch in de loop van de tijd op basis van het gedrag van de gebruiker om te anticiperen op de gewenste intentie met betrekking tot een bepaalde website met autoplay-inhoud. Elke website heeft een score tussen nul en één in deze index. Hogere scores geven aan dat de gebruiker verwacht dat inhoud van die website wordt afgespeeld.

Balans vinden

Feedback

Tom Greenaway

Hongchan Choi

Het is nu de bedoeling dat deze beleidswijziging in december 2018 wordt uitgerold voor Chrome 71 .

Wat houdt de beleidswijziging precies in?

Veranderingen uitstellen om de gemeenschap te ondersteunen

De Web Audio-ontwikkelaarsgemeenschap (met name de webgame-ontwikkelaars en WebRTC-ontwikkelaarsgedeelten van deze community) merkte op toen deze wijziging verscheen in het Chrome Stable-kanaal.

Daarnaast hebben we deze tijd gebruikt om:

Overweeg serieus of deze beleidswijziging de beste handelwijze was of niet.
Ontdek manieren waarop we kunnen helpen het aantal websites met audio dat hierdoor wordt beïnvloed, te verminderen.

We hebben ook een wijziging aangebracht om WebRTC-applicaties te ondersteunen; zolang er een actieve opnamesessie is, is autoplay toegestaan.

Welk probleem wil deze gedragsverandering oplossen?

Soms willen gebruikers echter dat inhoud automatisch wordt afgespeeld, en vervolgens wordt een aanzienlijk aantal geblokkeerde autoplays in Chrome door de gebruiker afgespeeld.

Nieuwe aanpassingen om ontwikkelaars van webgames te helpen

De meest voorkomende manier waarop ontwikkelaars de Web Audio API gebruiken, is door twee soorten objecten te maken om audio af te spelen:

Een audiocontext
En AudioNodes , die aan een context zijn gekoppeld

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

Toen we dit algemene patroon in webgames herkenden, besloten we onze implementatie aan te passen aan het volgende:

Een audiocontext wordt automatisch hervat wanneer aan twee voorwaarden wordt voldaan:

De gebruiker heeft interactie met een pagina.
De methode Start () van een bronknooppunt wordt aangeroepen.

Vanwege deze wijziging zullen de meeste webgames nu hun audio hervatten wanneer de gebruiker het spel begint te spelen.

Het web vooruit verplaatsen

Om het webplatform vooruit te helpen, is het soms nodig om wijzigingen aan te brengen die de compatibiliteit kunnen doorbreken. Helaas is Audio Autoplay complex en valt in deze categorie van verandering. Maar het maken van deze verschuiving is van cruciaal belang om ervoor te zorgen dat het web niet stagneert of zijn innovatieve voorsprong verliest.

Desalniettemin erkennen we dat het toepassen van fixes voor websites om verschillende redenen niet altijd op korte termijn haalbaar is:

Webontwikkelaars zijn mogelijk gericht op een nieuw project en onderhoud aan een oudere website is niet meteen mogelijk.
Web gameportals hebben mogelijk geen controle over de implementatie van de games in hun catalogus en het bijwerken van honderden - zo niet duizenden - van games kunnen tijdrovend en duur zijn voor uitgevers.
Sommige websites kunnen gewoon heel oud zijn en - om de een of andere reden - worden niet langer onderhouden maar nog steeds gehost voor historische doeleinden.

Hier is een kort JavaScript -codefragment dat het maken van nieuwe Audiocontext -objecten onderschept en de CV -functie van deze objecten autotrigger wanneer de gebruiker verschillende gebruikersinteracties uitvoert. Deze code moet worden uitgevoerd vóór het maken van audiocontext -objecten in uw webpagina - u kunt bijvoorbeeld deze code toevoegen aan de Tag van uw webpagina:

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();

Opgemerkt moet worden dat dit codefragment niet zal helpen bij het hervatten van audiocontexts die worden geïnstantieerd binnen een IFRAME, tenzij dit code -fragment wordt opgenomen binnen de reikwijdte van de inhoud van de IFRAME zelf.

Onze gebruikers beter bedienen

Bij de beleidsverandering introduceren we ook een mechanisme voor gebruikers om het autoplaybeleid uit te schakelen om de gevallen te dekken waarin het automatische leren niet werkt zoals verwacht, of voor websites die onbruikbaar worden gemaakt door de wijziging. Deze wijziging zal worden uitgerold met het nieuwe beleid in Chrome 71 en is te vinden in de geluidsinstellingen; Sites waar de gebruiker AutoPlay wil toestaan, kunnen worden toegevoegd aan de lijst Vermogen.

Hoe wordt de MEI geconstrueerd voor nieuwe gebruikers?

Zoals eerder vermeld, bouwen we de MEI automatisch in de loop van de tijd op basis van het gedrag van de gebruiker om te anticiperen op hun gewenste intentie met betrekking tot een bepaalde website met autoplay -inhoud. Elke website heeft een score tussen nul en één in deze index. Hogere scores geven aan dat de gebruiker verwacht dat inhoud van die website zal spelen.

Voor nieuwe gebruikersprofielen of als een gebruiker zijn browsegegevens wist, wordt echter in plaats van AutoPlay overal te blokkeren, een pre-seed-lijst op basis van geanonimiseerde geaggregeerde MEI-scores van de gebruiker gebruikt om te bepalen welke websites automatisch kunnen autoplay. Deze gegevens bepalen alleen de initiële status van de MEI bij het maken van het gebruikersprofiel. Terwijl de gebruiker op het web bladert en interactie heeft met websites met autoplay -inhoud, overschrijft hun persoonlijke Mei de standaardconfiguratie.

De sitelijst voor vooraf geplaatste sites wordt algoritmisch gegenereerd in plaats van handmatig samengesteld, en elke website komt in aanmerking om te worden opgenomen. Sites worden aan de lijst toegevoegd als voldoende gebruikers die die site bezoeken, autoplay op die site toestaat. Deze drempel is gebaseerd op percentage om grotere sites niet te begunstigen.

Balans vinden

We hebben nieuwe documentatie gepost om meer inzicht te geven in ons besluitvormingsproces en de ontwerprationale achter dit beleid. Evenals nieuwe documentatie over hoe de sitelijst voor vooraf geplaatste sites werkt .

We hebben onze gebruikers altijd op de eerste plaats gezet, maar we willen ook de Web Development Community niet in de steek laten. Soms betekent de browser dat deze twee doelen zorgvuldig moeten worden gebalanceerd. Wij zijn van mening dat met onze aanpassingen aan de implementatie van het beleid en de extra tijd die we voor webaudio -ontwikkelaars hebben gegeven om hun code bij te werken, dat we dit saldo zullen bereiken met Chrome 71.

Feedback

Tom Greenaway

Hongchan Choi

In september 2017 hebben we een komende wijziging aangekondigd in hoe audio zou worden afgehandeld met AutoPlay -gedragsbeleid in Chrome. De beleidsverandering werd vrijgegeven met Chrome 66 stabiel in mei 2018.

Na feedback van de Web Audio Development Community hebben we de release van het webaudiogedeelte van het AutoPlay -beleid vertraagd om ontwikkelaars meer tijd te geven om hun websites bij te werken. We hebben ook enkele wijzigingen aangebracht in de implementatie van het beleid voor webaudio, wat het aantal websites zal verminderen dat hun code moet aanpassen - vooral webgames - en daarom een betere ervaring bieden voor onze gebruikers.

Deze beleidswijziging is nu gepland om uit te rollen met Chrome 71 in december 2018 .

Wat doet de beleidsverandering precies?

Autoplay is de naam gegeven aan een stuk inhoud dat onmiddellijk speelt bij het laden van een webpagina. Voor websites die naar verwachting hun inhoud naar verwachting zullen kunnen automatisch opdagen, voorkomt deze wijziging standaard het afspelen. In de meeste gevallen zal het afspelen worden hervat, maar in andere is een kleine aanpassing aan de code nodig. In het bijzonder moeten ontwikkelaars code toevoegen die hun inhoud hervat als de gebruiker interactie heeft met de webpagina.

Als de gebruiker echter op een pagina aankomt met autoplay -inhoud en zij navigeerden naar die pagina van een pagina van dezelfde oorsprong, wordt die inhoud nooit geblokkeerd. Lees ons eerdere blogbericht over het AutoPlay -beleid voor meer gedetailleerde voorbeelden .

Bovendien hebben we een heuristiek toegevoegd om te leren van het gedrag van gebruikers in het verleden met betrekking tot websites die AutoPlay Audio AutoPlay AutoPlay hebben. We detecteren wanneer gebruikers tijdens de meeste van hun bezoeken aan een website regelmatig meer dan 7 seconden meer dan 7 seconden laten spelen en autoplay voor die website mogelijk maken.

We doen dit met een index die lokaal per chroomprofiel op een apparaat wordt opgeslagen - het wordt niet gesynchroniseerd op apparaten en wordt alleen gedeeld als onderdeel van de geanonimiseerde gebruikersstatistieken. We noemen deze index de Media Engagement Index (MEI) en u kunt deze bekijken via Chrome: // Media-Engagement.

Mei houdt bij hoeveel bezoeken aan een site audio -afspelen omvatten die meer dan 7 seconden lang is. Op basis van de Mei van een gebruiker geloven we dat we kunnen begrijpen of een gebruiker audio van een bepaalde website verwacht of niet - en anticiperen op de intentie van de gebruiker in de toekomst.

Als de gebruiker vaak het domein van een website meer dan 7 seconden laat spelen, gaan we ervan uit dat de gebruiker verwacht dat deze website het recht heeft om audio te autoplay hebben. Daarom geven we die website het recht op AutoPlay Audio toe zonder dat de gebruiker moet communiceren met een tabblad van dat domein.

Dit recht is echter niet voor onbepaalde tijd gegarandeerd. Als het gedrag van de gebruiker schakelt - bijvoorbeeld het stoppen van het afspelen van de audio of het afsluiten van het tabblad binnen de 7 seconden drempel in de loop van verschillende bezoeken - verwijderen we het recht van de website om te autoplay.

Zowel gebruik van media HTML -elementen (video en audio) als webaudio (JavaScript Instantiated Audiocontext Objects) zullen bijdragen aan de MEI. Ter voorbereiding op de uitrol van dit beleidsgebruikersgedrag met betrekking tot webaudio zal beginnen bij te dragen aan de MEI van Chrome 70 en verder. Dit zal ervoor zorgen dat we al in staat zijn om te anticiperen op de gewenste intentie van de gebruiker met betrekking tot AutoPlay en de websites die ze vaak bezoeken.

Opgemerkt moet worden dat IFRAMES alleen het recht kan krijgen om autoplay te autoplay zonder gebruikersinteractie als de bovenliggende webpagina die de IFRAME ingesloten , dat recht uitbreidt naar het gegeven iframe .

Verandering uitstellen om de gemeenschap te ondersteunen

De Web Audio Developer Community - met name de webspelontwikkelaar en WEBRTC -ontwikkelaar delen van deze community - merkte op toen deze wijziging verscheen in het Chrome Stable Channel.

De feedback van de gemeenschap was dat veel webgames en webaudio -ervaringen door deze verandering negatief zouden worden beïnvloed - met name, veel sites die niet werden bijgewerkt, zouden geen audio meer voor gebruikers spelen. Als gevolg hiervan besloot ons team dat het de moeite waard was om deze wijziging uit te stellen om webaudio -ontwikkelaars meer tijd te geven om hun websites bij te werken.

Bovendien hebben we deze tijd overgenomen om:

Overweeg serieus of deze beleidsverandering de beste manier van handelen was of niet.
Ontdek manieren waarop we kunnen helpen het aantal websites met audio te verminderen dat zou worden beïnvloed.

Voor het eerste hebben we uiteindelijk besloten dat de beleidsverandering inderdaad noodzakelijk is om de gebruikerservaring voor de meeste van onze gebruikers te verbeteren. Meer details over welk probleem de beleidsverandering is om te oplossen, kan in de volgende sectie van dit artikel worden gelezen.

Voor dit laatste hebben we een aanpassing aangepast aan onze implementatie voor webaudio die het aantal websites dat oorspronkelijk werd beïnvloed, zal verminderen. Van de sites die we kenden, werden gebroken door de verandering - waarvan vele werden gegeven als voorbeelden van de community voor de ontwikkeling van webgames - betekende deze aanpassing dat meer dan 80% van hen automatisch zou werken. Onze analyse en testen van deze voorbeeldsites kunnen hier worden bekeken . Deze nieuwe aanpassing wordt hieronder in meer detail beschreven.

We hebben ook een wijziging aangebracht om WebRTC -toepassingen te ondersteunen; Hoewel er een actieve vastlegsessie is, is AutoPlay toegestaan.

Welk probleem is deze gedragsverandering gericht op het oplossen?

Browsers zijn van oudsher slecht geweest in het helpen van de gebruiker om geluid te beheren. Wanneer gebruikers een webpagina openen en geluid ontvangen die ze niet hadden verwacht of willen, hebben ze een slechte gebruikerservaring. Deze slechte gebruikerservaring is het probleem dat we proberen op te lossen. Ongewenste ruis is de belangrijkste reden dat gebruikers niet willen dat hun browser inhoud autoplay autoplay autoplay.

Soms willen gebruikers echter dat inhoud autoplay wordt, en een zinvol aantal geblokkeerde autoplays in Chrome worden vervolgens door de gebruiker gespeeld.

Daarom geloven we door te leren van de gebruiker - en anticiperen op hun intentie per website - kunnen we de beste gebruikerservaring creëren. Als gebruikers de neiging hebben om inhoud van een website te laten spelen, zullen we in de toekomst inhoud van die site automatisch opduiken. Omgekeerd, als gebruikers de neiging hebben om autoplay -inhoud van een bepaalde website te stoppen, voorkomen we standaard AutoPlay voor die inhoud.

Een voorstel van de gemeenschap is geweest om de audio van een tabblad te dempen in plaats van de autoplay te pauzeren. Wij geloven echter dat het beter is om de autoplay -ervaring te stoppen, zodat de website zich ervan bewust is dat de autoplay is geblokkeerd en de website -ontwikkelaar hierop in staat te stellen hierop te reageren. Hoewel sommige ontwikkelaars bijvoorbeeld misschien audio willen dempen, kunnen andere ontwikkelaars misschien de voorkeur geven aan hun audio -inhoud dat wordt gepauzeerd totdat de gebruiker actief met de inhoud omgaat - anders kan de gebruiker een deel van de audio -ervaring missen.

Nieuwe aanpassingen om webspelontwikkelaars te helpen

De meest voorkomende manier waarop ontwikkelaars de Web Audio API gebruiken, is door twee soorten objecten te maken om audio te spelen:

Een audiocontext
En audionoden , die aan een context zijn verbonden

Web audio -ontwikkelaars maken een audiocontext voor het spelen van audio. Om hun audio te hervatten nadat het AutoPlay -beleid hun audiocontext automatisch heeft opgeschort, moeten ze de functie hervatten () op dit object oproepen nadat de gebruiker met het tabblad interageert:

    const context = new AudioContext();

    // Setup an audio graph with AudioNodes and schedule playback.
    ...

    // Resume AudioContext playback when user clicks a button on the page.
    document.querySelector('button').addEventListener('click', function() {
      context.resume().then(() => {
        console.log('AudioContext playback resumed successfully');
      });
    });

Er zijn veel interfaces die erven van audionode, waarvan er één de interface met audioscheduledsourcenode is. Audionodes die de audioscheduledsourcenode -interface implementeren, worden gewoonlijk bronknooppunten genoemd (zoals AudioBuffersourCenode, ConstantSourcenode en Oscillatornode). Bronknooppunten implementeren een methode start ().

Bronknooppunten vertegenwoordigen gewoonlijk individuele audiofragmenten die games spelen, bijvoorbeeld: het geluid dat wordt gespeeld wanneer een speler een munt verzamelt of de achtergrondmuziek die in het huidige podium speelt. Game -ontwikkelaars zullen zeer waarschijnlijk de functie Start () op bronknooppunten oproepen wanneer een van deze geluiden nodig is voor het spel.

Zodra we dit gemeenschappelijke patroon in webspellen hebben herkend, hebben we besloten om onze implementatie aan het volgende aan te passen:

Een audiocontext wordt automatisch hervat wanneer aan twee voorwaarden wordt voldaan:

De gebruiker heeft interactie met een pagina.
De methode Start () van een bronknooppunt wordt aangeroepen.

Vanwege deze wijziging zullen de meeste webgames nu hun audio hervatten wanneer de gebruiker het spel begint te spelen.

Het web vooruit verplaatsen

Desalniettemin erkennen we dat het toepassen van fixes voor websites om verschillende redenen niet altijd op korte termijn haalbaar is:

Webontwikkelaars zijn mogelijk gericht op een nieuw project en onderhoud aan een oudere website is niet meteen mogelijk.
Web gameportals hebben mogelijk geen controle over de implementatie van de games in hun catalogus en het bijwerken van honderden - zo niet duizenden - van games kunnen tijdrovend en duur zijn voor uitgevers.
Sommige websites kunnen gewoon heel oud zijn en - om de een of andere reden - worden niet langer onderhouden maar nog steeds gehost voor historische doeleinden.

(function () {
  // An array of all contexts to resume on the page
  const audioContextList = [];

  // An array of various user interaction events we should listen for
  const userInputEventNames = [
    'click',
    'contextmenu',
    'auxclick',
    'dblclick',
    'mousedown',
    'mouseup',
    'pointerup',
    'touchend',
    'keydown',
    'keyup',
  ];

  // A proxy object to intercept AudioContexts and
  // add them to the array for tracking and resuming later
  self.AudioContext = new Proxy(self.AudioContext, {
    construct(target, args) {
      const result = new target(...args);
      audioContextList.push(result);
      return result;
    },
  });

  // To resume all AudioContexts being tracked
  function resumeAllContexts(event) {
    let count = 0;

    audioContextList.forEach(context => {
      if (context.state !== 'running') {
        context.resume();
      } else {
        count++;
      }
    });

    // If all the AudioContexts have now resumed then we
    // unbind all the event listeners from the page to prevent
    // unnecessary resume attempts
    if (count == audioContextList.length) {
      userInputEventNames.forEach(eventName => {
        document.removeEventListener(eventName, resumeAllContexts);
      });
    }
  }

  // We bind the resume function for each user interaction
  // event on the page
  userInputEventNames.forEach(eventName => {
    document.addEventListener(eventName, resumeAllContexts);
  });
})();