बड़े एंड्रॉइड गतिविधि यूनिट-परीक्षण क्यों विफल हो जाते हैं?

Question

मैं परीक्षण के लिए कई विधियों के साथ एक गतिविधि के लिए एक इकाई परीक्षण बनाने की कोशिश कर रहा हूं। लेकिन लगभग 31 परीक्षणों के बाद आवेदन मारे गए क्योंकि ढेर स्मृति से बाहर है।

1152 E SurfaceFlinger createSurface() failed, generateId = -12 
1152 W WindowManager OutOfResourcesException creating surface 
1152 I WindowManager Out of memory for surface! Looking for leaks... 
1152 W WindowManager No leaked surfaces; killing applicatons! 
1152 W ActivityManager Killing processes Free memory at adjustment 1 

मैंने समस्या को खोजने के लिए 40 समान सरल परीक्षण-मामलों के साथ यूनिट-टेस्ट बनाया है। लेकिन ऐसा लगता है कि जीसी परीक्षण के दौरान स्मृति को साफ करने के लिए पर्याप्त तेज़ नहीं है।

package my.app; 

import android.os.Debug; 
import android.test.ActivityInstrumentationTestCase2; 
import android.util.Log; 

public class leakTest extends 
     ActivityInstrumentationTestCase2<TestActivityAndroid> { 

    String TAG = "leakTest"; 

    TestActivityAndroid mActivity = null; 

    public leakTest() { 
     super(TestActivityAndroid.class); 
    } 

    protected void setUp() throws Exception { 
     super.setUp(); 
     setActivityInitialTouchMode(false); 

     mActivity = getActivity(); 
    } 

    protected void tearDown() throws Exception { 
     super.tearDown(); 
    } 

    private void printHeapSize() { 
     Log.e(TAG, 
       "NativeHeapAllocatedSize = " 
         + Debug.getNativeHeapAllocatedSize()); 
     Log.e(TAG, "NativeHeapFreeSize = " + Debug.getNativeHeapFreeSize()); 
     Log.e(TAG, "NativeHeapSIZE = " + Debug.getNativeHeapSize()); 
    } 

    public void test_1() { 
     assertNotNull(mActivity); 
    } 

    public void test_2() { 
     assertNotNull(mActivity); 
    } 

    public void test_3() { 
     assertNotNull(mActivity); 
    } 

    public void test_4() { 
     assertNotNull(mActivity); 
    } 

    public void test_5() { 
     assertNotNull(mActivity); 
    } 

    public void test_6() { 
     assertNotNull(mActivity); 
    } 

    public void test_7() { 
     assertNotNull(mActivity); 
    } 

    public void test_8() { 
     assertNotNull(mActivity); 
    } 

    public void test_9() { 
     assertNotNull(mActivity); 
    } 

    public void test_10() { 
     assertNotNull(mActivity); 
    } 

    public void test_11() { 
     assertNotNull(mActivity); 
    } 

    public void test_12() { 
     assertNotNull(mActivity); 
    } 

    public void test_13() { 
     assertNotNull(mActivity); 
    } 

    public void test_14() { 
     assertNotNull(mActivity); 
    } 

    public void test_15() { 
     assertNotNull(mActivity); 
    } 

    public void test_16() { 
     assertNotNull(mActivity); 
    } 

    public void test_17() { 
     assertNotNull(mActivity); 
    } 

    public void test_18() { 
     assertNotNull(mActivity); 
    } 

    public void test_19() { 
     assertNotNull(mActivity); 
    } 

    public void test_20() { 
     assertNotNull(mActivity); 
    } 

    public void test_21() { 
     assertNotNull(mActivity); 
    } 

    public void test_22() { 
     assertNotNull(mActivity); 
    } 

    public void test_23() { 
     assertNotNull(mActivity); 
    } 

    public void test_24() { 
     assertNotNull(mActivity); 
    } 

    public void test_25() { 
     assertNotNull(mActivity); 
    } 

    public void test_26() { 
     assertNotNull(mActivity); 
    } 

    public void test_27() { 
     assertNotNull(mActivity); 
    } 

    public void test_28() { 
     assertNotNull(mActivity); 
    } 

    public void test_29() { 
     assertNotNull(mActivity); 
    } 

    public void test_30() { 
     assertNotNull(mActivity); 
    } 

    public void test_31() { 
     assertNotNull(mActivity); 
    } 

    public void test_32() { 
     assertNotNull(mActivity); 
    } 

    public void test_33() { 
     assertNotNull(mActivity); 
    } 

    public void test_34() { 
     assertNotNull(mActivity); 
    } 

    public void test_35() { 
     assertNotNull(mActivity); 
    } 

    public void test_36() { 
     assertNotNull(mActivity); 
    } 

    public void test_37() { 
     assertNotNull(mActivity); 
    } 

    public void test_38() { 
     assertNotNull(mActivity); 
    } 

    public void test_39() { 
     assertNotNull(mActivity); 
    } 

    public void test_40() { 
     assertNotNull(mActivity); 
    } 
} 

परीक्षण गतिविधि है जो फैली गतिविधि::

package my.app; 

import android.app.Activity; 

import android.os.Bundle; 

public class TestActivityAndroid extends Activity { 

    @Override 
    protected void onCreate(Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
    } 
} 

यहाँ स्मृति उपयोग जहां देशी मुक्त अंतरिक्ष 30KB नीचे और से करने के लिए चला जाता है है

यहाँ मेरी leakTest परीक्षण मामला है ऐप मारे गए

 Applications Memory Usage (kB): Uptime: 3804373 Realtime: 3804373 

** MEMINFO in pid 7315 [my.app] ** 
        native dalvik other total 
      size:  4048  3271  N/A  7319 
     allocated:  3942  2306  N/A  6248 
      free:  105  965  N/A  1070 
      (Pss):  844  1590  1806  4240 
    (shared dirty):  1404  4120  2288  7812 
    (priv dirty):  736  672  992  2400 Objects 
      Views:  0  ViewRoots:  0 
    AppContexts:  0  Activities:  0 
      Assets:  2 AssetManagers:  2  
    Local Binders:  11 Proxy Binders:  10 
Death Recipients:  0  
OpenSSL Sockets:   0  
SQL 
      heap:  0  memoryUsed:  0 
pageCacheOverflo:  0 largestMemAlloc:  0 
    Asset Allocations 
    zip:/data/app/my.app-1.apk:/resources.arsc: 1K 

क्या किसी के पास बेहतर समाधान है कि 2 सेकंड आंसू के अंदर नींद आती है? मुझे आंसू के अंदर नींद पसंद नहीं है()। और क्योंकि हमारे टेस्ट-सूट के अंदर हमारे पास लगभग 100 परीक्षण हैं, 2 सेकंड में बड़ी देरी होगी।

मुझे उम्मीद है कि कोई मेरी मदद कर सकता है और यदि मेरा प्रश्न स्पष्ट नहीं है तो कृपया मुझे बताएं।

अग्रिम धन्यवाद।

Answer 1

प्रत्येक यूनिट परीक्षण के बाद आपको जीसी करने की आवश्यकता क्यों है?

यदि ऐसा इसलिए है क्योंकि आप अपने परीक्षण के लिए एक स्वच्छ वातावरण चाहते हैं, तो 2 सेकंड देरी के साथ रहें। आंसूडाउन कम से कम 2 जीसी और कुछ अंतिमकरण करता है। यह आपके अगले परीक्षण के लिए एक स्वच्छ वातावरण छोड़ देता है। यदि आप एंड्रॉइड स्रोत कोड के माध्यम से पढ़ते हैं, तो परीक्षण के अंत में कॉलिलिंग आंसू की महत्वपूर्ण आवश्यकता को इंगित करने वाली कई टिप्पणियां हैं।

यदि आपके परीक्षणों को स्वच्छ वातावरण की आवश्यकता नहीं है, तो उन्हें गठबंधन करें। ऐसा कहा जा रहा है कि, दृश्यों के पीछे चलने वाली प्रक्रिया के 200 सेकंड एक परीक्षण के लिए भुगतान करने के लिए एक छोटी सी कीमत है जो परीक्षण आपको देगा।

हमारे वर्तमान बड़े प्रोजेक्ट पर हमारे स्वचालित परीक्षणों को चलाने में लगभग 5 मिनट लगते हैं। मैंने कभी ध्यान नहीं दिया, क्योंकि हमने शुरुआती चेक-इन में परीक्षण चलाने के लिए हमारी प्रणाली को स्वचालित कर दिया है और अगर वे विफल हो जाते हैं तो सबमिशन को बाउंस करें।

कुछ बार विफल होने के बाद, मैं वास्तव में चौंक गया हूं कि मैंने जो कोड बदल दिया है, वह ऐप के अन्य अनुभागों को गड़बड़ कर रहा है। हमने कम से कम सप्ताह बचाए हैं, और हमारे स्वचालित परीक्षणों के साथ हमारे ऐप को रखरखाव और डिबग करने में कई महीनों की संभावना है।