We Keep Coding

Is it possible to predict frames dropping with Unity, and before this happens deactivate all but the camera updating to avoid VR sickness?

Since a decent frame rate is so important in VR apps, I was just wondering if you can predict frames dropping? If so, before this issue actually occurs, can you deactivate some scripts or other features except the camera transform's updating and rendering of the environment? So, if performance drops (i.e. frames drop) no nausea will be experienced.

Predicting the future is not very likely, so you're going to have to adapt on the fly when you see performance drop. Either that or you could imagine creating a test environment a user could run where you try and figure out the capabilities of the user's hardware setup and tweak settings accordingly for future actual app runs. (i.e. "the test environment ran below the desired 120fps at medium settings, so default to low from now on")
I don't know what platform you are on exactly, but just in case you're on the Oculus ecosystem you might be able to get some help however.
By default on Oculus devices you're supported by what they refer to as "Asynchronous TimeWarp". This in essence decouples the headset's transform update and rendering from the framerate of your application. If no up-to-date frame is available, the latest frame will be transformed based on the latest head tracking information, reducing how noticeable such hiccups are. You will still want to avoid this having to kick in as much as possible though.
Additionally, Oculus supports "Fixed Foveated Rendering" on their mobile platforms where depending on your GPU utilization the device can render at lower resolutions at the edges of your view. In practice I've found this to be surprisingly effective, even though (as the name implies) it's fixed at the center of the view and does not include any eye tracking. But as with the previous method, not needing it is always better.
I'm unfortunately less familiar with options on other devices, but I'm sure others will pitch in if those exist.

c# game (xamarin spritekit) optimization

I write a game. This game isn't very simple, but I didn't suppose that it will take around 95% of CPU. I read much articles about optimization, but it wasn't helpful.
At the moment I have 2d models which contains much children and I have a complicated game logic. I tried to debug and test my code, but i can't understand why... why it takes so much CPU.
Can you give some advices about optimization?
UPD:
Platform: Cross Platform (macOS / iOS) Right now I use macOS, not a simulator

Simple 2D Unity Game has periodical jerkiness

I've made a simple 2D game in Unity using the application Tiled for the tilemap, but when I run it, every now and then the screen will jump like it has a quick fps drop.
I'm not sure what would be hurting the performance of the game, because it is not performing any demanding tasks. My only guess is that it could be the large tilemap I'm using, but I feel this is not the problem because the game was still jerky when the map was not large. Furthermore, I tried scaling the map to an even larger size but it didn't make the performance any worse than it already was.
Does anyone know what could be causing the performance issue here? Thanks.

Periodic frame-rate drops could be caused by a number of things - fortunately Unity gives you a very good tool to track this down in the form of the Profiler (Window > Profiler). It's recommended that you build the game (check Development Build and Autoconnect Profiler) rather than testing in the editor, as often the editor creates a lot of overhead that shows up in the Profiler and may lead you astray.
Play the game and see if there are any spikes when you notice the fps drop. I would not be surprised if you have Garbage Collection (GC) causing your periodic fps drops. GC is triggered periodically in the background to clean up memory that was allocated but is no longer needed. You can get a good idea of how much memory is being allocated by selecting CPU Usage and looking at the GC Alloc column. This can add up quickly! Optimising a game to avoid GC spikes is a whole topic unto itself.
But, of course, you problem might have nothing to do with GC spikes. Hopefully the Profiler will tell you which stones you should be turning over.

In C#, what's a good way for displaying zoomable, pannable video?

I've been sorting through DirectX, DirectShow, etc. and can't figure out which .NET C# library would be the best.
I'm making an art installation that will feature full screen video. I'd like the user to be able to pan and zoom in and out on the video as it's playing, ideally with no skipping or hiccups. Is there a Microsoft technology that stands out as an obvious choice for this?

Don't forget to consider WPF.. It is a lot faster to get started with than Direct3D... It also has an infrastructure designed for glitch free animations, independent from delays from garbage collection and ui thread activity.
In very complex GUI's, WPF can come with some hidden cost, which annoys people, claiming WPF is slow.
But I am confident it will work fine in the scenario you describe.

IMHO Use XNA. It has much deeper support than the old managed directX. This guy answered your question for you: http://www.david-amador.com/2009/10/xna-camera-2d-with-zoom-and-rotation/

Optimization of a GC language, any ideas?

I'm a pretty big newbie when it comes to optimization. In the current game I'm working on I've managed to optimize a function and shave about 0.5% of its CPU load and that's about as 'awesome' as I've been.
My situation is as follows: I've developed a physics heavy game in MonoTouch using an XNA wrapper library called ExEn and try as I might I've found it very hard to get the game to reach a playable framerate on an iPhone4 (don't even want to think about iPhone3GS at this point).
The performance degradation is almost certainly in the physics calculations, if I turn physics off the framerate jumps up sharply, if I disable everything, rendering, input, audio and just leave physics on performance hovers around 15fps during physics intensive situations.
I used Instruments to profile the performance and this is what I got: http://i.imgur.com/FX25h.png The functions which drain the most performance are either from the physics engine (Farseer) or the ExEn XNA wrapper functions they call (notably Vector2.Max, Vector2.Min).
I looked into those functions and I know wherever it can Farseer is passing values by reference into those functions rather than by value so that's that covered (and it's literally the only way I can think of. The functions are very simple themselves basically amounting to such operations as
return new Vector2(Max(v1.x, v2.x), Max(v1.y, v2.y))
Basically I feel like I'm stuck and in my limited capacity and understanding of code optimizations I'm not sure what my options are or if I even have any options (maybe I should just curl into a fetal position and cry?). With LLVM turned on and built in release I'm getting maybe 15fps at best. I did manage to bring the game up to 30fps by lowering the physics precision but this makes many levels simply unplayable as bodies intersect one another and collapse in on themselves.
So my question is, is this a lost cause or is there anything I can do to beef up performance?

First of all, love your game on Windows Phone 7!
Secondly, I don't see anything out of the ordinary in your profiler output. I did a quick and dirty performance analysis of the Farseer engine once (running in .net) and came up with similar results. It almost looks like you have a slowdown that is proportional across the board and may be due to mono itself.

I suppose you follow the performance hints in http://farseerphysics.codeplex.com/documentation already :-)
The most important thing seems to be
to reduce complexity for the
collision detection calculations,
i.e. not the visual but the colliding
shapes. In Unijty3D they are called
colliders and you can attach a simple
cube as a collider to a complex human
body. I don't know anything about
Fareer but they probably have similar
concept (is it called body?).
If possible, try to replace your main
character or other complex objects by
easy cubes and check if fps raises.
Compiler switches sometimes leverage performance. Be really sure that there are no debug settings activated (I got up to 30 times slower code in a C++ library project). Ensure that armv7 optimisation is turned on and -O3 or -Os
Watch out for logging statements as they are extremely expensive on iPhone
[Update:]
Try to decrease the number of actively calculated AABBs just to find out which part of the physics engine causes the trouble. If it's the pure number follow FFox' advice.
What is about other platforms? Where did you perform the testing during the development phase, on simulator? Which one? Any chance to get it running on Android or Android simulator or Windows Phone? This would give you a hint if it is an iPhone specific problem.
Ah, I just saw that ExEn still is in pre-release state and the final will be launched on July 21th as OS. IMO this changes the situation: If your App is running fine on some other comparable platform, then just wait for the release and give it a new try. Chances are pretty well that there is still debugging code in the pre-release you are working on.