Mais do que um meme: o Google usa TheVerge.com para avaliar dispositivos Nexus

Parece que o Google carrega a página inicial do The Verge ao realizar testes de automação de carga de trabalho em todos os seus dispositivos Nexus.

Explorar o AOSP é uma ótima maneira de fazer novas descobertas sobre o Android, e desta vez encontramos algo bastante hilário. Por algum tempo, usuários relataram que o site de tecnologia TheVerge. com forneceu desempenho lento em dispositivos móveis.

Agora, para crédito deles, o desempenho do site melhorou ao longo do tempo, na minha experiência. Além disso, não é como se outros sites (incluindo o nosso) não tivessem problemas nos quais possamos nos esforçar para resolver, mas mesmo assim achei bastante divertido que, em sua forma conjunto oficial de benchmarks de carga de trabalho, o Google decidiu usar The Verge em seus testes.


Automação de carga de trabalho Android

Automação de carga de trabalho (WA) é uma estrutura desenvolvida por BRAÇO para coletar dados de desempenho em dispositivos Android executando um conjunto de muitas cargas de trabalho repetíveis. O Google avalia o desempenho de seus dispositivos realizando muitos desses testes de carga de trabalho e coletando um resumo de uso de energia, que eles importam para uma planilha para ver como suas otimizações melhoraram o desempenho em relação tempo. A empresa escolhe quais aplicativos incluir em seu conjunto de testes, mas em geral eles se limitam à maioria dos aplicativos populares do Google. Essa é a essência de como funciona, mas mostraremos as evidências do código-fonte e descreveremos o teste suites com mais detalhes para que você possa ter uma ideia melhor do que os testes automatizados que o Google faz para medir desempenho.

Dentro do AOSP, existe um diretório dedicado aos testes de automação de carga de trabalho. Os aplicativos usados ​​para teste são definidos em defs.she geralmente se enquadram em uma de duas categorias: Google App padrão pré-instalado ou navegador da Web de terceiros. Um aplicativo de referência se destaca dos demais e é com.BrueComputing.SunTemple/com.epicgames.ue4.GameActivity que presumo que se refere ao Revisor BrueBench ST benchmark que é baseado no Unreal Engine 4.

# default activities. Can dynamically generate with -g.
gmailActivity='com.google.android.gm/com.google.android.gm.ConversationListActivityGmail'
clockActivity='com.google.android.deskclock/com.android.deskclock.DeskClock'
hangoutsActivity='com.google.android.talk/com.google.android.talk.SigningInActivity'
chromeActivity='com.android.chrome/_not_used'
contactsActivity='com.google.android.contacts/com.android.contacts.activities.PeopleActivity'
youtubeActivity='com.google.android.youtube/com.google.android.apps.youtube.app.WatchWhileActivity'
cameraActivity='com.google.android.GoogleCamera/com.android.camera.CameraActivity'
playActivity='com.android.vending/com.google.android.finsky.activities.MainActivity'
feedlyActivity='com.devhd.feedly/com.devhd.feedly.Main'
photosActivity='com.google.android.apps.photos/com.google.android.apps.photos.home.HomeActivity'
mapsActivity='com.google.android.apps.maps/com.google.android.maps.MapsActivity'
calendarActivity='com.google.android.calendar/com.android.calendar.AllInOneActivity'
earthActivity='com.google.earth/com.google.earth.EarthActivity'
calculatorActivity='com.google.android.calculator/com.android.calculator2.Calculator'
calculatorLActivity='com.android.calculator2/com.android.calculator2.Calculator'
sheetsActivity='com.google.android.apps.docs.editors.sheets/com.google.android.apps.docs.app.NewMainProxyActivity'
docsActivity='com.google.android.apps.docs.editors.docs/com.google.android.apps.docs.app.NewMainProxyActivity'
operaActivity='com.opera.mini.native/com.opera.mini.android.Browser'
firefoxActivity='org.mozilla.firefox/org.mozilla.firefox.App'
suntempleActivity='com.BrueComputing.SunTemple/com.epicgames.ue4.GameActivity'
homeActivity='com.google.android.googlequicksearchbox/com.google.android.launcher.GEL'

Essas atividades são iniciadas por meio da linha de comando do ADB com o seguinte Systrace opções para medir o desempenho do aplicativo:

dflttracecategories="gfx input view am rs power sched freq idle load memreclaim"

O aplicativo Chrome em particular é iniciado com um sinalizador para carregar o The Verge:

Quanto ao motivo pelo qual o teste parece diferir para o volantis (Nexus 9), não tenho certeza. De qualquer forma, quanto aos testes pelos quais essa atividade do Chrome com The Verge realmente passa, podemos determinar observando o código-fonte dos testes de automação de carga de trabalho.


Conjuntos de testes

Primeiro, há o systemapps.sh teste, que o Google afirma que funciona como tal:

# Script to start a set of apps in order and then in each iteration
# switch the focus to each one. For each iteration, the time to start
# the app is reported as measured using atrace events and via am ThisTime.
# The output also reports if applications are restarted (eg, killed by
# LMK since previous iteration) or if there were any direct reclaim
# events.

A seguir, há o recentefling.sh teste, que funciona assim:

# Script to start a set of apps, switch to recents and fling it back and forth.
# For each iteration, Total frames and janky frames are reported.

E então há chromefling.sh, que testa o desempenho do Chrome de forma bastante simples:

# Script to start 3 chrome tabs, fling each of them, repeat
# For each iteration, Total frames and janky frames are reported.

Outro teste divertido no pacote Workload Automation, embora não relacionado ao The Verge, é o youtube.sh teste de desempenho que mede a instabilidade da interface do usuário

#
# Script to play a john oliver youtube video N times.
# For each iteration, Total frames and janky frames are reported.
#
# Options are described below.
#
iterations=10
app=youtube
searchText="last week tonight with john oliver: online harassment"
vidMinutes=15

Finalmente, cada um desses testes é usado para medir o uso de energia no mundo real, percorrendo-os por um determinado período de tempo, conforme definido em pwrtest.sh:

# Script to gather perf and perf/watt data for several workloads
#
# Setup:
#
# - device connected to monsoon with USB passthrough enabled
# - network enabled (baseline will be measured and subtracted
# from results) (network needed for chrome, youtube tests)
# - the device is rebooted after each test (can be inhibited
# with "-r 0")
#
# Default behavior is to run each of the known workloads for
# 30 minutes gathering both performance and power data.

O Google pode então coletar esses dados usando pwrsummary.sh e importe-os para uma planilha:

# print summary of output generated by pwrtest.sh
#
# default results directories are -[-experiment]. By default
# match any device and the year 201*.
#
# Examples:
#
# - show output for all bullhead tests in july 2015:
# ./pwrsummary.sh -r "bh-201507*"
#
# - generate CSV file for import into spreadsheet:
# ./pwrsummary.sh -o csv
#

Todos esses são testes de desempenho de UI bastante comuns no mundo real, não muito diferentes dos tipos que você veria em nossos próprios testes. Parece que a mudança para carregar a página inicial do The Verge ao abrir o Chrome foi bastante recente, já que antes do ano passado o Google só abria uma nova aba no Chrome durante esses testes. Uma mudança feita em 28 de maio de 2015 introduziu o uso do The Verge ao testar o Chrome, no entanto. Por mais divertido que seja que o Google esteja usando The Verge de todos os lugares ao realizar a automação de carga de trabalho testes, lembre-se de que isso não significa que The Verge seja o pior infrator da web desempenho.

Longe disso, na verdade, já que muitas outras páginas da web sofrem de desempenho medíocre graças à proliferação de cada vez mais anúncios para compensar o aumento dos bloqueadores de anúncios. Na verdade, é mais provável que a decisão de usar The Verge tenha sido simplesmente uma questão de conveniência, dada a forma como a tecnologia experiente que o Googler médio é e a piada interna entre muitos entusiastas sobre a página da web do The Verge desempenho.