在unity工程下，建立文件夹“Plugins/Android/assets”，然后把需要的图片放在这个文件夹下，并取一个好用的名字

（”Logo.png”），这个名字在Android这边是需要用到的，unity的工作做完之后，在Android这边写代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

AssetManager asm = getAssets();

InputStream inputStream =null;

 try {

     inputStream = asm.open("Logo.png");

 }catch (IOException e) {
     // TODO Auto-generated catch block

    e.printStackTrace();
}

Drawable d =Drawable.createFromStream(inputStream,null);

Bitmap B = ((BitmapDrawable) d).getBitmap();

这样就完成了unity图片的读取与转化Bitmap。

首先看一个例子，新建一个Panel，在下面添加两个Button，分别命名为Button、Button2。

1、给Panel添加一个VerticalLayoutGroup组件，ChildForceExpand属性中勾上Width。

2、给Button、Button2添加LayoutElement组件，其中Button的FlexibleHeight设置为0.3，Button2的FlexibleHeight设置为0.1

3、将Panel的高度设置为100

这时我们发现，Button的高度是70，Button2的高度是30。奇怪，这个高度是怎么算出来的呢？

网上搜索一番，竟然很少有人讨论uGUI的AutoLayout，尤其是flexibleWidth/Height属性的意义，官方文档也语焉不详。这时只能放大招了，uGUI已经开源，索性把代码拉下来看看到底怎么实现的。下面是托管代码的地址：

https://bitbucket.org/Unity-Technologies/ui

uGUI的AutoLayout有三个核心接口，定义在ILayoutElement.cs文件中：

ILayoutElement

ILayoutController

ILayoutIgnorer

结构很清晰，由ILayoutElement提供布局信息，ILayoutController来控制布局，ILayoutIgnore提供给UI忽略AutoLayout的能力。

例子中使用的VerticalLayoutGroup继承自HorizontalOrVerticalLayoutGroup，这个类实现了布局的核心逻辑，代码量不多，我就直接贴上来了

其中SetChildrenAlongAxis方法清晰地阐释了minHeight,preferredHeight,flexibleHeight的涵义。

为了帮助理解，我们先定义几个概念。我们把当前UI所有同级并参与自动布局的组件的preferredHeight总和称为totalPreferredHeight，minHeight的总和称为totalMinHeight，父UI的真实高度称为realHeight。总结如下：

1、 minHeight

在自动布局中，此UI最小高度不会小于minHeight。这个参数定义了realHeight < totalMinHeight时，当前子UI的height为minHeight。

2、 preferredHeight

可以理解为，UI自身希望的高度。

当totalMinHeight < realHeight < totalPreferredHeight时，realHeight处于totalMinHeight和totalPreferredHeight之间一定百分比，把这个比例应用到每一个接受自动布局的子UI上，即是我们最终得到的效果

3、 flexibleHeight

当realHeight >
totalPreferredHeight时，父UI会剩下一部分高度。flexibleHeight就是告诉AutoLayout系统，应该怎么瓜分剩下的高度，使子UI填充满父UI。flexibleHeight默认是-1，不会进行扩充。当flexibleHeight

0时，flexibleHeight值作为权重来计算当前子UI最终的高度，公式如下：

height = preferredHeight + (flexibleHeight / totalFlexibleHeight) * (realHeight - totalPreferredHeight)

flexibleHeight示意图

弄清楚这些概念后，我们再看一下文章开头的例子。

button1的flexibleHeight=0.3，button2的flexibleHeight=0.1，minHeight和preferredHeight都没有设置，按道理高度应该分别是75、25。为什么会出现70、30？

查一下ILayoutElement的实现类

ILayoutElement实现类

发现Image和Text实现了ILayoutElement，而我们的按钮中默认是有一个Image组件的，用脚本获取这个Image然后打印它的preferredHeight，发现等于10

再套用flexibleHeight的计算公式：

这里有个问题，一个GameObject上挂载两个ILayoutElement组件，是怎么决定用哪个的？这个可以在LayoutUtility.cs中找到答案：

原来LayoutElement有一个layoutPriority属性用来决定优先级，这个属性暂时还没有在编辑器中暴露，也许后续版本会加强这方面的能力。

AutoLayout系统会选用优先级最高的ILayoutElement里相应属性返回。Image和Text的优先级默认是0，LayoutElement默认优先级是1。所以正常情况会使用LayoutElement中的设置，但我们的例子中，LayoutElement没有设置preferredHeight，LayoutElement里布局相关的初始值都是-1，所以还是使用了Image的preferredHeight:10。

【结语】

其实，只要官方文档描述详细一些，根本没必要浪费时间去查这个来龙去脉。这几天在学习Swift，苹果人性化的Programming
Guide加上iBooks的配合，使得学习这门语言真是件轻松愉快的事情。相比之下，Unity简直是在虐待开发者。Unity、Unreal、Cryengine等最近也为争市场弄得头破血流，除了降价开源提供新特性之外，完善文档也是不容忽视的工作，毕竟开发者才是这些厂商真正的衣食父母。

语音识别对于VR领域格外重要，因为它不仅能模拟AI与用户对话，还为用户提供了与任意应用进行沟通的更多选择。
手动输入指令可能不太现实，并且应用如果拥有太多按钮或其它GUI元素，也会很快让用户手足无措。但只要能语音控制，那么在VR环境中就很容易开口去进行各种操作。

Unity
Labs的虚拟现实（VR）授权平台Carte
Blanche将发布一个名为U的个人助理系统，用户可以通过语音控制它，很便利地执行一些操作。Unity
Labs研发团队一直在研究可以实现这种声控命令的语音识别与分析工具。

观看下面的视频了解Carte Blanche中的个人助理系统U：

本文第一部分将介绍语音识别的概念和理论。它将简单介绍其相关概念和参考，以帮助读者了解更多关于语音识别方面的信息。第二部分将简单介绍在Unity Asset
Store的安装包以及公开的代码库，我们封装了几个语音转文本的解决方案，还有一些用于对比各API的文本翻译的示例场景。

如果想详细了解语音识别的概念和理论以及更多相关的研究，请进入Unity官方中文社区。下面简单为大家介绍语音识别与语义分析的原理，以及Unity
Labs为大家提供的语音识别插件。

语音识别与语义分析的原理

语音识别，顾名思义就是通过程序将语音转换成文本 。而 语义分析是其下一步，即将转换出来的文本进一步分析
，并确定文本想要表达的意思。即使是目前最好的语音识别和语义分析程序也远称不上完美。虽然人们能直截了当并毫不费力地处理这样的任务，但是当我们试图让程序去执行这两个步骤时，困难程度真的是难以想象。

目前基于统计学的语音识别最重要的部分就是声学建模（Acoustic
Modeling）。这个过程中用于识别声音开始时不同的波形，或者是语音结束时的一些音节。对于声学模型而言，通过查看声波输出，并尝试找出最可能输入的音节是什么，
从而分析出说话者究竟想表达什么。

如上图所示，这是声学模型中“x”的发音模型。椭圆表示我们正在尝试识别的音节。它们无法被直接观察到，但它们产生的概率波形（底部）是可以被完整观察到的。因此，波形自身是可以观察的，但必须及时从可观察的状态中分辨出音节。

假设语音已经被成功转换成了文本，现在程序需要分辨该文本究竟是什么“意思”，这时语义分析就可以登场了。人们日常生活中就无时不刻地在进行着语义分析。例如，在阅读这句话之前，你可能已经猜到接下来会是人们如何进行语义分析练习的例子。那是因为你能利用上一句（例如“人们日常生活中就无时不刻地在进行着语义分析”）作为上下文线索，从而很好地预测后续几句。因此，如果想要拥有非常逼真的VR体验，AI必须善于分析玩家的语句并给予正确的反馈。

语音转文本的工具

Labs最初研究的语音识别涉及了对现有语音转文本解决方案的评估。我们开发了整合部分解决方案的Unity C#脚本插件并分享在Unity Asset
Store。里面包含了示例场景，可以依次对比每个API转换的文本内容，同时允许用户从给定的列表中选定短语，并查看说出该短语后程序判定的准确程度。该代码也可以从Unity代码库中获得。

我们提供的插件是对比目前Unity中几大语音转文本解决方案的简便方法，也很容易将其整合至你的项目。如果想在Unity中尝试其他API，使用该插件也非常简单
，只需新建类继承自Speech-To-
Text的Service基类，然后即成到示例场景或小部件即可。除了单独的语音文本转换SDK，插件还包括多个辅助类与函数（记录管理器，音频文件的创建和转换等等），以便集成和比较更多的API。

各大语音文本都各有特色，如果有兴趣，可以查看关于 Windows dictation recognition, Google Cloud Speech,
IBM Watson, 以及Wit.ai 四种语音识别解决方案的具体信息。

总结与未来规划

语音识别很难精准的原因在于有太多的变量需要考虑。对于每一种要识别的语言都需要储存大量的数据，包括所有现存的单词（包括俚语及简写形式），这些单词相互如何结合，语调和口音也可能影响发音，所有人类语言的冗余和矛盾等等更多因素。

发布至Asset Store的自Speech-To-
Text插件目前仅集成了几个语音文本转换解决方案，但这些足以用来比较现有语音识别工具的优缺点了。对Unity开发者而言，该插件只是起点，还可以根据具体需求来加入更多功能。

_ _

SimSensei，一款由南加州（USC）学院创新研究部（ICT）开发出来的模拟治疗程序

这项研究源于Carte
Blanche项目最初集成AI机器人U来响应声控命令的计划。这涉及到语音文本的转换以及关键字识别。另一个有趣却艰难的挑战是创造出能与用户“对话”的机器人。人们在日常对话中经常包含类似于“嗯”或者是“啊”之类的语气词来表达感受。如果VR应用中的AI机器人不仅能够理解关键字，还能理解人类回话的各个部分，那它将让VR环境的沉浸感进入全新的层次。