Tham dự Tech Lounge

Tham dự Tech Lounge


[Thảo luận] Tại sao Android tốn pin và hiệu suất không cao bằng HĐH khác

ashtxk
7/12/2012 20:31Phản hồi: 161
[Thảo luận] Tại sao Android tốn pin và hiệu suất không cao bằng HĐH khác
Tuy rằng nói ra thì có lẽ sẽ làm nản lòng một số chiến sĩ, nhưng chúng ta đôi lúc cũng nên tìm hiểu một chút về nền tảng mà mình đang sử dụng. Bên cạnh đó ôn lại một số kiến thức khi ngồi trong ghế trường học luôn.

Trước hết mình xin đính chính một thông tin sai lệch, đó là Android chạy chậm và kém mượt là do ứng dụng của nó phải chạy trên máy ảo (Virtual Machine) Davik, thực sự thì vấn đề hiệu năng không phải là do ứng dụng Android chạy thông qua VM hay không. Bản chất các ứng dụng của Android khi được chạy là mã nguồn bytecode được "tạm thời biên dịch" sang machine binary code trước khi thực thi.
Ai sử dụng Android thì cũng đều biết là nó sẽ mất 256MB Heap size RAM dành cho một thứ gọi là Dalvik Cache thứ mà không có trên tất cả các HĐH khác từ trước đến giờ, kể cả những HĐH sử dụng Java. Nó đóng vai trò như một vùng nhớ đệm, chứa phần mã máy đã được tạm thời biên dịch và thực thi nó như là các mã máy bình thường khác. Về nguyên tắc thì dù là chạy trên VM thì tốc độ của Android cũng không bị ảnh hưởng gì cả, có chăng là sẽ tốn thêm thời gian để nạp ứng dụng và biên dịch JIT, một khi anh ấy đã hoạt động rồi thì không có gì cản trở cả.
Quay lại vấn đề tại sao hiệu suất Android lại bị đánh giá thấp hơn iOS, WP hay BB10. Vấn đề nằm ở tư tưởng thiết kế HĐH.

Trước hết ta phải nói đến "hành vi" sử dụng smartphone không giống như sử dụng máy tính, trên smartphone anh không cần dùng "cửa sổ" này mà vẫn thấy cửa sổ khác, và anh không cần các cửa sổ phải cùng nhau hoạt động cùng một lúc. Bởi vì cửa sổ duy nhất mà anh cần đó là cái màn hình hiện tại. Vì vậy Apple mới đưa ra một kỹ thuật gọi là Pseudo Multitasking, nó hoạt động kiểu như thế này:

- Ứng dụng sẽ không được "keep running" khi mà anh chuyển đổi từ ứng dụng này sang ứng dụng khác, nói một cách khác nó sẽ bị tắt hoàn toàn. Nhưng trước khi nó được tắt, Apple cung cấp cho chúng ta một state, ở đó ta có thể lưu lại những dữ liệu cần dùng trong lần khởi động tới (những dữ liệu này sẽ được gọi là session), ứng dụng tắt hoàn toàn hệ thống không cần phải quản lý gì nữa, mọi thứ clean.


- Ở lần khởi động thứ 2, sau khi app started và trước khi "show hàng" apple lại cung cấp cho chúng ta một state, ở đấy đọc những dữ liệu đã được ghi trước đó, và phục hồi lại trạng thái ứng dụng trước khi tắt ở lần trước.

Về phía Android, ứng dụng sẽ được chạy theo một mô hinh lifecycle phức tạp hơn gồm nhiều trạng thái tương tự như iOS, nhưng có một điểm khác. Đó là ứng dụng Android vẫn "keep running" khi bạn thoát ra.


Lý giải cho việc ứng dụng được giữ tiếp tục chạy trong hệ thống, đội ngũ phát triển Android của Google nói rằng, như vậy khi nào cần thì mọi thứ đã có sẵn, ứng dụng không cần phải đợi nạp lại. Khi nào cần đến chỉ việc gọi thôi.
Tuy nhiên kéo theo đó là cả một hệ lụy

Trước hết mình nói thêm về 2 khái niệm cơ bản của HĐH để anh em tiện theo dõi:

- Memory paging hay còn gọi là "phân trang", thực tế viết đầy đủ là Memory allocation in paging systems, nhưng mình gọi tắt là MP quen rồi, đây là một tính năng của HĐH nhằm phân chia tài nguyên RAM của hệ thống, khi ta nạp 1 ứng dụng lên thì HĐH cần phải biết vị trí nào trong RAM còn trống, đủ kích thước nạp ứng dụng đó, và khi cần xử lý thì nó phải có một index chỉ đường đến vị trí nạp ứng dụng chứ nếu không làm sao mà biết đường lần trong hàng tỉ ô nhớ của hệ thống.

- System scheduling, gọi là "định thì" hệ thống, nó khá là quan trọng, bởi vì bản chất của CPU nó chỉ xử lý có một lệnh / 1 IPC thôi, trong khi có nhiều process cần được xử lý, vì vậy mới cần thằng "cảnh sát giao thông" này, nó là thằng quyết định xem process nào được vào gặp "sếp lớn", còn những thằng còn lại sẽ phải đứng chờ trong một "hàng đợi", còn đợi bao lâu thì tùy vào thuật toán định thì cụ thể. Ở cả Android lẫn iOS thì mặc định thuật toán định thì đều là dạng tuần tự theo lượt, vào trước ra trước FIFO. Tuy nhiên do tính mở Android có thể thay đổi được bằng các Kernel bên ngoài.

OK! Quay trở lại việc tại sao hiệu suất của Android lại kém thế, mình muốn nhấn mạnh là ở đây mình sẽ dùng từ hiệu suất chứ không phải hiệu năng nhé. Và vì sao Android lại tốn pin, và không mượt bằng iOS hay WP.

Quảng cáo



Có lẽ khi đọc về "phân trang" và "định thì" thì bạn cũng hiểu ra phần nào rồi, lý do đơn giản là việc phân phối tài nguyên của hệ thống. Ngoài ra số lượng process mà iOS phải xử lý sẽ ít hơn (vì khi chuyển ứng dụng thì process đã bị tắt cùng với ứng dụng trước đó rồi)

Với iOS toàn bộ tài nguyên của hệ thống có thể được huy động tối đa để phục vụ cho một ứng dụng, ngoài ra việc phân trang và định thì của hệ thống không phải là gánh nặng và vì thế nó có thể hoạt động trơn tru hơn Android mặc dù CPU có thể yêu hơn, RAM có thể ít hơn, và vì lý do đó nên tiêu thụ năng lượng cũng ít hơn dẫn đến thời lượng pin sẽ nhiều hơn.

Với Android, điều đáng buồn là một HĐH di động lại bị kỳ vọng quá mức vào khả năng xử lý multitasking, Google muốn biến nó trở thành một HĐH máy tính???
Sử dụng true multitasking đồng nghĩ với anh phải phân chia tài nguyên cho nhiều ứng dụng hơn, phân trang phức tạp hơn, định thì phức tạp hơn anh phải xử lý tranh chấp tài nguyên, ngăn ngừa deadlock... Tất cả những cái đó vô hình chung làm cho Android hiệu suất kém hơn, tốn tài nguyên hơn và tiêu thụ nhiều năng lượng hơn (do phải xử lý nhiều hơn ấy mà)

Việc so sánh giữa iOS với Android cũng giống như kiểu có 2 anh lực sĩ, anh iOS dùng cả 2 tay nâng 1 quả tạ 100kg, còn anh Android thì mỗi tay một quả 100kg, ngoài ra còn phải treo trên người một tá phụ kiện lỉnh kỉnh nữa.

Bởi vậy nên với các thiết bị Android, người ta mới dùng giải pháp là cung cấp thêm tài nguyên hệ thống, bằng cách nâng cấp thêm CPU, RAM, tăng thêm pin.
Điều đáng buồn là hiện tại trong tất cả các HĐH di động chỉ có một mình Android là xây dựng theo thiết kế true multitasking, còn lại cả WP, lẫn BB10 đều thiết kế theo mô hình tương tự như Apple có chỉnh sửa phù hợp với "triết lý" của họ.

Quảng cáo



Có một số bạn từng hỏi mình là nếu như thiết kế của Apple tốt thế thì Android giờ "cải lùi" thiết kế lại Android theo cách đó được không? Câu trả lời là có thể và cũng không thể. Việc nâng cấp từ một HĐH đơn nhiệm hoặc giả đa nhiệm lên đa nhiệm dễ hơn là làm ngược lại, bởi vì nâng cấp thì chỉ cần chèn thêm các states mới vào mô hình chạy ứng dụng thôi, các ứng dụng vẫn có thể chạy bình thường. Còn làm ngược lại thì các ứng dụng cũ có các state mà đơn nhiệm không có sẽ... mất bới tính năng, mất công phát triển lại lắm, cũng giống như các apps chạy qua VM giả lập trên BB10 có nhiều cái không đầy đủ tính năng như chạy trên Android.

Android hiện tại thì vẫn đang phát triển, và bên cạnh đó chính những yếu điểm của nó cũng có lợi ích làm kéo theo cuộc đua phần cứng. Tạm không nói đến vấn đề tư tưởng thiết kế của iOS tốt hơn hay Android tốt hơn. Nhưng có một điều rõ ràng ta phải công nhận, Android là một cuộc cánh mạng, vì nó cho chúng ta có thêm lựa chọn và nhờ đó thúc đẩy thế giới sang một thời kỳ mới, kỷ nguyên của smartphone và điện toán di động.

Ta không thể nào trông chờ vào một cái gì đó hoàn hảo, vì điều hoàn hảo vốn không tồn tại trên thế giới này, mọi thứ đều có điểm tốt và điểm xấu của, điều chúng ta phải làm là học cách chấp nhận. Có thể một ngày nào đó Android sẽ tàn lụi, sau khi làm tốt nhiệm vụ của nó, và sau đó có thể Google sẽ lại tung ra một người kế nhiệm của nó "The Android reborn as beginner"

Bài viết có tham khảo một số thông tin từ:
http://developer.android.com
http://developer.apple.com
http://www.xda-developers.com

XDA | The future is computing

The world’s best source for computing news, reviews, editorials guides, and more.
xda-developers.com


Một món quà dành cho những người đã bỏ thời gian đọc bài viết của mình 😃
161 bình luận
Chia sẻ

Xu hướng

domxam123
ĐẠI BÀNG
11 năm
Óa máy gì mà bá đạo vậy. cpu 2Ghz, ram 256Mb
@domxam123 Hitech thì phải, nhớ không nhầm, 2GHz, 256 Mb ram, lại không có 3G!
Bài viết của chủ thớt quá hay ,diễn đàn mình cần thêm những bài viết chuyên sâu thế này 😃.
ronxatac
ĐẠI BÀNG
11 năm
Sau khi đọc và ngẫm nghĩ xong, xem clip mấy em xinh xinh nhảy nhót của bác thấy thư giãn hẳn (giống như đi học mà được ra chơi vậy)!:p
baby1982
ĐẠI BÀNG
11 năm
Bổ sung: thời lượng sử dụng pin sẽ lâu hơn.

Bài viết good.

Đọc đến đây cứ ngỡ theard copy/paste ấy chứ :]
Android được cái backup app dễ .hình như app của các hdh khác họ giải nén file cài ra các nơi còn android thì chỉ chuyển file .apk vào data/app lấy thêm chút thông tin app nữa

Sent from my GT-I9100 using Tinhte.vn
Mình thấy việc thoát ứng dụng mà vẫn chạy ngầm nhiều khi rất khổ vì chạy ngầm làm tốn Ram khủng khiếp.mình thích cái trực quan hơn là việc mượt mà của hệ điều hành.Ước gì android nghĩ lại làm giống với windowphone 7,8; IOS thì android bá đạo,không có đối thủ
@chomaimotnguoi_hd Lúc đấy lại không có tên là Androi nữa, mà là iordna
Bài viết tốt. Có vài ý kiến với bạn chủ topic:

- Vài thuật ngữ bạn dùng theo mình là hơi tối nghĩa hay ít nhất là khó hiểu ví dụ như "định thì" - 1 khái niệm căn bản trong bài viết của bạn và đc đề cập nhiều lần.

- Bạn làm rõ thêm dùm mình: nếu iOS và các OS tương tự stop + lưu trạng thái của ứng dụng ko đc sử dụng trên cửa sổ chính thì những ứng dụng kiểu music, facebook hay email sẽ hoạt động kiểu gì để đảm bảo tính liên tục trong việc cập nhật. Hay là đã có sự cải biên nào đó trong kiểu multitasking khác đi so với bài phân tích của bạn?

Sent from AndroidVietnam
@Zanr Zij - Đa số các tài liệu về HĐH ở VN đều dịch thuật ngữ scheduling là "định thì" hoặc "định thời', thuật ngữ này thực tế cũng không xa lạ với những người học hoặc làm việc bên chuyên ngành khoa học máy tính.
- Một ứng dụng thì thường sẽ chứa bên trong nó 2 dạng tiến trình (process), loại thứ nhất khi chạy bạn có thể thấy được, đó là foreground process (Android gọi là Activity), thứ 2 là là loại tiến trình chạy ngầm trong hệ thống gọi là background process (Android gọi là Service). Tuy nhiên, có một điểm khác biệt trong thiết kế của 2 HĐH, với iOS ứng dụng chạy ngầm không phải là một tiến trình (what the heck???), bạn coi lại hình này:


Đây là một ứng dụng iOS, nó có 2 trạng thái là Foreground và Background, và trước khi ứng dụng suspend thì nó sẽ vào trạng thái background trước. Mọi chuyện sẽ xảy ra như thế này, nếu như ứng dụng của bạn được chuyển vào background state, và trong đó bạn đăng ký một tác vụ, ví dụ sau 15 thì lấy email rồi notify, hệ thống sẽ bắt đầu đếm ngược, background state vẫn chưa kết thúc, ứng dụng của bạn vẫn sẽ tồn tại. Sau 15ph, tác vụ của bạn sẽ được thực hiện, và bạn lại đăng ký lại tác vụ đó 15ph tiếp theo. Vòng lặp sẽ được thực hiện liên tục, như vậy bạn sẽ giải quyết được bài toán đảm bảo tính liên tục trong cập nhật dữ liệu. Như vậy, với iOS ứng dụng chạy ngầm thực chất chỉ là một tác vụ được đăng ký lặp tuần tự theo thời gian.

Với Android, do thiết kế true multitasking, nên Service của Android được thiết kế tách riêng thành một tiến trình (process) hoàn chỉnh, nhưng mình tạm gọi là ứng dụng cho mọi người dễ hình dung về sự khác biệt so với iOS) chứ không phải chỉ là một tác vụ giống như iOS, và nó cũng có nhiều trạng thái trong quá trình vận hành.

Chi tiết cách hoạt động thì không cần nói nữa, quá rõ ràng rồi. Tuy nhiên thiết kế Service của Android có ưu điểm là có thể chạy độc lập không cần đến các Activity. Các service này có thể là một ứng dụng độc lập.

Chính do sự khác biệt trong vấn đề thiết kế nên trong vận hành của 2 hệ điều hành sẽ có sự khác biệt trong quản lý ứng dụng như sau:

iOS: chỉ phải quản lý một ứng dụng hiện thời, và các ứng dụng cần thiết chạy ở background, các ứng dụng không có yêu cầu thực thi background sẽ bị suspend hoàn toàn khi thoát khỏi.
Android: Phải quản lý nhiều Activity cùng lúc, ngoài ra còn phải quản lý thêm các Service.

Và một ứng dụng khi xây dựng ở iOS khi so với Android cũng có sự khác biệt, mình lấy ví dụ làm một ứng dụng check mail, ở iOS bạn chỉ cần một giao diện, 1 process để chạy, get dữ liệu và thông báo. Trong khi đó Android sẽ phải xây dựng thành 2 process, thứ nhất là Activity để get, hiển thị nội dung email khi ứng dụng hoạt động, thứ 2 là service để get dữ liệu và thông báo khi ứng dụng chạy nền.
ashtxk :

- Thuật ngữ: ( ZZ quen nói thẳng ) thực sự thì thuật ngữ đó đã cũ và lỗi thời. Các thầy vốn là người bị tác động bởi chữ Hán và thường cố gắng dịch theo kiểu như vậy. Thuật ngữ Schedule/Scheduling nên dịch là "lịch trình" hoặc có thể tìm 1 từ sáng nghĩa hơn 😁

- ZZ thấy rằng có những thứ không hoàn toàn như bạn đã viết/phân tích. Bạn lý giải sao về các app kiểu như Facebook. Dù ta đặt cho nó 1 lịch trình lấy thông tin là 15p thì nó vẫn sẽ lấy sớm hơn hoặc muộn hơn. Sự phức hợp ở đây thể hiện trong sự pha trộn - kết hợp giữa Facebook App và Facebook Messenger. Nếu mọi thứ cứ theo lịch trình như thế, đặc biệt là với các app iOS thì thật khó để đảm bảo tính cập nhật tức thời kiểu Pushmail như trên BB OS. Câu chuyện trình duyệt cũng sẽ phần nào tương tự như vậy.

- Chúng ta đang bàn đến vấn đề tốn pin, đến độ mượt của Android và đến hiệu suất của nó. Bạn có thể lý giải về việc : vì sao hiện nay, dù cấu hình 1 smartphone Android có cao cỡ nào đi nữa thì trong rất nhiều tác vụ liện quan đến cuộn trang, chuyển đổi cửa sổ thì Android vẫn thi thoảng gặp hiện tượng lag hay có thể nói là không có độ mượt tốt như iOS.

ashtxk : ZZ edit thêm. Các thứ mà bạn lý giải ở bài viết này chỉ nói lên rằng do Android phải xử lý câu chuyện multitasking nên abc xyz nhưng cái việc cuộn trang kia dường như không liên quan đến multitasking đó 😃
Zanr Zij: Những thứ mình lý giải ở đây là bàn đến vấn đề hiệu suất và điện năng tiêu thụ, tức là việc so sánh tốc độ ứng dụng của Android so với các nền tảng khác như iOS hoặc WP. Còn việc tại sao Android lại kém mượt hơn so với iOS thì không liên quan đến multitasking.

Việc Android cuộn kém mượt hơn mình nghĩ là do bộ phận render chưa được tốt, thực ra thì mình nghĩ như sau:

Thông thường thì để biểu diễn một chuyển động trên màn ảnh trong điều kiện lý tưởng, người ta sẽ cho chiếu lần lượt 24 khung hình/s, mắt người sẽ cảm giác là chuyển động liên tục. Nhưng giờ giả sử vì một lý do nào đó, trong 24 khung hình đó mà có 3 khung hình giống nhau, khi chiếu lên thì sẽ bị hiện tượng khựng hình rồi nhảy.

Bởi vì trong kỹ thuật không ai dám chắc là sẽ render 24 khung hình đó một cách chính xác được nên mới có việc người ta đẩy nó lên 30,60,120 khung hình/s. Nhằm mục đích là giảm độ sai lệch trong quá trình dựng ảnh.

Với Android thì cơ chế render chưa được tốt, dẫn đến khi dựng hình bị trễ và sai lệch khá nhiều nên Android mới kém mượt hơn iOS. Google đã giải quyết bằng cách tăng số khung hình lên 60FPS và bổ sung triple buffering. Yếu tố cuối cùng là tâm lý của bạn lúc cuộn trang thôi ;)

Quay trở lại việc cập nhật dữ liệu, để cập nhật tức thời thì ta có nhiều cách, ta có thể giảm timeout trong lúc đặt lịch, đặt lịch dựa theo hành vi, dùng socket thay cho middleware để cung cấp dữ liệu, nói chung đây là công việc của lập trình viên, và tùy mỗi nền tảng anh ta phải tìm giải pháp phù hợp với mình.
ZZ ko hoàn toàn cho rằng do vấn đề render 😃. Render giúp lấp đầy thêm các khung hình liên tiếp. Nhưng ở đây ngoài chuyện giật do thiếu khung hình ra thì nó còn bị hiện tượng "khựng".

Về vấn đề multitasking cũng vậy. Theo đánh giá của mình nó còn liên quan đến 1 yếu tố trong cái gọi là System Scheduling/ lịch trình hệ thống đó. Khả năng xử lý liên tiếp tốt, xử lý ưu tiên cái nào tốt căn cứ vào hành vi sử dụng của người dùng, cung cấp cho lập trình viên 1 công cụ vận dụng cái đó sẽ tạo ra 1 ứng dụng có độ mượt tốt hơn.
Bị khựng có thể là do deadlock.
@ashtxk Mình ko trong nghành ko dám ho he.
Nhưng android có những lần khựng (rất nhẹ) đúng vào lúc nhảy nấc performance của gpu.

Gửi từ Galaxy S3/Tapatalk
@ashtxk Cho mình hỏi:
1
IOS thì app ko đc keep running, tạo 1 state, rồi khi cần lại nó có 1 session.
Android vẫn keep running app.
Vậy Android làm thế để có lợi ích ntn khi việc đấy tốn tài nguyên và năng lượng quá nhiều?
2
Khi load 1 fb chẳng hạn, khi vào IOS thì fb load cái mới nhất. Android cũng load cái mới nhất, nhưng fb android chạy ngầm vẫn load chậm hơn IOS not keep running?
3
Lợi ích của việc để ứng dụng chạy ngầm là gì? Tong khi IOS vẫn lưu 1 state, khi cần vẫn có đữ liệu Session mà ko cần load lại!
4 Sao android quản lý ứng dụng hơi kém. 1 App down về xài ok, nhưng vài lần kế, bấm vào lại báo lỗi ko vào đc dù đó là App offline!
@mymymoamoa 1)Bạn hoàn toàn hiểu sai. Android app có thể keep running in background, chứ ko phải lúc nào cũng running in background. Ví dụ bạn muốn download 1 file mất thời gian lâu, hay làm 1 phép xử lý ảnh, âm thanh gì đó mất thời gian, bạn có thể muốn tạm thời chuyển qua 1 app khác để làm việc khác, ví dụ như duyệt web, trong khi đó tác vụ bạn cần thực hiện vẫn được chạy trong background, với Android thì việc này rất dễ dàng. Còn với iOS thì cũng có thể được, nhưng khó khăn hơn.
2) Facebook của Android ko chạy ngầm, trừ khi bạn thực hiện upload ảnh chẳng hạn...
3) Xem lại điều 1.
4) Vì Google Play thoải mái hơn trong việc xét phần mềm. Thường developer up lên 1 ngày là đã được approve còn Apple thì khó tính hơn, thường là hơn 2 tuần. Trong trường hợp này thì mình thấy GOogle có lý hơn. Người quyết định phần mềm có chất lượng hay ko là người sử dụng, chứ ko phải là Apple hay Google. Nếu phầm mềm ko đủ chất lượng, người sử dụng sẽ tự quay lưng với phầm mềm đó. Có nhiều tính năng người sử dụng muốn dùng, nhưng lại ko có được trừ khi dùng Cydia chính là do bị Apple từ chối. Dĩ nhiên cách của Google có hậu quả là khách hàng có thể mua trúng phầm mềm dỏm, nên Google đã cho phép người dùng có 15 phút có thể yêu cầu refund. NGược lại bên iOS nếu bạn mua trúng 1 app ko đúng ý bạn thì bạn cũng đành chịu.
Còn nếu phầm mềm của bạn là download từ nguồn ko phải Playstore thì dĩ nhiên bạn ko thể phàn nàn gì rồi
@ronaldo5285 Thank bạn nhiều. Cái này phước tạp quá. Xài Chrome khi cuộn thấy giựt giựt, còn khi xài trình duyệt mặc định lai ko. Với FB cũng thế, nó cứ giựt giựt dù cho mạng load nhanh
nozz12345
ĐẠI BÀNG
11 năm
@ronaldo5285 Có mấy app android cực kì mất dạy, down về mà xài là nó auto gửi tin nhắn trừ tiền. Mình biết nên chả bao giờ bị, tự nhiên thằng cháu mượn đt down về sex siếc gì ấy xong mất hơn 100k. Mình trả sau mới chết chứ 😕
Dannyboy
TÍCH CỰC
11 năm
Việc xử lí cuộn trang , pinch to zoom, ... trước khi có ICS ,và cả Honeycomb 3.1 hầu như đều do CPU xử lí . Nói kiểu khác là trước 4.0 thì GPU trên SOC sử dụng cho Android là hầu như vô dụng , có rất ít tác vụ mà CPU đẩy sang cho GPU xử lí. Dễ thấy nhất là Gingerbread thì RAM free phải nói là cực nhiều , nếu RAM 1GB thì lượng ram sử dụng được có thể lên đến khoảng 800Mb cơ, nhưng lên ICS và Jelly Bean thì lượng Ram sử dụng được chỉ còn khoảng 600Mb thôi , vì RAM được share nhiều hơn cho GPU.

Một điều nữa là cái pinch to zoom và scrolling của IOS trông có vẻ nhanh hơn Jelly Bean ( dù cả 2 đều ở 60 FPS ) là do Apple đã dùng mẹo là Blur + Accelerate Scrolling thôi, Android không có nên với delay khoảng 100ms của các loại touchsensor hiện nay thì không có cửa nào để Android trông nhạy hơn IOS được
ngoanrazo
TÍCH CỰC
11 năm
Cái này mih nhớ các kỹ sư của google có nói rồi là do cơ chế delay của android, khi chạy 1 ứng dụng và ứng dụng đó đang xử lý,khi ta chọt vào màn hình thì tác vụ đó vẫn chạy chứ ko delay. Còn trên ios thì tác vụ đang xử lý sẻ delay nhường tài nguyên cpu cho thao tác chạm của ngón tay trên màn hình nên ios mượt hơn là vậy đó
@ngoanrazo Chuẩn, nhưng lên 4.1 thì có thay đổi rồi. Cache dành cho touch scrên nhiều hơn và mượt hơn.

Send from my Galaxy Note using tinhte.vn
Đọc bài này xong đau hết cả đầu, nhưng mà hay :
boss14420
ĐẠI BÀNG
11 năm
cho dù các JIT hiện nay có cải tiến đến mức nào đi nữa thì cũng không thể so sánh với native code (C/C++/Obj-C) được. Cũng giống như chương trình bằng các ngôn ngữ trên không thể bằng được các chương trình viết bằng ASM (nói chung)
Nguyên lý chung là càng can thiệp được ở mức thấp thì càng có cơ hội tối ưu hoá chương trình.
oasiss
ĐẠI BÀNG
11 năm
một bài viết hay, các bác vào tranh luận tiếp đi để mọi người có thêm nhiều thông tin😃
kutamitsu
TÍCH CỰC
11 năm
hiện tại thì JB đã làm rất tốt vụ pin và mượt rồi. Tôi hài lòng ở việc đa nhiệm, dễ sử dụng (sử dụng cứ như pc) của Android là chính thôi.
@kutamitsu Với góc nhìn của mình thì JB đã làm tốt hơn nhưng chưa phải là "rất tốt". Còn có thể và sẽ cải thiển kha khá thêm nữa về pin và độ mượt.

Xu hướng

Bài mới









  • Chịu trách nhiệm nội dung: Trần Mạnh Hiệp
  • © 2024 Công ty Cổ phần MXH Tinh Tế
  • Địa chỉ: Số 70 Bà Huyện Thanh Quan, P. Võ Thị Sáu, Quận 3, TPHCM
  • Số điện thoại: 02822460095
  • MST: 0313255119
  • Giấy phép thiết lập MXH số 11/GP-BTTTT, Ký ngày: 08/01/2019