2016年5月20日，我正式从老东家MStar离开，怀揣着搞万物互联的想法在5月31日加入了黑鲨的前身，众思科技，开始了为期6年6个月的新赛季。
最初接触到Zeusis团队是在2016年2月份，当时整个上海似乎只有70人左右，办公室也是刚装修完毕。彼时我在MStar已经是从事非Android工作，偶尔有一些交集，对Android的理解还是停留在2013年4.0的阶段，整个技术栈也是比较杂的，在公司也是属于公司要做啥就去做啥的角色，往好听的地方说是技术全面，从底层到上层，从linux到ecos都做过；另外一方面，别人会认为就是啥都不精；整个面试过程更倾向于是“你问我答”的知识竞赛，对着履历的工作讲问题说细节谈思路，当时说了啥已经记不得了，最重要的一点是跟面试官达成了共识：“XXX小区是个好小区，希望以后可以买进去”，有共同的目标可能应该是一个面试加分项。
重修数据结构+算法
重启了leetcode的算法题，但是进度缓慢
重修图形学知识
忙着学习openxr的东西，图形学的部分反而没有怎么看
找到一个落地黑科技
完全NG，年初一个大转型就走出了手机行业，不知道XR的部分是不是算黑科技？
完成一次mini铁人三项
没有完成，2022-11-29健身房器械PB：史密斯机蹲20+60x2=140KG，自由杆推：14+37.5x2=89KG，硬拉：14+45x2=104KG，自身体重82.3KG。
2022年快要接近尾声了，罗列了一下这一年读过的书，做一个简单的回顾：
最近的诸多问题都出在了坐标系上，收集了一下零散在各个地方的资料，汇总一下各个场合下的坐标系，强行做个笔记。
首先我们在谈论坐标系的时候，一般是会讲到左手坐标系和右手坐标系，它们是怎么定义的呢？
我们可以拿出我们的左手。
请牢记这个标准姿势，后面所有的左手坐标系都是在这个姿势的情况下做旋转
在工作中发现对于纯App开发的同学来说，frameworks的代码属于是一个禁区的存在，一旦进入到frameworks以后出现的各种问题，或者是流程跟踪，再或者是代码走读，大家都会一筹莫展。
大部分的工程师会采取访问androidxref的方式来跟代码，少部分有AOSP源码编译经验的工程师会通过增加日志的方式来进行调试，但是这两种做法的效率其实都不是太高，结合我自己的工作经验和认知，在这边分享一个调试frameworks操作指南，可以把system_server等其他进程当做是普通App进行调试，也可以把普通App运行到frameworks中的流程调试起来。
因此，我们在进行前期准备的时候，需要人为构造一个项目，但是这个项目又不能是AOSP的源码，不然一次同步就会很久，有些电脑就直接挂掉了；后期调试的时候需要人为选择调试的进程，而不是通过Android Studio帮我们无脑attach。
Oculus有着一个非常庞大的Integration SDK，其中又涵盖了Unity 3D，Unread和Native的开发，而这些部分又可以叠加OpenXR和非OpenXR。
在VR设备领域，Oculus是绝对的标杆和对标的竞品，厂商可以通过分析Oculus App的集成情况来窥探当前App的一个生态布局。
大部分的命令都是常规性的，比如过滤日志的grep，抓日志用的adb logcat，这边主要就这两个场景做一下扩展。
logcat为最近时间，而logcat.034是最远的时间。
logcat.034，logcat.033，…，一直到logcat.001，logcat这些文件中指定进程id的日志捞出来。、grep命令的话无法保证所有的输出是严格按照时间顺序的。在做OpenXR Runtime的过程中，打算把Runtime apk直接预置到/system/app分区下，主要是因为Runtime Apk本身算的上是一个“系统应用”，直接预置是一个比较方便的做法。
OpenXR Runtime的机制，实际是一个dlopen的过程，根据之前的经验和认知，整个OpenXR App实际是一个链式调用的过程。
因此，Application实际是通过集成的libopenxr_loader.so去发现系统中的libopenxr_runtime.so，然后通过dlopen的方式把Runtime加载到Application进程中。
OpenXR中的手势一共分为两种，一种是手势tracking相关的，一种是手势动作识别相关的。
其中手势Extension相关一共有以下几种：
我们先从spec的定义上来拆解一下openxr下的hand tracking。
github地址：https://github.com/google/mediapipe
python环境，推荐使用anaconda，注意下载linux版本的
bazel工具：
以上工具的安装强烈建议安装到一个指定的目录，这样后面构造环境变量PATH和Android SDK Home以及Android NDK Home的时候也可以统一到一起。
OpenXR中的Extension有两种实现方式，第一种方式是直接以Hard Code方式直接写在Runtime中，第二种方式则是以Api layer的方式来“外挂实现”。这边主要介绍api layer的实现方式为主。
Khronos在介绍Api Layer的时候给出的例子有点过于具体了，以至于刚开始我也就认为Api layer是实现debug + validating。
Some examples of features that API layers may expose include:
- Validating API usage
- Adding the ability to perform API tracing and debugging
- Intercept and filter information between the application and the runtime
但实际上，在整个Api layer介绍的开头，Khronos已经是给出了一个定义：
API layers are optional components that augment the OpenXR system.
然后也给出了一个功能和架构的介绍：
They may intercept, evaluate, modify, and insert existing OpenXR commands on their way from the application down to the runtime.
最后是给出了一个实施的建议：
API layers are implemented as libraries that are enabled in a variety of ways (including by application request).
以上这一大段的内容出自：https://www.khronos.org/registry/OpenXR/specs/1.0/loader.html#openxr-api-layers
其实概括起来，api layer是作为Runtime的一个增强组件而存在，主要是以so库的形式给openxr command提供一些额外的能力，这些能力可以是debug信息，validating，甚至是hook。有了以上的认知，我们再来看整个api layer中的call flow，感觉就会好一些：
在OpenXR的应用开发中，开发者唯一可以接触到的部分就是loader，根据OpenXR Loader的定义图:
Loader其实是一个承上启下的模块，对下它需要负责去加载Runtime，对上它需要给应用开发者提供openxr.h的具体实现。
api layer的部分在这里不做展开
HelloXR的源码部分还是比较干净的，其中会联动编译openxr loader，因此在学习上价值很大。
代码地址：https://github.com/KhronosGroup/OpenXR-SDK-Source/tree/main/src/tests/hello_xr
Khronos在loader的spec中也一并给出了Loader的架构设计：https://www.khronos.org/registry/OpenXR/specs/1.0/loader.html#loader-design
先前在《Monado Out of Process流程分析》一文中有提到了XrSession的部分，只是简单描述了一下整个XrSession的创建流程，对于OpenXR来说，XrSession是类似于Android中Activity的存在，是一个比较重要的概念，因此打算特别写一篇文档来讲述一下XrSession的几个状态流转过程和对应的具体场景。
在OpenXR的spec中，XrSession是有定义的：
A session represents an application’s intention to display XR content to the user.
需要速成的可以直接到最后看时序图《Flow Chart》
由于OpenXR的runtime存在in process和out of process两种模式，逆向了oculus quest2的工程以后发现竞品是out of process的方案，然后很多小伙伴都问到了同一个问题，Composite的部分是在哪里做的，所以带着这两个问题来系统学习了一下。
这篇内容是一个代码学习笔记，内容比较长，细节部分从源起编译开始，摘录主要的结论如下：
