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.