О 1Ц веб клијенту

Једна од лепих карактеристика 1Ц:Ентерприсе технологије је да се апликативно решење, развијено коришћењем технологије управљаних образаца, може покренути и у танком (извршном) клијенту за Виндовс, Линук, МацОС Кс и као веб клијент за 5 претраживача - Цхроме, Интернет Екплорер, Фирефок, Сафари, Едге и све то без промене изворног кода апликације. Штавише, споља апликација у танком клијенту и у претраживачу функционише и изгледа скоро идентично.
Пронађите 10 разлика (2 слике испод резања):

Прозор танког клијента на Линук-у:

Исти прозор у веб клијенту (у Цхроме претраживачу):

Зашто смо направили веб клијент? Некако патетично речено, време нам је поставило такав задатак. Рад преко Интернета је дуго био предуслов за пословне апликације. Прво смо додали могућност рада преко Интернета за нашег танког клијента (неки од наших конкурената су, иначе, стали на томе; други су, напротив, напустили танки клијент и ограничили се на имплементацију веб клијента). Одлучили смо да нашим корисницима пружимо могућност да изаберу опцију клијента која им највише одговара.

Додавање веб-базираних могућности танком клијенту био је велики пројекат са потпуном променом клијент-сервер архитектуре. Креирање веб клијента је потпуно нов пројекат, почевши од нуле.

Проблем статемент

Дакле, захтеви пројекта: веб клијент мора да ради исто што и танки клијент, наиме:

1. Прикажите кориснички интерфејс
2. Извршите клијентски код написан на 1Ц језику

Кориснички интерфејс у ​​1Ц је описан у визуелном уређивачу, али декларативно, без распореда елемената пиксел по пиксел; Користи се око три десетине типова елемената интерфејса – дугмад, поља за унос (текст, број, датум/време), листе, табеле, графикони итд.

Клијентски код на језику 1Ц може да садржи позиве сервера, рад са локалним ресурсима (датотеке, итд.), Штампање и још много тога.

И танки клијент (када ради преко веба) и веб клијент користе исти скуп веб услуга за комуникацију са 1Ц сервером апликација. Имплементације клијента су, наравно, различите - танки клијент је написан у Ц++, веб клијент је написан у ЈаваСцрипт-у.

Мало историје

Пројекат веб клијента почео је 2006. године, са тимом од (у просеку) 5 људи. У одређеним фазама пројекта, програмери су били укључени у имплементацију специфичне функционалности (документ прорачунске табеле, дијаграми, итд.); по правилу, то су били исти програмери који су ову функционалност радили у танком клијенту. Оне. програмери су поново написали компоненте у ЈаваСцрипт-у које су претходно креирали у Ц++.

Од самог почетка, одбацили смо идеју о било каквој аутоматској (чак и делимичној) конверзији Ц++ кода танког клијента у ЈаваСцрипт веб клијент због јаких концептуалних разлика између два језика; веб клијент је написан у ЈаваСцрипт-у од нуле.

У првим итерацијама пројекта, веб клијент је конвертовао клијентски код у уграђеном 1Ц језику директно у ЈаваСцрипт. Танки клијент се понаша другачије - код у уграђеном 1Ц језику се компајлира у бајткод, а затим се овај бајт код интерпретира на клијенту. Након тога, веб клијент је почео да ради исто - прво, дао је повећање перформанси, а друго, омогућио је да се уједини архитектура танког и веб клијента.

Прва верзија платформе 1Ц:Ентерприсе са подршком за веб клијенте објављена је 2009. године. Веб клијент је у то време подржавао 2 претраживача - Интернет Екплорер и Фирефок. Првобитни планови су укључивали подршку за Оперу, али због непремостивих проблема у то време са обрађивачима затварања апликација у Опери (није било могуће са 100% сигурношћу пратити да се апликација затвара, и у том тренутку спровести процедуру искључења са 1Ц апликацијски сервер) из ових планова морали су да буду напуштени.

Структура пројекта

Укупно, платформа 1Ц:Ентерприсе има 4 пројекта написана у ЈаваСцрипт-у:

1. ВебТоолс – дељене библиотеке које користе други пројекти (ми такође укључујемо Гоогле Цлосуре Либрари).
2. Контролни елемент ФорматтедДоцумент (примењено у ЈаваСцрипт-у и у танком и веб клијенту)
3. Контролни елемент Планер (примењено у ЈаваСцрипт-у и у танком и веб клијенту)
4. Веб клијент

Структура сваког пројекта личи на структуру Јава пројеката (или .НЕТ пројеката - шта је ближе); Имамо просторе имена и сваки простор имена је у посебном фолдеру. Унутар фасцикле налазе се датотеке и класе именског простора. Постоји око 1000 датотека у пројекту веб клијента.

Структурно, веб клијент је у великој мери подељен на следеће подсистеме:

• Управљани интерфејс клијентске апликације
  • Општи интерфејс апликације (системски менији, панели)
  • Интерфејс управљаних форми, укључујући, између осталог, око 30 контрола (дугмад, разне врсте поља за унос - текстуална, нумеричка, датум/време, итд., табеле, листе, графикони итд.)

• Објектни модел доступан програмерима на клијенту (укупно преко 400 типова: објектни модел управљаног интерфејса, подешавања распореда података, условни стил итд.)
• Тумач уграђеног 1Ц језика
• Екстензије за прегледач (користе се за функције које нису подржане у ЈаваСцрипт-у)
  • Рад са криптографијом
  • Рад са датотекама
  • Технологија екстерних компоненти, која им омогућава да се користе у танким и веб клијентима

Развојне карактеристике

Имплементација свега горе наведеног у ЈаваСцрипт-у није лака. Можда је 1Ц веб клијент једна од највећих апликација на страни клијента написаних у ЈаваСцрипт-у - око 450.000 линија. Активно користимо објектно оријентисани приступ у коду веб клијента, што поједностављује рад са тако великим пројектом.

Да бисмо смањили величину клијентског кода, прво смо користили сопствени обфускатор, а почевши од верзије платформе 8.3.6 (октобар 2014.) почели смо да користимо Гоогле преводилац за затварање. Ефекат употребе у бројевима – величина оквира веб клијента након замагљивања:

• Сопствени обфускатор – 1556 кб
• Гоогле Цлосуре Цомпилер – 1073 кб

Коришћење Гоогле Цлосуре Цомпилер-а нам је помогло да побољшамо перформансе веб клијента за 30% у поређењу са нашим сопственим обфускатором. Поред тога, количина меморије коју апликација троши смањена је за 15-25% (у зависности од претраживача).

Гоогле Цлосуре Цомпилер ради веома добро са објектно оријентисаним кодом, тако да је његова ефикасност за веб клијента што је могуће већа. Цлосуре Цомпилер чини неколико добрих ствари за нас:

• Статичка провера типа у фази израде пројекта (осигурава да покријемо код ЈСДоц напоменама). Резултат је статичко куцање, веома блиско куцању у Ц++. Ово помаже да се ухвати прилично велики проценат грешака у фази компилације пројекта.
• Смањење величине кода кроз замагљивање
• Бројне оптимизације извршеног кода, на пример, као што су:
  • инлине функције замене. Позивање функције у ЈаваСцрипт-у је прилично скупа операција, а инлине замене често коришћених малих метода значајно убрзавају код.
  • Бројање константи у време компајлирања. Ако израз зависи од константе, стварна вредност константе ће бити замењена у њега

Користимо ВебСторм као окружење за развој веб клијената.

За анализу кода користимо СонарКубе, где интегришемо статичке анализаторе кода. Помоћу анализатора пратимо деградацију квалитета ЈаваСцрипт изворног кода и покушавамо да је спречимо.

Које проблеме смо решавали/решавали?

Током реализације пројекта наишли смо на низ занимљивих проблема које смо морали да решимо.

Размените податке са сервером и између прозора

Постоје ситуације у којима замагљивање изворног кода може ометати рад система. Код изван извршног кода веб клијента, због замагљивања, може имати имена функција и параметара која се разликују од оних које наш извршни код очекује. Спољни код за нас је:

• Код који долази са сервера у облику структура података
• Код за други прозор апликације

Да бисмо избегли замагљивање приликом интеракције са сервером, користимо ознаку @екпосе:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

А да бисмо избегли замагљивање при интеракцији са другим прозорима, користимо такозване извезене интерфејсе (интерфејсе у које се извозе све методе).

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

Користили смо виртуелни ДОМ пре него што је постао мејнстрим)

Као и сви програмери који се баве сложеним веб корисничким интерфејсима, брзо смо схватили да ДОМ није погодан за рад са динамичким корисничким интерфејсима. Скоро одмах је имплементиран аналог виртуелног ДОМ-а за оптимизацију рада са корисничким интерфејсом. Током обраде догађаја, све ДОМ промене се чувају у меморији и тек када се све операције заврше, акумулиране промене се примењују на ДОМ стабло.

Оптимизација веб клијента

Да би наш веб клијент радио брже, трудимо се да максимално користимо стандардне могућности претраживача (ЦСС, итд.). Дакле, командни панел обрасца (који се налази на скоро сваком облику апликације) се приказује искључиво помоћу алата претраживача, користећи динамички распоред заснован на ЦСС-у.

Тестирање

За функционално тестирање и тестирање перформанси користимо власнички алат (написан у Јави и Ц++), као и скуп тестова изграђен на врху Селен.

Наш алат је универзалан - омогућава вам да тестирате скоро сваки прозорски програм и стога је погодан за тестирање и танког клијента и веб клијента. Алат бележи радње корисника који је покренуо решење апликације 1Ц у датотеку скрипте. Истовремено се снимају слике радног подручја екрана — стандарда. Приликом праћења нових верзија веб клијента, скрипте се репродукују без учешћа корисника. У случајевима када снимак екрана ни у једном кораку не одговара референтном, тест се сматра неуспелим, након чега специјалиста за квалитет спроводи истрагу како би утврдио да ли је реч о грешци или планираној промени понашања система. У случају планираног понашања, стандарди се аутоматски замењују новим.

Алат такође мери перформансе апликације са тачношћу до 25 милисекунди. У неким случајевима петљамо делове скрипте (на пример, понављамо унос налога неколико пута) да бисмо анализирали деградацију времена извршења током времена. Резултати свих мерења се бележе у дневник ради анализе.

Наш алат за тестирање и апликација у тестирању

Наш алат и селен се допуњују; на пример, ако је неко дугме на једном од екрана променило своју локацију, Селен то можда неће пратити, али ће наш алат приметити, јер прави пиксел по пиксел поређење снимка екрана са стандардом. Алат такође може да прати проблеме са обрадом уноса са тастатуре или миша, јер управо то репродукује.

Тестови на оба алата (наш и Селениум) покрећу типичне радне сценарије из наших апликативних решења. Тестови се аутоматски покрећу након дневне изградње платформе 1Ц:Ентерприсе. Ако су скрипте спорије (у поређењу са претходном верзијом), истражујемо и решавамо узрок успоравања. Наш критеријум је једноставан - нова верзија не би требало да ради спорије од претходне.

Програмери користе различите алате за истраживање инцидената успоравања; углавном се користи Динатраце АЈАКС издање продукцијска кућа ДинаТраце. Евиденција извршења проблематичне операције на претходним и новим верзијама се снима, а затим се анализирају. Истовремено, време извршавања појединачних операција (у милисекундама) можда није одлучујући фактор - сервисни процеси као што је сакупљање смећа се периодично покрећу у претраживачу, могу се преклапати са временом извршавања функција и искривити слику. Релевантнији параметри у овом случају би били број извршених ЈаваСцрипт инструкција, број атомских операција на ДОМ-у, итд. Ако се број инструкција/операција у истој скрипти повећао у новој верзији, то скоро увек значи пад перформанси који треба исправити.

Такође, један од разлога за пад перформанси може бити тај што Гоогле Цлосуре Цомпилер из неког разлога није могао да изврши инлине замену функције (на пример, зато што је функција рекурзивна или виртуелна). У овом случају покушавамо да исправимо ситуацију поновним писањем изворног кода.

Екстензије претраживача

Када је апликацијском решењу потребна функционалност која није доступна у ЈаваСцрипт-у, користимо екстензије прегледача:

• за рад са датотекама
• за рад са криптографијом
• рад са спољне компоненте

Наша проширења се састоје из два дела. Први део је оно што се назива екстензија претраживача (обично проширења за Цхроме и Фирефок написана у ЈаваСцрипт-у), која је у интеракцији са другим делом – бинарним проширењем које имплементира функционалност која нам је потребна. Треба напоменути да пишемо 3 верзије бинарних екстензија - за Виндовс, Линук и МацОС. Бинарно проширење се испоручује као део платформе 1Ц:Ентерприсе и налази се на серверу апликација 1Ц. Када се први пут позове са веб клијента, преузима се на клијентски рачунар и инсталира у претраживач.

Када раде у Сафарију, наша проширења користе НПАПИ; када раде у Интернет Екплорер-у, користе АцтивеКс технологију. мицрософт ивица још увек не подржава екстензије, тако да веб клијент у њему ради са ограничењима.

Даљи развој

Један од задатака тима за развој веб клијената је даљи развој функционалности. Функционалност веб клијента треба да буде идентична функционалности танког клијента; све нове функционалности се имплементирају истовремено и у танком и у веб клијенту.

Остали задаци укључују развој архитектуре, рефакторисање, побољшање перформанси и поузданости. На пример, један од праваца је даље кретање ка асинхроном моделу рада. Неке од функционалности веб клијента су тренутно изграђене на синхроном моделу интеракције са сервером. Асинхрони модел сада постаје релевантнији у прегледачима (и не само у претраживачима), и то нас приморава да модификујемо веб клијент заменом синхроних позива асинхроним (и рефакторисањем кода у складу са тим). Постепени прелазак на асинхрони модел објашњава се потребом подршке издатим решењима и њиховом постепеном адаптацијом.

Извор: ввв.хабр.цом