This is an >5 years old question, but it's still not only quite relevant, but also getting more and more complex over the years as there are even more screen ratios on mobile devices nowadays than even when this question was asked.
Since this question was ask, there have been quite a few additional options given in Unity (especially with Unity 2018). Still, there are quite a few tips & tricks when handling the screen ratio so that it can fit with almost every screen sizes.
First, the best universal method is, ironically, the old method: Dynamically build whatever screen-related assets in real-time when, for example, a scene is started. This is a similar thing to what is used for websites where you create a different kind of GUI & experience based on the screen sizes. For example, having a screen less wide than 800px would have 1 kind of GUI while having one of over 2000px would have another kind. It's really time consuming and relatively complex to build (hence more prone to bugs & errors), but offers the best versatility of any kind of setup.
In such a way, your goal is to make sure every buttons and texts are always big enough to by pressed by people with big fingers and/or be read by anyone.
The main difference between doing it in a game engine (like Unity) and doing in HTML5 for the web is the fact that you're not stuck with a single "scene" in the game engine while HTML5 might requires you to work in a single web page as redirection scripts might be blocked by the User's browser. This means that you could start your game with a custom flash scene (such as a custom scene where your company logo appears) and, in that scene, you apply a checked that detect the screen sizes. Then, after, you make you scene transition script to decide which "scene" to load depending on the screen pixel sizes. This is far easier than having to script everything into a single scene.
The second way is a quite easier and faster, but it can have quite some impact on the performances depending on how good the optimization was applied. Simply put, using a 3D space (known as "World Canvas" in Unity) based GUI may saves you a ton of work. Unlike other kind of canvas, the World Canvas (3D based canvas) is getting automatically adjusted on the height of the screen based on its active screen rotation. This includes even a built-in Anti-Aliasing as well as a really good pixels ratio conversion of the textures using in the GUI which means that the GUI will look as if it was made especially for that screen resolution as long as each displayed textures doesn't exceed their maximum resolution. Another really important part of this method which is, for now, unique and can't be used with others is that this method also allow you to use basic VECTORS based graphics. Yup, for a while now Unity can render SVG files with flat colors. It's just not yet compatible with the GUI 5.x yet which is why this doesn't work with other GUI methods as this one is the only one who's using the proper Z-Buffer and some other built-in system of the engine to render the UI (which is why you can put both UI and 3D models in the canvas). Note that I precise that, for now, only basic Vectors based graphics can be used such as flat colors and really basic gradients (kinda like the limited HTML5 SVG-based code rendering). No outlines or styles or any kind of complex "rendered" magic can be done (yet?).
Lastly, the 3rd way is to use the "Canvas Scaler" component on the same GameObject as the Canvas' component. Usually, the best result comes from using the UI Scale Mode "Scale with Screen Size" and decide if the screen should be matching either the Width or Height of the target device. This methods comes with some restrictions and requires you to design something that can be well adjusted in one direction with a wide range of screen size. For this, I always suggest the use of something I call fractal UI design. This means to cut your menus in smaller sections while raising how "deep" the menus gets OR getting a menu design that allow you to display limited information at one time.
The best example I could give of how to cut a menu in smaller sections which widen the menu depth is making an option menu with tabs such as Sounds, Graphics, Gameplay, etc. Each of those tabs would have 1 to 5 options each at most. This can easily be displayed well on both small and big screens alike. You sacrifice maybe 60-80 pixel for the Tabs buttons, but you gain many times the remaining amount of pixels. As an example, the smallest yet still used Android-based screen size is 240x320 pixels. Yes, it's quite small, but it's surprisingly still used by some small devices in populated areas of China. If you avoid those, you avoid a tiny part of the market and the choice is yours. Personally, I usually focus on a basic of 480x800 pixels as a basic ratio & minimal screen sizes, but I keep looking at the GUI while in 240x320 now and then to make sure it's still "usable".
The quality of the 3rd method is that you can soft-launch the game with that method and, at a later point if necessary, apply an update that allow you to implement the 1st method. It's quite useful when you're on a tight budget and/or time allotment.
The downside of the 3rd method (and 1st) is mostly that you got to do quite a bit of maths when you're attempting to sync things properly. Such as having sprite-based animations with proper refresh rate based on the screen size because the sprite is tiled over the screen width or height is truly a pain to adjust properly without any wackiness.
As an example, one of my projects has a main menu with 2 animated gears that rotates and 2 chains that move up or down when the user change the menu selection. It's all in 2D and the chains are tiled at 100% pixel fidelity. This means that the chain seems "bigger" on a smaller screen slimmer on a bigger screen, but it has no weird pixels even if the screen reaches thousands of pixels in height. Yet the sprites of the chains are 53x254 and 33x254 and they are all part of a single Atlas 1024x1024 texture. To lighten the time requires to animate the UI properly, I created a general GUI animation script. Something that allows me to easily setup a list of GUI element so that they can animate by either rotation, changing sprites or by movement (translation) and this script's action can be remotely accessed by reference. Pretty straight-forward if you ask me. Still, to make it semi-universal, I had to add a few additional option (as Boolean parameters) that allows me to decide if the animation is affected by the screen ratio and on which direction if it's such a case. I noticed this to be needed when I tried the main menu on an old LG Android phone that has a, nowadays, unpopular screen ratio as the chain animation (which is based on the sprite switching speed like a sub-framerate) was 1.4x too slow while it was alright on more common screen ratios (like Android tablets) I tested it on.
P.S. If you wonder why I used 33x254 and 53x254 for the texture instead of numbers that are multiplication of 2, that is because of built-in Anti-Aliasing of the GUI textures where, sometimes, 1 additional pixel is read and displayed around resized GUI texture in a canvas. So while the texture size is 33x254, it sometimes display 34x254 pixels of the source. It's the usual float precision issue because of the resizing is done in floats (within the engine) that gets rounded up as integer for pixel reading.