Jak stworzyliśmy warstwę OWL, nową architekturę dla naszej przeglądarki ChatGPT Atlas

Autorzy: Ken Rockot, członek personelu technicznego, oraz Ben Goodger, kierownik ds. inżynierii, ChatGPT Atlas

W zeszłym tygodniu udostępniliśmy przeglądarkę ChatGPT Atlas⁠, która zapewnia nowy sposób przeglądania sieci z ChatGPT u boku. Atlas to nie tylko w pełni funkcjonalna przeglądarka internetowa, to także zwiastun przyszłości: świata, w którym z ChatGPT będzie można korzystać wszędzie w sieci, zadając pytania, uzyskując sugestie i zlecając automatyczne wykonywanie zadań. W tym wpisie omówimy jeden z najbardziej złożonych aspektów technicznych tego produktu: przekształcenie ChatGPT w przeglądarkę, która w miarę korzystania z niej staje się coraz bardziej przydatna.

Uczynienie z ChatGPT prawdziwego partnera podczas korzystania z sieci wymagało wymyślenia na nowo całej architektury przeglądarki: oddzielenia przeglądarki ChatGPT Atlas od środowiska uruchomieniowego Chromium. Wymagało to opracowania nowego sposobu integracji projektu Chromium, który pozwoliłby nam zrealizować nasze cele dotyczące produktu: błyskawiczne uruchamianie, szybkie działanie nawet przy dużej liczbie otwartych kart oraz stworzenie solidnego fundamentu dla zastosowań agentowych.

Uznaliśmy, że Chromium będzie idealną podstawą do budowy naszego rozwiązania. Ma silnik internetowy z najnowocześniejszymi rozwiązaniami i solidnym modelem zabezpieczeń oraz charakteryzuje się udowodnioną wydajnością i doskonałą zgodnością internetową. Co więcej, jest rozwijany przez globalną społeczność, która nieustannie ulepsza ten projekt. Jest także powszechnie stosowany w nowoczesnych przeglądarkach internetowych na komputery stacjonarne.

Nasz utalentowany zespół projektantów postawił sobie ambitne cele dotyczące interfejsu użytkownika, w tym złożone animacje i efekty wizualne dla funkcji takich jak tryb agenta. Aby można było je zrealizować, nasz zespół inżynierów musiał opracować interfejs użytkownika przy użyciu najnowszych natywnych frameworków (SwiftUI, AppKit i Metal), zamiast po prostu stworzyć nową skórkę dla projektu open source Chromium. W rezultacie interfejs użytkownika przeglądarki Atlas powstał w wyniku kompleksowej przebudowy całej koncepcji UX aplikacji.

Mieliśmy również inne cele dotyczące produktu, takie jak szybkie uruchamianie i możliwość korzystania z setek kart bez pogorszenia wydajności. Ich zrealizowanie przy użyciu gotowego projektu Chromium było trudne, ponieważ narzuca on wiele założeń dotyczących sekwencji uruchamiania, modelu wątków i modeli kart. Rozważaliśmy wprowadzenie istotnych zmian w tym obszarze, ale chcieliśmy utrzymać wąskie ukierunkowanie naszego zestawu poprawek do Chromium, ponieważ zależało nam na szybkiej integracji nowych wersji. Aby umożliwić jak najszybsze tempo opracowywania produktu, musieliśmy wymyślić inny sposób integracji i używania środowiska uruchomieniowego Chromium.

Decydującym czynnikiem dla naszej inwestycji technicznej była nie tylko możliwość szybszego eksperymentowania, szybszej iteracji i szybszego wprowadzania nowych funkcji, ale także możliwość zachowania najważniejszego elementu kultury pracy inżynierów OpenAI: wdrożenia funkcjonalnej wersji już pierwszego dnia. Każdy nowy inżynier realizuje i wprowadza niewielką zmianę w godzinach popołudniowych swojego pierwszego dnia pracy. Musieliśmy upewnić się, że będzie to możliwe, chociaż przygotowanie i kompilacja Chromium może zająć kilka godzin.

Naszą odpowiedzią na te wyzwania było stworzenie nowej warstwy architektury, którą nazywamy OWL: OpenAI’s Web Layer (warstwa sieci OpenAI). Warstwa OWL to nasza integracja projektu Chromium, w ramach której proces przeglądarki Chromium działa poza głównym procesem aplikacji Atlas.

Należy pomyśleć o tym w ten sposób: Projekt Chromium zrewolucjonizował przeglądarki dzięki przeniesieniu kart do oddzielnych procesów. Rozwijamy tę koncepcję, przenosząc sam projekt Chromium z głównego procesu aplikacji do izolowanej warstwy usług. Ta zmiana zapewnia szereg korzyści:

• Prostsza, nowoczesna aplikacja: Przeglądarka Atlas została stworzona niemal w całości przy użyciu SwiftUI i AppKit. Jeden język, jeden stos technologiczny, jedna uporządkowana baza kodu.
• Szybsze uruchamianie: Chromium uruchamia się asynchronicznie w tle. Atlas nie czeka — piksele wyskakują na ekranie prawie natychmiast.
• Izolacja od zawieszeń i awarii: Chromium to zaawansowany i złożony silnik internetowy. Jeśli jego główny wątek się zawiesi, nie spowoduje to zawieszenia się przeglądarki Atlas. W razie jego awarii Atlas zachowuje funkcjonalność.
• Mniej problemów ze scalaniem: Ponieważ w małym stopniu opieramy się na interfejsie użytkownika projektu open source Chromium, wprowadzone przez nas zmiany w kodzie oficjalnej wersji Chromium nie są znaczące i można je łatwo aktualizować.
• Szybsza iteracja: Większość inżynierów nigdy nie musi kompilować projektu Chromium lokalnie. Warstwa OWL jest udostępniana wewnętrznie jako gotowy plik binarny, dlatego kompilacja przeglądarki Atlas zajmuje kilka minut, a nie godzin.

Ponieważ większość inżynierów w naszym zespole nie kompiluje regularnie projektu Chromium ze źródła, prace rozwojowe mogą przebiegać znacznie szybciej — nawet nowi członkowie zespołu mogą scalać proste zmiany już pierwszego popołudnia.

Na wysokim poziomie przeglądarka Atlas jest klientem OWL, a proces przeglądarki Chromium jest hostem OWL. Komunikują się one przy użyciu mechanizmu IPC, a konkretnie Mojo⁠(otwiera nowe okno), wewnętrznego systemu komunikatów w Chromium. Stworzyliśmy niestandardowe powiązania w języku Swift (a nawet TypeScript) dla Mojo, dlatego nasza aplikacja stworzona przy użyciu języka Swift może bezpośrednio wywoływać interfejsy po stronie hosta.

Biblioteka klienta OWL udostępnia prosty publiczny interfejs API Swift, który abstrahuje kilka najważniejszych elementów udostępnianych przez warstwę usług hosta:

• Session: Umożliwia konfigurowanie i kontrolowanie hosta globalnie
• Profile: Umożliwia zarządzanie stanem przeglądarki dla określonego profilu użytkownika
• WebView: Umożliwia kontrolę i osadzanie poszczególnych treści internetowych (np. renderowanie, wprowadzanie danych, nawigację, powiększanie itp.)
• WebContentRenderer: Umożliwia przekazywanie zdarzeń wejściowych do potoku renderowania Chromium i odbieranie informacji zwrotnych od procesu renderującego
• LayerHost/Client: Te elementy umożliwiają wymianę informacji dotyczących kompozycji między interfejsem użytkownika i Chromium

Istnieje również wiele punktów końcowych usługi umożliwiających zarządzanie funkcjami wysokiego poziomu, takimi jak zakładki, pobieranie plików, rozszerzenia i autouzupełnianie.

Elementy WebView, które współdzielą wzajemnie wykluczającą się przestrzeń prezentacji w aplikacji klienta, są umieszczane we współdzielonym kontenerze kompozycji i usuwane z niego w celu umieszczenia innego elementu WebView. Okno przeglądarki na przykład często ma jeden widoczny współdzielony kontener, a wybranie karty na pasku kart powoduje podmianę elementu WebView tej karty w kontenerze. Po stronie Chromium ten kontener odpowiada elementowi gfx::AcceleratedWidget, który jest ostatecznie obsługiwany przez warstwę CALayer. Udostępniamy identyfikator kontekstu tej warstwy klientowi, którego element NSView osadza ten identyfikator przy użyciu prywatnego interfejsu API CALayerHost.

W specjalnych przypadkach, takich jak menu rozwijane lub selektory kolorów, które Chromium renderuje przy użyciu oddzielnych wyskakujących widżetów, stosowane jest to samo podejście. W ich przypadku nie istnieje element content::WebContents, ale istnieje element content::RenderWidgetHostView z własnym elementem gfx::AcceleratedWidget, dlatego ma zastosowanie ten sam model renderowania delegowanego.Warstwa OWL synchronizuje wewnętrznie geometrię widoku ze stroną Chromium, dlatego kompozytor karty graficznej może być odpowiednio aktualizowany i zawsze generować zawartość warstw o prawidłowym rozmiarze i skali odpowiedniej dla urządzenia.Tę technikę wykorzystujemy również do selektywnego wyświetlania elementów natywnego interfejsu użytkownika Views Chromium w przeglądarce Atlas (jest ona również przydatna do szybkiego uruchamiania funkcji, takich jak monity o przyznanie uprawnień bez konieczności tworzenia od podstaw zamienników przy użyciu SwiftUI). Ta technika w znacznym stopniu opiera się na istniejącej infrastrukturze Chromium dla instalowalnych aplikacji internetowych w systemie macOS.Zdarzenia wejściowe: analizowanie i przekazywanieInterfejs użytkownika Chromium tłumaczy zdarzenia platformy (takie jak zdarzenia NSEvent systemu macOS) na model WebInputEvent silnika Blink przed przekazaniem ich do procesów renderujących. Ponieważ jednak warstwa OWL uruchamia Chromium w ukrytym procesie, sami wykonujemy to tłumaczenie przy użyciu biblioteki klienta napisanej w języku Swift i przekazujemy już przetłumaczone zdarzenia do Chromium.Następnie ich cykl życia przebiega tak samo jak w przypadku rzeczywistych zdarzeń wejściowych w przypadku treści internetowych. Obejmuje to między innymi zwracanie zdarzeń do klienta za każdym razem, gdy strona sygnalizuje, że nie obsłużyła zdarzenia. W takiej sytuacji ponownie syntetyzujemy zdarzenie NSEvent i dajemy pozostałym elementom aplikacji możliwość obsługi wprowadzonych danych.Tryb agenta: przypadki szczególneFunkcja przeglądania agentowego w przeglądarce Atlas stanowi wyjątkowe wyzwanie związane z naszym podejściem do renderowania, przekazywania zdarzeń wejściowych i przechowywania danych.Nasz model obsługi komputera używa pojedynczego obrazu ekranu jako danych wejściowych. Jednak niektóre elementy interfejsu użytkownika, na przykład menu rozwijane , są renderowane poza granicami karty w osobnych oknach. W trybie agenta tworzymy kompozycję obrazu strony głównej z tymi wyskakującymi elementami z zachowaniem ich prawidłowego położenia, aby model widział pełny kontekst w jednej ramce.

W przypadku zdarzeń wejściowych stosujemy tę samą zasadę: zdarzenia generowane przez agenta są kierowane bezpośrednio do procesu renderującego, nigdy przez uprzywilejowaną warstwę przeglądarki. Pozwala to zachować granice piaskownicy nawet w przypadku zautomatyzowanego sterowania. Nie chcemy na przykład, aby ta klasa zdarzeń syntetyzowała skróty klawiaturowe powodujące, że przeglądarka wykonuje czynności niezwiązane z wyświetlaną treścią internetową.

Przeglądanie agentowe może również przebiegać w tymczasowym kontekście stanu „wylogowanego”. Zamiast udostępniać istniejący profil incognito użytkownika, co mogłoby spowodować wyciek danych, używamy infrastruktury StoragePartition Chromium do uruchamiania izolowanych magazynów w pamięci. Każda sesja agenta jest uruchamiana bez żadnych zapisanych wcześniej danych, a po jej zakończeniu wszystkie pliki cookie i dane witryny są usuwane. Można uruchomić wiele sesji agenta „z wylogowaniem”, każdą w osobnej karcie przeglądarki i całkowicie odizolowaną od pozostałych.

Nie byłoby to możliwe bez globalnej społeczności Chromium i jej niesamowitej pracy nad stworzeniem fundamentu dla nowoczesnej sieci. Warstwa OWL rozwija ten fundament w nowy sposób: oddzielając silnik od aplikacji, łącząc światowej klasy platformę internetową z nowoczesnymi natywnymi frameworkami oraz zapewniając szybszą i bardziej elastyczną architekturę.

Zmieniając sposób, w jaki przeglądarka korzysta z Chromium, tworzymy inną jakość komfortu obsługi: płynniejsze uruchamianie, bardziej atrakcyjny i rozbudowany interfejs użytkownika, większa integracja z pozostałymi elementami systemu operacyjnego oraz cykl rozwoju dostosowany do tempa pojawiania się nowych pomysłów. Jeśli widzisz tu wyzwanie dla siebie, zapoznaj się z naszymi ofertami pracy dotyczącymi przeglądarki Atlas Inżynier oprogramowania, Atlas⁠, Inżynier oprogramowania, iOS⁠ i nie tylko⁠.

Wypróbuj przeglądarkę Atlas. Pobierz ją ze strony chatgpt.com/atlas⁠⁠(otwiera nowe okno).