ANR, Crashes & slow rendering

ANR, Crashes & slow rendering
0
#1

Hello Devs and Cocos Team,
My Android game on Google Play is suffering a lot. I’m seeing very bad reports even I recently updated my game with latest cocos2dx 3.16 and sdkbox/Admob is updated to the latest.

54%20AM
Screen Shot 2018-04-11 at 11.03.54 AM.png1044x191 13.6 KB

24%20AM
Screen Shot 2018-04-11 at 11.04.24 AM.png976x500 33 KB

How do I solve these issues? Is there any tools or way out to check on which point these slow rendering or ANR is happening? PLEASE HELP!!! @walzer @nite @zhangxm @yinjimmy

#2

as I know, 3.14.1 is better.

#3

There is no need to tag a lot of people for attention. These forums are reviewed by engineering already. Or tag me so I can work out getting you help.

#4

ok I won’t do it from next time. What do you suggest on my above issues ?

#5

@jeevs I am not sure.

@yinjimmy are you saying that v3.16 doesn’t work with the current SDKBOX plugins and are suggesting the OP switch back to 3.14?

#6

Are there any useful anr/crash logs? What can you see behind the view details text?

#7

30%20PM
Screen Shot 2018-04-12 at 1.37.30 PM.png962x645 84.6 KB

Yes there are hell lot of reports which I don’t understand. This is the screenshot of the ANR reports.
And below is the details of the first cluster(ANR).
If you would like to see I can send you the reports in csv or excel file in PM.
Can you figure it out what’s exactly going wrong?

“main” tid=1 Waiting
“main” prio=5 tid=1 Waiting
| group=“main” sCount=1 dsCount=0 obj=0x75b8c000 self=0xb4827800
| sysTid=22161 nice=-4 cgrp=default sched=0/0 handle=0xb6fa2bec
| state=S schedstat=( 0 0 0 ) utm=3179 stm=1027 core=0 HZ=100
| stack=0xbe67f000-0xbe681000 stackSize=8MB
| held mutexes=
at java.lang.Object.wait! (Native method)

  • waiting on <0x0cd95830> (a android.opengl.GLSurfaceView$GLThreadManager)
    at android.opengl.GLSurfaceView$GLThread.surfaceDestroyed (GLSurfaceView.java:1636)
  • locked <0x0cd95830> (a android.opengl.GLSurfaceView$GLThreadManager)
    at android.opengl.GLSurfaceView.surfaceDestroyed (GLSurfaceView.java:541)
    at android.view.SurfaceView.updateWindow (SurfaceView.java:594)
    at android.view.SurfaceView.onWindowVisibilityChanged (SurfaceView.java:246)
    at android.view.View.dispatchWindowVisibilityChanged (View.java:9152)
    at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1170)
    at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1170)
    at android.view.ViewGroup.dispatchWindowVisibilityChanged (ViewGroup.java:1170)
    at android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:1350)
    at android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1093)
    at android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:6010)
    at android.view.Choreographer$CallbackRecord.run (Choreographer.java:767)
    at android.view.Choreographer.doCallbacks (Choreographer.java:580)
    at android.view.Choreographer.doFrame (Choreographer.java:550)
    at android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:753)
    at android.os.Handler.handleCallback (Handler.java:739)
    at android.os.Handler.dispatchMessage (Handler.java:95)
    at android.os.Looper.loop (Looper.java:135)
    at android.app.ActivityThread.main (ActivityThread.java:5912)
    at java.lang.reflect.Method.invoke! (Native method)
    at java.lang.reflect.Method.invoke (Method.java:372)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:1405)
    at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1200)
#8

No. It’s not about SDKBox, it’s about cocos2d-x.

I remember that cocos2d-x 3.14.1 is more stable than others, data from @energyy.

#9

what I can help is https://www.google.com/search?q=ANR+reports&oq=ANR+reports&aqs=chrome..69i57.507j0j7&sourceid=chrome&ie=UTF-8

it’s ok to PM me.

#10

Yes, we recommend to switch to cocos 3.14 or 3.15.1 - 3.16 by some unknown reason is disaster in production.

#11

Thanks for letting me know this. Let me talk to the engineering team.

#12

The SCREEN_ON/SCREEN_OFF intents or receiver aren’t in the cocos engine (or I’m to blind to find them). That’s weird.

Can you check your AndroidManifest.xml, if SDKBox adds them?

#13

I can’t find any related things added in the xml by SDKBOX.
Please see below the xml if you would like to see.

25%20PM
Screen Shot 2018-04-13 at 3.51.25 PM.png799x550 103 KB

#14

You need to look into the merged manifest. Every (gradle) dependency is able to inject data into your AndroidManifest.xml file. What’s the packageName of your game, so I can install and check it by myself.

#15

Yes I checked the merged xml too and found no extra thing added. My game’s package id is com.js.ludo .

#16

Slow Rendering flag is because of ad sdks. You can read more about them here



https://groups.google.com/forum/#!topic/google-admob-ads-sdk/yPH7H3EWVBM

#17

For ads, I’m using Admob through SDKBOX only. Putting ad is the only option I’ve got for monetization. So no solution for this issue? :frowning: Or is there any thing SDKBOX can optimize on their part to minimize this issue?

#18

@slackmoehrle Did you got any new on that?

@energyy Also, may I ask which SDK/NDK do you recommend for 3.14 or 3.15.1?

Also, last but not least, 3.15.1 or 3.14.1? Android Studio support (introduced in 3.15) “shouldn’t” be decisive factor to choose 3.15.1 over 3.14.1, any other reason should apply and, if possible, be explained.

Thanks :slight_smile:

#19

Hi,

We using 3.15.1 - but 3.14 also is good working one, for NDK we chosed NDK 13B .

Regarding android studio support - it’s totally not problem to add it to any cocos version, u just need to copy over build.gradle file from 3.15 and add some extra gradle config files and it will work same. There is just one extra command added which running NDK compile from gradle .

#20

you can call plugin::init after use enter your game main scene.

node::init()
{
    time_after(2 seconds, plugin::init());
}