Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
I have a performance issue with HTC One. When using a Xamarin.Android application using the high level screen layout (seen below) of controls the screen start to process everything very slow. I created a Java/Android app in IntelliJ with the same visual layouts and adapters and that application didn't have the performance issue that was seen with the Xamarin project.
Do you know of any open performance issues with the HTC One?
High level screen layout:
ListView - Used for grouping images into rows.
TextView - group description
HorizontalListView - Cheesebaron control used for horizontal scrolling of images
LinearLayout - orientation horizontal
ImageView - source loaded via UniversalImageLoader
ImageView - loading a vertical divider drawable
More info and version information:
Here is a sample project [link in above private comment] that contains a nav menu with 4 options to mimic our production app. Nav2 option is the only one populated with the layout in our app that has the performance issue.
We have only seen this issue on the HTC One device to report this issue.
Here is a full list of devices that we have had install our app during our testing phase.
tmous|HTC Sensation 4G
=== Xamarin Studio ===
Version 4.2.4 (build 35)
Installation UUID: 1100c63d-1d86-404f-9f7f-f58579095b0f
Mono 3.2.6 ((no/9b58377)
GTK+ 2.24.23 (Raleigh theme)
Package version: 302060000
=== Xamarin.Android ===
Version: 4.12.3 (Business Edition)
Android SDK: /Users/jdenney/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
=== Apple Developer Tools ===
Xcode 5.1.1 (5085)
=== Xamarin.Mac ===
Xamarin.Mac: Not Installed
=== Xamarin.iOS ===
Version: 22.214.171.124 (Starter Edition)
Build date: 2014-04-18 15:39:16-0400
=== Build Information ===
Release ID: 402040035
Git revision: 1173cb1c45bc56cb702e82cd21a7c9d0cea4acbf
Build date: 2014-04-17 13:45:52-04
Xamarin addins: 53bde0041263928e8bd64686f5ca5a8e4338dd76
=== Operating System ===
Mac OS X 10.9.2
Darwin [hostname redacted] Darwin Kernel Version 13.1.0
Wed Apr 2 23:52:02 PDT 2014
*** Bug 19744 has been marked as a duplicate of this bug. ***
I have checked this issue with HTC one V. I am also seeing performance issue on this device. Using the attached sample when I click on Nav2, It takes time to upload images compare to other devices.
X.S 4.2.5(Build 0)
Git revision: 95ac543f224a70960a9ab71e24ce341eb87de06f
Android Log: https://gist.github.com/saurabh360/c2ddc247a5a665dc05c4
adb log: https://gist.github.com/saurabh360/017d090e90fde9aaf3b5
Here are the results from: adb shell cat /system/build.prop | grep "product"
This is from the first hands on experience we had with the performance issue.
# ro.build.product is obsolete; use ro.product.device
ro.product.display_resolution = 5 inch 1080p resolution
ro.product.main_camera = HTC UltraPixel Camera
ro.product.front_camera = 5M
ro.product.hwreset = 1
ro.product.hwreset.timer1 = 6
ro.product.hwreset.timer2 = 9
ro.product.ram = 2GB
ro.product.wifi = 802.11 a/b/g/n/ac
Show layout bounds: off
Show screen updates: off
Animation scale: 1x
Has there been any new findings to this?
@Jason: I don't have an HTC one.
That said, could you please state how you're observing this? What should I tap/scroll/etc. to attempt to see the performance issue? What IS the performance issue? Bad scrolling? Bad downloading? Not seeing anything at all when there should be something?
For example, when I launch the app it launches MainActivity, which is only shown for less than a second before it's replaced by a Fragment with "Nav 1" as the active view, which appears to be empty. I then tap the "hamburger" icon, which shows a menu allowing selection of Nav 1 through Nav 4. Nav 1, 3, and 4 all appear empty.
Selecting Nav 2 shows a variety of images. Scrolling is "weird", in that if I scroll to the top or bottom scrolling stops immediately, but if at the top I try to scroll "above the top" the contents are "pulled down", a'la iOS, which is rather odd to see on Android. There is no equivalent at the bottom of the list. Each row also allows scrolling horizontally, which is occasionally hard to trigger as my efforts frequently make the screen scroll vertically. When I hit the end of a horizontal/row list, it stops suddenly, more or less as I'd expect, though with no actual feedback that I'm at the end of the list, making me wonder if the app was stuttering the first time I did it.
Looking closer, it seems that _sometimes_ when I horizontally scroll a row it stutters slightly, but it might be my imagination; I'm not sure.
narayanp on 2014-05-14 05:32:06 EDT had reported seeing the performance issues with testing on multiple devices.
However Nav 1, 3, & 4 are left blank as those are just place holders for how our application navigation is handled.
The pull down to refresh action is becoming common and is a Android Support Tools released control and is used in a number of Google released applications and is making the design patterns more blurred between iOS and Android to more mobile design. However design of the application isn't the concern of the support request as the Xamarin App has the performance issue where as a Java based Android app created with IntelliJ does not see the same performance issue.
The issue is observed by navigating to Nav 2 screen. Once on Nav 2 the 2nd and 3rd rows on the vertical list both have approx 10 items with around 3 visible on the screen at the time. Under normal performance the horizontal scrolling of those rows is smooth and can scroll from end to end very quickly with a fast flick. However on 4 different HTC One's (2 M7's and 2 M8s) the scrolling distance is held properly and does eventually process correctly however the scroll animation for the rendering appears to be running at about 5fps vs 30fps however it's not dropping frames so the animation now takes a tremendous amount of time longer.
After an afternoon of profiling and investigation we're still unsure as to what is causing this performance degradation on the HTC One.
Here's a comparison of profiler results, one from an HTC One, and the other a Nexus 4: https://gist.github.com/pjcollins/1690bf6c0790e8d5073a
It appears that average execution time is faster on the HTC One versus the Nexus 4, however the HTC One's performance is much, much worse. It's also clear that the system time, and average cpu load are much higher in the case of the HTC One, what's still unclear is why.
To provide a little more information, I was seeing a very dramatic performance degradation immediately upon clicking the navigation drawer item in the top left, regardless of which item was selected. Navigating to the 'Nav 2' screen was not needed in my case, as the 'drawer open' and 'drawer close' actions were extremely slow when selecting any of the four Nav items. The Choreographer also made it very apparent that a large number of frames were being skipped right from the get-go, not only after navigating to 'Nav 2'.
Looking at the profiler results there doesn't seem to be a significant difference between what managed code is doing between the two devices, but there's a huge difference in time spent in the kernel and the system load.
User Time : 5590.000ms
System Time : 2280.000ms
Total Time : 11180.000ms
Working Set : 123375616
Private Bytes : 57712640
Virtual Bytes : 971722752
Page Faults : 69976
CPU Load Average - 1min : 1.270000
CPU Load Average - 5min : 0.880000
CPU Load Average - 15min : 0.700000
User Time : 6040.000ms
System Time : 71630.000ms
Total Time : 12080.000ms
Working Set : 147554304
Private Bytes : 71880704
Virtual Bytes : 1021452288
Page Faults : 2073732
CPU Load Average - 1min : 3.520000
CPU Load Average - 5min : 22.150000
CPU Load Average - 15min : 43.660000
Look at the load average - something is keeping the system very busy. Could we find out which process(es) are the culprits? If it's our process, attach the debugger and see what it's doing. There should be an immense number of threads doing something.
I believe 3 key factors involved in this problematic behavior are (roughly in order of importance):
1. The app currently uses a large (1.2 MB) background image.
2. The pixel density of the HTC One is high, so processing of each image in the scroll views might be comparatively CPU-intensive.
3. The horizontal scroll views are nested within a ListView.
From what I saw, none of these factors is specific to Xamarin. They all apply to Java Android apps on the HTC One as well. It might be appropriate to mark this bug RESOLVED UPSTREAM or RESOLVED INVALID.
## 1. Large background image
I was able to solve the problem in the original test case from comment 0 by either:
a. Resizing `background.png` from 768 x 1280 pixels down to 384 x 640 pixels before building the project.
b. Removing the `background.png` drawable resource from the project. The resource was used in `Main.axml`, `Fragment2Layout.axml`, and `splash_background.xml`.
I suspect this issue is closely related to bug 24508, comment 3. Note that this problem is not specific to Xamarin. I spent some time further simplifying the C# sample, and then I did a line-by-line port to Java. To my eye the performance of the Java sample is approximately identical to the C# sample: scrolling is "low frame rate" on an HTC One but fluid on an LG Optimus L9.
## 2. High pixel density on the HTC One
I created a second simplified C# sample to remove the UniversalImageLoader dependency. This also gave me easy access to the scaling ratio of the individual images. This second version of the app performs a bit worse than the original on an LG Optimus L9 because the image loading and caching are more simplistic, but the relative performance of the HTC One is still worse.
Decreasing the scale improves the scrolling speed on the HTC One. For example, if I scale all the images down to 20 x 20 pixels (the ImageViews on the HTC One are around 400 x 400 pixels), then the horizontal scroll views scroll smoothly.
Results in the line-by-line Java port were again equivalent.
### Optimus L9
Processor: dual-core 1 GHz
Pixel density: 234 ppi
### HTC One M7
Processor: quad-core 1.7 GHz
Pixel density: 469 ppi
Relative single-threaded processor speed: 1.7
Relative image size: 4
Relative (processor speed / image size): 0.4
## 3. Horizontal scroll views nested in ListView
Removing the "items" ListView from `Fragment2Layout.axml` and replacing it with 4 in-line copies of `Fragment2ListItem.axml` improves the scrolling behavior _some_. The effect is not as pronounced as downsampling the background image, but still noticeable.
## Version information
Xamarin.Android 4.20.0 (ba9bbbdd44cfdc4bf485e8885bd2ad24fba525f7)
java version "1.6.0_65"
## Steps to reproduce
1. Launch the test case (from comment 0).
2. Tap the drawer menu icon in the top left of the app and select "Nav 2".
3. Swipe the 3rd horizontal scroll view from right to left slowly to allow all of the images to download.
4. Swipe the scroll view back to the beginning.
5. Swipe the scroll view quickly from right to left. It's possible to move across the entire length of the scroll view in 1 swipe.
The scrolling speed is lower on an HTC One compared to an LG Optimus L9. More noticeably, the individual items in the scroll view do not "blur together" at all. For example, the thin black borders between items stay clearly visible and distinguishable for the duration of the scroll. There are never more than 4 borders visible at once. In contrast, on an Optimus L9 the items blur together more so that at times there appear to be more than 4 borders on the screen at once.
Downsampling the background image by a factor of 2 is sufficient to restore fluid scrolling on the HTC One so that more than 4 borders appear on the screen at once.
## Status update
I am marking this old bug as resolved answered per the analysis in Comment 11 and in particular the finding that Java apps have the same behavior.
*** Bug 46500 has been marked as a duplicate of this bug. ***