2012-06-08 29 views
14

Có chế độ xem web tốt hơn cho Android không? Các tài liệu của Google đề cập đến việc không dựa vào đối tượng webview.Có chế độ xem web tốt hơn cho Android

Nhưng đối với việc sử dụng webkit, có vẻ lạ khi nó quá hạn chế, so với các trình duyệt webkit khác được sử dụng trên thiết bị di động có phần cứng tương đương.

Điều này hiển nhiên trong việc triển khai trên thiết bị di động jquery hoặc triển khai sencha tương tự tương tự cho ứng dụng web. Phiên bản Android bị chậm lại, các vấn đề hiển thị và trải nghiệm người dùng kém, nơi các thiết bị di động khác - như một chiếc iPhone - sẽ chạy tốt. cả hai đều sử dụng webkit. và bên ngoài ứng dụng, trình duyệt android thực sự chỉ chạy tốt.

Có cách nào thực sự giải quyết vấn đề của Android, ở cấp độ thấp hơn không? Có ai đã tạo ra một đối tượng web toàn diện hơn cho Android không?

Thanks cho bất kỳ cái nhìn sâu sắc

Trả lời

6

tôi sợ rằng cả hai câu trả lời (Commonsware và Fuzzical Logic) được tránh thực tế.

Thực tế từ hai năm kinh nghiệm của chúng ta về việc phát triển một ứng dụng web HTML5 và sau đó ứng dụng PhoneGap (hybrid sử dụng xem web) dành cho iOS, Android và Windows Phone là:

công trình lớn trên iOS (cả Safari và trong WebView), hoạt động hợp lý trong Chrome trên Android, IE trên Windows 8 và IE WebView (tất cả đều có vấn đề, nhưng có thể được giải quyết) nhưng vẫn còn một cơn ác mộng trong Android WebView.

WebView trong Android đã bị hỏng và vẫn bị hỏng sau khi cập nhật lên KitKat bằng Chromium thay thế. Nó chỉ đơn giản là treo trên HTML5 bình thường (thậm chí không nhận được đến các vấn đề Javascript). Bạn sẽ tìm thấy rất nhiều của những người trong mạng quan sát những điều tương tự.

Những thứ như "Hỗ trợ Flash" không liên quan gì đến điều này - Flash không phải là HTML5. Có hay không một nhà sản xuất muốn hỗ trợ một plugin nhất định (hoặc, trong trường hợp này, một phần mềm trung gian) là tùy thuộc vào anh ta. Tôi luôn hiểu quyết định của Apple, và trong một WebView nó thậm chí còn ít ý nghĩa hơn.

Vì vậy, vấn đề là một vấn đề Android/Google, nhiều như những người ủng hộ nền tảng này muốn phủ nhận nó. Nó đặc biệt đáng xấu hổ cho một công ty luôn khóc "cởi mở" và sau đó không thể cung cấp một thành phần trình duyệt HTML5 hoạt động sau nhiều năm.

Nhưng câu hỏi của bạn là, nếu có bất kỳ WebView nào khác từ bất kỳ ai khác:

Vâng, chúng tôi rất muốn nghe về một. Xin lỗi chúng tôi cũng không tìm thấy một đến nay, và lý do có lẽ là chính xác những gì đã được đề cập trong bài viết trên: Rất khó để thực hiện nó và nó sẽ phụ thuộc phần cứng (tăng tốc phần cứng, vv). Tuy nhiên, vì Chrome hoạt động ít nhất là hợp lý (sau nhiều năm ...) Tôi tự hỏi liệu việc thiếu chất lượng tương tự trong Chromium WebView có phải là cố ý của Google hay không, cố gắng ngăn mọi người tránh xa các ứng dụng web tuyệt vời hoặc ứng dụng lai. (Hoàn toàn trái ngược với những gì Microsoft đang làm.)

+0

Bạn nói đúng. Nhưng bạn đã tìm thấy giải pháp nào cho vấn đề này? Có sự thay thế tốt cho webView không? –

0

Đây là chết tiệt gần một off-topic, gửi-bạn-rants-nơi khác-xin loại "câu hỏi".

Có chế độ xem web tốt hơn cho Android không?

Nếu bởi "webview" bạn có nghĩa là một Web nhúng rendering engine, có lẽ không, như viết cơ như vậy là cứng. Bạn có thể xem nếu có sẵn như là một nhánh của Firefox Mobile. Hoặc, bạn có thể tự tạo cổng WebKit của riêng mình cho Android, sử dụng phiên bản AOSP làm điểm bắt đầu. Lưu ý rằng cả hai khả năng tăng đáng kể kích thước ứng dụng của bạn.

Tài liệu của chính Google đề cập không dựa vào đối tượng xem web.

Trích dẫn, vui lòng.

Có ai đã tạo một đối tượng web toàn diện hơn cho Android không?

Điều đó tùy thuộc vào định nghĩa của một "đối tượng web toàn diện hơn". Đáng chú ý, bạn bỏ qua để cung cấp bất kỳ loại định nghĩa cho cụm từ này.

+3

Tôi sẽ giải quyết thông tin này theo từng phần, nhưng mọi người đã tạo danh sách tốt hơn, luồng không đồng bộ tốt hơn và đóng góp giải quyết vấn đề tổng thể cho cơ sở mã Android, như bạn đã biết.Đây là một câu hỏi về đối tượng Webview nhìn thấy nếu có ai đó đã tạo lại nó hoặc mở rộng nó để giải quyết các vấn đề thực sự mà đối tượng Webview có. – CQM

+2

@CQM: 'WebView' nằm trên một tấn số nguyên của mã gốc, điều này hạn chế tính linh hoạt của chúng tôi khi thực hiện thay đổi. Mọi thứ khác bạn trích dẫn đều được thực hiện hoàn toàn bằng Java. – CommonsWare

+1

@CoderSeven Có thể khủng khiếp cho trình độ kỹ năng của bạn, nhưng đây là những câu trả lời sâu sắc và mang tính thông tin cho người đã làm việc với nền tảng này một thời gian và không cần phải nắm tay họ. –

14

CQM,

Hiểu rằng tôi đồng ý với Commonswares và gần như mọi thứ được nêu trong câu trả lời được cung cấp. Tuy nhiên, câu hỏi dường như ngụ ý rằng có một vấn đề mà bạn đang gặp phải (hoặc là hiểu hoặc thụ thai) và muốn tìm/phát triển một giải pháp thích hợp hơn cho nhu cầu của bạn.

Phát biểu tại câu hỏi và các câu trả lời bạn có lẽ sẽ nhận được:

Tôi tin Commonswares hợp lệ chỉ trích là do thực tế rằng bạn không nêu tại sao hoặc cách đối tượng nền tảng được cung cấp không đạt yêu cầu, cũng như bạn không nêu rõ lý do tại sao hoặc khi bạn tin rằng Google đã nói rằng đối tượng đó không đáng tin cậy. Nếu bạn muốn có phản hồi tốt hơn, hãy chỉnh sửa câu hỏi của bạn một cách thích hợp để giao tiếp và bạn sẽ gặp ít vấn đề hơn ở đây.

Hơn nữa, như được giải thích thêm bên dưới, bạn ngụ ý rằng đây là một vấn đề với nền tảng Android (trên thực tế, hầu như trực tiếp tuyên bố nó) và nó không phải là. Có quá nhiều cân nhắc trong phạm vi rộng của duyệt web hoàn toàn được giải quyết bằng một điều khiển đơn giản như WebView. Microsoft phải đối mặt với vấn đề tương tự với đối tượng IE COM được nhúng của họ vào những năm 90. Đó là một vấn đề lớn không thuộc về một nhóm nào.

Phát biểu tại câu hỏi ngụ ý:

Đối tượng WebView về cơ bản là một mini-trình duyệt sử dụng đang vẽ rất linh hoạt dựa trên các thông số hoàn toàn khác với một trình duyệt chuyên dụng. Điều này bao gồm mọi thứ từ hiển thị đơn giản, cho đến các đối tượng tương tác (sp?) Chẳng hạn như các liên kết mà một trang như vậy sẽ sử dụng. Quá trình này rất khó (để thiếu một từ tốt hơn) để thu nhỏ theo cách mà khả năng là đồng nhất để nhúng vào nhiều ứng dụng có thể có cấu trúc bố cục và thông số khác nhau mỗi lần. Heck, các công cụ như vậy khó có thể lập trình đồng đều ngay cả với một công cụ duyệt web chuyên dụng, dẫn đến nhiều sự khác biệt giữa các trình duyệt chính hiện tại nói chung.

Như vậy, WebView không có nghĩa là cung cấp đầy đủ chức năng của trình duyệt chuyên dụng, nhưng các khía cạnh hữu ích nhất để hiển thị nội dung được phân phối trên web trong ứng dụng thường làm những việc khác. Điều này đặc biệt đúng khi bạn xem xét các tác động bảo mật của việc thêm chức năng Javascript hoặc xử lý dựa trên ứng dụng khách được phân phối từ nội dung đã nói. Thêm vào đó, mỗi thiết bị có khả năng có một công cụ hiển thị khác nhau hoặc phiên bản khác nhau của cùng một công cụ hiển thị, giống như cách các thiết bị khác nhau có khả năng khác nhau bằng cách sử dụng SQLite (ví dụ: Hỗ trợ khóa ngoài).

Như vậy, WebView được cung cấp như một giải pháp để hiển thị web đã phân phối nội dung không có bảo lãnh để mở rộng hoặc khả năng sử dụng của nó trừ khi bạn sử dụng nó thuần túy để xem (và có thể phản ứng) tin cậy và tiêu chuẩn tuân thủ QTI mã HTML. Một khi bạn nhận được vào thực tế thực tế của các trang web thế giới thực, bạn nhận ra rằng HTML đã được thực hiện rất linh hoạt cụ thể bởi vì mỗi tiêu chuẩn được tôn trọng ở các cấp độ khác nhau bởi các nhà phát triển khác nhau. Vì bản chính của HTML là nó hoạt động (hiển thị nội dung), mặc dù tiềm năng mơ hồ, vấn đề phát triển một giải pháp hướng đối tượng được nhúng hoàn toàn toàn diện trở nên khó phát triển hơn.

... nơi các thiết bị di động khác - giống như một iphone - sẽ chạy nó tốt

này phụ thuộc vào nội dung.Ngoài ra triết lý phát triển cho các thiết bị của Apple là hoàn toàn khác với Android. Apple chỉ có một số ít thiết bị, vì vậy họ có thể đảm bảo tính đồng nhất trên các thiết bị của họ và chọn thiết bị nào và khi nào để thêm các tính năng bổ sung. Ví dụ: iPhone đầu tiên không có hỗ trợ gốc cho Flash. Dựa trên ý nghĩa của câu hỏi của bạn, tôi tin rằng điều này thất bại trong bài kiểm tra "toàn diện".

Android, ngược lại, có nhiều tiết mục thiết bị hơn. Mã cho Android được điều chỉnh và thay đổi bởi các nhà sản xuất các thiết bị này để cho phép họ thực hiện các giải pháp hỗ trợ phù hợp hơn cho nhu cầu thiết bị cụ thể của họ. Google không thể đảm bảo rằng bất kỳ thiết bị cụ thể nào cũng sẽ giữ bất kỳ hoặc tất cả mã của nó giống nhau theo bất kỳ cách nào. Điều này tạo ra những hạn chế hơn nữa nhưng tạo ra các quyền tự do rất tuyệt vời khác.

... cả hai đều sử dụng webkit.

Cả Chrome và Safari đều sử dụng webkit. Nhiều nhà phát triển đã bị cản trở bởi những khác biệt trong cả hai phút theo cách mà cả hai đều sử dụng nó khác nhau.

... bên ngoài ứng dụng, trình duyệt android thực tế chỉ chạy tốt.

Điều này được giải quyết ở trên.

Có cách nào thực sự giải quyết vấn đề của Android, ở cấp độ thấp hơn không?

Một lần nữa, đây không phải là android của vấn đề. Nếu bạn đang gặp vấn đề cụ thể với việc triển khai hiện tại, bạn được tự do mã hóa một giải pháp riêng biệt. Hơn nữa, nội dung web đã được thực hiện để được xem trong trình duyệt và được cung cấp. Cách tốt nhất là xác định những gì bạn cần để thực hiện cụ thể. Bạn có cần WebView để xem bất kỳ trang web nào không? Hay chỉ là của bạn? Các vấn đề của bạn với kết xuất hiện tại của nó là gì? Bạn có yêu cầu kịch bản phía máy khách không?

Mọi công cụ đều được thực hiện theo nhu cầu cụ thể. Điều này thậm chí còn đúng với cái gọi là "tốt hơn" listviews. Những quan điểm đó được thực hiện để giải quyết các nhu cầu cụ thể mà có thể là cần thiết bởi nhiều hơn một nhà phát triển. Trong thế giới lập trình (đặc biệt là OOP), có rất ít thứ như vậy là toàn diện. Nếu có, chúng ta sẽ không phải mở rộng các vật thể của chúng ta ngay từ đầu. Khi nhìn vào một công cụ như vậy, hãy xem xét những gì cần nó đã được cụ thể cố gắng để giải quyết.

Có ai đã tạo một đối tượng web toàn diện hơn cho Android không?

Có. Chúng thường được thể hiện trong các trình duyệt chuyên dụng khác mà bạn có thể tải xuống thiết bị của mình. Về việc có hay không họ có thể truy cập: cá nhân, tôi không có ý tưởng và không nghiêng để xem xét.

Tuyên bố cuối cùng

Vấn đề bạn đã nêu ra là thực sự không đủ cụ thể để cung cấp một giải pháp đúng. Nó cũng dường như có một lập trường đối kháng, do sự lựa chọn từ kém. Nếu vấn đề của bạn không được giải quyết bằng câu trả lời của CommonsWare hoặc của riêng tôi, hãy xem xét chỉnh sửa câu hỏi của bạn để thêm các nhu cầu cụ thể hơn của chúng tôi. Điều đó nói rằng, tôi hy vọng cả hai câu trả lời của chúng tôi đều có thể cung cấp một số thông tin chi tiết cho bạn.

Hope this helps,

FuzzicalLogic

+2

Đây là giải thích tốt nhất cho webview của Android và lý do về sự khác biệt, ngay cả giữa các nhà sản xuất Android khác nhau. Cám ơn vì cái này! –

1

Tôi ngạc nhiên không ai đề cập đến CocoonJS.

Nó có một reimplementation của WebView chuẩn (Webview +); một Webview được đóng gói, vì vậy ứng dụng của bạn sẽ chạy liên tục trên các thiết bị (mặc dù bị giới hạn ở Android 4+ và iOS 8+).

Ngoài ra còn có một môi trường được gọi là Canvas + cho WebGL, nhưng hoàn toàn tách biệt với WebView +. Điều này có nghĩa là bạn cần phải phủ lớp WebView + lên trên Canvas + để hiển thị đồng thời với DOM và canvas. Họ không chia sẻ cùng một môi trường JS, nhưng có một hệ thống nhắn tin để gửi tin nhắn giữa hai người.

CocoonJS dường như không phải là giải pháp cấp sản xuất tốt vì hỗ trợ hệ điều hành bị hạn chế, nhưng có thể nó sẽ là trong tương lai.

Ngoài ra còn có Crosswalk. Nó hoạt động cho Android 4+ và Tizen.

+0

Không ai đề cập đến nó vì câu hỏi này đã được đăng 3 năm trước câu trả lời của bạn. Cảm ơn bạn đã chỉ ra ngay bây giờ – CQM

Các vấn đề liên quan