We use the Android Premium SDK of HERE in our application containging truck navigation. We have just upgraded from version 3.3 to 3.8, and and we experience a quite strange problem. The app started to use the CPU and the GPU very much after this upgrade. We made some investigations and the followings are happening:
The extra CPU and GPU usage occurs when truck restrictions are displayed on the map, that is when we use: map.setFleetFeaturesVisible(EnumSet.of(Map.FleetFeature.TRUCK_RESTRICTIONS));
We tested such that we set all the layers invisibile with map.setVisibleLayers(), and the truck restrictions were displayed. However, the app is still very slow. Nothing changed.
Using the map.setFadingAnimations(false); helped a little bit, but not too much.
We are trying to solve the problem with different tilt angles by using map.setTilt(). It looks like this helps, but it is still worse than with the version 3.3.
Based on these facts, we believe the problem is with the amount of markers displayed when TRUCK_RESTRICTIONS are required. It is noted here: https://developer.here.com/documentation/android-starter/dev_guide/topics/development-tips.html , that too many objects can cause performance problems. However, we cannot modify the amount of objects with TRUCK_RESTRICTION, and in cities (e.g in Budapest) there are many restrictions.
Does anyone have any advices on what should we do?
Thank you in advance!
Thank you for bringing this to our attention. We are working on a solution and plan to fix this within the next SDK release (3.10).
Related
I have been playing with optimizing my app, and I see that there are some general ideas on how much memory it should use... I'm running between 70-80Mb right now, is that a crazy number or just a little on the heavy side?
My second question is about the memory I am using. About 42Mb is taken up by graphics, whether I run the app with the layout graphics or run it without setting any views... any ideas on where to look? I feel like it is the theme, but I am not sure how to test that.
I've been searching for days to figure out why it uses so much and cannot figure it out. It remains constant regardless of which activity I am on, any ideas are welcome!
UPDATE:
I ended up running it on an emulator and got about 26Mb, more what I was expecting, but it runs at 70Mb with the 42Mb of graphics on the actual device.
The emulator allows for a 384Mb app after getting memoryclass information, while the device only allows 256Mb... the emulator has more storage and runs more efficiently.
The emulator is Android 8.1 27api while the device is Android 7.0 24api.
Tried on an older Android 5.1.1 api 22 below also.
Any ideas?
I have another question with about why the emulators have a such a difference in performance here if you know the answer on that, but I wanted to keep these questions separate: Other Question
Android Studio has an awesome tool called Memory Profiler. It helps you analyze possible memory leaks and see which calls are using up the most memory. You can even pause the processor and 'zoom in' to deep dive on the call stack.
You can use LeakCanary A memory leak detection library for Android and Java. Maintain by Square. This is one of the best developer's Tool for memory optimization and detecting leaks.here
I have found two issues with SKMaps 3.0.0 with two of my Android devices, although they seem to not be issues on other devices (such as my tablet).
Devices include:
Samsung S6 Edge+ Android:6.0.1
Nexus 6 Android:5.1.1
EDIT:STILL BROKEN WITH 3.0.1 SKPolyline.setOutlineSize() seems to have a maximum size around 10. Setting it any higher does not affect the line size. I reported this to the skobbler team already and nothing has been done about it.
EDIT:FIXED WITH 3.0.1 SKMapSurfaceView.animateToLocation() seems to animate the location to the location to the bottom of the map, so that the center of the map is exactly half way above the spot I would have liked to animate to. Sometimes it works correctly, but this is rare.
If anyone has encountered these issues and has solutions please let me know...
The issued has been fixed with in our 3.0.2 release, now the line width and the outline width of the polyline can be set to any value between 0 and 100.
You can find the links for the 3.0.2 release candidate builds in our forum:
http://forum.skobbler.com/showthread.php/14515-3-0-2-release-candidate-builds
Regarding the first problem reported, it seems there's a bug in the SDK. Our dev team is handling the issue. The feature will be available in a future version of our SDK.
Since a while ago I started having some artifacts on some android devices. I have checked build settings, I was disabling code stripping and setting all options to the default ones - nothing worked out.
This visual interference (see screenshot) happens at least in Note II and HTC One Mini/2. Nexus 5 exhibited very minor interferences.
Any help would be highly appreciated!
Picture here
Well, that was quite obvious, I just needed to turn on my brain, lol.
So, if you're having issues with rendering like I was - try to check your main camera.
And especially be careful with Clear Flags property. Personally, I have faced with a situation when some of my background layers (which have SpriteRenderers on) were switching their alpha values. At that point camera would "see" through the layers. And that is the problem if you have "Don't Clear" value in "Clear Flags" property.
Hope it helps.
which Unity version are you using? Can you make sure to use ETC1 compression (+alpha if needed) and try again on those devices?
I'm trying to run the ionic-angular-cordova-seed project on Android 4.3.1 with Cordova. One thing I've noticed is that page transitions (for example, clicking on a tab or a list item) are very slow.
I tried to disable hardware acceleration using:
super.appView.setLayerType(WebView.LAYER_TYPE_SOFTWARE, null);
... and it worked perfectly. But then scrolling, side menu sliding and more animations became extremely slow.
I've tried FastClick, it didn't make any difference.
I found this CSS-based solution to the problem, but I'm not familiar enough with Ionic to apply it on it. Any ideas?
Note: I'm not using any animations for page transitions.
It seems like Ionic has made a lot of Android-related fixes that really improved performance. In addition, I've splitted my Android version into two versions: 4.4 and pre-4.4. Pre 4.4 is using cordova-android-chromeview which makes it so much faster. Even though it adds ~20 MB to the apk, it worths it.
Since this bug seems to be very specific to Android 4.4.2
I believe this may be what we're looking for, or at least helpful:
http://playlablondon.tumblr.com/post/102534909709/improving-performance-on-cordova-powered-android
Recently upgraded to the AIR 3.1 SDK and have run into a show stopping issue regarding InvokeEvent on mobile devices. The application is dispatching a new InvokeEvent each and every time you change orientation on the device. And it isn't clearing the "queuedEvents" array. Worst of all, the new event it dispatches each time is a clone of the last one recieved. In the case of our application, this would be parameters that tell the application to load certain data. So each time you change orientation, the application re-triggers that load sequence, causing lots of undersirable behavior.
The code is pretty simple to test out:
protected function preinitializeHandler(event:FlexEvent):void
{
NativeApplication.nativeApplication.addEventListener(InvokeEvent.INVOKE, onInvoke);
}
protected function onInvoke(event:InvokeEvent):void
{
trace(event.toString());
}
Now each time you change orientation you will see the trace statement and the event.target.queuedEvents collection continues to grow while never clearing any of the previously caught events out.
Rolling back to AIR 3.0 fixes this behavior. And I've been able to demonstrate that in two separate projects.
I'd love to hear of a fix or work around so we can release using 3.1, but either way, I thought I'd make others aware of this issue as I haven't been able to find anything about it through my searching.
For additional details on hardware: This doesn't occur in emulator or my LG Slate, but it does happen every time on both of our Xooms and our Samsung Galaxy Tab. It doesn't appear to be an issue with iOS.
UPDATE: Just updated to the 3.2 release candidate (3.2.0.2060) and the problem remains. Our software wont be able to update past 3.0 for the foreseeable future, which means we can't upgrade to Flex 4.6 SDK either, not without removing a significant feature of our application. This doesn't inspire us to the future of AIR in our company.
There are a few solutions and work around we might be able to employ to fix our specific feature, but there is still a concern over the effects of having an ever ballooning invoke queue that never clears. That could have additional issues over extended use of the application.
UPDATE 2: I put more details in the Adobe forum post. http://forums.adobe.com/message/4278518
Eric Jensen