Một trong những tính năng hay của công nghệ 1C:Enterprise là giải pháp ứng dụng, được phát triển bằng công nghệ biểu mẫu được quản lý, có thể được khởi chạy cả trong ứng dụng khách mỏng (có thể thực thi) cho Windows, Linux, MacOS X và dưới dạng ứng dụng khách web cho 5 trình duyệt - Chrome, Internet Explorer, Firefox, Safari, Edge và tất cả những thứ này mà không thay đổi mã nguồn ứng dụng. Hơn nữa, bên ngoài ứng dụng trong máy khách mỏng và trong trình duyệt hoạt động và trông gần như giống hệt nhau.
Tìm 10 điểm khác biệt (2 hình dưới phần cắt):
Cửa sổ máy khách mỏng trên Linux:
Cửa sổ tương tự trong ứng dụng khách web (trong trình duyệt Chrome):
Tại sao chúng tôi tạo ra một ứng dụng web? Nói một cách hơi thảm hại, thời gian đã đặt ra một nhiệm vụ như vậy cho chúng ta. Làm việc qua Internet từ lâu đã là điều kiện tiên quyết cho các ứng dụng kinh doanh. Đầu tiên, chúng tôi đã bổ sung khả năng làm việc qua Internet cho máy khách mỏng của mình (nhân tiện, một số đối thủ cạnh tranh của chúng tôi đã dừng ở đó; ngược lại, những người khác đã từ bỏ máy khách mỏng và hạn chế triển khai máy khách web). Chúng tôi quyết định cho người dùng cơ hội lựa chọn tùy chọn khách hàng phù hợp nhất với họ.
Việc bổ sung các khả năng dựa trên web vào máy khách tối thiểu là một dự án lớn với sự thay đổi hoàn toàn về kiến trúc máy khách-máy chủ. Tạo một ứng dụng khách web là một dự án hoàn toàn mới, bắt đầu từ đầu.
Báo cáo sự cố
Vì vậy, yêu cầu của dự án: máy khách web phải thực hiện giống như máy khách mỏng, cụ thể là:
- Hiển thị giao diện người dùng
- Thực thi mã khách hàng được viết bằng ngôn ngữ 1C
Giao diện người dùng trong 1C được mô tả trong trình chỉnh sửa trực quan, nhưng mang tính khai báo, không có sự sắp xếp các phần tử theo từng pixel; Khoảng ba chục loại thành phần giao diện được sử dụng - nút, trường nhập (văn bản, số, ngày/giờ), danh sách, bảng, đồ thị, v.v.
Mã máy khách bằng ngôn ngữ 1C có thể chứa các cuộc gọi máy chủ, làm việc với tài nguyên cục bộ (tệp, v.v.), in và nhiều hơn thế nữa.
Cả máy khách tối thiểu (khi làm việc qua web) và máy khách web đều sử dụng cùng một bộ dịch vụ web để liên lạc với máy chủ ứng dụng 1C. Tất nhiên, việc triển khai máy khách là khác nhau - máy khách tối thiểu được viết bằng C++, máy khách web được viết bằng JavaScript.
Một chút lịch sử
Dự án máy khách web bắt đầu vào năm 2006, với một nhóm (trung bình) có 5 người. Ở các giai đoạn nhất định của dự án, các nhà phát triển đã tham gia để triển khai chức năng cụ thể (tài liệu bảng tính, sơ đồ, v.v.); theo quy định, đây chính là những nhà phát triển đã thực hiện chức năng này trong máy khách mỏng. Những thứ kia. các nhà phát triển đã viết lại các thành phần bằng JavaScript mà trước đây họ đã tạo bằng C++.
Ngay từ đầu, chúng tôi đã bác bỏ ý tưởng chuyển đổi tự động (thậm chí một phần) mã máy khách C++ sang máy khách web JavaScript do sự khác biệt lớn về khái niệm giữa hai ngôn ngữ; ứng dụng khách web được viết bằng JavaScript từ đầu.
Trong những lần lặp lại đầu tiên của dự án, máy khách web đã chuyển đổi mã máy khách bằng ngôn ngữ 1C tích hợp trực tiếp thành JavaScript. Máy khách tối thiểu hoạt động khác - mã bằng ngôn ngữ 1C tích hợp được biên dịch thành mã byte và sau đó mã byte này được diễn giải trên máy khách. Sau đó, máy khách web cũng bắt đầu làm điều tương tự - thứ nhất, nó mang lại hiệu suất tăng và thứ hai, nó giúp có thể thống nhất kiến trúc của máy khách web và máy khách mỏng.
Phiên bản đầu tiên của nền tảng 1C:Enterprise có hỗ trợ máy khách web được phát hành vào năm 2009. Máy khách web lúc đó hỗ trợ 2 trình duyệt - Internet Explorer và Firefox. Các kế hoạch ban đầu bao gồm hỗ trợ cho Opera, nhưng do các vấn đề không thể khắc phục vào thời điểm đó với trình xử lý đóng ứng dụng trong Opera (không thể theo dõi chắc chắn 100% rằng ứng dụng đang đóng và tại thời điểm đó hãy thực hiện quy trình ngắt kết nối khỏi máy chủ ứng dụng 1C) khỏi các kế hoạch này đã phải bị loại bỏ.
Cấu trúc dự án
Tổng cộng, nền tảng 1C:Enterprise có 4 dự án được viết bằng JavaScript:
- WebTools – thư viện dùng chung được các dự án khác sử dụng (chúng tôi cũng bao gồm ).
- phần tử điều khiển (được triển khai bằng JavaScript ở cả máy khách mỏng và máy khách web)
- phần tử điều khiển (được triển khai bằng JavaScript ở cả máy khách mỏng và máy khách web)
- Máy khách web
Cấu trúc của từng dự án giống với cấu trúc của các dự án Java (hoặc các dự án .NET - tùy theo cái nào gần hơn); Chúng tôi có các không gian tên và mỗi không gian tên nằm trong một thư mục riêng. Bên trong thư mục có các tập tin và các lớp không gian tên. Có khoảng 1000 tệp trong dự án máy khách web.
Về mặt cấu trúc, máy khách web phần lớn được chia thành các hệ thống con sau:
- Giao diện ứng dụng khách hàng được quản lý
- Giao diện ứng dụng chung (menu hệ thống, bảng điều khiển)
- Giao diện của các biểu mẫu được quản lý, bao gồm khoảng 30 điều khiển (nút, nhiều loại trường nhập khác nhau - văn bản, số, ngày/giờ, v.v., bảng, danh sách, đồ thị, v.v.)
- Mô hình đối tượng có sẵn cho các nhà phát triển trên máy khách (tổng cộng hơn 400 loại: mô hình đối tượng giao diện được quản lý, cài đặt bố cục dữ liệu, kiểu dáng có điều kiện, v.v.)
- Trình thông dịch ngôn ngữ 1C tích hợp
- Tiện ích mở rộng trình duyệt (được sử dụng cho chức năng không được hỗ trợ trong JavaScript)
- Làm việc với mật mã
- Làm việc với tệp
- Công nghệ của các thành phần bên ngoài, cho phép chúng được sử dụng trong cả máy khách mỏng và web
Tính năng phát triển
Việc thực hiện tất cả những điều trên trong JavaScript không hề dễ dàng. Có lẽ máy khách web 1C là một trong những ứng dụng phía máy khách lớn nhất được viết bằng JavaScript - khoảng 450.000 dòng. Chúng tôi tích cực sử dụng cách tiếp cận hướng đối tượng trong mã máy khách web, giúp đơn giản hóa công việc với một dự án lớn như vậy.
Để giảm thiểu kích thước của mã máy khách, trước tiên chúng tôi sử dụng bộ obfuscator của riêng mình và bắt đầu với phiên bản nền tảng 8.3.6 (tháng 2014 năm XNUMX), chúng tôi bắt đầu sử dụng . Hiệu quả của việc sử dụng số lượng – kích thước của khung máy khách web sau khi làm xáo trộn:
- Bộ obfuscator riêng – 1556 kb
- Trình biên dịch đóng cửa của Google – 1073 kb
Việc sử dụng Trình biên dịch đóng cửa của Google đã giúp chúng tôi cải thiện hiệu suất của ứng dụng khách web lên 30% so với trình làm xáo trộn của chính chúng tôi. Ngoài ra, dung lượng bộ nhớ mà ứng dụng tiêu thụ đã giảm 15-25% (tùy thuộc vào trình duyệt).
Google Closure Compiler hoạt động rất tốt với mã hướng đối tượng nên hiệu quả của nó đối với máy khách web càng cao càng tốt. Trình biên dịch đóng cửa thực hiện một số điều tốt cho chúng tôi:
- Kiểm tra loại tĩnh ở giai đoạn xây dựng dự án (đảm bảo rằng chúng tôi bao gồm mã bằng các chú thích JSDoc). Kết quả là gõ tĩnh, rất gần với gõ trong C++. Điều này giúp bắt được tỷ lệ lỗi khá lớn ở giai đoạn biên soạn dự án.
- Giảm kích thước mã thông qua việc che giấu
- Ví dụ: một số tối ưu hóa mã được thực thi, chẳng hạn như:
- thay thế chức năng nội tuyến. Gọi một hàm trong JavaScript là một thao tác khá tốn kém và việc thay thế nội tuyến các phương thức nhỏ được sử dụng thường xuyên sẽ tăng tốc mã đáng kể.
- Đếm các hằng số tại thời điểm biên dịch. Nếu một biểu thức phụ thuộc vào một hằng số thì giá trị thực của hằng số đó sẽ được thay thế vào nó
Chúng tôi sử dụng WebStorm làm môi trường phát triển ứng dụng khách web của mình.
Để phân tích mã, chúng tôi sử dụng , nơi chúng tôi tích hợp các bộ phân tích mã tĩnh. Bằng cách sử dụng máy phân tích, chúng tôi theo dõi sự suy giảm chất lượng của mã nguồn JavaScript và cố gắng ngăn chặn điều đó.
Chúng ta đã/đang giải quyết những vấn đề gì?
Trong quá trình thực hiện dự án, chúng tôi đã gặp phải một số vấn đề thú vị mà chúng tôi phải giải quyết.
Trao đổi dữ liệu với server và giữa các windows
Có những tình huống mà mã nguồn bị xáo trộn có thể cản trở hoạt động của hệ thống. Mã bên ngoài mã thực thi của máy khách web, do bị xáo trộn, có thể có tên hàm và tham số khác với tên mà mã thực thi của chúng tôi mong đợi. Mã bên ngoài cho chúng tôi là:
- Mã đến từ máy chủ ở dạng cấu trúc dữ liệu
- Mã cho một cửa sổ ứng dụng khác
Để tránh tình trạng khó hiểu khi tương tác với máy chủ, chúng tôi sử dụng thẻ @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;
}Và để tránh tình trạng khó hiểu khi tương tác với các cửa sổ khác, chúng tôi sử dụng cái gọi là giao diện được xuất (giao diện trong đó tất cả các phương thức đều được xuất).
/**
* Экспортируемый интерфейс контрола 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 (){}Chúng tôi đã sử dụng Virtual DOM trước khi nó trở nên phổ biến)
Giống như tất cả các nhà phát triển xử lý các giao diện người dùng Web phức tạp, chúng tôi nhanh chóng nhận ra rằng DOM không phù hợp để làm việc với các giao diện người dùng động. Gần như ngay lập tức, một phiên bản tương tự của Virtual DOM đã được triển khai để tối ưu hóa công việc với giao diện người dùng. Trong quá trình xử lý sự kiện, tất cả các thay đổi DOM được lưu trữ trong bộ nhớ và chỉ khi tất cả các thao tác được hoàn thành, các thay đổi tích lũy mới được áp dụng cho cây DOM.
Tối ưu hóa máy khách web
Để làm cho ứng dụng khách web của chúng tôi hoạt động nhanh hơn, chúng tôi cố gắng sử dụng tối đa các khả năng tiêu chuẩn của trình duyệt (CSS, v.v.). Do đó, bảng lệnh biểu mẫu (nằm trên hầu hết mọi biểu mẫu của ứng dụng) được hiển thị độc quyền bằng các công cụ trình duyệt, sử dụng bố cục động dựa trên CSS.
Kiểm tra
Để kiểm tra chức năng và hiệu suất, chúng tôi sử dụng một công cụ độc quyền (viết bằng Java và C++), cũng như một bộ kiểm tra được xây dựng dựa trên .
Công cụ của chúng tôi rất phổ biến - nó cho phép bạn kiểm tra hầu hết mọi chương trình cửa sổ và do đó phù hợp để kiểm tra cả máy khách mỏng và máy khách web. Công cụ ghi lại hành động của người dùng đã khởi chạy giải pháp ứng dụng 1C vào tệp tập lệnh. Đồng thời, hình ảnh vùng làm việc của màn hình—tiêu chuẩn—được ghi lại. Khi giám sát các phiên bản mới của máy khách web, các tập lệnh được phát mà không có sự tham gia của người dùng. Trong trường hợp ảnh chụp màn hình không khớp với ảnh tham chiếu ở bất kỳ bước nào, quá trình kiểm tra được coi là không thành công, sau đó chuyên gia chất lượng sẽ tiến hành điều tra để xác định xem đây là lỗi hay là sự thay đổi theo kế hoạch trong hoạt động của hệ thống. Trong trường hợp hành vi được lên kế hoạch, các tiêu chuẩn sẽ tự động được thay thế bằng các tiêu chuẩn mới.
Công cụ này cũng đo hiệu suất ứng dụng với độ chính xác lên tới 25 mili giây. Trong một số trường hợp, chúng tôi lặp lại các phần của tập lệnh (ví dụ: lặp lại mục nhập đơn hàng nhiều lần) để phân tích mức độ suy giảm thời gian thực thi theo thời gian. Kết quả của tất cả các phép đo được ghi lại vào nhật ký để phân tích.
Công cụ thử nghiệm và ứng dụng đang được thử nghiệm của chúng tôi
Công cụ của chúng tôi và Selenium bổ sung cho nhau; ví dụ: nếu một số nút trên một trong các màn hình đã thay đổi vị trí của nó, Selenium có thể không theo dõi điều này, nhưng công cụ của chúng tôi sẽ nhận thấy, bởi vì so sánh từng pixel của ảnh chụp màn hình với tiêu chuẩn. Công cụ này cũng có thể theo dõi các vấn đề khi xử lý đầu vào từ bàn phím hoặc chuột, vì đây chính xác là những gì nó tái tạo.
Các thử nghiệm trên cả hai công cụ (của chúng tôi và Selenium) chạy các kịch bản công việc điển hình từ các giải pháp ứng dụng của chúng tôi. Các thử nghiệm được tự động khởi chạy sau quá trình xây dựng nền tảng 1C:Enterprise hàng ngày. Nếu các tập lệnh chậm hơn (so với bản dựng trước), chúng tôi sẽ điều tra và giải quyết nguyên nhân gây ra tình trạng chậm lại. Tiêu chí của chúng tôi rất đơn giản - bản dựng mới không được hoạt động chậm hơn bản dựng trước.
Các nhà phát triển sử dụng các công cụ khác nhau để điều tra các sự cố làm chậm; chủ yếu được sử dụng công ty sản xuất . Nhật ký thực hiện thao tác có vấn đề trên các bản dựng trước và mới được ghi lại, sau đó nhật ký được phân tích. Đồng thời, thời gian thực hiện các thao tác đơn lẻ (tính bằng mili giây) có thể không phải là yếu tố quyết định - các quy trình dịch vụ như thu gom rác được khởi chạy định kỳ trong trình duyệt, chúng có thể trùng lặp với thời gian thực hiện các chức năng và làm sai lệch hình ảnh. Các tham số phù hợp hơn trong trường hợp này sẽ là số lượng lệnh JavaScript được thực thi, số lượng thao tác nguyên tử trên DOM, v.v. Nếu số lượng hướng dẫn/thao tác trong cùng một tập lệnh tăng lên trong phiên bản mới, điều này hầu như luôn có nghĩa là hiệu suất giảm và cần phải sửa.
Ngoài ra, một trong những lý do khiến hiệu suất giảm có thể là do Trình biên dịch đóng cửa của Google vì lý do nào đó không thể thực hiện thay thế nội tuyến của hàm (ví dụ: vì hàm này là đệ quy hoặc ảo). Trong trường hợp này, chúng tôi cố gắng khắc phục tình trạng này bằng cách viết lại mã nguồn.
Tiện ích mở rộng của trình duyệt
Khi một giải pháp ứng dụng cần chức năng không có sẵn trong JavaScript, chúng tôi sử dụng các tiện ích mở rộng của trình duyệt:
- để làm việc với các tập tin
- để làm việc với mật mã
- làm việc với
Phần mở rộng của chúng tôi bao gồm hai phần. Phần đầu tiên được gọi là tiện ích mở rộng trình duyệt (thường là tiện ích mở rộng dành cho Chrome và Firefox được viết bằng JavaScript), tương tác với phần thứ hai - tiện ích mở rộng nhị phân triển khai chức năng chúng ta cần. Cần đề cập rằng chúng tôi viết 3 phiên bản phần mở rộng nhị phân - dành cho Windows, Linux và MacOS. Phần mở rộng nhị phân được cung cấp như một phần của nền tảng 1C:Enterprise và được đặt trên máy chủ ứng dụng 1C. Khi được gọi lần đầu tiên từ máy khách web, nó sẽ được tải xuống máy khách và cài đặt trong trình duyệt.
Khi chạy trong Safari, các tiện ích mở rộng của chúng tôi sử dụng NPAPI; khi chạy trong Internet Explorer, chúng sử dụng công nghệ ActiveX. chưa hỗ trợ các tiện ích mở rộng, vì vậy ứng dụng khách web trong đó hoạt động với những hạn chế.
Phát triển hơn nữa
Một trong những nhiệm vụ của nhóm phát triển máy khách web là phát triển thêm chức năng. Chức năng của máy khách web phải giống với chức năng của máy khách tối thiểu; tất cả chức năng mới được triển khai đồng thời trên cả máy khách mỏng và máy khách web.
Các nhiệm vụ khác bao gồm phát triển kiến trúc, tái cấu trúc, cải thiện hiệu suất và độ tin cậy. Ví dụ: một trong những hướng là tiếp tục hướng tới mô hình làm việc không đồng bộ. Một số chức năng của máy khách web hiện được xây dựng trên mô hình tương tác đồng bộ với máy chủ. Mô hình không đồng bộ hiện đang trở nên phù hợp hơn trong các trình duyệt (và không chỉ trong các trình duyệt) và điều này buộc chúng tôi phải sửa đổi ứng dụng khách web bằng cách thay thế các lệnh gọi đồng bộ bằng các lệnh gọi không đồng bộ (và tái cấu trúc mã cho phù hợp). Việc chuyển đổi dần dần sang mô hình không đồng bộ được giải thích là do nhu cầu hỗ trợ các giải pháp đã phát hành và việc điều chỉnh dần dần chúng.
Nguồn: www.habr.com