[J2ME] bạn đã tối ưu code dự án J2ME như thế nào ? [cùng thảo luận]

[chinh92]

bạn đã tối ưu code dự án J2ME như thế nào ? hãy cùng thảo luận, chia sẻ những kinh nghiệm để các dự án J2ME chạy được nuột hơn [IMG]images/smilies/smile.png[/IMG]

View more random threads:

• Cách Update plugin của Netbean cho Android?
• Run ứng dụng Android bị lỗi launching new_configuration has encountered a problem?
• Tính toán thời điểm Alarm sẽ kêu tiếp theo có kết hợp ngày nghỉ lễ
• Nhận dạy kèm khóa học lập trình Android Apps/Games từ Cơ Bản đến Nâng Cao
• Cách kết hợp hàm update và present trong lập trình Android game?
• Máy ảo chạy ra kết qua nhưng máy thật lại không ra là sao , ai biết chỉ với!
• Định hướng học lập trình Java cho di động?
• phiên bản android để test chương trình
• Cách kéo thả ảnh (ImageView) vào Gridview?
• Cách dò tìm vị trí của 1 người có mang đt di động ko cần kết nối internet?

[honghoa]

Mình hay dùng cách sử dụng 1 Thread cho tất cà các canvas. Không sử dụng các hàm gc bừa bãi.

[nhatlinhit88]

1. vấn đề dùng canvas
Dùng nhiều canvas là ko nên [IMG]images/smilies/biggrin.png[/IMG]

chỉ nên dùng 1 Canvas trong project J2ME
lí do :
- dùng 1 Canvas sẽ tránh được hiện tượng giật hình (khi chuyển canvas này sang canvas nọ)
- không phải get graphics nhiều lần, vì chỉ có mỗi 1 canvas, get graphics 1 lần duy nhất
- bộ thu gom gc cũng ko phải làm việc nhiều

thực tế qua 16 dự án của công ty mình cũng kiểm nghiệm điều này rồi (*)

các dự án thực tế ng ta chỉ sử dụng 1 canvas duy nhất (*)

[suckhoenhakhoa247]

16 : Con số ấn tượng thật. Bạn này dày dặn kinh nghiệm rồi, còn gì nữa cùng chia sẻ đi.

[niemvuics]

2. vấn đề bộ nhớ & giải phóng bộ nhớ tự động

mặc dù j2me có bộ thu gom bộ nhớ tự động nhưng trong J2ME chờ để bộ thu gom hoạt động thì lúc đó
ứng dụng đã out of memory từ lâu rồi nhé [IMG]images/smilies/biggrin.png[/IMG] .nguyên nhân thì hỏi chúa @_@
tốt nhất là tự tay giải phóng

cách giải phóng :

bạn gán null tất cả các object được khởi tạo (những object ko còn dùng đến) và gọi lệnh gc như sau

Runtime.getRuntime().gc();

hoặc

System.gc();

=> khuyến cáo dùng Runtime.getRuntime().gc(); [IMG]images/smilies/biggrin.png[/IMG]
lúc nào thì giải phóng

- thường đối với 1 j2me apps thì lúc nào bạn ko cần dùng nữa thì sẽ giải phóng,
- đối với 1 j2me game, thực tế người ta sẽ dùng 1 thread quét định kì (0.5s) , gọi lệnh gc ở trên liên tục

biến nào chiếm nhiều bộ nhớ nhất
- dĩ nhiên là biến String, chiếm đến >=60% bộ nhớ của ứng dụng j2me thông thường.bạn có thể enable memory monitor lên để kiểm tra điều này => hạn chế dùng biến String, nếu dùng thì nên dùng String buffer. String buffer có thể hiểu nôm na là dùng đến đâu thì chiếm bộ nhớ đến đó.\
- hạn chế dùng biến int, nên dùng short,byte nếu có thể
- hạn chế dùng các biến Image, các image nếu ko transparent thì nên để định dạng jpg, nếu image kích thước 320x240 nên để dung lượng tầm 10kb là vừa
- hạn chế dùng thread, thread là 1 nguyên nhân để bộ nhớ tăng vọt thất thường.khuyến cáo là dùng tối đa 3 thread trong 1 dự án j2me. 3 thread thì máy tàu giật điên cuồng rồi thì phải. nên dùng timer nếu có thể.
Kinh nghiệm của mình là dùng tối đa 1 thread, thay thế = timer nếu có thể

- nếu dùng thread,timer thì trước khi hủy class chứa nó cần phải hủy nó trước. thực tế là nếu hủy class chứa timer mà ko hủy timer trước thì dù có gọi gc, bộ nhớ vẫn tăng vọt...biết chết liền [IMG]images/smilies/biggrin.png[/IMG]

trong j2me vấn đề tối ưu bộ nhớ khá hay, làm nhiều sẽ rút ra được kinh nghiệm. chả như android, cứ khai báo biến quên ngày tháng mà ko cần lo nghĩ gì...^^

[traihalinh]

Có vài ý góp vui :
- jar size : ảnh png 256 colors và dùng lại những vùng ảnh trùng nhau thường là chia ra ảnh thành những mảnh nhỏ và lưu tọa độ lại . Dùng code để sinh lại các chunks của ảnh png.Dùng một thuật toán nén hay hơn libz để nén data vào jar.Code thì nên so sánh các statement và các operator sau khi gen ra JIT code sẽ hơn thua nhau bao nhiêu bytes và ý nghĩa của từng statement trên javac ( không nên tập trung vào đây vì xuống size jar ít lắm nhưng sẽ tốt hơn cho performace ) .
- performace : tối đa việc đẩy người dùng vào cases mà ta có thể tính toán trước trên giấy trong giai đoạn analyzing & design,dynamic struct cho app của bạn ( vẫn ở giai đoạn design),cache data vào mem tối đa có thể ( mâu thuẫn với mem), code chú ý các vòng lặp .Chỉ vẽ lại những vùng cần vẽ trên canvas.
- mem : Thread và timer sống nhiều sẽ chiếm nhiều mem lý do vì JVM phải tạo ra các stack riêng cho các thread và timer này .Thường thì dùng 1 thread chính rồi kick-off 1 thread done-die liền sau mỗi case.String thường các app thông dụng hay có nhiều => biến nó thành 1 cục data rồi load string từ data lên .Static nhiều sẽ làm hao mem nhưng stable .

[IMG]images/smilies/smile.png[/IMG] profiler để debug rồi tùy từng trường hợp thui .À mà trên realdevice thì còn nhiều thứ lắm để nói .

[penguins06]

Một topic hay. Cố gắng phát huy nhé, nhất là những anh em nào có kinh nghiệm về mảng này. [IMG]images/smilies/clap_grin.gif[/IMG]

[vutien2401]

3. có nên dùng thư viện của hãng thứ 3 không ? ưu nhược điểm của từng thư viện ?
hãy cùng thảo luận....

[misuto]

Các câu trả lời của các bác trên khá hay, một kiến thức ứng dụng tốt.
Tuy nhiên chúng ta vẫn còn nhiều cách nữa, trong đó có cả thay đổi chút thói quen code nữa, mình xin đóng góp một vài cách sau:

1. Chú ý việc khởi tạo các object:
Việc khởi tạo các object rất tốn bộ nhớ, nên chúng ta tránh khởi tạo nó trong vòng lặp for như sau:

        for (int i = 0; i < length; i++) {
            ClassName p = new ClassName();
            results[i] = p.calculateResult();
        }

2. Xem lại vòng lặp của bạn
Nếu bạn dùng vòng lặp kiểu như vậy thì rất dở

        for (int i = 0; i < v.size(); i++) {
            // Làm gì đó 
        }

Vì mỗi lần lặp, hệ thống sẽ tính toán lại kích thước của v. Thay vào đó hãy tính kích thước của v trước khi vào vòng lặp:

        int size = v.size();
        for (int i = 0; i < size; i++) {
            // Làm gì đó
        }

Tốt hơn nữa bạn có thể làm như sau:

        for (int i = 0, n = v.size(); i < n; i++) {
            // Làm gì đó
        }

Còn nếu vòng lặp của bạn không cần quan tâm đến thứ tự của các item lặp, thì hãy chọn cách lặp ngược về 0 vì ngôn ngữ nào cũng vậy, so sánh với số 0 bao giờ cũng hiệu quả hơn hẳn:

        for (int i = v.size() - 1; i >= 0; i--) {
            // Làm gì đó
        }

3. Sử dụng mảng một chiều thay cho mảng đa chiều

4. Nếu được thì dùng toán tử shift thay cho các toán tử toán học khác
Chẳng hạn ta có thể dùng int a = 11 << 1 thay cho int a = 11 * 2
Tuy nhiên nếu bạn không rành về toán tử shift thì mình khuyến cáo là không nên dùng.

5. Tránh sử dụng synchronization nếu không cần thiết

6. Cuối cùng là sử dụng obfuscater khi biên dịch ứng dụng.