ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
К сожалению, проблемы начали постепенно накапливаться.
Когда вы разрабатываете большое приложение, вам нужно что-то изменить, чтобы исправить ошибки или добавить новые функции, или повысить производительность. В мире XPCOM это означало изменение компонентов XPCOM. Иногда для добавления новых функций в компонент. Иногда нужно полностью удалить один, потому что этот дизайн был заменен на лучший дизайн.
В первую эру механизма расширения на основе XPCOM это часто было запрещено. Если в надстройках использовался компонент XPCOM, его просто нельзя было изменить несовместимыми способами. Это было здорово для разработчиков надстроек, но быстро стало кошмаром для разработчиков Firefox. Потому что каждое изменение должно было быть выполнено с обратной совместимостью как внешне (для веб-разработчиков), так и внутри (для разработчиков надстроек). Это означало, что каждый компонент XPCOM nsISomething быстро сопровождался компонентом nsISomething2, который был лучшим – и оба должны были работать вместе друг с другом – Один случай был еще более сложным для разработчиков Firefox: надстройки на основе XPCOM могли заменить любой существующий компонент XPCOM. Излишне говорить, что это был очень хороший способ взломать Firefox, что озадачило исследователей сбоев Firefox.
Это означало, что разработка становилась все медленнее и медленнее, поскольку нам нужно было проверять каждую новую функцию или каждое улучшение не только с текущими функциями, но и с прошлыми/устаревшими функциями или просто старыми способами работы, которые были устаревшими в течение многих лет. Какое-то время этот налог на развитие был приемлемым. В конце концов, основным конкурентом Firefox был Internet Explorer, у которого были еще более серьезные архитектурные проблемы, и было очевидно, что неограниченное количество участников с открытым исходным кодом помогало. Кроме того, набор функций Интернета был намного меньше, так что это все еще было возможно.
Однако по мере роста Интернета стало очевидно, что эти варианты сделали просто невозможным исправить некоторые проблемы, в частности проблемы с производительностью. Например, примерно в 2008 году разработчики Firefox осознали, что на платформе просто слишком много компонентов XPCOM и что это значительно снижает производительность, поскольку компоненты XPCOM не позволяют компилятору JIT и C ++ оптимизировать код и требуют слишком большого количества преобразований данных. Так началось обеззараживание, заключающееся в переписывании критически важных для производительности участков кода без компонентов XPCOM. Что означало взлом надстроек.
В эту вторую эру механизма расширений на основе XPCOM разработчикам Firefox было разрешено удалять или реорганизовывать компоненты XPCOM при условии, что они связались с разработчиками надстроек и работали с ними, чтобы сделать возможным исправление их надстроек. Это разблокированное развитие, но налог на разработку каким-то образом сумел вырасти еще выше, поскольку это иногда означало недели мозгового штурма с внешними разработчиками, прежде чем мы могли внести хотя бы простые улучшения. Таким образом, также начался высокий налог на дополнительные разработки, поскольку некоторым разработчикам надстроек приходилось время от времени переделывать свои надстройки. В некоторых случаях между разработчиками Firefox и разработчиками надстроек были очень хорошие отношения, что иногда приводило к разработке разработчиками надстроек API, используемых в Firefox. В других случаях разработчики дополнений устали от этого бремени обслуживания и сдались, иногда переключаясь на зарождающуюся экосистему Chrome.
Примерно в это же время Mozilla начала уделять Chrome серьезное внимание. Chrome начинал с очень разных принципов дизайна, чем Firefox:
В течение многих лет для Mozilla было ясно, что Firefox необходимо перейти на многопроцессорный дизайн. Фактически, демонстрационные версии многопроцессорного Firefox циркулировали примерно тогда, когда был представлен Chrome 1.0. Проект назывался Electrolysis, или сокращенно e10s. Мы вернемся к этому.
В то время Mozilla решила приостановить работу e10s, которая должна была использовать гораздо больше памяти, чем было у многих наших пользователей, и сосредоточиться на новом проекте под названием Snappy. Snappy использовал те же дизайнерские приемы, что и Chrome, чтобы Firefox работал быстрее, надеюсь, без необходимости реорганизовывать все.
Причина, по которой Firefox работал медленнее, чем Chrome, заключалась в том, что мы почти все делали в одном потоке. Когда Firefox записывал файл на диск, это блокировало визуальные обновления, поэтому количество кадров в секунду упало. Когда Firefox собирал список вкладок, чтобы сохранить их в случае сбоя, это блокировало обновления с тем же результатом. Когда Firefox очищал файлы cookie, это блокировало обновления и т. д.
Для этого было два решения, которые мы оба использовали:
Оба решения помогли нам гарантировать, что мы не пропустим кадры и что мы сможем немедленно ответить, когда пользователь щелкнет. Это означало, что пользовательский интерфейс казался быстрым. Преимущество первого заключалось в том, что в нем использовалась операционная система, тогда как для второго требовалось значительное количество измерений и тонкой настройки. Оба решения было сложно реализовать, потому что мы внезапно столкнулись с проблемами параллелизма, которые, как известно, сложно отлаживать. Оба решения также были трудны для разработчиков надстроек, поскольку они требовали изменения всех функций с синхронного на асинхронный, что часто означало, что надстройку нужно было переписывать с нуля.
Это время памяти, поскольку именно тогда Ираклий, Паоло представили Promise и то, что теперь известно как async function кодовая база Firefox. Эти эксперименты (которые никоим образом не были единственными экспериментами по данной теме) послужили испытательной площадкой для последующего внедрения этих функций в Интернет. Более того, они значительно упростили написание асинхронного кода как для разработчиков Firefox, так и для разработчиков надстроек. Несмотря на эти улучшения (и другие, которые еще не дошли до стандартов), написание и отладка асинхронного кода оставались очень сложными.
Итак, снова был введен новый налог на обслуживание для разработчиков дополнений, который быстро стал действительно сложным. Что касается возможностей расширений, ситуация была еще хуже, когда мы переместили код из основного потока, потому что они обычно перемещались в потоки C ++, которые полностью отделены от потоков JavaScript. Компоненты XPCOM исчезали то тут, то там, теряя возможности расширения для разработчиков надстроек.
Именно на этом этапе многие разработчики дополнений начали серьезно жаловаться на этот налог на обслуживание – или, чаще, просто перестали обновлять свои дополнения. И они были правы. К тому времени, разработчики дополнений, уже давно отказались от обслуживания своих дополнений, на это тратилось чертовски много времени. Налог на обслуживание сжигал сообщество разработчиков дополнений.
И Mozilla серьезно подошла к поиску нового способа написания дополнений, который значительно снизил бы налог как для разработчиков Firefox, так и для разработчиков дополнений. В то время решением был Jetpack, и это было довольно здорово! Некоторое время сосуществовали два механизма расширения: более чистый Jetpack и более старая беспорядочная модель.
Snappy ушел довольно далеко, но он никогда не смог решить всех проблем Firefox.
Как упоминалось выше, разработчики Firefox уже давно знали, что нам в конечном итоге потребуется перейти к многопроцессорной модели. Это было лучше для безопасности, так было проще обеспечить плавное обновление кадров, и это казалось естественным. К тому времени разработчики Mozilla уже некоторое время экспериментировали с многопроцессорным Firefox, но две вещи помешали Mozilla продвинуться вперед с многопроцессорным Firefox (также известным как Electrolysis или e10s):
Поскольку оперативная память стала дешевле и мы оптимизировали ее использование (проект Memshrink), проблема 1. постепенно перестала быть блокирующим устройством. Проблема 2, с другой стороны, не могла быть решена.
Давайте рассмотрим простой случай надстройки, которая каким-то образом должна взаимодействовать с содержимым страницы. Например, надстройка, предназначенная для увеличения контраста. До e10s это был код JavaScript, который существовал в главном окне Firefox и мог напрямую управлять DOM отдельных страниц. Это было довольно просто написать. С e10s это дополнение нужно было переписать для работы между процессами. Родительский процесс мог общаться только с дочерними процессами путем обмена сообщениями, а дочерние процессы могли быть остановлены в любой момент, в том числе при обработке сообщения, либо операционной системой (в случае сбоя), либо конечным пользователем (путем закрытия вкладки).
Однако не все процессы могли позволить себе так хорошо работать с надстройками. Например, процессы, предназначенные для защиты Firefox от печально известных сбоев плагина Flash, не имели виртуальной машины JavaScript. У процессов, предназначенных для взаимодействия с графическим процессором, не было виртуальной машины JavaScript. Все это сделано по (веским) причинам производительности и безопасности – а также из-за того факта, что добавление виртуальной машины JavaScript к этим процессам сделало бы их намного более сложными.
И все же у Mozilla не было выбора. Каждый день, когда Mozilla не выпускала Electrolysis, в один прекрасный день Chrome просто становился лучше с точки зрения архитектуры, безопасности и защищенности. К сожалению, Mozilla отложила Electrolysis на годы, отчасти из-за иллюзии, что тесты Firefox были настолько лучше, что это не имело бы значения в течение длительного времени, отчасти потому, что мы решили протестировать Electrolysis с FirefoxOS до самого Firefox, но в основном потому что мы не хотели терять все эти дополнения.
Когда Mozilla, наконец, совершила переход на Electrolysis, некоторые разработчики дополнений портировали свои дополнения, посвятив много времени этой задаче, но многие этого не сделали, либо потому что это было невозможно для их дополнения, либо, что чаще, потому что мы потеряли их из-за налога на обслуживание аддонов. И, к сожалению, даже надстройки, которые были перенесены на Electrolysis, ломались одно за другим по всем другим причинам, упомянутым в этой статье.
В конце концов, Mozilla решила внедрить WebExtensions и, наконец, совершить прыжок в сторону e10s как часть Quantum Project. Потеряли годы развития, которые никогда не восстановить.
Производительность улучшалась. Надстройки нужно было переписать. Мощность надстройки безвозвратно упала. Механизм расширения на основе XPCOM в основном был исключен (мы все еще используем его внутри).
Начало:
Продолжение:
(1 оценок, среднее: 5,00 из 5)
Загрузка...
