एंड्रॉइड स्ट्रिक्टमोड इंस्टेंसकाउंटउल्लंघन

ऐसा लगता है कि कुछ उपकरणों पर स्ट्रिक्टमोड जांच में एक बग हो सकता है।

यदि कोई गतिविधि शुरू की जाती है, और बहुत जल्दी बाहर निकल जाती है और फिर से शुरू हो जाती है, तो आप एक StrictMode.InstanceCountViolation प्राप्त कर सकते हैं।

हालाँकि यह केवल इसलिए है क्योंकि कचरा संग्रहकर्ता ने अभी तक गतिविधि के पहले उदाहरण को अंतिम रूप नहीं दिया है, जिसका अर्थ है कि स्मृति में अस्थायी रूप से 2 (या अधिक) उदाहरण हैं।

StartActivity() या startActivityForResult() से पहले System.gc() को कॉल करना StrictMode.InstanceCountViolation को रोक देगा।

ऐसा लगता है कि StrictMode जांच में एक बग (या शायद एक सुविधा?)

यहां StrictMode InstanceCountViolation को संभालने के बारे में Google समूहों पर चर्चा की गई है। ऐसा लगता है कि हर अलग Android संस्करण की एक अलग नीति है, इसलिए वे इसे अक्षम करने लगते हैं। साथ ही Android दस्तावेज़ सख्त मोड के बारे में कहते हैं

लेकिन स्ट्रिक्टमोड को मिलने वाली हर चीज को ठीक करने के लिए मजबूर महसूस न करें। विशेष रूप से, सामान्य गतिविधि जीवनचक्र के दौरान डिस्क एक्सेस के कई मामले अक्सर आवश्यक होते हैं। दुर्घटना से आपके द्वारा की गई चीजों को खोजने के लिए स्ट्रिक्टमोड का उपयोग करें। हालाँकि, UI थ्रेड पर नेटवर्क अनुरोध लगभग हमेशा एक समस्या है।

मुझे लगता है कि @sri अपने कोड के साथ यही दिखाने की कोशिश कर रहे हैं।

public class MyApplication extends Application {

@Override 
public void onCreate (){
   super.onCreate();
   // when you create a new application you can set the Thread and VM Policy
   StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
   .detectCustomSlowCalls() // API level 11, to use with StrictMode.noteSlowCode
   .detectDiskReads()
   .detectDiskWrites()
   .detectNetwork()
   .penaltyLog()
   .penaltyFlashScreen() // API level 11
   .build());

//If you use StrictMode you might as well define a VM policy too

   StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
   .detectLeakedSqlLiteObjects()
   .detectLeakedClosableObjects() // API level 11
   .setClassInstanceLimit(Class.forName(“com.apress.proandroid.SomeClass”), 100)
   .penaltyLog()
   .build());
 }
}

मेरी समझ यह है कि इस उल्लंघन का उपयोग मेमोरी लीक का पता लगाने के लिए किया जाता है। तो उस समय आपके पास लोड किए गए वर्ग के केवल 2 उदाहरण होने चाहिए, लेकिन VM ने 3 पाया।

मैंने इस उल्लंघन को अपने कोड में भी देखा है, लेकिन मेरे अतिरिक्त उदाहरण सभी कमजोर पॉइंटर्स द्वारा संदर्भित किए गए थे। इसलिए मैं इस नियम को अक्षम करना चुनता हूं।

नीचे दिए गए उदाहरण को देखें यह Android संस्करण के आधार पर भिन्न होता है

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
            .detectCustomSlowCalls() // API level 11, to use with StrictMode.noteSlowCode
            .detectDiskReads()
            .detectDiskWrites()
            .detectNetwork()
            .penaltyLog()
            .penaltyFlashScreen() // API level 11
            .build());

        // not really performance-related, but if you use StrictMode you might as well define a VM policy too
        StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
            .detectLeakedSqlLiteObjects()
            .detectLeakedClosableObjects() // API level 11
            .setClassInstanceLimit(Class.forName(“com.apress.proandroid.SomeClass”), 100) // API level 11
            .penaltyLog()
            .build());
    }
}

नीचे की लाइन को ऑन क्रिएट से हटा दें।

//StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().penaltyDeath().detectLeakedSqlLiteObjects().build());