In order to improve how fast your views are laid out on the screen on the device, you can do a very important thing. Flattening your layout. What does this mean? Let me show you an example!

Consider the following page layout, which is very much made out of nested LinearLayouts.

The problem with the nested layout above is the amount of measure passes which has to be done in order to lay it out. For each child with a layout_weight tag, it needs to measure itself twice. Other layouts need to measure themselves too. Imagine having a more complex layout, with a lot of nesting; would resolve in excessive measure passes and make displaying of your layout slow. Especially in cases where you use the layout is used as a row layout. This would hit the app performance quite a lot and there would be noticeable slowdowns in your app.
The layout above, can be flattened using RelativeLayout. You will notice, that layout_weight is quite powerful for layout out equal sized views, so some tricks have to be used to achieve the same with a RelativeLayout. The performance in the end is much better though.

As you see. The above layout employs two additional layouts, which are used to center the other views. An alternative to RelativeLayout to make percentage sized views is PercentRelativeLayout from the Android.Support.Percent package. With it you can set aspect ratios, use percents for widths and heights and more. I would recommend keeping your layouts as simple as possible.

If you simply wish to stack views on top of each other, you can use FrameLayout, which is a real good performer as well.

You can read more about optimizing layouts in the official Android documentation, which also shows how to use the Hierarchy viewer to inspect slow layouts.

GPU Overdraw

Enable showing GPU overdraw

This will gives us this when showing it with GPU overdraw debugging enabled.

Our layout is RED just because we added backgrounds to our layouts. Removing these backgrounds reduce overdraw significantly and in turn improves performance of your app.

Just removing the outermost background reduces overdraw and in this layout the change won't be visible anyways.
The two nested LinearLayouts use the same color, what if we use that as our theme background and remove the color from the layouts?
Again less overdraw. Here is the view without GPU overdraw enabled.

In this case, since the buttons themselves have a background, there will be some overdraw and that can we sometimes cannot do anything to prevent. However, simply reducing a layout from being red all over to green or light blue, means a lot towards performance. Especially in cases where the layout is used in a ListView or RecyclerView or similar Adapter type of view as less time is used to draw the row.

Hence, try to avoid using backgrounds, especially if you can't see them at all. Also a good idea is instead of adding a background to each layout, add that background to your theme, which is pretty simple.

You can also opt to actively remove backgrounds from views with android:background:"@null" for views you don't really care about their background.

As for shadows, borders and the like, which you could do as a background. If you really have to have them use 9-patches with transparency in the areas you don't show anyways. Android will optimize the drawing of these for you and will not overdraw here.

Reducing overdraw in custom views

You might have views that override the OnDraw method where you draw stuff to the Canvas it provides. Here overdraw matters as well. Using OnDraw is what normal views essentially end up using in the end when they draw them selves on the screen. So you have to be careful here as well.

One way to eliminate all overdraw is to draw to a Bitmap first and then draw that to the canvas. This is normally know as double buffering. Be careful with using this, it gives the overhead of first drawing to the Bitmap then to the canvas which draws it to the screen.

The above code shows a simplified version of it. It does indeed result in just 1x overdraw if draw on a background. However, if your draw code is slow, you may encounter flickering if you need to redraw your view a lot.
SurfaceView in Android does it a bit differently. It does all the buffered drawing on a separate thread. You could do this as well. Then call Invalidate() or PostInvalidate() when you need the buffer to be shown on the screen

The technique I ended up using is a modified version, where I delay the drawing until everything is drawn on the Bitmap. Then I signal with PostInvalidate(). It looks something like this the code below.

Now this could probably made a bit simpler. However, what I achieve with this is, whenever I manually signal with Refresh() I cancel any current drawing operations to the buffer as I am not interested in what it provides as it is old data... PostInvalidate() triggers the OnDraw method whenever the GPU is ready. In here I kick off a new Task which draws to the buffer. When that Task is done it calls PostInvalidate() to signal that the buffer has changed and that will be drawn. It is a variation of double buffering, which allows draw operations to take a long time. This has resulted in smooth scrolling of the RecyclerView I am using with these graphs as rows and no overdraw.

Maybe you can use some of these techniques in your app. Let me know what you find out in your application.
In general you want to

• Flatten your layouts to reduce measure calls
• Use RelativeLayout instead of LinearLayout with weights
• Even better FrameLayout for stacked views
• Remove backgrounds that are not shown anyways
• Use theme background where applicable
• android:background:"@null"
• Use 9-patch for borders and shadows
• Reduce overdraw in your own OnDraw calls

Resources

https://medium.com/@elifbon/android-application-performance-step-1-rendering-ba820653ad3
https://www.hackerearth.com/practice/notes/rendering-performance-in-android-overdraw/
http://www.xenomachina.com/2011/05/androids-2d-canvas-rendering-pipeline.html
http://developer.android.com/tools/performance/debug-gpu-overdraw/index.html
http://developer.android.com/reference/android/graphics/Canvas.html
https://www.udacity.com/course/android-performance--ud825

1. Start the Marshmallow image

2. Drag the gapps-L-4-21-15.zip onto the Emulator after it has booted. It will prompt you to install the zip and shutdown the device after that.

The result should look something like

That is it. Now your Windows 8.1 project should be able to pick up all the languages you have specified and you can get the correct strings from your RESX files.

Here is how I use it.

In my PCL I have a small helper for Windows 8.1 which looks like:

I have registered that helper in my App.xaml file like so:

Then I can use it like this in my Windows 8.1 app XAML pages and templates:


Given that Welcome is a key in the RESX files.


On iOS I create my views in C# code pretty much by hand. Hence I simply use the RESX files directly. So if we say my RESX file is called ApplicationStrings.resx then usage looks like:



On Android I use RESX localization plugin for MvvmCross, where Stefan Schoeb has a very nice description on how to use it. I don't use it for iOS since it is just easier to directly get the strings. Less code 😁

Last week I released a new NuGet package called ALRadialMenu, which is a port from Swift to C# of Alex Littlejohn's ALRadialMenu. It is simply a menu which spawns N amounts of UIButton's in a circle around the point you want it to. It is highly configurable.

I also released a new NuGet package called SGTabbedPager, which is mimicking a ViewPager and ViewPagerIndicator on iOS. This is a port from Swift to C# as well.

This week I created a Device Information plugin for MvvmCross. I know there are some other plugins. However, not all of them covered exactly what I needed. The plan is to expand it with more device information, such as batter, storage, connectivity etc. Ideas are welcome and can be submitted as a GitHub issue on the repository.

This plugin can be found on NuGet too as Cheesebaron.MvxPlugins.DeviceInfo and targets Android, iOS and Windows 8 + Windows Phone 8.1 (universal). It should also work in the new Windows 10 UWP apps, although not tested.

For some reason the Apple SDK does not provide a simple boolean Property where you can just disable it. A lot of solutions on StackOverflow requires you to set a background image and a shadow image to remove it entirely.

Digging through solutions a bit I found that these two ways seem to work pretty well.

So for the NavigationBar, what you do is traverse through all subviews to find the UIImageView which is the shadow and simple remove that from showing up. This is done as follows.

For the TabBar it is slightly different. It has a member variable, which is private, so you cannot get hold of it directly. However, using the SetValueForKey() method, which all NSObject's have, you can set that variable to true.

See the difference?