Trang 1 của 3 123 CuốiCuối
Kết quả 1 đến 10 của 22
  1. #1
    Ngày tham gia
    Jun 2014
    Bài viết
    0

    Bài phản pháo chính thức cho vấn đề kém mượt từ Android

    Bài viết này được lấy từ Google Plus, được viết bời Dianne Hackborn, thành viên chính của nhóm lập trình Android, nhằm phản bác lại bài viết từ anh chàng thực tập sinh Andrew Munn mấy hôm trước. Đây có thể coi là tiếng nói chính thức của Google cho vấn đề giao diện cảm ứng của Android



    Bài viết khá dài nhưng chi tiết, xin hãy bỏ chút thời gian đọc hết toàn bộ. Mình cũng tốn không ít công ngồi dịch, nếu bạn cảm thấy có ích, xin nhấn vào nút cảm ơn. Mọi góp ý chỉnh sửa, làm ơn nhắn tin riêng (PM) cho mình để giúp hoàn thiện bài viết.






    Một vài ngày trước tôi viết một bài post giải thích các nhận định sai lầm thường thấy về vấn đề đồ họa trên Android. Bài viết này đã kéo theo rất nhiều sự thảo luận hay và bổ ích. Tuy nhiên nó cũng dẫn đến việc một vài người nảy ra những ý tưởng kỳ lạ, và dẫn đến những phàn nàn không chính xác về họat động của Android (ám chỉ đến anh chàng thực tập sinh tại Google)



    Bài viết này sẽ giải thích rõ hơn về các quyết định thiết kế cơ bản của Android. Tôi cũng muốn giúp các bạn hiểu (và tự đánh giá) những thảo luận trước đây bằng việc giới thiệu một cách cơ bản nhất cách giao diện người dùng (UI-user interface) của Android thực sự hoạt động như thế nào.



    Có ý kiến cho rằng Android không phân thứ tự ưu tiên trong xử lý đa nhiệm nên những công việc nền có thể ảnh hưởng đến giao diện người dùng. Đây là nhận định sai hoàn toàn. Android thực sự có sử dụng thứ tự ưu tiên, bạn có thể tìm thấy một topic về vấn đề này tại đây http://developer.android.com/referen...PRIORITY_AUDIO trong SDK (software development kit)



    Điểm quan trọng nhất là về phần nền và các ưu tiên mặc định. Các thread (trong IT có thể hiểu rằng đây là các quy trình công việc được chia ra ở mức nhỏ nhất) liên quan đến UI thường chạy ở mức ưu tiên mặc định, các thread nền sẽ chạy ở mức ưu tiên nền. Tất cả các thread của ứng dụng chạy nền sẽ bị buộc phải chạy ở mức ưu tiên nền



    Ưu tiên nền của Android thực sự khá thú vị. Nó sử dụng một chức năng của Linux gọi là cgroup để đặt tất cả các thread nềnvào các nhóm kế hoạch đặc biệt, tổng cộng lại không được phép vượt quá 10% CPU. Cho dù bạn có 10 ứng dụng chạy nền cùng một lúc cũng không được phép vượt quá 10% này. Điều này là đủ để các thread nền chạy một cách từ từ mà cũng không tiêu tốn quá nhiều tài nguyên dành cho phần hiển thị trước người dùng (phần UI)



    (Bạn có thể nhận thấy rằng chúng tôi cũng đã định nghĩa các ưu tiên cận cảnh (ưu tiên UI). Ở các bản Android đầu chúng tôi nhận ra rằng lịch ưu tiên của Linux không đủ chi tiết trong việc đánh giá các thread, vì thế chúng tôi đã chuyển sang cgroup tử bản Android 1.6)



    Tôi cũng thấy một số tuyên bố rằng thiết kế cơ bản của Android là thiếu sót và lạc hậu trong cách nó dựng hình so với iOS (ở đây có thể hiểu là cách Android hiển thị các yếu tố hình ảnh ra ngoài màn hình). Đúng là iOS có một vài lợi thế, nhưng cách nhìn nhận này quá tập trung vào các chi tiết cụ thể mà quên đi cách những điểm chung giữa Android và iOS.



    Android có mục tiêu thiết kế ban đầu khác với iOS. Một mục tiêu quan trọng của Android là tạo ra một nền tảng ứng dụng mở, sử dụng các sandbox ứng dụng (sandbox là một môi trường ảo chuyên để chạy thử các ứng dụng không được tin tưởng một cách an toàn) để tạo ra các môi trường an toàn hơn mà không phải dựa trên một cơ quan quản lý trung ương xác minh hoạt động của các ứng dụng. Để làm được điều này, nó cách ly các quy trình Linux và ID người dùng nhằm cản trở việc các ứng dụng truy cập vào hệ thống hay truy cập vào các ứng dụng khác mà không được kiểm soát an toàn



    Đây là khác biệt lớn so với hạn chế của iOS là không cho phép chạy các ứng dụng từ bên thứ ba

    Một phần quan trọng của việc bảo mật trên Android là nó cho phép từng yếu tố UI riêng có thể chia sẻ màn hình một cách an toàn. Nó giải thích cho các cửa sổ trên Android. Thanh trạng thái và thông báo là một cửa sổ riêng, được vẽ bởi hệ thống. Phần này riêng biệt hẳn với cửa sổ ứng dụng, vì thế các ứng dụng không thể thay đổi bất cứ thứ gì trên thanh trạng thái, như là xóa hay thay đổi chữ SMS được hiển thị ở thanh trạng thái. Tương tự, phần bàn phím mềm là một cửa sổ riêng, quản lý bởi ứng dụng riêng, nó và phần ứng dụng chỉ có thể tương tác với nhau qua một giao diện xác định, và được kiểm soát. (Điều này lý giải tại sao Android có thể chạy an toàn các phần mềm hỗ trợ bàn phím từ bên thứ ba)



    Một mục tiêu khác của Android là cho phép phối hợp chặt chẽ giữa các ứng dụng, ví dụ, rất dễ để thực hiện việc chia sẻ API (Application Programming Interface) mà sử dụng một phần của ứng dụng khác tich hợp với ứng dụng ban đầu. Các ứng dụng Android truyền thống được chia thành các mảnh nhỏ (gọi là “các hoạt động”) để xử lý các phần cụ thể của các ứng dụng UI. Ví dụ danh bạ là một hoạt động, các chi tiết trong danh bạ là một hoạt động khác, thay đổi một số liên lạc lại là một hoạt động khác nữa. Di chuyển giữa các phần của UI danh bạ là sự di chuyển giữa các hoạt động, mỗi hoạt động là một cửa sổ riêng.



    Chúng ta có thể thấy một điều lý thú là trong hầu hết các phần của UI Android nguyên gốc mà bạn thấy chuyển động, cái mà bạn thực sự thấy là các cửa sổ chuyển động. Ấn vào một contact để xem thông tin chi tiết là một chuyển động của cửa sổ danh bạ và cửa sổ chi tiết contact. Hiển thị bàn phím mềm là chuyển động của cửa sổ bàn phím. Hiển thị tính năng chọn phần mềm chia sẻ là một chuyển động của cửa sổ hiển thị tính năng.



    Khi bạn nhìn thấy một cửa sổ trên màn hình, cái mà bạn thực sự nhìn thấy là “bề mặt”. Đây là một phần riêng của bộ nhớ chung mà các cửa sổ vẽ UI vào đó, và nó liên kết với các cửa sổ khác trên màn hình bằng một chức năng riêng của hệ thống (cái này là một thread riêng, có mức độ ưu tiên cao hơn), quá trình này gọi là “surface flinger” (tạm dịch là vẽ bề mặt). Nghe rất quen phải không? Thực ra quá trình này cũng giống như iOS, bề mặt được xây dựng bằng các thread riêng biệt, Android làm điều này kém mịn hơn nhưng ở một mức độ an toàn hơn nhiều. (Và việc xây dựng cửa sổ này được phần cứng tăng tốc ngay từ những bản Android đầu)



    Một tương tác khá thú vị trong UI là việc định hướng ngón tay, các thanh cuộn, các thao tác gạt ngang... Các cử động này liên quan đến việc cập nhật nội dung trong một cửa sổ, đòi hỏi việc dựng hình cửa sổ đó trong mỗi chuyển động. Tuy nhiên quá trình dựng hình từ thread chính không hề dễ dàng. Nó không đơn giản chỉ là “di chuyển phần này của UI từ chỗ X sang chỗ Y, và thông báo khi công việc hoàn tất”. Mỗi chuyển động được dựa trên các thao tác từ ngón tay trên màn hình, được xử lý bởi các ứng dụng trên thread chính của nó.



    Vì thế, việc tránh phải vẽ lại toàn bộ nội dung của các phần UI chuyển động sẽ giúp tăng tốc độ xử lý. Android đã làm được điều này từ bản 1.0; các thành phần của UI như xem danh sách cuộn có thể gọi thuật toán http://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) để có nội dung được dựng hình nhanh hơn.



    Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.

    (đoạn này người viết dùng các ngôn ngữ kỹ thuật khó, mình không hiểu hết nên không dịch, sợ gây hiểu sai cho người đọc)



    Ở bản Android 1.0 việc hiển thị được vẽ thành các kết cấu, và các kết cấu tạo thành cửa sổ ở một thread khác, cân nhắc kỹ thì việc này không mang lại nhiều lợi ích trong khi lại tiêu tốn khá nhiều tài nguyên. Chi phí tài nguyên kỹ thuật này đã được sử dụng tốt hơn vào các mục đích khác như hệ thống phân cấp bố trí việc hiển thị (để tạo ra sự linh hoạt tùy theo các kích cỡ màn hình khác nhau), hay việc theo dõi từ xa cho các thông báo và widget, điều này thực sự hữu dụng cho các bản Android phát triển sau.



    Thực tế là việc dựng hình được tăng tốc bởi phần cứng là không khả thi cho đến gần đây. Vì Android được thiết kế xung quanh việc vẽ nhiều cửa sổ trên màn hình. Để các cửa sổ vẽ ra được tăng tốc bởi phần cứng đòi hỏi GPU và driver hỗ trợ nhiều nội dung GL (graphic library) chạy cùng một lúc. Phần cứng cho di động trước đây không đủ hỗ trợ vấn đề này, thậm chí bỏ qua bộ nhớ bổ xung cần thiết cho việc này. Ngày nay thậm chí chúng ta cũng mới ở giai đoạn đầu của việc này, hầu hết các GPU di động vẫn còn tiêu tốn nhiều tài nguyên khi chuyển đổi GL



    Tôi hi vọng những giải thích bên trên phần nào giúp các bạn hiểu rõ hơn về cách thức hoạt động của Android. Và tôi cũng xin nhấn mạnh rằng tôi viết ra những điều này không nhằm giải thích cho những gì người ta không thích về Android; tôi chỉ cảm thấy mệt mỏi khi có những người đưa ra những giải thích sai lầm về phương thức hoạt động của Android, tệ hơn, họ còn tự nhận mình có đủ tư cách để nói về chủ đề này (ám chỉ anh chàng thực tập sinh tại Google)



    Tất nhiên còn có nhiều thứ cần được cải thiện ở Android, cũng như rất nhiều thứ đã được cải thiện kể từ bản Android đầu tiên. Khi có những vấn đề khác nảy sinh, cũng như khả năng của phần cứng được cải thiện, chúng tôi sẽ tiếp tục cố gắng làm cho Android tốt hơn, đưa nó tiếp tục tiến về phía trước



    (còn một đoạn ngắn tác giả nói về vần đề framerate khi cuộn thanh của iOS, nhưng tác giả cũng tự nhận mình không phải là chuyên gia iOS nên mình thấy không cần thiết phải dịch phần này)
    nếu bạn cảm thấy bài viết có ích, xin nhấn vào nút cảm ơn. Mọi góp ý chỉnh sửa, làm ơn nhắn tin riêng (PM) cho mình để giúp hoàn thiện bài viết.



    Ban có thể xem bài viết gốc tại link: https://plus.google.com/105051985738280261832/posts



    Nếu có điều kiện mong các mod đưa bài lên trang nhất tinhte để mọi người có cái nhìn đúng đắn nhất về hệ điều hành Android

  2. #2
    Ngày tham gia
    Jul 2014
    Bài viết
    0
    Cha nội thực tập này bị đuổi là cái chắc, mới chập chững mà bày đặt

  3. #3
    Trích dẫn Gửi bởi lebinh_hung
    Cha nội thực tập này bị đuổi là cái chắc, mới chập chững mà bày đặt
    Không nói thì sao biết được cái sai của mình =). Im lặng mới là đang chứng tỏ mình ngu đấy.

  4. #4
    Ngày tham gia
    Jun 2014
    Bài viết
    0
    Trích dẫn Gửi bởi lebinh_hung
    Cha nội thực tập này bị đuổi là cái chắc, mới chập chững mà bày đặt
    nướg ngoài chứ ko như Vietnam mình đâu bác [IMG]styles/default/xenforo/clear.png[/IMG]

  5. #5
    Ngày tham gia
    Jul 2014
    Bài viết
    0
    Haiz những người dũng cãm nói lên những điều sai trái đều sẽ bị khai trừ dù những điều họ nói là đúng đắng

  6. #6
    Đọc cũng ko giải thích tại sao Android kô mượt bằng IOS.

    Giải thích chuyên môn người tiêu dùng ko hiểu và cũng ko cần phải hiểu.

  7. #7
    Ngày tham gia
    Jun 2014
    Bài viết
    0
    Trích dẫn Gửi bởi maybach
    Đọc cũng ko giải thích tại sao Android kô mượt bằng IOS.

    Giải thích chuyên môn người tiêu dùng ko hiểu và cũng ko cần phải hiểu.
    Chuẩn không cần chỉnh.

    Chỉ cần cảm nhận mượt hay không mượt, thế thôi.

    Còn về vấn đề bảo mật thì hiện tại android đang kém nhất trong các HĐH.

    Thế mà còn bảo chậm hơn nhưng an toàn hơn.

    => Chẳng giải thích được điều gì.

  8. #8
    Ngày tham gia
    Jul 2014
    Bài viết
    0
    Trích dẫn Gửi bởi nayeula
    Chuẩn không cần chỉnh.

    Chỉ cần cảm nhận mượt hay không mượt, thế thôi.

    Còn về vấn đề bảo mật thì hiện tại android đang kém nhất trong các HĐH.

    Thế mà còn bảo chậm hơn nhưng an toàn hơn.

    => Chẳng giải thích được điều gì.
    nói bậy , android nhiều phần mềm độc ko có nghĩa là nó bảo mật kém . các phần mềm độc tràn lan trên android chủ yếu là do cơ chế lỏng lẻo của market và lợi dụng sơ hở về cấp phát quyền điều hành của những người kém hiểu biết thôi =).

  9. #9
    Ngày tham gia
    Jun 2014
    Bài viết
    0
    đọc mấy bài viết ntn nhức đầu ghê,vò đầu bứt tai suốt.

    chỉ có các dev mới hiểu tường tận.

    nói gì thì nói android vẫn là sự lựa chọn tốt nhất hiện nay.

  10. #10
    Ngày tham gia
    Jun 2014
    Bài viết
    0
    Không phải chuyên môn thì đố mà hiểu được.

    Có muốn biết cái nào chậm cái nào trễ thì phải đem ra test mới thấy được.

Quyền viết bài

  • Bạn Không thể gửi Chủ đề mới
  • Bạn Không thể Gửi trả lời
  • Bạn Không thể Gửi file đính kèm
  • Bạn Không thể Sửa bài viết của mình
  •