2013-03-19 7 views
6

私は、テストする方法がたくさんあるアクティビティの単体テストを作成しようとしています。しかし、約31回のテストの後、ヒープのメモリが不足しているため、アプリケーションは強制終了されます。大きなAndroidアクティビティユニットテストが失敗するのはなぜですか?

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の同一の簡単なテスト・ケースでユニットテストを行いました。しかし、GCがテスト中にメモリをクリーンアップするほど速くないように感じます。ここで

は私のleakTestテストケースである:活動を拡張し

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以下にし、より下がるメモリ使用量でありますアプリが殺される

 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 

誰かがtearDown()内の2秒のスリープ状態を改善するソリューションを持っていますか?私はtearDown()内の睡眠が気に入らない。私たちのテストスイートの中には約100のテストがあるので、2秒は非常に遅れます。

誰かが私を助けてくれることを願っています。私の質問が明確でない場合は、私に知らせてください。

ありがとうございます。

答えて

2

各ユニットテストの後にgcを実行する必要があるのはなぜですか?

テストのためのクリーンな環境が必要な場合は、2秒の遅延で居住してください。 tearDownは少なくとも2 gcで終了します。それはあなたの次のテストのためのきれいな環境を残します。あなたがアンドロイドのソースコードを読んだら、テストの終わりにcallilng tearDownの重要な必要性を示すいくつかのコメントがあります。

テストでクリーンな環境が必要ない場合は、それらを組み合わせてください。つまり、200秒間のプロセスの後で実行されるプロセスは、テストがあなたに与える保護に対する犠牲を払うための小さな値段です。

私たちの現在の大きなプロジェクトの自動テストでは、実行に約5分かかります。初期のチェックインでテストを実行するシステムを自動化し、失敗した場合に提出をバウンスさせるため、私は気付かない。

何度か失敗してしまいましたが、私が変更したコードがアプリの他のセクションを混乱させてしまったことに本当に驚いています。私たちは、少なくとも数週間節約しました。私たちの自動化されたテストでは、アプリの保守やデバッグに数ヶ月かかる可能性があります。

+0

こんにちは、お返事ありがとうございます。現在のテストでは、すべてのテストできれいな新鮮なアクティビティが必要です。前のテストが次のテストに影響を与えることはありません。しかし、私は、2秒の遅れで 'OutOfResourcesExceptionが表面を生成する'エラーを修正するのが奇妙だと分かっています。 Androidのバグ、またはサーフェスリソースを十分に速くリリースしないような感じです。しかし今のところ、クイックビルドセットアップで毎日実行されるので、2秒の遅延を受け入れるだけです。 – kuipers

関連する問題