那么上面的按钮、其它元素如何去做呢？
理想的方案：由地图单纯的提供地图以及地图上的标注元素，上面的元素仍然由Unity 侧进行绘制。这样只需要将地图的显示插入到 Unity 的层级中。可以看一下Unity 的原理。
Android 侧由于 Activity 加载的是 UnityPlayer，这里可以看一下 UnityPlayer 的代码：
private SurfaceView n;
public class UnityPlayer extends FrameLayout implements
com.unity3d.player.a.aaa {
public UnityPlayer(final ContextWrapper m) {
super((Context) m);
this.n = new SurfaceView((Context) m);
this.n.getHolder().addcallback((SurfaceHolder.Callback) new SurfaceHolder.Callback() {
public final void surfaceCreated{
//缺省**************************
}
public final void surfaceChanged{
//缺省**************************
}
public final void surfaceDestroyed（final SurfaceHolder surfaceHolder) {
//缺省**************************
}
});
this.n.setFocusable(true);
this.n.setFocusableInTouchMode(true);
//缺省**************************
}
}
其实内部的 Unity 在渲染原理上是一个 SurfaceView 。比较容易理解，由于地图渲染使用的是普通的 sdk，和view层级不在一个级别，而且要将原生的 View 放到 SurfaceView 下面进行展示，也是做不到的，起初有一个很好的比喻可以解释，SurfaceView 会将屏幕扣出一个洞，然后进行绘制，因此只要这块区域通过SurfaceView 进行了绘制，普通View就没办法进行渲染了。
如果是 SurfaceView，基于 OPenGl 渲染的 3D 地图 sdk 就成了可选方案，但需要解决如何将 Unity 和 Native 两层渲染打通，这里会涉及到大量的改动以及接口封装，考虑到方案调研和研发的时间成本以及包大小的控制，前期不必在这个方案上做深究。可以得出如下结论：
如果上次使用原生的 View 进行地图渲染，那么在此地图上的所有 UI 元素，都必须使用原生 View 进行绘制。
2.2.3 第三阶段 技术设计原则确认了上层都使用了端上的原生 View 进行绘制，那么这次的需求就不再只是地图的能力支持了。而需要考虑到业务逻辑的变化性，将王者层和地图平台层进行明确划分：地图平台团队负责 UI 渲染部分，王者团队负责具体的产品交互和业务逻辑，阿波罗团队负责 Native 和 Unity 之间的桥接中转。
这样，就存在了 Unity 调用原生 Android/ios 以及 Native 调用 Unity 的一系列调用。阿波罗团队将会承担中间的通道中大量的中转任务。中转过程中，涉及大量的数据结构。一旦结构发生变化，就需要 Unity 以及原生的 Android 和 ios 平台进行数据格式的调整。
为了降低维护三个平台数据结构的复杂度，同事们提出引入 JCE 作为 Unity 和Android/ios 的数据结构头文件。结合公司内部的JCE语法和编译平台，就可以做到维护一份标记语言。
加入 JCE 后，就可以彻底把阿波罗团队解放出来，使其更专注于数据通道的实现，改变后的三层结构是这样的：
讨论完可行性和数据交互协议以后，团队一开始就是准备上层按照王者的具体需求去实现 UI 展示效果，然后数据由王者来填充。
这个阶段时间不长，王者团队又提出：能否定制一些按钮的显示位置，文字大小等。毕竟很多时候需求会有变化，这就涉及到一个思考：
为什么要定制 UI？为什么不做一套通用的UI框架来实现王者的需求？
开始这样思考的时候，已经按照之前的计划排期了。整体的研发为三周时间，第一周完成首页面的开发，后面两周都做联调。做整体架构和具体实现也就只有一周时间。
我仍记得这个场景：当时我们团队几个人到了会议室，已是某个周五下午的5点多，整个会议室充斥着沿这个思路去策划方案的兴奋！没有理由不去做。
我和同事放下「狠话」说：“做不出来，晚上不回去！”结果，我们奋战到第二天日出。
为了纪念那个周五晚上，我们把这个方案名叫做 Friday。
03
项目架构设计
由于目标从实现具体的页面，转向实现一套跨平台的 UI 框架，那么就需要考虑这套 UI 框架如何去定义、去创建。
3.1 整体架构整体架构和最初的思路没有太大出入，地图团队提供一套完整的 native UI 框架以及实际的渲染方案，王者团队负责业务逻辑以及绘制逻辑，而作为通道的阿波罗团队负责数据中转。
