درباره مشتری وب 1C

یکی از ویژگی های خوب فناوری 1C: Enterprise این است که راه حل برنامه، توسعه یافته با استفاده از فناوری فرم های مدیریت شده، می تواند هم در یک کلاینت نازک (قابل اجرا) برای Windows، Linux، MacOS X و به عنوان یک سرویس گیرنده وب برای 5 مرورگر راه اندازی شود. کروم، اینترنت اکسپلورر، فایرفاکس، سافاری، اج و همه اینها بدون تغییر کد منبع برنامه. علاوه بر این، برنامه کاربردی در تین کلاینت و در مرورگر عملکردهای خارجی دارد و تقریباً یکسان به نظر می رسد.
10 تفاوت را پیدا کنید (2 تصویر زیر برش):

پنجره Thin Client در لینوکس:

همان پنجره در سرویس گیرنده وب (در مرورگر کروم):

چرا یک سرویس گیرنده وب ایجاد کردیم؟ به بیان تا حدی رقت انگیز، زمان چنین وظیفه ای را برای ما تعیین کرده است. کار از طریق اینترنت برای مدت طولانی پیش نیاز برنامه های تجاری بوده است. ابتدا، ما توانایی کار از طریق اینترنت را برای تین کلاینت خود اضافه کردیم (به هر حال، برخی از رقبای ما در آنجا متوقف شدند؛ برخی دیگر، برعکس، تین کلاینت را رها کردند و خود را به اجرای یک کلاینت وب محدود کردند). ما تصمیم گرفتیم به کاربران خود این فرصت را بدهیم تا گزینه مشتری را انتخاب کنند که برای آنها مناسب تر است.

افزودن قابلیت های مبتنی بر وب به تین کلاینت یک پروژه بزرگ با تغییر کامل در معماری کلاینت-سرور بود. ایجاد یک سرویس گیرنده وب یک پروژه کاملاً جدید است که از ابتدا شروع می شود.

بیانیه مشکل

بنابراین، الزامات پروژه: سرویس گیرنده وب باید همانند تین کلاینت انجام دهد، یعنی:

1. نمایش رابط کاربری
2. کد مشتری نوشته شده به زبان 1C را اجرا کنید

رابط کاربری در 1C در یک ویرایشگر بصری توضیح داده شده است، اما به صورت شفاف، بدون آرایش پیکسل به پیکسل عناصر. حدود سه دوجین نوع از عناصر رابط استفاده می شود - دکمه ها، فیلدهای ورودی (متن، عددی، تاریخ/زمان)، لیست ها، جداول، نمودارها و غیره.

کد مشتری در زبان 1C می تواند شامل تماس های سرور، کار با منابع محلی (فایل ها و غیره)، چاپ و موارد دیگر باشد.

هم تین کلاینت (هنگام کار از طریق وب) و هم کلاینت وب از مجموعه خدمات وب مشابهی برای ارتباط با سرور برنامه 1C استفاده می کنند. البته پیاده سازی های کلاینت متفاوت است - تین کلاینت با C++ نوشته شده است، کلاینت وب با جاوا اسکریپت نوشته شده است.

کمی از تاریخ

پروژه مشتری وب در سال 2006 با تیمی متشکل از (به طور متوسط) 5 نفر شروع شد. در مراحل خاصی از پروژه، توسعه دهندگان برای اجرای عملکردهای خاص (سند صفحه گسترده، نمودارها و غیره) مشارکت داشتند. به عنوان یک قاعده، اینها همان توسعه دهندگانی بودند که این عملکرد را در تین کلاینت انجام دادند. آن ها توسعه دهندگان کامپوننت هایی را که قبلا در C++ ایجاد کرده بودند در جاوا اسکریپت دوباره نوشتند.

از همان ابتدا، ما ایده هر گونه تبدیل خودکار (حتی جزئی) کد نازک کلاینت C++ به وب کلاینت جاوا اسکریپت را به دلیل تفاوت های مفهومی قوی بین این دو زبان رد کردیم. کلاینت وب از ابتدا با جاوا اسکریپت نوشته شده است.

در اولین تکرار پروژه، مشتری وب کد کلاینت را در زبان داخلی 1C مستقیماً به جاوا اسکریپت تبدیل کرد. تین کلاینت متفاوت عمل می کند - کد در زبان داخلی 1C به بایت کد کامپایل می شود و سپس این بایت کد بر روی مشتری تفسیر می شود. متعاقباً ، مشتری وب شروع به انجام همین کار کرد - اولاً باعث افزایش عملکرد شد و ثانیاً امکان یکسان سازی معماری مشتریان نازک و وب را فراهم کرد.

اولین نسخه پلتفرم 1C: Enterprise با پشتیبانی از مشتری وب در سال 2009 منتشر شد. کلاینت وب در آن زمان از 2 مرورگر - Internet Explorer و Firefox پشتیبانی می کرد. برنامه های اولیه شامل پشتیبانی از اپرا بود، اما به دلیل مشکلات غیرقابل حل در آن زمان با کنترل کننده های بسته شدن برنامه در اپرا (ممکن بود با اطمینان 100٪ بسته شدن برنامه را ردیابی کرد و در آن لحظه مراحل قطع ارتباط را از سرور برنامه 1C) از این برنامه ها باید کنار گذاشته می شد.

ساختار پروژه

در مجموع، پلت فرم 1C: Enterprise دارای 4 پروژه است که با جاوا اسکریپت نوشته شده اند:

1. WebTools – کتابخانه های مشترکی که توسط پروژه های دیگر استفاده می شود (ما همچنین شامل کتابخانه بسته شدن گوگل).
2. عنصر کنترل Formatted Document (در جاوا اسکریپت هم در تین کلاینت و هم در کلاینت وب پیاده سازی شده است)
3. عنصر کنترل برنامه ریز (در جاوا اسکریپت هم در تین کلاینت و هم در کلاینت وب پیاده سازی شده است)
4. مشتری وب

ساختار هر پروژه شبیه ساختار پروژه های جاوا (یا پروژه های دات نت - هر کدام نزدیکتر است) است. ما فضاهای نام داریم و هر فضای نام در یک پوشه جداگانه قرار دارد. در داخل پوشه فایل ها و کلاس های فضای نام وجود دارد. در پروژه کلاینت وب حدود 1000 فایل وجود دارد.

از نظر ساختاری، کلاینت وب تا حد زیادی به زیر سیستم های زیر تقسیم می شود:

• رابط برنامه مشتری مدیریت شده
  • رابط کاربری عمومی (منوهای سیستم، پانل ها)
  • رابط فرم های مدیریت شده، از جمله، از جمله، حدود 30 کنترل (دکمه ها، انواع مختلف فیلدهای ورودی - متن، عدد، تاریخ/زمان و غیره، جداول، لیست ها، نمودارها و غیره)

• مدل شی در دسترس برای توسعه دهندگان روی کلاینت (در مجموع بیش از 400 نوع: مدل شی رابط مدیریت شده، تنظیمات طرح بندی داده ها، یک ظاهر طراحی شرطی و غیره)
• مترجم زبان داخلی 1C
• پسوندهای مرورگر (برای عملکردی که در جاوا اسکریپت پشتیبانی نمی شود استفاده می شود)
  • کار با رمزنگاری
  • کار با فایل ها
  • فناوری اجزای خارجی، به آنها اجازه می دهد تا هم در کلاینت های تین و هم در وب استفاده شوند

ویژگی های توسعه

پیاده سازی همه موارد فوق در جاوا اسکریپت کار آسانی نیست. شاید وب کلاینت 1C یکی از بزرگترین برنامه های کاربردی سمت کلاینت باشد که با جاوا اسکریپت نوشته شده است - حدود 450.000 خط. ما به طور فعال از یک رویکرد شی گرا در کد مشتری وب استفاده می کنیم که کار با چنین پروژه بزرگی را ساده می کند.

برای به حداقل رساندن اندازه کد مشتری، ابتدا از مبهم کننده خودمان استفاده کردیم و با شروع نسخه 8.3.6 پلتفرم (اکتبر 2014) شروع به استفاده کردیم. کامپایلر بسته شدن گوگل. اثر استفاده در اعداد - اندازه چارچوب وب مشتری پس از مبهم سازی:

• مبهم کننده شخصی - 1556 کیلوبایت
• کامپایلر بسته شدن گوگل - 1073 کیلوبایت

استفاده از Google Closure Compiler به ما کمک کرد تا عملکرد کلاینت وب را تا 30 درصد در مقایسه با obfuscator خودمان بهبود بخشیم. علاوه بر این، میزان حافظه مصرفی برنامه بین 15 تا 25 درصد کاهش یافته است (بسته به مرورگر).

Google Closure Compiler با کدهای شی گرا بسیار خوب کار می کند، بنابراین کارایی آن برای مشتری وب تا حد امکان بالا است. Closure Compiler چند کار خوب برای ما انجام می دهد:

• بررسی نوع استاتیک در مرحله ساخت پروژه (اطمینان حاصل می کند که کد را با حاشیه نویسی JSDoc پوشش می دهیم). نتیجه تایپ ایستا است که از نظر سطح بسیار نزدیک به تایپ در C++ است. این کمک می کند تا درصد نسبتاً زیادی از خطاها را در مرحله تدوین پروژه دریافت کنید.
• کاهش اندازه کد از طریق مبهم سازی
• تعدادی از بهینه سازی های کد اجرا شده، به عنوان مثال، مانند:
  • جایگزینی توابع درون خطی فراخوانی یک تابع در جاوا اسکریپت یک عملیات نسبتاً گران است و جایگزینی درون خطی روش‌های کوچک پرکاربرد به طور قابل توجهی سرعت کد را افزایش می‌دهد.
  • شمارش ثابت ها در زمان کامپایل اگر یک عبارت به یک ثابت بستگی داشته باشد، مقدار واقعی ثابت به آن جایگزین می شود

ما از WebStorm به عنوان محیط توسعه مشتری وب خود استفاده می کنیم.

برای تجزیه و تحلیل کد استفاده می کنیم soundQube، جایی که ما تحلیلگرهای کد استاتیک را ادغام می کنیم. با استفاده از تحلیلگرها، کاهش کیفیت کد منبع جاوا اسکریپت را رصد می کنیم و سعی می کنیم از آن جلوگیری کنیم.

چه مشکلاتی را حل کردیم/در حال حل کردن هستیم؟

در طول اجرای پروژه با یکسری مشکلات جالب مواجه شدیم که باید آنها را حل می کردیم.

تبادل اطلاعات با سرور و بین ویندوز

شرایطی وجود دارد که مبهم سازی کد منبع می تواند در عملکرد سیستم اختلال ایجاد کند. کد خارج از کد اجرایی کلاینت وب، به دلیل مبهم بودن، ممکن است نام تابع و پارامتری داشته باشد که با نام هایی که کد اجرایی ما انتظار دارد متفاوت باشد. کد خارجی برای ما این است:

• کدی که از سرور به شکل ساختارهای داده می آید
• کد برای پنجره برنامه دیگر

برای جلوگیری از مبهم سازی هنگام تعامل با سرور، از تگ @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;
}

و برای جلوگیری از ابهام در هنگام تعامل با سایر ویندوزها، از رابط های به اصطلاح صادراتی (واسط هایی که در آن همه روش ها صادر می شوند) استفاده می کنیم.

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

ما از Virtual DOM قبل از تبدیل شدن به جریان اصلی استفاده کردیم)

مانند همه توسعه دهندگانی که با رابط های کاربری پیچیده وب سروکار دارند، ما به سرعت متوجه شدیم که DOM برای کار با رابط های کاربر پویا مناسب نیست. تقریباً بلافاصله، یک آنالوگ Virtual DOM برای بهینه‌سازی کار با رابط کاربری پیاده‌سازی شد. در طول پردازش رویداد، تمام تغییرات DOM در حافظه ذخیره می‌شود و تنها زمانی که تمام عملیات تکمیل شد، تغییرات انباشته شده روی درخت DOM اعمال می‌شود.

بهینه سازی سرویس گیرنده وب

برای اینکه کلاینت وب ما سریعتر کار کند، سعی می کنیم از قابلیت های استاندارد مرورگر (CSS و غیره) حداکثر استفاده را ببریم. بنابراین، پنل فرمان فرم (که تقریباً در هر فرمی از برنامه قرار دارد) منحصراً با استفاده از ابزارهای مرورگر و با استفاده از طرح‌بندی پویا بر اساس CSS ارائه می‌شود.

آزمایش

برای تست عملکرد و عملکرد، از یک ابزار اختصاصی (نوشته شده در جاوا و C++) و همچنین مجموعه ای از تست های ساخته شده در بالای آن استفاده می کنیم. سلنیوم.

ابزار ما جهانی است - به شما امکان می دهد تقریباً هر برنامه پنجره ای را آزمایش کنید و بنابراین برای آزمایش تین کلاینت و مشتری وب مناسب است. این ابزار اقدامات کاربری را که راه حل برنامه 1C را راه اندازی کرده در یک فایل اسکریپت ثبت می کند. در همان زمان، تصاویری از منطقه کاری صفحه نمایش - استانداردها - ضبط می شود. هنگام نظارت بر نسخه های جدید سرویس گیرنده وب، اسکریپت ها بدون مشارکت کاربر پخش می شوند. در مواردی که اسکرین شات در هیچ مرحله ای با تصویر مرجع مطابقت نداشته باشد، آزمایش ناموفق تلقی می شود، پس از آن یک متخصص کیفیت تحقیقی را برای تعیین اینکه آیا این یک خطا یا تغییر برنامه ریزی شده در رفتار سیستم است انجام می دهد. در صورت رفتار برنامه ریزی شده، استانداردها به طور خودکار با استانداردهای جدید جایگزین می شوند.

این ابزار همچنین عملکرد برنامه را با دقت حداکثر 25 میلی ثانیه اندازه گیری می کند. در برخی موارد، بخش‌هایی از اسکریپت را حلقه می‌کنیم (مثلاً چندین بار ورود سفارش را تکرار می‌کنیم) تا کاهش زمان اجرا را در طول زمان تجزیه و تحلیل کنیم. نتایج تمام اندازه گیری ها برای تجزیه و تحلیل در یک گزارش ثبت می شود.

ابزار و برنامه آزمایشی ما در حال آزمایش است

ابزار ما و سلنیوم مکمل یکدیگر هستند. به عنوان مثال، اگر برخی از دکمه‌های یکی از صفحه‌ها مکان خود را تغییر داده باشد، سلنیوم ممکن است آن را ردیابی نکند، اما ابزار ما متوجه خواهد شد، زیرا پیکسل به پیکسل اسکرین شات را با استاندارد مقایسه می کند. این ابزار همچنین قادر است مشکلات مربوط به پردازش ورودی از صفحه کلید یا ماوس را ردیابی کند، زیرا این دقیقا همان چیزی است که بازتولید می کند.

آزمایش‌های روی هر دو ابزار (ما و سلنیوم) سناریوهای کاری معمولی را از راه‌حل‌های کاربردی ما اجرا می‌کنند. پس از ساخت روزانه پلتفرم 1C:Enterprise، تست ها به طور خودکار راه اندازی می شوند. اگر اسکریپت ها کندتر هستند (در مقایسه با ساخت قبلی)، علت کندی سرعت را بررسی و برطرف می کنیم. معیار ما ساده است - ساخت جدید نباید کندتر از قبلی کار کند.

توسعه دهندگان از ابزارهای مختلفی برای بررسی حوادث کاهش سرعت استفاده می کنند. عمدتا استفاده می شود Dynatrace AJAX Edition شرکت تولیدی DynaTrace. گزارش‌های اجرای عملیات مشکل‌ساز در ساخت‌های قبلی و جدید ثبت می‌شوند، سپس گزارش‌ها تجزیه و تحلیل می‌شوند. در عین حال، زمان اجرای عملیات منفرد (در میلی ثانیه) ممکن است یک عامل تعیین کننده نباشد - فرآیندهای خدماتی مانند جمع آوری زباله به طور دوره ای در مرورگر راه اندازی می شوند، آنها می توانند با زمان اجرای عملکردها همپوشانی داشته باشند و تصویر را تحریف کنند. پارامترهای مرتبط تر در این مورد، تعداد دستورات جاوا اسکریپت اجرا شده، تعداد عملیات اتمی روی DOM و غیره خواهد بود. اگر تعداد دستورالعمل ها/عملیات در همان اسکریپت در نسخه جدید افزایش یافته باشد، این تقریباً همیشه به معنای کاهش عملکرد است که باید اصلاح شود.

همچنین، یکی از دلایل افت عملکرد ممکن است این باشد که Google Closure Compiler به دلایلی قادر به جایگزینی درون خطی تابع نبود (مثلاً به دلیل بازگشتی یا مجازی بودن تابع). در این مورد، سعی می کنیم با بازنویسی کد منبع، وضعیت را اصلاح کنیم.

پسوند مرورگر

هنگامی که یک راه حل کاربردی به عملکردی نیاز دارد که در جاوا اسکریپت موجود نیست، از پسوندهای مرورگر استفاده می کنیم:

• برای کار با فایل ها
• برای کار با رمزنگاری
• کار با اجزای خارجی

افزونه های ما از دو قسمت تشکیل شده است. بخش اول چیزی است که افزونه مرورگر نامیده می شود (معمولاً برنامه های افزودنی برای کروم و فایرفاکس نوشته شده در جاوا اسکریپت) که با بخش دوم تعامل دارند - یک افزونه باینری که عملکرد مورد نیاز ما را پیاده سازی می کند. لازم به ذکر است که ما 3 نسخه از افزونه های باینری را می نویسیم - برای ویندوز، لینوکس و MacOS. پسوند باینری به عنوان بخشی از پلت فرم 1C: Enterprise عرضه می شود و در سرور برنامه 1C قرار دارد. هنگامی که برای اولین بار از یک سرویس گیرنده وب فراخوانی می شود، در رایانه مشتری دانلود شده و در مرورگر نصب می شود.

هنگام اجرا در Safari، برنامه‌های افزودنی ما از NPAPI استفاده می‌کنند، و هنگام اجرا در اینترنت اکسپلورر، از فناوری ActiveX استفاده می‌کنند. مایکروسافت لبه هنوز از برنامه های افزودنی پشتیبانی نمی کند، بنابراین سرویس گیرنده وب در آن با محدودیت هایی کار می کند.

پیشرفتهای بعدی

یکی از وظایف تیم توسعه کلاینت وب، توسعه بیشتر عملکرد است. عملکرد وب کلاینت باید با عملکرد تین کلاینت یکسان باشد؛ همه عملکردهای جدید به طور همزمان در هر دو کلاینت تین و وب اجرا می شوند.

سایر وظایف شامل توسعه معماری، بازسازی، بهبود عملکرد و قابلیت اطمینان است. به عنوان مثال، یکی از جهت ها حرکت بیشتر به سمت یک مدل کار ناهمزمان است. برخی از عملکردهای سرویس گیرنده وب در حال حاضر بر اساس یک مدل همزمان تعامل با سرور ساخته شده است. مدل ناهمزمان در حال حاضر در مرورگرها (و نه تنها در مرورگرها) مرتبط‌تر شده است، و این ما را مجبور می‌کند تا با جایگزین کردن تماس‌های همزمان با تماس‌های ناهمزمان، کلاینت وب را اصلاح کنیم (و بر این اساس کد را تغییر دهیم). انتقال تدریجی به یک مدل ناهمزمان با نیاز به پشتیبانی از راه حل های منتشر شده و انطباق تدریجی آنها توضیح داده می شود.

منبع: www.habr.com