[Thủ Thuật] Tinh chỉnh VM Heap trong Build.prop cho L3

.Mình muốn đưa đến cho các bạn một khái niệm nằm trong build.prop của ROM của mọi phiên bản Android. Đó là dalvik cache heap size. Các bạn có thể tìm thấy dòng thông số này vỏn vẹn và gỏn gọn đúng 1 dòng trong build.prop, nhưng tác dụng và ảnh hưởng của nó đến quá trình vận hành của máy rất lớn và cũng rất thú vị để tìm hiểu sâu về nó.




Vị trí dòng mã trong build.prop:

dalvik.vm.heapsize=xxxm (với xxx là giá trị được set, m là viết tắt của mb - megabyte)




Mục lục nội dung:

A) Cách tinh chỉnh.

B) Các khái niệm cần biết đến trước khi tìm hiểu về dalvikcache heapsize.

C) Quy trình bằng hình ảnh.




A) Cách tinh chỉnh:

- Máy đã được ROOT

- Vào RootExplorer\system\ tìm đến file build.prop, chuyển chế độ từ R/W sang R/O ở góc trên bên phải. Nhấn giữ lên file build.prop và chọn Open in Text Editor.

- Kéo xuống đến dòng lệnh như trên và bắt đầu thiết lập thông số.

- Sau khi set thông số xong ấn nút Back, chọn Save, file build.prop đã được chỉnh sửa và ngoài ra có một filebuild.prop.bak được sinh ra với vai trò là back up những thông số trước khi thay đổi. Trong trường hợp thay đổi thông số không đạt được kết quả như ý muốn, các bạn chỉ cần xóa bỏ file build.prop, rồi đổi tên file build.prop.bak thành lạibuild.prop là xong. Khởi động lại máy mọi thứ lại như trước.

- Sau mỗi lần chỉnh thông số hoặc thay đổi hay add thêm các đoạn mã vào build.prop yêu cầu cần reboot lại máy để thấy tác dụng.




B) Các khái niệm cần biết đến trước khi tìm hiểu về dalvikcache heapsize




1) Garbage collection (GC): đây là một thuật ngữ của một thuật toán phát triển cho máy tính và được sáng tạo ra vào năm 1959 bỏi JohnMcCarthy. Garbage Collection có nghĩa là "thu gom rác".




Để truyền đạt một cách dễ hiểu như thế này (cũng là dựa trên ý hiểu của chính bản thân mình). GC hoạt động theo một phương thức gọi là cycle (chu kỳ, tuần tự nối tiếp nhau). Chu kỳ này được bắt đầu khi hệ thống nhận thấy rằng cần rà soát lại bộ nhớ, thường thấy khi hệ thống ở tình trạng thiếu hụt bộ nhớ.




Bước đầu nó sẽ tiến hành quét một loạt theo kiểu hình cây, từ một nhánh rồi tỏa ra các nhánh khác, đánh dấu lần lượt từng điểm trên các nhánh. Mỗi điểm trên các nhánh (nói dễ hiểu là các quả); các quả này sẽ được cắm một cái gọi là cờ (cho biết rằng quả này đang có sâu, quả thì phải có sâu chứ), và việc rà soát nhánh tỏa ra nhánh này sẽ diễn ra cho đến khi toàn bộ hệ thống được lướt qua. Những quả nào có sâu sẽ cho GC thấy rằng các quả đang được sử dụng bởi một chương trình nào đó, những quả nào mà không cắm được cờ (không có sâu ở trong) đồng nghĩa với việc những quả này chưa có chủ (không có con sâu nào làm chủ) hoặc đã từng có chủ nhưng hiện thời không có (sâu chán bò sang quả khác). Đây sẽ chính là những quả mà GC sẽ thu lượm lại và trực tiếp mang đến cho những con sâu đang đói (những chương trình đang thiếu bộ nhớ để chạy).




Đấy gọi là quá trình thu gom rác. Những quả đã có sâu trong đợt kiểm tra này sẽ được đưa vào danh mục sẵn sàng để check trong " next cycle" - chu kỳ sau (kiểm tra lúc đó còn sâu hay không, hết rồi thì tiếp tục được GC gom lại và giao cho sâu khác đang đói).




2) Dalvik Cache: các bạn hãy hiểu đơn giản Dalvik cache là bộ đệm của các ứng dụng đang hoạt động của máy. Chính xác thì thao tác của nó là hỗ trợ "read:application" nhưng thật tình để trình bày ý hiểu thì khó lắm. Các bạn cố gắng đọc phần giải thích dưới này của mình nhé:




Dalvik cache là khu vực bộ nhớ ẩn (đệm) của một chương trình gọi là Dalvik. Dalvik là một hệ thống ảo viết trên nền tảng JAVA có chức năng làm cơ sở để chạy các ứng dụng của người dùng (những ứng dụng đuôi apk trong HĐH Android của chúng ta). Với nhiệm vụ giúp cho thao tác tiếp cận và kích hoạt ứng dụng nhanh hơn (vì theo mặc định HĐH Android không có trình biên dịch thời gian thực "JIT - Just in time complier" ); thì Dalvik cache là kết quả của hệ thống Dalvik thực hiện tối ưu hóa các chương trình đang chạy.




Loằng ngoằng và hơi khó hiểu đúng không? Mong các bạn thông cảm vì mình văn hơi kém.




Đây cũng là lý do chúng ta luôn được khuyên là nên WIPE Dalvik cache trước khi up ROM do phần cache để chạy các ứng dụng của ROM cũ nếu không được tẩy (wipe) sạch sẽ thì việc up ROM mới sẽ khiến chồng chéo dữ liệu bộ đệm của ROM cũ và mới gây ra những xung đột nhỏ có lớn có, khiến việc up ROM mới không được hoàn hảo.




3) Heapsize: nói nôm na nó là một khoảng bộ nhớ được hệ thống cắt ra ngay từ đầu. Giống như nhà bếp (chúng ta) chia phần ăn vậy. Bạn đưa cho công nhân (các chương trình) một đĩa cơm 48m (48megabyte, cứ coi như là 48.000VND ấy); có người ăn yếu người ăn khỏe. Người ăn yếu chỉ ăn hết 12m, 15m, 26m, 35m,... nhưng người ăn khỏe nhiều khi ăn hết 48m rồi mà vẫn không đủ, họ phải ăn thêm thì mới hoạt động được. Nhưng suất ăn chỉ có thế, kiếm đâu ra thêm??? Câu trả lời sẽ là sự tổng hợp của một loạt 3 mục khái niệm này. Tất cả được gói gọn trong 1 dòng mã:




Dalvik.vm.heapsize=xxxm

(chữ vm ở đây là viết tắt của "virtual machine" - hệ thống ảo nhé)




Các bạn đã hiểu Dalvikcache, hiểu Heapsize, biết đến quy trình Garbage Collection; chắc các bạn cũng đã đoán được phân nữa ý nghĩa của đoạn mã này. Mình sẽ tóm lại cho các bạn:




Việc set thông số của đoạn mã này giúp ích gì cho các bạn? Theo như lời khuyên của rất nhiều người (mà không biết họ lấy cơ sở ở đâu, vì theo bản thân mình thấy tùy ROM, tùy app mà mỗi người sử dụng thì không có bất cứ nguyên mẫu nào cho việc set thông số này chuẩn mực cả); họ cho rằng việc set giá trị 48m là tốt nhất. Mình đồng ý, đây là giá trị ổn định. Nhưng liệu nó đã tối ưu và thỏa mãn nhu cầu của tất cả mọi người???




Câu trả lời nằm ở chính các bạn, cách các bạn sử dụng máy; số lượng app cài vào máy; app khủng như game, mạng xã hội, chỉnh sửa ảnh, hay những app nhẹ nhàng phục vụ nhu cầu bình thường; launcher bạn dùng là loại nào; ROM bạn dùng tối ưu hóa nhất ở điểm nào,...




Việc chỉnh thông số ở đây, chúng ta hãy lấy cái mốc là 48m. Bạn có thể tăng hoặc giảm thông số này với sai số từng 8đơn vị một. VD: 24, 32, 40, 48, 56, 64, 72, 80,... Đơn vị 8 là đơn vị cơ bản của các hệ thống bộ nhớ, mình khuyên dùng vì sẽ ổn định và cho các bạn các mốc vừa phải để đánh giá.


Với những giá trị lớn thì lợi ích gì các bạn có được?

- Việc các app khủng như game, facebook, chỉnh sửa ảnh, launcher khủng... sẽ được cấp một suất ăn lớn (dung lượng lớn), việc khởi động và duy trì quá trình hoạt động sẽ rất tốt và trong quá trình sử dụng cũng sẽ mượt mà, truy xuất nhanh hơn. Sau khi dùng hết suất ăn rồi quá trình GC mới được bắt đầu do hệ thống nhận thấy rằng bộ nhớ cần phải có thêm. Chính việc quá trình GC này chậm được tiến hành và vòng lặp của nó được tiến hành ít (vì ngoài việc GC đi thu nhặt các bộ nhớ trống rơi rớt thì tự các app đang chạy cũng nhả bớt dần bộ nhớ ra, và với việc bộ nhớ được cấp ban đầu lớn, việc nhả dần này cũng sẽ tạo ra một lượng bộ nhớ sẵn có lớn nên GC không cần phải liên tục lặp lại chu kỳ góp nhặt). Lợi ích tiếp theo ở đây là pin sẽ được tiết kiệm hơn vì vòng lặp của GC không nhiều (mỗi lần GC chạy vòng lặp sẽ rà soát toàn bộ hệ thống nên tốn khá nhiều năng lượng, giống như người đi quyên góp mỗi lần phải chạy một lượt phố vậy).




Nghe có vẻ hay và tuyệt đấy nhưng bên cạnh đó có hại gì không? Câu trả lời là CÓ?

- Việc cấp một suất ăn lớn dẫn đến cái gì? Một cantin chỉ có khối lượng cơm có hạn. Bạn chia toàn những suất to không quan tâm là người ta ăn nhiều hay ăn ít, thế nên chắc chắn có trường hợp người ăn một thìa thôi nhưng được vứt cho cả bát ô tô còn người khác ăn nhiều cũng chỉ được vậy, và còn một hàng dài đứng chờ nữa nhưng hứa hẹn là chả có tý cơm nào sót lại mà chia ra. Nói theo thực tế cầm máy trên tay sử dụng, nếu bạn là người có thói quen chạy 1 chương trình nặng như game khủng hay facebook thì bạn nên để giá trị lớn. Còn nếu bạn vừa nhắn tin, vừa nghe nhạc, vừa xem album ảnh, lâu lâu lại vào mạng, rồi chạy ngầm vài ứng dụng nho nhỏ khác thì việc set giá trị này lớn là một sự hoang phí và gây mất ổn định cho hệ thống.




Vậy với các giá trị nhỏ thì lợi ích gì bạn có được?

- Bạn là người thích đa tác vụ. Cùng một lúc làm nhiều việc với chiếc máy của mình. Liên tục đổi qua đổi lại giữa các app thì lựa chọn set một giá trị nhỏ sẽ tốt hơn cho các bạn. Đưa một suất ăn vừa phải cho người ăn ít sẽ đỡ hoang phí hơn và những người xung quanh thì vẫn có phần. GC cũng không hẳn lúc nào cũng chạy cycle vì cơ chế của nó là khi nào người ăn kêu thiếu nó mới chạy. Đưa ra một thông số thấp hợp lý sẽ không bao giờ bạn phải bận tâm đến việc GC có phải chạy nhiều hay không, thậm chí nó chả cần phải chạy là mấy.




Nhưng giá trị nhỏ bắt bạn trả giá điều gì?

- Đơn giản là miễn chạy các ứng dụng khủng. Game 3D ah, Facebook ah, xem phim ah. Bạn vào và chưa kịp hiểu đầu đuôi ra sao sẽ bị đá văng ra ngay. Lịch sự thì nó cho bạn cái bảng Force close vào mặt. Còn không thì bạn sẽ lại lên diễn đàn gào khóc "Ối giời ơi, sao vợ của em nó ứ cho em làm cái này cái kia, abcxyz". Để bắt một người ăn như trâu ăn có một thìa cơm rồi bảo họ đi cày cả quãng đồng thì không ai chịu đâu, nước mình qua thời bao cấp rồi mà. Chỉ còn cách bạn set lại phần cơm cho người ta thôi nhé.




TÓM LẠI: Đọc đến đây ít nhất bạn có thể tự vỗ ngực tự hào là mình kiên trì hơn người và hiểu biết hơn người khác thêm được tý xíu rồi. Chân thành cám ơn các bạn đã bỏ công và thời gian theo dõi đến tận đây. Bài viết này của mình là do chính mình bỏ công sức tâm huyết tìm hiểu để viết nên. Mong nó sẽ có ích cho mọi người dù là để các bạn áp dụng hay là để đọc cho biết.




KINH NGHIỆM: set là 64m, chạy ổn. Những game lag ko còn lag lém, pin thấy dồi dào hơn chút đỉnh.

Còn với những bạn không có nhu cầu game hay phim ảnh nhiều, thích những thứ nhẹ nhàng và mượt mà, hý hoáy cái này tý cái kia tẹo thì có thể set xuống tầm 32m hoặc 40m. 32m mình đảm bảo vẫn chạy ổn định.

Ngoài ra,  bạn có thể tinh chỉnh thêm 2 dòng phụ nữa:

dalvik.vm.heapstartsize=yyym (cái này sẽ set lượng bộ nhớ được cấp ngay lập tức để làm bàn đạp cho ứng dụng khi bắt đầu được kích hoạt, giống như bàn đạp xuất phát của vận động viên nước rút vậy, ngay sau đó nó sẽ được cung cấp mức heapsize đã được set theo giá trị xxx).




dalvik.vm.heapgrowthlimit=zzzm (cái này sẽ cung cấp thêm 1 lượng bộ nhớ nữa cho ứng dụng khi ứng dụng khủng đòi hỏi vượt quá lượng bộ nhớ set mặc định xxx ban đầu; song song lúc này quá trình GC cũng đã bắt đầu chạy chu kỳ để thu hoạch thêm bộ nhớ rơi vãi cung cấp tiếp cho ứng dụng)




Cách set 2 giá trị này thường như sau:

startsize=1/2 growthlimit= 1/4 heapsize (VD: startsize là 16m, growthlimit là 32m, heapsize là 64m)

hoặc:

startsize=1/4 growthlimit=1/4 heapsize (VD: startsize là 16m, growthlimit là 64m, heapsize là 64m)










TUY NHIÊN, cảnh báo với các bạn có ý định thử với tầm từ 24m trở xuống nên backup lại ROM vì nếu các bạn để quá thấp thì khi reboot lại sẽ không đủ heapsize để chạy boot đâu đấy, lúc đó phải up lại ROM thì đừng kêu mình không nói trước nhá. Mình không chắc nhưng ai muốn thử lửa thì nên back up lại trước.




Chúc các bạn thành công!!!

C) Quy trình bằng hình ảnh:

1) vào rootexplorer\system\ đổi chế độ từ R/W sang R/O, tìm xuống file build.prop





2) Giữ vào build.prop, một bảng thông báo hiện ra, kéo xuống chọn Open in Text Editor







3) Tìm đến dòng dalvik.vm.heapsize=xxxm ; thay thế xxx bằng một giá trị bạn muốn (đừng vượt quá 100mb và đừng nhỏ hơn 32m, sẽ gây ra tình trạng máy hoạt động không ổn định). Ngoài ra có thể thêm 2 dòng về startsize vàgrowthlimit nếu muốn.






4) Sau khi set xong, ấn nút Back (nút cứng dưới màn hình), rồi chọn Yes để lưu những thay đổi.







5) Thoát ra ngoài bạn sẽ thấy một file build.prop.bak xuất hiện và một thông báo nhỏ xuất hiện nhanh dưới màn hình "All change have been saved" (đại khái thế). Như vậy là việc thay đổi đã hoàn thành, file build.prop.bak kia là file back up, nếu tác dụng sau khi thay đổi không như ý muốn, bạn hãy xóa file build.prop đi, đổi tên build.prop.bak lại thành build.prop, giữ chặt lên nó chọn permission rồi ở cột đầu tích cả 3 dấu, cột thứ 2 và thứ 3 chỉ tích cái trên cùng. Xong rồi khởi động lại máy để các thay đổi được thực thi.










Chúc các bạn thành công !!!
p/s mình k chắc thông số vm heapsize mình đưa ra là tối ưu nhất,nên các bạn có thể thử ở giá trị khác và test để cảm nhận,nếu bạn nghĩ 1 thông số khác là tối ưu hơn,xin hãy comment để giúp tối ưu l3 nhà ta nhé.^^
nguồn hkp

• Title : [Thủ Thuật] Tinh chỉnh VM Heap trong Build.prop cho L3
• Author : Unknown
• Date : 12:16 AM
• Labels :