Ynglŷn â'r cleient gwe 1C

Un o nodweddion braf technoleg 1C:Enterprise yw y gellir lansio'r datrysiad cymhwysiad, a ddatblygwyd gan ddefnyddio technoleg ffurflenni wedi'i reoli, mewn cleient tenau (gweithredadwy) ar gyfer Windows, Linux, MacOS X, ac fel cleient gwe ar gyfer 5 porwr - Chrome, Internet Explorer, Firefox, Safari, Edge, a hyn i gyd heb newid cod ffynhonnell y cais. Ar ben hynny, yn allanol y cais yn y cleient tenau ac yn y porwr swyddogaethau ac yn edrych bron yn union yr un fath.
Darganfyddwch 10 gwahaniaeth (2 lun o dan y toriad):

Ffenestr cleient denau ar Linux:

Ynglŷn â'r cleient gwe 1C

Yr un ffenestr yn y cleient gwe (yn y porwr Chrome):

Ynglŷn â'r cleient gwe 1C

Pam wnaethon ni wneud cleient gwe? I’w roi braidd yn druenus, mae amser wedi gosod tasg o’r fath i ni. Mae gweithio dros y Rhyngrwyd wedi bod yn rhagofyniad ar gyfer cymwysiadau busnes ers amser maith. Yn gyntaf, fe wnaethom ychwanegu'r gallu i weithio trwy'r Rhyngrwyd ar gyfer ein cleient tenau (gyda llaw, stopiodd rhai o'n cystadleuwyr yno; i'r gwrthwyneb, cefnodd eraill ar y cleient tenau a chyfyngu eu hunain i weithredu cleient gwe). Fe benderfynon ni roi'r cyfle i'n defnyddwyr ddewis yr opsiwn cleient sydd fwyaf addas iddyn nhw.

Ynglŷn â'r cleient gwe 1C

Roedd ychwanegu galluoedd ar y we at y cleient tenau yn brosiect mawr gyda newid llwyr ym mhensaernïaeth cleient-gweinydd. Mae creu cleient gwe yn brosiect cwbl newydd, gan ddechrau o'r dechrau.

Datganiad o'r broblem

Felly, gofynion y prosiect: rhaid i'r cleient gwe wneud yr un peth â'r cleient tenau, sef:

  1. Arddangos rhyngwyneb defnyddiwr
  2. Gweithredu cod cleient wedi'i ysgrifennu mewn iaith 1C

Disgrifir y rhyngwyneb defnyddiwr yn 1C mewn golygydd gweledol, ond yn ddatganiadol, heb drefniant picsel-wrth-picsel o elfennau; Defnyddir tua thri dwsin o fathau o elfennau rhyngwyneb - botymau, meysydd mewnbwn (testun, rhifol, dyddiad/amser), rhestrau, tablau, graffiau, ac ati.

Gall cod cleient yn yr iaith 1C gynnwys galwadau gweinydd, gweithio gydag adnoddau lleol (ffeiliau, ac ati), argraffu, a llawer mwy.

Mae'r cleient tenau (wrth weithio trwy'r we) a'r cleient gwe yn defnyddio'r un set o wasanaethau gwe i gyfathrebu â gweinydd cymhwysiad 1C. Mae gweithrediadau cleient, wrth gwrs, yn wahanol - mae'r cleient tenau wedi'i ysgrifennu yn C ++, mae'r cleient gwe wedi'i ysgrifennu yn JavaScript.

Tipyn o hanes

Dechreuodd y prosiect cleient gwe yn 2006, gyda thîm o (ar gyfartaledd) 5 o bobl. Ar rai camau o'r prosiect, roedd datblygwyr yn cymryd rhan i weithredu swyddogaethau penodol (dogfen taenlen, diagramau, ac ati); fel rheol, dyma'r un datblygwyr a wnaeth y swyddogaeth hon yn y cleient tenau. Y rhai. ail-ysgrifennodd datblygwyr gydrannau yn JavaScript yr oeddent wedi'u creu o'r blaen yn C++.

O'r cychwyn cyntaf, fe wnaethom wrthod y syniad o unrhyw drosi cod cleient tenau C++ yn awtomatig (hyd yn oed yn rhannol) yn gleient gwe JavaScript oherwydd y gwahaniaethau cysyniadol cryf rhwng y ddwy iaith; ysgrifennwyd y cleient gwe yn JavaScript o'r dechrau.

Yn iteriadau cyntaf y prosiect, trosodd cleient y we god cleient yn yr iaith 1C adeiledig yn uniongyrchol i JavaScript. Mae'r cleient tenau yn gweithredu'n wahanol - mae'r cod yn yr iaith 1C adeiledig yn cael ei grynhoi i mewn i bytecode, ac yna mae'r cod byte hwn yn cael ei ddehongli ar y cleient. Yn dilyn hynny, dechreuodd y cleient gwe wneud yr un peth - yn gyntaf, rhoddodd enillion perfformiad, ac yn ail, fe'i gwnaeth yn bosibl uno pensaernïaeth y cleientiaid tenau a gwe.

Rhyddhawyd fersiwn gyntaf y platfform 1C:Enterprise gyda chefnogaeth cleient gwe yn 2009. Roedd y cleient gwe ar y pryd yn cefnogi 2 borwr - Internet Explorer a Firefox. Roedd y cynlluniau gwreiddiol yn cynnwys cefnogaeth i Opera, ond oherwydd problemau anorchfygol bryd hynny gyda'r trinwyr cau ceisiadau yn Opera (nid oedd yn bosibl olrhain gyda sicrwydd 100% bod y cais yn cau, a bryd hynny cyflawni'r weithdrefn datgysylltu o bu'n rhaid rhoi'r gorau i'r gweinydd cais 1C) o'r cynlluniau hyn.

Strwythur y prosiect

Yn gyfan gwbl, mae gan y platfform 1C:Enterprise 4 prosiect wedi'u hysgrifennu yn JavaScript:

  1. WebTools – llyfrgelloedd a rennir a ddefnyddir gan brosiectau eraill (rydym hefyd yn cynnwys Llyfrgell Cau Google).
  2. Elfen reoli Dogfen wedi'i Fformatio (wedi'i weithredu yn JavaScript yn y cleient tenau a'r cleient gwe)
  3. Elfen reoli Trefnydd (wedi'i weithredu yn JavaScript yn y cleient tenau a'r cleient gwe)
  4. Cleient gwe

Mae strwythur pob prosiect yn debyg i strwythur prosiectau Java (neu brosiectau .NET - pa un bynnag sydd agosaf); Mae gennym ofodau enwau, ac mae pob gofod enw mewn ffolder ar wahân. Y tu mewn i'r ffolder mae ffeiliau a dosbarthiadau gofod enwau. Mae tua 1000 o ffeiliau yn y prosiect cleient gwe.

Yn strwythurol, mae'r cleient gwe wedi'i rannu'n bennaf i'r is-systemau canlynol:

  • Rhyngwyneb cais cleient a reolir
    • Rhyngwyneb cymhwysiad cyffredinol (bwydlenni system, paneli)
    • Rhyngwyneb ffurflenni a reolir, gan gynnwys, ymhlith pethau eraill, tua 30 o reolaethau (botymau, gwahanol fathau o feysydd mewnbwn - testun, rhifol, dyddiad / amser, ac ati, tablau, rhestrau, graffiau, ac ati)

  • Model gwrthrych ar gael i ddatblygwyr ar y cleient (dros 400 o fathau i gyd: model gwrthrych rhyngwyneb a reolir, gosodiadau gosodiad data, steilio amodol, ac ati)
  • Dehonglydd yr iaith 1C adeiledig
  • Estyniadau porwr (a ddefnyddir ar gyfer ymarferoldeb na chefnogir yn JavaScript)
    • Gweithio gyda cryptograffeg
    • Gweithio gyda ffeiliau
    • Technoleg cydrannau allanol, gan ganiatáu iddynt gael eu defnyddio mewn cleientiaid tenau a gwe

Nodweddion Datblygu

Nid yw'n hawdd gweithredu pob un o'r uchod yn JavaScript. Efallai mai cleient gwe 1C yw un o'r cymwysiadau ochr cleientiaid mwyaf a ysgrifennwyd yn JavaScript - tua 450.000 o linellau. Rydym yn mynd ati i ddefnyddio dull gwrthrych-ganolog yn y cod cleient gwe, sy'n symleiddio gweithio gyda phrosiect mor fawr.

Er mwyn lleihau maint y cod cleient, fe wnaethom ddefnyddio ein obfuscator ein hunain yn gyntaf, a chan ddechrau gyda fersiwn platfform 8.3.6 (Hydref 2014) dechreuon ni ddefnyddio Casglwr Cau Google. Effaith defnydd mewn niferoedd – maint y fframwaith cleient gwe ar ôl cuddio:

  • Gwrthwynebydd eich hun - 1556 kb
  • Casglwr Cau Google – 1073 kb

Fe wnaeth defnyddio Google Closure Compiler ein helpu i wella perfformiad y cleient gwe 30% o'i gymharu â'n obfuscator ein hunain. Yn ogystal, mae faint o gof a ddefnyddir gan y cais wedi gostwng 15-25% (yn dibynnu ar y porwr).

Mae Google Closure Compiler yn gweithio'n dda iawn gyda chod gwrthrych-ganolog, felly mae ei effeithlonrwydd ar gyfer y cleient gwe mor uchel â phosib. Mae Closure Compiler yn gwneud ychydig o bethau da i ni:

  • Mae gwirio math statig yn ystod cam adeiladu'r prosiect (yn sicrhau ein bod yn cwmpasu'r cod ag anodiadau JSDoc). Y canlyniad yw teipio statig, yn agos iawn o ran lefel i deipio yn C++. Mae hyn yn helpu i ddal canran eithaf mawr o wallau yn ystod cam llunio'r prosiect.
  • Lleihau maint y cod trwy rwymo
  • Nifer o optimeiddiadau o'r cod a weithredwyd, er enghraifft, megis:
    • amnewidiadau swyddogaeth inline. Mae galw swyddogaeth yn JavaScript yn weithrediad eithaf drud, ac mae amnewidiadau mewnol o ddulliau bach a ddefnyddir yn aml yn cyflymu'r cod yn sylweddol.
    • Cyfrif cysonion ar amser llunio. Os yw mynegiad yn dibynnu ar gysonyn, bydd gwerth gwirioneddol y cysonyn yn cael ei amnewid ynddo

Rydym yn defnyddio WebStorm fel ein hamgylchedd datblygu cleient gwe.

Ar gyfer dadansoddi cod rydym yn ei ddefnyddio sainQube, lle rydym yn integreiddio dadansoddwyr cod statig. Gan ddefnyddio dadansoddwyr, rydym yn monitro diraddiad ansawdd cod ffynhonnell JavaScript ac yn ceisio ei atal.

Ynglŷn â'r cleient gwe 1C

Pa broblemau wnaethom/rydyn ni'n eu datrys?

Yn ystod gweithrediad y prosiect, daethom ar draws nifer o broblemau diddorol yr oedd yn rhaid i ni eu datrys.

Cyfnewid data gyda'r gweinydd a rhwng ffenestri

Mae yna sefyllfaoedd lle gall obfuscation y cod ffynhonnell ymyrryd â gweithrediad y system. Gall cod y tu allan i god gweithredadwy'r cleient gwe, oherwydd rhwystredigaeth, fod ag enwau swyddogaeth a pharamedr sy'n wahanol i'r rhai y mae ein cod gweithredadwy yn eu disgwyl. Y cod allanol i ni yw:

  • Cod yn dod o'r gweinydd ar ffurf strwythurau data
  • Cod ar gyfer ffenestr cais arall

Er mwyn osgoi rhwystr wrth ryngweithio â'r gweinydd, rydym yn defnyddio'r tag @expose:

/**
 * @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;
}

Ac er mwyn osgoi rhwystr wrth ryngweithio â ffenestri eraill, rydym yn defnyddio rhyngwynebau wedi'u hallforio fel y'u gelwir (rhyngwynebau lle mae pob dull yn cael ei allforio).

/**
 * Экспортируемый интерфейс контрола 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 (){}

Fe wnaethon ni ddefnyddio Virtual DOM cyn iddo ddod yn brif ffrwd)

Fel pob datblygwr sy'n delio â UI Gwe cymhleth, sylweddolom yn gyflym fod y DOM yn addas iawn ar gyfer gweithio gyda rhyngwynebau defnyddwyr deinamig. Bron yn syth, gweithredwyd analog o Virtual DOM i wneud y gorau o waith gyda'r UI. Yn ystod prosesu digwyddiadau, mae'r holl newidiadau DOM yn cael eu storio yn y cof a, dim ond pan fydd yr holl weithrediadau wedi'u cwblhau, mae'r newidiadau cronedig yn cael eu cymhwyso i'r goeden DOM.

Optimeiddio'r cleient gwe

Er mwyn gwneud i'n cleient gwe weithio'n gyflymach, rydym yn ceisio defnyddio'r galluoedd porwr safonol (CSS, ac ati) i'r eithaf. Felly, mae'r panel gorchymyn ffurflen (sydd wedi'i leoli ar bron bob ffurf o'r cais) yn cael ei rendro gan ddefnyddio offer porwr yn unig, gan ddefnyddio cynllun deinamig yn seiliedig ar CSS.

Ynglŷn â'r cleient gwe 1C

Profi

Ar gyfer profion swyddogaethol a pherfformiad, rydym yn defnyddio offeryn perchnogol (wedi'i ysgrifennu yn Java a C ++), yn ogystal â chyfres o brofion wedi'u hadeiladu ar ben Seleniwm.

Mae ein hofferyn yn gyffredinol - mae'n caniatáu ichi brofi bron unrhyw raglen ffenestr, ac felly mae'n addas ar gyfer profi cleient tenau a chleient gwe. Mae'r offeryn yn cofnodi gweithredoedd y defnyddiwr a lansiodd y datrysiad cymhwysiad 1C i mewn i ffeil sgript. Ar yr un pryd, mae delweddau o ardal waith y sgrin - safonau - yn cael eu cofnodi. Wrth fonitro fersiynau newydd o'r cleient gwe, mae sgriptiau'n cael eu chwarae heb gyfranogiad defnyddwyr. Mewn achosion lle nad yw'r sgrin yn cyd-fynd â'r un cyfeirio ar unrhyw gam, ystyrir bod y prawf wedi methu, ac ar ôl hynny mae arbenigwr ansawdd yn cynnal ymchwiliad i benderfynu a yw hwn yn gamgymeriad neu'n newid arfaethedig yn ymddygiad y system. Mewn achos o ymddygiad wedi'i gynllunio, mae'r safonau'n cael eu disodli'n awtomatig â rhai newydd.

Mae'r offeryn hefyd yn mesur perfformiad cais gyda chywirdeb o hyd at 25 milieiliad. Mewn rhai achosion, rydym yn dolennu rhannau o'r sgript (er enghraifft, ailadrodd y cofnod gorchymyn sawl gwaith) i ddadansoddi diraddiad amser gweithredu dros amser. Mae canlyniadau pob mesur yn cael eu cofnodi mewn log ar gyfer dadansoddi.

Ynglŷn â'r cleient gwe 1C
Ein teclyn profi a chymhwysiad o dan brawf

Mae ein hofferyn a Seleniwm yn ategu ei gilydd; er enghraifft, os yw rhai botwm ar un o'r sgriniau wedi newid ei leoliad, efallai na fydd Seleniwm yn olrhain hyn, ond bydd ein hofferyn yn sylwi, oherwydd yn gwneud cymhariaeth picsel-wrth-picsel o'r sgrinlun â'r safon. Mae'r offeryn hefyd yn gallu olrhain problemau gyda phrosesu mewnbwn o'r bysellfwrdd neu'r llygoden, gan mai dyma'n union y mae'n ei atgynhyrchu.

Mae profion ar y ddau offeryn (ein un ni a Seleniwm) yn rhedeg senarios gwaith nodweddiadol o'n datrysiadau cymhwysiad. Mae profion yn cael eu lansio'n awtomatig ar ôl adeiladu'r platfform 1C:Menter bob dydd. Os yw sgriptiau'n arafach (o gymharu â'r adeiladwaith blaenorol), rydym yn ymchwilio ac yn datrys achos yr arafu. Mae ein maen prawf yn syml - ni ddylai'r adeilad newydd weithio'n arafach na'r un blaenorol.

Mae datblygwyr yn defnyddio gwahanol offer i ymchwilio i achosion o arafu; a ddefnyddir yn bennaf Argraffiad AJAX Dynatrace cwmni cynhyrchu DynaTrace. Cofnodir logiau o gyflawni'r gweithrediad problemus ar yr adeiladau blaenorol a'r adeiladau newydd, yna dadansoddir y logiau. Ar yr un pryd, efallai na fydd amser gweithredu gweithrediadau sengl (mewn milieiliadau) yn ffactor pendant - mae prosesau gwasanaeth fel casglu sbwriel yn cael eu lansio o bryd i'w gilydd yn y porwr, gallant orgyffwrdd ag amser gweithredu swyddogaethau ac ystumio'r llun. Paramedrau mwy perthnasol yn yr achos hwn fyddai nifer y cyfarwyddiadau JavaScript a weithredwyd, nifer y gweithrediadau atomig ar y DOM, ac ati. Os yw nifer y cyfarwyddiadau/gweithrediadau yn yr un sgript wedi cynyddu mewn fersiwn newydd, mae hyn bron bob amser yn golygu gostyngiad mewn perfformiad y mae angen ei gywiro.

Hefyd, efallai mai un o'r rhesymau dros y gostyngiad mewn perfformiad yw nad oedd Google Closure Compiler am ryw reswm yn gallu perfformio amnewidiad mewnol y swyddogaeth (er enghraifft, oherwydd bod y swyddogaeth yn ailadroddus neu'n rithwir). Yn yr achos hwn, rydym yn ceisio cywiro'r sefyllfa trwy ailysgrifennu'r cod ffynhonnell.

Estyniadau porwr

Pan fydd angen ymarferoldeb ar ddatrysiad cymhwysiad nad yw ar gael yn JavaScript, rydym yn defnyddio estyniadau porwr:

  • ar gyfer gweithio gyda ffeiliau
  • ar gyfer gweithio gyda cryptograffeg
  • gweithio gyda cydrannau allanol

Mae ein estyniadau yn cynnwys dwy ran. Y rhan gyntaf yw'r hyn a elwir yn estyniad porwr (fel arfer estyniadau ar gyfer Chrome a Firefox a ysgrifennwyd yn JavaScript), sy'n rhyngweithio â'r ail ran - estyniad deuaidd sy'n gweithredu'r ymarferoldeb sydd ei angen arnom. Dylid crybwyll ein bod yn ysgrifennu 3 fersiwn o estyniadau deuaidd - ar gyfer Windows, Linux a MacOS. Mae'r estyniad deuaidd yn cael ei gyflenwi fel rhan o'r platfform 1C:Menter ac mae wedi'i leoli ar weinydd cymhwysiad 1C. Y tro cyntaf y caiff ei alw gan gleient gwe, caiff ei lawrlwytho i'r cyfrifiadur cleient a'i osod yn y porwr.

Wrth redeg yn Safari, mae ein hestyniadau yn defnyddio NPAPI; wrth redeg yn Internet Explorer, maent yn defnyddio technoleg ActiveX. Microsoft Edge nid yw'n cefnogi estyniadau eto, felly mae'r cleient gwe ynddo yn gweithio gyda chyfyngiadau.

Datblygiad pellach

Un o dasgau tîm datblygu cleientiaid y we yw datblygu ymarferoldeb ymhellach. Dylai swyddogaeth y cleient gwe fod yn union yr un fath ag ymarferoldeb y cleient tenau; gweithredir pob swyddogaeth newydd ar yr un pryd yn y cleientiaid tenau a'r we.

Mae tasgau eraill yn cynnwys datblygu'r bensaernïaeth, ailffactorio, gwella perfformiad a dibynadwyedd. Er enghraifft, un o'r cyfarwyddiadau yw symudiad pellach tuag at fodel gwaith asyncronaidd. Mae peth o ymarferoldeb y cleient gwe wedi'i adeiladu ar hyn o bryd ar fodel cydamserol o ryngweithio â'r gweinydd. Mae'r model asyncronig bellach yn dod yn fwy perthnasol mewn porwyr (ac nid yn unig mewn porwyr), ac mae hyn yn ein gorfodi i addasu'r cleient gwe trwy ddisodli galwadau cydamserol â rhai asyncronig (ac ailffactorio'r cod yn unol â hynny). Eglurir y trawsnewid graddol i fodel asyncronaidd gan yr angen i gefnogi datrysiadau a ryddhawyd a'u haddasiad graddol.

Ffynhonnell: hab.com

Ychwanegu sylw