Consumer Reports: Apple verteilt Fix für inkonsistente Akkulaufzeiten des neuen MacBook Pro
Neulich checkte Consumer Reports die neuen Modelle des MacBook Pro. Eine Empfehlung für Kunden gab es nicht, aus einem einfachen Grund: Die Akkulaufzeit war nicht konstant genug, um einen verlässlichen Wert zu liefern. Laufzeiten zwischen 4 und 18 Stunden wurden mit dem gleichen Test auf demselben Gerät erreicht, keine verlässliche Aussage über die mögliche Laufzeit. Das Verhalten der MacBooks war in den Tests schlichtweg nicht nachvollziehbar. Consumer Reports wandte sich dann vor der Veröffentlichung der Ergebnisse an Apple und lieferte auch danach noch Infos zu den Tests nach Cupertino.
Das Resultat ist nun, dass Apple in der aktuellen macOS Beta einen Fix verteilt, der den Test aussagekräftiger machen soll. Die Inkonsistenz der Testergebnisse soll auf einen Bug in Safari zurückzuführen sein. Ausgelöst durch eine Einstellung, die für Entwickler gedacht ist, zeigt Safari dann das Verhalten, das zu einer kurzen Akkulaufzeit führt. Auch Caching spielt eine große Rolle.
Consumer Reports testet die Laufzeit immer mit ausgeschaltetem Caching von Webseiten, jede Seite wird also immer wieder neu geladen. Keine Einstellung, die für den Nutzer vorgesehen ist, aber ebenfalls für niedrigere Laufzeiten sorgt. Consumer Reports selbst berichtet, dass nach aktiviertem Caching die Laufzeiten der MacBooks konstant hoch waren.
Nun wird Consumer Reports noch einmal testen, mit dem Fix, der von Apple verteilt wird und die Ergebnisse entsprechend anpassen. Für MacBook-Nutzer, die nicht an Apples Beta-Programm teilnehmen, wird der Fix dann in ein paar Wochen im Zuge eines größeren Software-Updates verteilt. Die neuen Testergebnisse von Consumer Reports soll es ebenfalls bald geben.
Wird geladen ...
VW hat doch auch nur einen Bug auf dem Prüfstand gefixt, oder? 🙂
Ok, aber wer nicht mit den Cache-Settings von Safari gespielt hat, wird wohl keine Verbesserung der Akkulaufzeit durch das Update erfahren?
Wer nicht mit den Settings rumspielt hat sowieso konstante Laufzeiten. So verstehe ich das jedenfalls.
Ja, entweder konstant gute oder konstant schlechte.
Trotzdem macht der Test con Consumer Reports keinen SInn, die müssen einen weiteren systematischen fehler im Versuchsaufbau gaben, da sie nicht nur knapp 3 Stunden sondern auch 19 Stunden laufzeit gemessen hatten – So ein grosser Ausreisser nach oben (190% von dem was Apple verspricht) kann kein Safari Bug sein.
@bergzierde
Das ist richtig. In den erweiterten Einstellungen in Safari kann man das Entwickler-Menü aktivieren, dann dort den Cache deaktivieren. Ein deaktivierter Cache ist wichtig für JS und CSS Debugging. So werden Assets nicht aus dem Cache genommen sondern immer die aktuelle Version vom Server. Geht auch per Shortcut (Command-R, bzw Ctrl-F5 in Windows), ist aber nervig beim arbeiten.
Das Testszenario ist schon recht grenzwertig und spiegelt nicht gerade den Durchschnittsnutzer wieder.
@Kashif
Kann sich auch um Interferenzen handeln. Andere Geräte mit WiFi oder Bluetooth (Notebook, Smartphones, Lautsprecher), selbst Ladegeräte usw haben Auswirkungen auf das WiFi. Befinden sich viele Leuten im Büro müssen die Antennen ständig mit höherer Leistung gefahren werden. Verabschieden sich die meisten und der Test läuft weiter dann fahren die Antennen die Leistung runter. Ist zBsp auch bei Smartphones so. Bei schlechtem Empfang ist der Akku viel schneller runter.
Ich stelle mir das so vor, dass die halt im Test nur eine Handvoll von Seiten immer weider aufrufen. Um aber einen Nutzer zu simulieren, der wahrscheinlich über 10 h am Rechner auch viele Seiten ansteuert, die nicht schon gechachet sind, haben sie den Cahce-deaktiviert. In diesem Sinne scheint mir das aktivieren dieser Option jetzt gar nicht so völlig realitätsfern und grenzwertig.
@Juzam
Eigentlich ist das Gegenteil der Fall. Beispiel: die Page Weight von dem Artikel hier ist 1,71 MB. Das ist ziemlich hoch ist. Dabei sind Bilder und HTML aber noch der kleinste Anteil, nur 3% (!). Der Rest sind Javascript und CSS. Die befinden sich im Cache. Wenn du vorher einen anderen Artikel gelesen hast muss ein Grossteil der Ressourcen nicht geladen werden. Das funktioniert oft auch Seitenübergreifend weil viel von Google, WordPress, etc selbst gehostet wird, der ganze Kram von Facebook, Twitter etc ebenfalls. Auch das grösste Bild, das Logo oben, ist im Cache (das könnte man übrigens mit nahezu verlustfreier PNG-Kompression um 50% reduzieren).