Cách tiếp cận nào để làm theo để phát triển các ứng dụng nhắm mục tiêu vào nhiều nền tảng?

Đối với các ứng dụng nhắm mục tiêu nhiều nền tảng, tôi thấy chủ yếu là hai cách tiếp cận phát triển-

• Đi cho một số nền tảng phát triển giống như JAVA. Có một giải pháp mã và để thời gian chạy trung gian xử lý các nền tảng khác nhau. Nếu có lỗi xảy ra trong bất kỳ nền tảng nào, hãy chỉnh sửa mã một chút. Nhưng giữ nó cho tất cả.

• Tạo mã mô-đun phân tách logic lõi và giao diện người dùng. Phát triển các UI riêng cho các nền tảng tương ứng sẽ gọi các thư viện lõi giống nhau. Xây dựng ứng dụng riêng cho từng nền tảng đích.

Vì vậy, cái nào để làm theo? Tôi biết, câu trả lời sẽ bắt đầu bằng " Nó phụ thuộc ". Nhưng tôi muốn nghe ý kiến ​​của bạn về các phương pháp này và các yếu tố được xem xét để lựa chọn bất kỳ trong số chúng.

Oracle / Apache / Google hiện tại đã bỏ qua một bên, vẫn khó có thể đánh bại JVM cho mục đích này. Nó thực sự có chất lượng rất cao trên hầu hết các nền tảng, phổ quát và bạn có nhiều ngôn ngữ để lựa chọn (Java, Clojure, Scala, v.v.). Nó cho phép bạn nhắm mục tiêu một kiến ​​trúc máy đơn (VM) và không phải lo lắng quá nhiều về phần cứng người dùng cuối cụ thể.

Điều đó nói rằng, có một số loại ứng dụng nhất định có thể không phù hợp với: mạng cấp thấp xuất hiện trong tâm trí, cũng như xử lý đồ họa / video nặng.

Đi cho HTML5. Bất kỳ nền tảng nào có trình duyệt HTML5 đều có thể chạy ứng dụng của bạn. Mặc dù HTML5 chưa sẵn sàng cho thời gian lớn, nhưng cách tiếp cận ứng dụng Web là.

Trong trình chỉnh sửa âm thanh Audacity, chúng tôi sử dụng wxWidgets làm thư viện đa nền tảng của chúng tôi. Vì chúng tôi cần liên kết đến các thư viện C và chúng tôi cần truy cập tốc độ và mức độ thấp, nên cách tiếp cận JVM sẽ không hiệu quả với chúng tôi. Mã GUI giống nhau 95% trên tất cả các nền tảng. Chúng tôi sử dụng #ifdefs cho các biến thể nhỏ. Tuy nhiên, chúng tôi thấy cần có một nhà phát triển làm việc trên cả ba nền tảng (Mac, Windows Linux), bởi vì ngay cả khi sử dụng thư viện đa nền tảng, việc thay đổi một máy trên một máy khác là quá dễ dàng.

Nếu bạn có thể có được hiệu năng bạn cần, hãy tìm JVM. Nếu bạn không thể, hãy sử dụng QT hoặc wxWidgets và tôi sẽ đề xuất QT qua wxWidgets vì sẽ ít làm việc hơn để khiến nó trông đẹp hơn.

Là một nhà phát triển thời gian thực, tôi đã sử dụng thành công một tùy chọn tương tự như 2 - các mô-đun dành riêng cho nền tảng với một API chung được sử dụng bởi logic lõi. Tuy nhiên, không có gì tôi làm được có UI - kết nối mạng, âm thanh, truyền dữ liệu - trong trường hợp này là giao diện phần cứng cấp thấp dành riêng cho nền tảng.

Tôi đã làm theo cách này vì nhiều lý do:

1) Để có được hiệu suất tối ưu trên mỗi nền tảng

2) Tận dụng các tính năng chỉ được cung cấp trên 1 nền tảng

3) (J) VM không tồn tại đối với một số nền tảng (hệ thống nhúng, máy chơi game ...)

Nó phụ thuộc vào những gì quan trọng với bạn :)

Khi chúng tôi phải đối mặt với lựa chọn này cho ứng dụng Mac / Windows đa nền tảng khoảng 10 năm trước, chúng tôi đã có một cái nhìn tốt xung quanh các tùy chọn đa nền tảng khác nhau - Java, Qt, wxWidgets, v.v. Vấn đề chúng tôi gặp phải là giao diện Giao diện người dùng thực sự quan trọng đối với chúng tôi và tất cả các ứng dụng "đa nền tảng" trông có vẻ đã bị xâm phạm. Cuối cùng chúng tôi đã cắn viên đạn và xây dựng lõi đa nền tảng của riêng mình, với giao diện người dùng tùy chỉnh cho mỗi nền tảng trên cùng (được viết bằng PowerPlant cho Mac và MFC trên Windows). Theo thời gian, chúng tôi đã khá tốt về điều này và phần "đa nền tảng" đã dày hơn mà không ảnh hưởng đến giao diện người dùng.

Bây giờ chúng tôi đang xem xét quyết định này một lần nữa cho một dự án mới. Nhìn vào các tùy chọn bây giờ, tôi có thể sẽ đi với Qt - nó miễn phí và dường như đã trưởng thành tốt đẹp. Java có thể là một tùy chọn nhưng chúng tôi thực sự không thể đạt được hiệu suất (chúng tôi đang xử lý hình ảnh 3D).

Nếu UI thực sự quan trọng đối với bạn, tôi nghi ngờ bạn sẽ phải đầu tư khá nhiều thời gian để mọi thứ trở nên phù hợp trên từng nền tảng cho dù bạn sử dụng thứ gì đó như Qt hay tự cuộn. Đối với một ứng dụng nội bộ hoặc chuyên gia nơi người dùng có thể chấp nhận giao diện người dùng ít bóng bẩy hơn, điều đó có thể ổn!

Mọi người đều gây ồn ào về các ngôn ngữ như Java là "nền tảng chéo" nhưng điều họ thực sự đang nói đến là bạn có thể biên dịch một lần và chạy ở mọi nơi. Ngay cả trong một ngôn ngữ như Java (hoặc C # / mono), bạn vẫn sẽ cần các lớp trừu tượng để xử lý các chi tiết cụ thể của HĐH trong một số lĩnh vực.

C ++, và trên thực tế hầu hết các ngôn ngữ, là nền tảng chéo, bạn chỉ cần biên dịch để nhắm mục tiêu từng nền tảng.

Chìa khóa của họ là quá trình chứ không phải là các công cụ / ngôn ngữ:

1. Hãy chắc chắn rằng bạn có một quy trình xây dựng tích hợp để xây dựng và chạy các bài kiểm tra đơn vị cho tất cả các nền tảng đích .
2. Đảm bảo mọi nhà phát triển kiểm tra trên tất cả các nền tảng đích trước khi kiểm tra mã - Điều này rõ ràng có nghĩa là đảm bảo rằng nhà phát triển có quyền truy cập vào số lượng máy / vms thích hợp.
3. Tóm tắt tốt. Trừu tượng tất cả mọi thứ mà gọi vào apis bản địa. Viết thư viện bao bọc các cuộc gọi này.
4. Nếu bạn đang làm bất cứ điều gì ngoài giao diện người dùng khá đơn giản, chỉ phục vụ cho mẫu số chung thấp nhất, chỉ cần chấp nhận rằng mã GUI không phải là nền tảng chéo. Tóm tắt lớp GUI / trình bày của bạn ra và mã hóa riêng cho từng nền tảng. Vâng, có các bộ công cụ GUI đa nền tảng, rất phù hợp cho các ứng dụng chuyển tiếp thẳng nhưng nếu bạn đang làm bất cứ điều gì nâng cao hơn, bạn sẽ muốn mã hóa các khả năng của nền tảng gốc.

Các bước này đều giống nhau cho dù bạn sử dụng ngôn ngữ / bộ công cụ / khung nào.

Tận dụng Web!

Nghiêm túc mà nói, nếu bạn muốn THE bang nhất cho bạn, hãy viết một ứng dụng web.

Tại sao?

• Các máy khách web thường không yêu cầu nhiều năng lượng PC.
• Khách hàng web là MỌI NƠI. Không chỉ PC / MAC / Linux, mà trên điện thoại, thiết bị di động, v.v.
• Không có gì thêm để tải về cho người dùng! (Thông thường, trừ khi bạn muốn một cái gì đó lạ mắt và sử dụng Flash, hoặc Silverlight)
• Tất cả các thành phần phổ biến nằm ở phía máy chủ và có thể là Java, .NET, PHP hoặc một hodgepodge của một loạt các thành phần hiện có mà bạn có. Các khách hàng không nên quan tâm!

Ngay cả hai cách tiếp cận bạn đề cập cũng rất giống nhau. Trình duyệt web hiển thị HTML cho nhiều kiến ​​trúc cơ bản. Tương tự, JVM diễn giải mã Java theo cách có ý nghĩa đối với phần cứng bên dưới. Tuy nhiên, web chỉ đơn giản là có một cơ sở khách hàng rộng hơn!

Tôi đã có khá nhiều may mắn với Mono. Tôi có thể viết cùng một mã cho các máy tính windows như tôi làm cho các máy Linux và phần lớn, nó hoạt động trên cả hai. Và tôi có thể sử dụng các kỹ năng mà tôi đã biết trong C # và Winforms.

Làm một bằng chứng về khái niệm đầu tiên.

Nếu đó là một ứng dụng khá phức tạp, việc đưa ra một bằng chứng về khái niệm sẽ cho bạn ý tưởng về những tính năng ngôn ngữ bạn cần và những lĩnh vực bạn sẽ cần để tận dụng các thư viện khung hoặc bên thứ ba.

Các tính năng ngôn ngữ và thư viện bạn cần sẽ xác định ngôn ngữ nào bạn sẽ chọn (và do đó, cách bạn sẽ tiếp cận với hỗ trợ đa nền tảng)

Tôi đã xây dựng một hệ thống, bắt đầu với một ứng dụng máy tính để bàn, 15 năm trước khi Java vẫn còn ở giai đoạn sơ khai và chưa sẵn sàng để sử dụng để xây dựng các loại ứng dụng này. Tôi biết rằng tôi cần phải có lõi trong C ++ và thiết kế nó ngay từ đầu để trở thành nền tảng chéo, bao gồm sử dụng các loại có kích thước (ví dụ int32 thay vì int hoặc long), để nó có thể chạy trên Mac, Windows và UNIX (tiền Linux ngày).

Vào thời điểm tôi cố gắng tìm kiếm một môi trường UI đa nền tảng tốt, đã có một vài cái sau đó bao gồm XVT. Tôi đã trải qua khóa đào tạo cho XVT và khi tôi bắt đầu xây dựng một ứng dụng thực sự, tôi nhận ra rằng tôi sẽ không thể tạo ra giao diện sạch sẽ, tự nhiên trên nền tảng (bắt đầu với Mac). Vì vậy, tôi đã từ bỏ ý tưởng đó và xây dựng giao diện người dùng Mac (PowerPlant) gốc trên lõi di động.

Vài năm sau, chúng tôi chuyển sang Windows (UI trong MFC). Việc xây dựng giao diện người dùng nhanh hơn lần thứ hai, chúng tôi đã duy trì song song giao diện người dùng Mac và Windows trong một thời gian ngắn và sau đó chuyển sang Windows. Lõi sau này chuyển sang các hương vị khác nhau của UNIX và Linux, để cho phép chúng tôi chạy các tính toán dựa trên máy chủ. Lõi đã hoạt động tốt, với một số điều chỉnh khi chúng tôi sẵn sàng 64-bit.

Bây giờ tôi quay lại sử dụng máy Mac và tôi ước chúng tôi có thể quay lại máy Mac, nhưng kích thước và độ phức tạp của ứng dụng khiến đây là một lựa chọn khó khăn. Nó vẫn có ý nghĩa đối với phần lớn ứng dụng này là một ứng dụng máy tính để bàn - nó giống như một môi trường CAD. Nhưng thay vì xây dựng lại UI bằng ngôn ngữ C / C ++ dành riêng cho nền tảng (và tiếp tục duy trì UI dựa trên MFC), tôi có xu hướng viết lại toàn bộ ngăn xếp trong Java để nó có thể chạy trên nhiều nền tảng.

Vẫn có thể có lý do để chạy lõi không phải Java, nói C ++ như chúng ta đã làm. Nhưng tôi sẽ muốn chạy thử nghiệm hiệu suất sớm để xem nếu điều đó thực sự cần thiết. Và tôi sẽ xem xét kỹ giao diện người dùng của mình để xem liệu tôi có thể xây dựng nó như một ứng dụng web, kết nối với lõi thông qua các dịch vụ web hay không, vì vậy tôi có thể có một loạt khách hàng - ứng dụng máy tính để bàn, ứng dụng di động, ứng dụng web, v.v. Nếu tôi cần một phần trong C hoặc C ++, nó có thể được viết dưới một lớp Java không? Hay như một dịch vụ web?

Một cân nhắc khác - ứng dụng của bạn sẽ tồn tại bao lâu? Làm thế nào nó sẽ phát triển phức tạp? Nếu bạn có bất kỳ ý tưởng nào về điều này, hãy xem xét tuổi thọ có thể có của bất kỳ thư viện UI nào bạn đang sử dụng và khả năng của bạn theo thời gian để có người giúp duy trì chúng. Điều này có thể khó để xem xét bây giờ nhưng đáng suy nghĩ.

- Alex

Nếu bạn có thể biến nó thành một ứng dụng web, hãy biến nó thành một ứng dụng web. Sử dụng các bộ công cụ như ExtJS , việc tạo giao diện người dùng tương thích với trình duyệt tương tự như trình duyệt GUI tương đối dễ dàng.

Mặt khác, Java hoặc QT + C ++ hoặc C + Wx là các tùy chọn có thể có một nguồn cho tất cả.

Cách tiếp cận thứ hai của bạn là phù hợp nếu bạn muốn ứng dụng trông và cảm thấy tự nhiên trên mọi nền tảng đích. Các ứng dụng Mac gốc trông và cảm nhận khác với các ứng dụng Windows gốc, chỉ cần sử dụng giao diện và các phím khác sẽ không đủ để đáp ứng điều đó.