Những ưu và nhược điểm của phương pháp tiếp cận ứng dụng di động gốc, HTML5 và lai là gì?

Tôi muốn phát triển một ứng dụng di động. Gần đây tôi đã đọc một bài viết trên Diễn đàn Telerik , so sánh giữa ba loại ứng dụng di động và tôi không biết nên chọn loại nào để bắt đầu. Dưới đây là hình ảnh mô tả ưu và nhược điểm của các lựa chọn thiết kế di động khác nhau

Để quyết định giữa các lựa chọn thiết kế này, tôi muốn hiểu rõ hơn về ưu và nhược điểm của từng lựa chọn kiến ​​trúc được liệt kê trong sơ đồ. Những ưu và nhược điểm của từng phương pháp kiến ​​trúc là gì?

Tôi là một nhà phát triển di động đã dành rất nhiều thời gian để xem xét vấn đề này.

Tại sao bạn hỏi

Rất có thể, bạn hy vọng sẽ giảm chi phí phát triển ứng dụng bằng cách:

• Sử dụng các kỹ năng phát triển HTML5 / Javascript hiện có
• Nhắm mục tiêu nhiều nền tảng mà không cần viết nhiều ứng dụng từ đầu
• Không phải duy trì nhiều cơ sở mã trong tương lai

Lý do cũng có thể bao gồm:

• Phát triển HTML5 / Javascript được coi là "dễ dàng" hơn so với phát triển nền tảng bản địa
• Tránh thanh toán phí đăng ký chương trình dành cho nhà phát triển
• Tránh các hạn chế nội dung của cửa hàng ứng dụng (cờ bạc, v.v.)
• Tránh mua phần cứng phát triển (ví dụ: Mac để phát triển iPhone)

Định nghĩa

Chúng ta hãy thiết lập chính xác những gì chúng ta muốn nói trong mỗi ba phương pháp được đề cập:

Bản địa
Một ứng dụng được cài đặt trên thiết bị, thường là từ cửa hàng ứng dụng của nó (mặc dù đôi khi có thể được tải xuống). Đối với mục đích của cuộc thảo luận này, giao diện người dùng của ứng dụng gốc thường không chỉ bao gồm một chế độ xem web toàn màn hình.

Web di động
Trên thực tế có thể là bất kỳ trang web nào, tuy nhiên đối với cuộc thảo luận này, hãy xem xét một ứng dụng web một trang cố gắng bắt chước giao diện của ứng dụng gốc. Nó không phải là một ứng dụng gốc, nó chạy trong trình duyệt của thiết bị.

Lai
hybrid ứng dụng instanceofứng dụng bản địa.

Hầu hết mọi người có thể hiểu một ứng dụng lai là một ứng dụng web dành cho thiết bị di động (một lần nữa rất có thể bắt chước giao diện của ứng dụng gốc), nhưng được đóng gói dưới dạng một ứng dụng gốc có quyền truy cập vào các dịch vụ gốc (à la Phonegap).

Tuy nhiên, trên thực tế có một phổ giữa mô hình Phonegap và hoàn toàn tự nhiên mà tôi sẽ đến sau.

Web di động

Các hạn chế về kỹ thuật
Trước tiên, trước tiên, hãy liệt kê một số hạn chế kỹ thuật đối với các ứng dụng web dành cho thiết bị di động có thể là các công cụ giải quyết tùy thuộc vào những gì bạn đang làm:

• Chỉ giao diện người dùng HTML / canvas
• Không có quyền truy cập vào một số sự kiện và dịch vụ của thiết bị (những tài liệu này được ghi lại rộng rãi)
• Không thể được liệt kê trong các cửa hàng ứng dụng (ảnh hưởng đến khả năng khám phá)
• Có thể trở thành toàn màn hình và có biểu tượng màn hình chính trên iOS, tuy nhiên đây là một trải nghiệm bất thường và lạ lẫm đối với hầu hết người dùng

Nếu bạn có thể sống với tất cả những điều trên, thì hãy đọc tiếp để biết thêm về những thách thức của các ứng dụng web kiểu trang đơn. Tuy nhiên, phần này sẽ không hoàn thành nếu không tham khảo ứng dụng FT.

Financial Times
Các FT ứng dụng web là một ví dụ nổi tiếng của phong cách này của ứng dụng. Đây là một tính năng thú vị từ tờ báo Anh Guardian về nó.

Đó chắc chắn là một kỳ công đáng chú ý của kỹ thuật. Lưu ý rằng hiện tại nó vẫn chỉ khả dụng trên iOS - điều này cho tôi biết rằng họ đang thấy rằng việc giải quyết các thách thức của phát triển trình duyệt chéo tiên tiến thực sự rất khó khăn.

Các ứng dụng web kiểu đơn trang

Phần này áp dụng cho cả ứng dụng web di động và ứng dụng kiểu Phonegap.

Giao diện kiểu bản địa trong ứng dụng web thường đạt được với một khung như Sencha Touch cung cấp một bộ các thành phần UI để bạn sử dụng.

Các khung như vậy là tốt cho các UI rất đơn giản. Tuy nhiên họ thiếu linh hoạt. Bạn sẽ không thể triển khai bất kỳ thiết kế ứng dụng gốc nào bằng Sencha, bạn sẽ cần điều chỉnh thiết kế của mình theo những gì khung có thể đáp ứng.

Cách chính mà các khung công tác này phải chịu là cố gắng mô phỏng các rắc rối UI của chính nền tảng. Hiệu ứng nảy nhỏ tuyệt vời mà bạn có được khi bạn cuộn đến cuối danh sách trên iPhone? Khung của bạn cần mô phỏng điều đó trong Javascript. Không thể tạo lại hoàn toàn, nó sẽ dễ bị chậm lại và người dùng của bạn sẽ bị mắc kẹt trong "thung lũng kỳ lạ" của một ứng dụng trông giống như bản địa, nhưng rõ ràng là không, và phi kỹ thuật người dùng sẽ không thể đặt ngón tay của họ chính xác tại sao.

Huyền thoại "HTML5 / Javascript thật dễ dàng"

Sự phân mảnh thiết bị trong các trình duyệt web đầy rẫy và khi bạn vượt ra khỏi HTML và CSS cơ bản nhất, bạn sẽ nhận thấy mọi thứ không hoạt động như bạn mong đợi. Bạn có thể thấy mình dành nhiều thời gian hơn để giải quyết các vấn đề UI khó khăn hơn là bạn đã lưu nó thực hiện hai lần. Nếu bạn là người bản địa, lưu ý rằng các lần xem web ứng dụng gốc không giống như trình duyệt thiết bị và có các vấn đề phân mảnh riêng.

Và khi ứng dụng của bạn trở nên phức tạp hơn về mặt chức năng, bạn sẽ thấy rằng bạn cần nhiều hơn các kỹ năng jquery cơ bản để giữ cho Javascript của bạn sạch sẽ và có thể bảo trì.

Điều đó nói rằng, hoàn toàn có thể tạo ra các ứng dụng đơn giản, chức năng khá nhanh chóng với phương pháp này. Nhưng nó khá rõ ràng khi một ứng dụng đang làm điều đó.

Hơn nữa dọc theo quang phổ

Vì vậy, chúng tôi muốn có một UX tốt hơn các ứng dụng kiểu Phonegap có thể cung cấp, mà không cần viết hoàn toàn mọi thứ từ đầu nhiều lần. Chúng ta có thể làm gì?

Chia sẻ mã không phải UI

Có một loạt các kỹ thuật có sẵn để chia sẻ logic kinh doanh trên nhiều nền tảng bản địa. Google đã ra mắt J2ObjC , dịch Java thành Objective-C. Với việc bao thanh toán cẩn thận, một thư viện Java có thể được sử dụng trên cả Android và iOS.

Các thư viện như Calatrava và Kirin cho phép các cơ sở mã được viết bằng Javascript (và do đó, bất kỳ thứ gì có thể được biên dịch thành Javascript) đều được xử lý từ mã gốc. Tuyên bố miễn trừ trách nhiệm: Tôi làm việc cho các Nền tảng tương lai đã tạo ra Kirin; chúng tôi đã thành công lớn khi sử dụng nó trên iOS với Javascript được tạo từ Java bằng GWT, với mã Java cũng được chạy tự nhiên trên Android.

Sử dụng xem web ... khi thích hợp

Xem xét toàn màn hình có rất nhiều việc phải làm để có thể bắt chước chuyển đổi màn hình và hiệu ứng thoát. Nhưng một webview bên trong ứng dụng chrome có thể không thể phân biệt được với bản địa.

Có các phương pháp tiêu chuẩn và được ghi chép tốt cho các ứng dụng và webview để giao tiếp.

Danh sách và bảng có thể hoạt động đặc biệt tốt khi được thực hiện theo cách này, tuy nhiên, nhập văn bản là một ví dụ về thứ gì đó được xử lý tốt nhất (để kiểm soát hoàn toàn bàn phím).

Tóm tắt

Cách tiếp cận phù hợp với bạn phụ thuộc vào mức độ phức tạp của ứng dụng của bạn và mức độ đánh bóng UI bạn sẽ hài lòng.

Phương châm của tôi: sử dụng các cuộc xem web bất cứ nơi nào bạn có thể, nhưng hãy đảm bảo rằng người dùng của bạn không thể biết .

Trước tiên hãy kiểm tra khảo sát này để biết những gì đang xảy ra!

so sánh giữa ba loại: Tìm hiểu Tùy chọn phát triển ứng dụng di động của bạn

So sánh giữa bản địa và hyprid:

HTML5 so với bản địa

Ứng dụng HTML5 vs Native: Chọn loại nào ??

Điều này thực sự tốt: Ứng dụng gốc HTML5 v: những cân nhắc chính cho chiến lược di động của bạn

Bình luận:

• Bạn có thể chọn một trong số chúng tùy thuộc vào những gì bạn có (kỹ năng) và những gì bạn có thể nhận được (giao diện và cảm nhận, hiệu suất, chức năng, ...)
• Mỗi nhà phát triển ứng dụng di động nên có một tầm nhìn / yêu cầu rõ ràng về ứng dụng mà anh ta sắp phát triển cho các phiên bản đầu tiên và các phiên bản tương lai! chỉ để đảm bảo rằng tùy chọn anh ta sẽ sử dụng sẽ không giới hạn anh ta tại một số điểm.
• Không có gì giống như có một trải nghiệm thực sự với ba cách và được cập nhật cùng một lúc, điều này sẽ mang lại cho bạn cảm giác và khả năng đưa ra quyết định đúng đắn.

Nếu bạn cần truy cập phần cứng điện thoại, bạn nên xây dựng một ứng dụng gốc (trong HTML5, bạn có thể truy cập một số thành phần phần cứng của thiết bị như GPS).

Nếu bạn cảm thấy thoải mái hơn với việc phát triển web, bạn nên kiên trì với điều đó trừ khi bạn cần tạo một ứng dụng gốc.

Theo như những gì bạn nên biết, tôi sẽ nói rằng bạn nên ghi nhớ tất cả các kích thước màn hình khác nhau (bao gồm cả hướng dọc và ngang). Bạn nên ghi nhớ các phiên bản khác nhau của HĐH (cái này nhiều hơn cho Android). Vì đây là các thiết bị di động, có khả năng người dùng sẽ trả lời một cuộc gọi điện thoại đó là điện thoại và họ cũng không có khả năng tính toán của máy tính để bàn hoặc máy chủ.

Đối với tôi khi viết bất kỳ ứng dụng tiêu dùng nào, điều tối quan trọng đối với thành công của nó là sự chấp nhận của người dùng và nhận thức về ứng dụng. Vì bốn lý do để nghiêng về các ứng dụng gốc, mặc dù các chi phí bổ sung liên quan đến việc học, đào tạo và mất WORA (viết một lần chạy ở bất cứ đâu) là:

1. Khởi động ứng dụng nhanh hơn
2. Cuộn mượt hơn
3. Ứng dụng thống nhất hơn ui liên kết chặt chẽ hơn với các ứng dụng và hệ điều hành còn lại
4. Phản hồi UI ứng dụng nhanh hơn

Những gì bạn muốn trên tất cả mọi thứ khác là một trải nghiệm người dùng tuyệt vời giúp ứng dụng của bạn thành công trong một thị trường cắt cổ. Tất nhiên có những trường hợp ngoại lệ đặc biệt là thiếu kỹ năng, thiếu thời gian và ngân sách. Đôi khi các ứng dụng hướng đến một nhóm người dùng doanh nghiệp hạn chế, những người có thể không quan tâm nhiều đến những điều này.

Đó là những lý do tương tự như vậy mà Facebook đã từ bỏ chiến lược ứng dụng của họ để ủng hộ các ứng dụng gốc cho iOS và Android:

Xin vui lòng đọc:

Mark Zuckerberg: Sai lầm lớn nhất của chúng tôi đã đặt cược quá nhiều vào HTML5 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- html5 /

Tại sao Facebook từ bỏ Web di động và đi bản địa với ứng dụng iOS mới http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

Hi vọng điêu nay co ich.

Với những điều dưới đây, lập trường hiện tại của tôi về sự thất bại này là việc bắt đầu với, để khám phá ứng dụng của bạn, nhanh chóng lặp lại phản hồi của khách hàng và ổn định bộ tính năng. Sau đó, để viết lại ứng dụng về bản địa theo thông số kỹ thuật, để nâng cao trải nghiệm.

Tôi đã rời khỏi Web di động, vì nó phục vụ một mục đích hoàn toàn khác. Nếu bạn muốn có mặt trong các cửa hàng ứng dụng, Native / Hybrid là cách để đi. Nếu bạn muốn đơn giản hóa việc triển khai và sẵn sàng hy sinh kinh nghiệm và khả năng kỹ thuật, hãy truy cập Mobile Web.

Pro / Nhược điểm bản địa :

• Pro: Nó phù hợp với phần còn lại của trải nghiệm thiết bị, không có vấn đề thung lũng kỳ lạ .
• Pro: Nó chủ yếu cung cấp trải nghiệm UI ổn định trơn tru, không chậm trễ, không lắp đặt.
• Pro: Vài hạn chế kỹ thuật, bạn hoàn toàn có thể sử dụng thiết bị.
• Pro: Công cụ bản địa cung cấp tuân thủ xác thực cửa hàng ứng dụng.
• Pro: Khung công tác gốc bao gồm các tinh chỉnh cho mỗi phiên bản nền tảng, ít thời gian hơn cho việc tinh chỉnh.
• Con: Nó được xây dựng để tồn tại và do đó cần nhiều thời gian hơn để xây dựng.
• Con: Yêu cầu các nhà phát triển polyglot khó tìm, đắt tiền.
• Con: Cần làm quen với từng API nền tảng thiết bị (iOS / Android / vv).
• Con: Đường cong học tập ổn định.
• Con: Bộ công cụ khác nhau cho mỗi nền tảng.

Pro / Nhược điểm lai :

• Pro: Codebase đơn để nhắm mục tiêu nhiều nền tảng thiết bị.
• Pro: Chu kỳ phát triển nhanh, tính khả thi cao trong bố cục, hoàn hảo cho tạo mẫu và MVP .
• Pro: Đường cong học tập thoải mái, nhiều tài liệu, khung để giúp bạn ra ngoài.
• Pro: Bộ công cụ phát triển đơn. Công cụ gỡ lỗi Chrome là tuyệt vời.
• Pro: Một codebase để nhắm mục tiêu nhiều nền tảng thiết bị.
• Pro: Rất nhiều nhà phát triển có sẵn, dễ học.
• Con: Yêu cầu khung UI tốt để điều chỉnh UI cho mọi nền tảng khác nhau để phù hợp với trải nghiệm thiết bị. Có các giải pháp như Kendo UI , Sencha Touch .
• Con: Cần phải rất ý thức về bộ nhớ và tính toán sử dụng, một số vòng lặp CSS, javascript có thể làm chậm ứng dụng một cách nghiêm trọng. Không phải là công cụ rất tốt có sẵn trên thiết bị để gỡ lỗi.
• Con: Chưa trưởng thành, mọi thứ có thể đột ngột thay đổi, công cụ đang trở nên tốt hơn.

Là một nhà phát triển di động, điều tồi tệ nhất là truy cập ngoại tuyến. Bạn chỉ cần buộc người dùng trực tuyến sẽ hoạt động trong rất nhiều ứng dụng, nhưng không phải tất cả.

Các khía cạnh xấu lớn khác là chậm. Thời gian cần thiết để phân tích dữ liệu từ xa có thể mất thời gian đáng kể. Có, bạn có thể tìm nạp trước dữ liệu trong thời gian tải, nhưng trong tất cả các trường hợp khác, bạn không thể tránh bị chậm.

Tôi thấy rằng ứng dụng như vậy đã kết thúc ứng dụng đắt hơn ứng dụng bản địa. Tôi không còn giới thiệu họ cho bất kỳ khách hàng nào của tôi.

Vấn đề lớn với các ứng dụng lai là sự phân mảnh của các khung: rõ ràng có rất nhiều trong số chúng (Ionic, Xamarin, React Native, v.v.) so với các nền tảng di động gốc (thường chỉ có hai, Android và iOS). Các khung này cạnh tranh, xuất hiện, suy giảm, do đó, việc lai tạo sẽ không giúp bạn tránh khỏi việc nhảy từ nền tảng này sang nền tảng khác ngay cả khi bạn có kế hoạch duy trì đội ngũ hiện tại của mình suốt đời.

Google và Apple đang cố gắng hết sức để cung cấp và hỗ trợ các biên tập viên, trình gỡ lỗi, khung thử nghiệm, công cụ tái cấu trúc và các phương tiện khác để phát triển cho họ nền tảng. Do đó tôi sẽ có một từ ngữ điển hình " việc phát triển một ứng dụng lai dễ dàng hơn nhiều, chỉnh sửa với trình chỉnh sửa yêu thích của bạn và mở trong trình duyệt " với sự bảo lưu hợp lý. Xamarin và React Native là các nền tảng phát triển, giống như Swift hoặc Java / Android, và trong khi "hello world" có thể trông ngắn hơn, cuối cùng nên dành thời gian so sánh để học đúng cách.

Nếu, trong mọi trường hợp, nhu cầu về các thành phần gốc sẽ xuất hiện (ví dụ: thư viện bên thứ ba hiện tại phải được tích hợp), bạn sẽ kết thúc với ba khung chứ không phải hai: iOS, Android và khung lai của bạn ở trên cùng, kết thúc với kiến ​​trúc phức tạp hơn. Gỡ lỗi các ứng dụng như vậy, bước giữa các cuộc gọi giữa các lớp, ghi nhật ký tất cả các lớp, giữ mã đồng bộ hóa rất phức tạp đến mức không thể.

Một số người nói rằng " ứng dụng sẽ trông giống hệt nhau cho tất cả các nền tảng ". Nó thực sự là một điều tốt? Ứng dụng Android phải trông giống như ứng dụng Android và ứng dụng iOS phải giống như ứng dụng iOS.

Còn các tính năng mới thì sao? Thiết bị đeo? Ứng dụng tức thì được cung cấp bởi nền tảng Android? Hiển thị dữ liệu bổ sung trên màn hình ngoài? Các ứng dụng lai hiện hỗ trợ nhiều tính năng gốc, nhưng chúng có thực sự hỗ trợ tất cả chúng không? Bất cứ lúc nào, ngay lập tức?

Cuối cùng, không chỉ hiệu suất và trải nghiệm người dùng, mà còn bảo mật có thể hơn ở phía ứng dụng gốc. Hybrid framework thêm lớp gián tiếp có thể có lỗi riêng, lỗi bảo mật bao gồm.

Kết luận tất cả những điều trên, theo khả năng lựa chọn, tôi chắc chắn sẽ chọn hai ứng dụng gốc, một cho iOS và một cho Android hoặc đơn giản là thiết kế phiên bản di động của trang web mà không cần bận tâm đến việc phát triển ứng dụng cho bất kỳ nền tảng nào .