Oculus Mobile SDK 1.14.0 深度剖析
Keyword: Life Cycle, ATW, Direct Render
Oculus Mobile SDK 1.14.0 为当前官网最新版本。由于 Oculus SDK 在某版本之后，不再开放源码，而是通过提供静态库文件的形式。虽然我手中有一份早期的开源版本，但是对比了最新的 SDK 头文件之后，我发现还是有所不同的。因个人精力有限，仅对当前最新版本 Oculus Mobile SDK 进行解读，后期可能会针对早期版本的具体实现进行进一步的解读。
在这个 SDK 中，我们最关心的是其原生接口，官方手册中详细描述了原生四个模块的主要功能，列表如下：
| Component | Description | Source code folder |
|---|---|---|
| VrApi | The Virtual Reality API provides a minimal set of entry points for enabling VR rendering in native applications and third-party engines. | VrApi |
| VrApplication Framework | Framework and support code for native applications. Includes code for rendering, user interfaces, sound playback, and more. It is not meant to provide the functionality of a full-fledged engine, but it does provide structure and a lot of useful building blocks for building native applications. | VrAppFramework/Src |
| Native Samples | Sample projects illustrating use of VrApi and VrAppFramework. | VrSamples/Native |
| LibOVRKernel | The Oculus library. | LibOVRKernel/Src |
这四个模块的依赖关系总结如下：
Native Samples --> VrApplication Framework --> VrApi --> LibOVRKernel
接下来，我们由上而下具体分析下这四个模块：
1. Native Samples
官方原生样例程序库，通过统一的文件夹名称 Native 我们可以发现，这里提供的所有样例都是需要编写原生代码的，即需要添加 C++ 代码，并通过 JNI 的方式调用其原生模块来实现 SDK 的调用。这里并没有提供只编写 java 代码就可以实现的样例。
-
模板方法：
此方法是 SDK 最简单的实现，也是样例库中 VrTemplate 提供的方法。具体方法为：在 java 层，继承 com.oculus.vrappframework.VrActivity 接口；在 native 层，编写 OVR::VrAppInterface 抽象类的实现。由于此方法使用了 VrApplication Framework 中定义好的生命周期和 JNI 调用逻辑，极大地简化了编码的工作。可以发现，在 java 层代码量非常少，主要的逻辑在原生代码中。 -
纯原生：
这种方式相当暴力，直接绕过了 java 层面，只有工程 VrCubeWorld_NativeActivity 使用了此种方法。这种方法直接放弃了 java 层的代码逻辑，也没有继承 com.oculus.vrappframework.VrActivity （只继承了最原始的 android.app.NativeActivity），放弃了 VrApplication Framework 中封装地逻辑，直接使用 C++ 控制底层 VrApi 来编写逻辑。可以说是更灵活，更 C++。
我相信，此代码的提供展示了直接使用 C++ 调用 VrApi 编写应用的可能性，也展示了如何直接使用或整合 C++ 引擎。 -
混合编程：
这种方法在模板方法的基础上，在 Java 层添加了大量的逻辑代码。可以这样理解，SDK 其实只提供了针对 VR 图像渲染相关的 api，即一个渲染引擎的相关逻辑。如果想要其他功能，或者整合成一个游戏引擎，在 Java 层调用 Android 服务接口无疑是最方便的方法。
样例库剩下的工程如 CinemaSDK，Oculus360VideosSDK 都在 java 层有大量逻辑代码。
这里我们重点看一下 VrTemplate 这个工程，毕竟是官方文档中的模板工程，如果你不需要魔改
在头文件 OvrApp.h 中，我们可以看到这个类主要继承了 OVR::VrAppInterface，具体实现了暴露出来的五个接口。即是说，OVR::VrAppInterface 中封装了 VR 渲染的大部分逻辑，我们只需要把我们想要的实现补充好就可以了。
这在设计模式中叫啥来着我忘记了，回头补上，这是目前我所指的绝大多数渲染引擎主要使用的设计模式。
class OvrApp : public OVR::VrAppInterface
{
public:
OvrApp();
virtual ~OvrApp();
virtual void Configure( OVR::ovrSettings & settings );
virtual void EnteredVrMode( const OVR::ovrIntentType intentType, const char * intentFromPackage, const char * intentJSON, const char * intentURI );
virtual void LeavingVrMode();
virtual bool OnKeyEvent( const int keyCode, const int repeatCount, const OVR::KeyEventType eventType );
virtual OVR::ovrFrameResult Frame( const OVR::ovrFrameInput & vrFrame );
// 省略了其他部分，感兴趣的可以去源码中查看。
};
那么在 OVR::VrAppInterface 中被封装的逻辑是怎样的，我们在下一环节进行仔细的讲解。
2. VrApplication Framework
/************************************************************************************
Filename : App.h
Content : Native counterpart to VrActivity
Applications that use this framework should NOT include any VrApi
headers other than VrApi_Types.h and VrApi_Helpers.h included here.
The framework should provide a complete superset of the VrApi.
Avoid including this header file as much as possible in the
framework, so individual components are not tied to the native
application framework, and can be reused more easily by Unity
or other hosting applications.
Created : September 30, 2013
Authors : John Carmack
Copyright : Copyright 2014 Oculus VR, LLC. All Rights reserved.
*************************************************************************************/
/*
VrAppInterface
==============
The VrAppInterface class implements the application life cycle. A class that implements
an application is derived from VrAppInterface. The application then receives life cycle
events by implementing the virtual functions from the VrAppInterface class. The virtual
functions of the VrAppInterface will be called by the application framework. An application
should never call these virtual functions itself.
All of the VrAppInterface virtual functions will be called from the VR application thread.
All functions except for VrAppInterface::Configure() will be called while the application
is in VR mode. An applications that does not care about a particular virtual function,
is not required to implement it.
VrAppInterface life cycle
-------------------------
<--------+
1. Configure(settings) |
2. EnteredVrMode() |
<--+ |
3. while(keyEvent) OnKeyEvent() | |
4. Frame() | |
---+ |
5. LeavingVrMode() |
---------+
*/
3. LibOVRKernel
SDK 的底层以来实现，具体包括 文件操作，日志操作，数组类型，线程控制，各类数学计算 等等的实现。此模块给上层的 VrApi 等模块提供了统一且明确的底层接口。很明显，Oculus SDK 是希望能通过统一的标准库编写，来避免不同版本编译器或 NDK 对程序可能造成的影响。
此模块代码开源，方便了第三方开发者对其进行修改与扩展。
4. VrApi
最重要的部分，也是此唯一不再开源的部分。Oculus 最精华的技术如 ATW，Direct
虽然无法看到最新版本的源码，不过我们可以根据
这里对其实现不做过多展开，就像文章开始时承诺的一样，如果有时间将根据旧版本的 SDK 此部分源码进行深度剖析。
在头文件 VrApi.h 的开头，我们可以发现下面这段非常重要的注释。
Android Activity life cycle
===========================
VrApi
=====
Multiple Android activities that live in the same address space can cooperatively use the VrApi.
However, only one activity can be in "VR mode" at a time. The following explains when an activity
is expected to enter/leave VR mode.
Android Activity life cycle
===========================
An Android Activity can only be in VR mode while the activity is in the resumed state.
The following shows how VR mode fits into the Android Activity life cycle.
1. VrActivity::onCreate() <---------+
2. VrActivity::onStart() <-------+ |
3. VrActivity::onResume() <---+ | |
4. vrapi_EnterVrMode() | | |
5. vrapi_LeaveVrMode() | | |
6. VrActivity::onPause() -----+ | |
7. VrActivity::onStop() ---------+ |
8. VrActivity::onDestroy() ---------+
Android Surface life cycle
==========================
An Android Activity can only be in VR mode while there is a valid Android Surface.
The following shows how VR mode fits into the Android Surface life cycle.
1. VrActivity::surfaceCreated() <----+
2. VrActivity::surfaceChanged() |
3. vrapi_EnterVrMode() |
4. vrapi_LeaveVrMode() |
5. VrActivity::surfaceDestroyed() ---+
Note that the life cycle of a surface is not necessarily tightly coupled with the
life cycle of an activity. These two life cycles may interleave in complex ways.
Usually surfaceCreated() is called after onResume() and surfaceDestroyed() is called
between onPause() and onDestroy(). However, this is not guaranteed and, for instance,
surfaceDestroyed() may be called after onDestroy() or even before onPause().
An Android Activity is only in the resumed state with a valid Android Surface between
surfaceChanged() or onResume(), whichever comes last, and surfaceDestroyed() or onPause(),
whichever comes first. In other words, a VR application will typically enter VR mode
from surfaceChanged() or onResume(), whichever comes last, and leave VR mode from
surfaceDestroyed() or onPause(), whichever comes first.
主要资料链接：
