تتمتع آلة s40 بذاكرة أفضل للألعاب والعلوم الشعبية.

هناك نوعان رئيسيان من استخدام الذاكرة، وهما البرامج والموارد. · سيتم تجميع فئة البرنامج في ملف bytecode للفئة وتحميلها في الذاكرة عند بدء تشغيل MIDlet، وسيتم إضافتها كلها مرة واحدة. وهذا يعني أنه كلما زاد عدد الفئات الموجودة في MIDlet، كلما زاد طول برنامج فئة واحدة، وكلما زادت ثوابت السلسلة والبيانات داخل الفئة، كلما زاد حجم ملف الفئة المترجمة وزادت الذاكرة التي سيشغلها بعد التحميل. غالبًا ما أستخدم أسلوب Runtime في مُنشئ فئة MIDlet للتحقق من مقدار الذاكرة التي يشغلها البرنامج بأكمله بعد بدء تشغيل MIDlet. // طريقة التحسين: 1. تمت كتابة برنامج MIDlet إلى فئتين لتقليل استخدام الذاكرة، ولكن على حساب ميزات OOP الخاصة بـ Java. سيكون هذا العيب واضحًا بشكل خاص عندما يكون البرنامج كبيرًا نسبيًا. علاوة على ذلك، واجهت CoCoMo ذات مرة موقفًا حيث كانت فئة واحدة كبيرة جدًا وكان وقت التحميل طويلًا جدًا، مما ينتهك حد الـ 6 ثوانٍ الموجود على شعار صندوق الكنز. //2. حاول كتابة تعليمات برمجية أنيقة، وتقليل عدد الوظائف، وإزالة محاولة الالتقاط عند إصدار البرنامج، وتقليل عدد أسطر البرنامج. هذا غير ممكن بشكل عام في الإصدار 40 القديم، ولكن الآن لم تعد CoCoMo تعتمد على هذا لحفظ الذاكرة. //3. كتابة البيانات والسلاسل في الملفات، وتحميلها في الذاكرة عند استخدامها، وتعيينها على قيمة فارغة عندما لا تكون قيد الاستخدام. 4. عملية الإدخال/الإخراج getClass(). getResourceAsStream(file);, عملية قاعدة البيانات RecordStore. openRecordStore(name, true);, مدير إنشاء الصوت. createPlayer();، إنشاء الصورة Image. createImage(file); سوف تشغل كمية كبيرة من الذاكرة في فترة زمنية قصيرة ثم تحررها لاحقًا. إذا كانت الذاكرة المتبقية لبرنامج MIDlet غير كافية، فسيحدث تجاوز في الذاكرة عند استدعاء هذه الوظائف بشكل متكرر، مما يؤدي إلى ما يسمى بذروة الذاكرة، وهو أمر شائع بشكل خاص في الـ 40 القديمة. عند مواجهة OutOfMemoryError مرة أخرى، استخدم Runtime للعثور على الموقع الذي تحدث فيه ذروة الذاكرة وحاول استدعاء هذه العبارات بشكل منفصل، واستخدم النظام بشكل مرن. gc() للتجميع في الوقت المناسب. //·صور الموارد: تشغل مساحة كبيرة من الذاكرة، خاصة ألعاب الهاتف المحمول التي تحتوي على العديد من موارد الصور. أصبح حساب استخدام الذاكرة لموارد الصورة مهمة عادية لمطوري ألعاب J2ME. سوف يشرح CoCoMo كيفية حساب استخدام الذاكرة للصور: // استخدام الذاكرة = العرض * الارتفاع * عدد بايتات البكسل، حيث يختلف عدد بايتات البكسل حسب الطراز. // على سبيل المثال، استخدام الذاكرة لصورة مقاس 64*64 على 7210 = 64*64*1.5 = 614 4 (بايت) = 6 كيلو، استخدام الذاكرة على S60 = 64*64*2 = 8192 (بايت) = 8K. يختلف عدد بايتات البكسل حسب الطراز. على سبيل المثال، 7210 هو نموذج مكون من 4096 لونًا، مما يعني أنه يتم استخدام 12 بت لتمثيل البكسل، لذا اضرب في 1.5، بينما S60 هو نموذج مكون من 65536 لونًا، ويستخدم 16 بت لتمثيل البكسل، لذا اضرب في 2. // طريقة التحسين// من الخطأ الاعتقاد بأن ضغط الصور يمكن أن يوفر الذاكرة. وفقًا للشرح أعلاه، بعد تحميل الصورة في الذاكرة، تكون مرتبطة فقط بالعرض والارتفاع، ولا علاقة لها بحجم بيانات الصورة. يمكن أن يؤدي ضغط الصورة إلى تقليل حجم الجرة فقط وليس استخدام الذاكرة. //1. الطريقة الثابتة: تقليل حجم الصورة. إذا كان العرض والارتفاع أصغر، ستكون النتيجة أصغر. وبناءً على هذه الفكرة، ظهرت أدوات مثل محرري الرسوم المتحركة، مثل لعبة Prince of Persia من شركة Gameloft. بعد تقسيم الشخصيات، يمكن إعادة استخدام أجزاء جسم الإنسان. يهدف الموضع المضغوط لكل جزء إلى تقليل حجم الصورة والاستفادة الكاملة من كل بوصة من المساحة في الصورة. //2. الطريقة الديناميكية: تقليل عدد الصور المحملة في الذاكرة في نفس الوقت. واجهت CoCoMo هذا الموقف ذات مرة في مشروع Naruto Samurai. كان هناك 6 أنواع من الوحوش في ذلك الوقت. إذا تم تحميلها في الذاكرة في نفس الوقت، فسوف تنفجر بالتأكيد في الأربعين القديمة. ومع ذلك، لم يظهر سوى نوعين أو ثلاثة أنواع من الوحوش في كل مستوى، لذلك كل مستوى يحتاج فقط إلى تحميل صور الوحوش التي ظهرت في ذلك المستوى. الآن بعد أن فكرت في هذا المشروع، حدثت تجاوزات بشكل متكرر في الأربعينات القديمة. // الصوت // الصوت هو أيضًا مورد يستهلك الذاكرة نسبيًا. سيتم تحويل البايتات التي يشغلها المسار الصوتي في الصوت إلى دفق بايت وتحميلها في الذاكرة. ولذلك، فإن تقليل وحدات البايت التي يشغلها المسار الصوتي يمكن أن يقلل من استهلاك الذاكرة. يتمثل النهج الحالي لشركة Gameloft في استخدام أداة تحويل الصوت لتحويل mid إلى ott، ثم تغييرها إلى دفق بايت ByteArrayInputStream لإنشاء مشغل.