（一）数据库
1、设计相关
数据库使用的是什么？
MySQL 5.7以及搭配了Navicat for mysql5.7数据库管理工具。
你数据库中使用了几个表?怎么设计的？
总共有三个表，分别是扫描区域划分类目表（scan_info）、位置信息详情表（location_info）和人员信息表（person_info）。具体来说在scan_info表中有scan_id作为这个二维码的唯一标识，scan_name作为这个表的区域名称，scan_type作为这个区域的唯一标识编号，以及这个二维码区域信息的创建时间和更新时间。然后在位置信息详情表中有location_id表示位置ID，location_name来表示这个位置的名称。然后分别使用经度、纬度、高度来唯一确定该位置的存在。使用location_description来对该位置进行描述。使用了location_picture来显示二维图像，然后又新增了全景外链，在改位置的人员，和这个位置的更新时间和创建时间，利用时间戳实现，该表唯一标识是location_id。然后是人员信息表，表示某地点的人员信息（id作为唯一标识，该位置的人员，姓名等信息）
create table `scan_info`(
`scan_id` int not null auto_increment,
`scan_name` varchar(64) not null comment '区域名称',
`scan_type` int not null comment '类目编号',
`create_time` timestamp not null default current_timestamp comment '创建时间',
`update_time` timestamp not null default current_timestamp on update current_timestamp comment '修改时间',
primary key(`scan_id`),
unique key `uqe_scan_type` (`scan_type`)
)comment '扫描区域划分类目表';
create table `location_info`(
`location_id` varchar(32) not null comment '位置ID',
`location_name` varchar(64) not null comment '位置名称',
`location_latitude` decimal(8) not null comment '经度',
`location_longitude` decimal(8) not null comment '纬度',
`location_altitude` decimal(8) not null comment '高度',
`location_description` varchar(512) comment '位置描述',
`location_picture` varchar(512) comment '位置二维图像',
`panoramic_link` varchar(512) comment '全景外链',
`scan_type` int not null comment '类目编号',
`person_type` int not null comment '该位置的人员',
`create_time` timestamp not null default current_timestamp comment '创建时间',
`update_time` timestamp not null default current_timestamp on update current_timestamp comment '修改时间',
primary key(`location_id`),
unique key `uqe_person_type` (`person_type`),
foreign key (`scan_type`) references `scan_info`(`scan_type`) on delete cascade on update cascade
)comment '位置信息详情表';
create table `person_info`(
`person_id` varchar(32) not null comment '人员ID',
`person_type` int not null comment '该位置的人员',
`person_name` varchar(32) not null comment '姓名',
`person_age` tinyint(3) comment '年龄',
`person_sex` char(2) comment '性别',
`person_responsibility` varchar(32) comment '职责',
`person_phone` varchar(32) comment '联系方式',
`create_time` timestamp not null default current_timestamp comment '创建时间',
`update_time` timestamp not null default current_timestamp on update current_timestamp comment '修改时间',
primary key(`person_id`),
foreign key (`person_type`) references `location_info`(`person_type`) on delete cascade on update cascade
)comment '人员信息表';
为什么要这样设计，设计的初衷是什么？
因为当时的需求大概是这样的，用户扫描二维码，系统需要听过用户扫描的二维码信息来确定用户所在的区域，这就有了扫描区域划分类目表，然后在这个区域内查找一些店铺、景点之类的建筑物，而这个建筑物理论上是可以通过经度、纬度、高度来唯一确定的，并且希望的是通过AR的形式来显示建筑物的标签，用户可以通过点击标签来获取该位置的详细信息、VR全景等信息，这就需要位置信息详情表，而建筑物中一般来说会有人，这就需要人员信息表。当时的想法大致是这样的，主要是为了以后扩展方便，可以应用于旅游、房地产等产业。
2、关于mysql的一些基础知识点
索引相关的内容？
MySQL索引使用的数据结构主要有BTree索引和哈希索引。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录的时候，可以选择哈希索引，查询性能更快；其余大部分场景，建议选择BTree索引。
Mysql的BTree索引使用的是B树中的B+Tree，但对于主要的两种存储引擎的实现方式（MylSAM和InnoDB）是不同的。我是用的是InnoDB.
InnoDB:其数据文件本身就是索引文件。相比MylSAM,索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶结点data域保存了完整的数据记录。这个索引的Key是数据表的主键，因此InnoDB表数据文件本身就是主索引，被称为“聚簇索引”，而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址。在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂。
事务机制知识点?
关于幻读和可重复读的解释？
锁机制和InnoDB算法？
（二）服务端
1、后端框架设计
MVC设计模式？
日志的使用？
我使用的只要是logback,故仅简单介绍一下
Logback是log4j框架的作者开发的新一代日志框架，它效率更高、能够适应诸多的运行环境，同时天然支持SLF4J。
默认情况下，Spring Boot会用Logback来记录日志，并用INFO级别输出到控制台。在运行应用程序和其他例子时，你应该已经看到很多INFO级别的日志了。
logback有五种日志级别
- Trace级别最小，打印信息最为详细
- DEBUG
- INFO
- WARN
- ERROR级别最大，打印信息最为简略
SpringBoot框架简单介绍？
2、项目中出现的注解
3、项目结构图
4、数据封装逻辑实现
- API文档如下所示
//获取该区域的所有定位点以及相关信息
GET /ar/client/location/show
参数
scanType:1
返回
{
"code":0,
"msg":"success",
"data":{
"name": "黄河路",
"type": 1,
"locationList":[
{
"id":"123456",
"name":"丹尼斯",
"latitude":12.335,
"longitude":34.225,
"altitude":5.2,
"description":"一个购物的地方",
"icon":"http://www.dennis.com.cn/u/cms/www/201707/191157482x37.jpg",
"link":"http://122.114.223.188/toShow?VRourEditor=206",
"people":[
{
"name":"jack",
"responsibility":"doctor",
"phone":"13052312154"
},
{
"name":"evan",
"responsibility":"护士",
"phone":"13565667488"
}
]
},
{
"id":"123457",
"name":"微阿科技",
"latitude":44.123,
"longtitude":33.124,
"altitude":5.2,
"description":"公司",
"icon":"http://www.dennis.com.cn/u/cms/www/201707/191157482x37.jpg",
"link":"http://122.114.223.188/toShow?VRourEditor=206",
"people":[
{
"name":"linda",
"responsibility":"doctor",
"phone":"1325355555"
},
{
"name":"tim",
"responsibility":"护士",
"phone":"13561125488"
}
]
}
]
}
}
- 逻辑分析
1.接收APP端请求的参数，这里是scantype
2.查询所扫描的ID信息，返回Object
==3.=通过扫描的id所确定的scantype来查找所有的位置信息，返回一个链表=
4.通过查找的位置信息中的persontype查找所有人员信息，返回链表
由上述可以分析，返回的json数据应该是一个链表嵌套着另一个链表 - 数据拼装
1.遍历locationlist进行逐个赋值
2.遍历personlist进行逐个赋值
3.将personlist加入到locationlist中
4.将得到的locationlist加入到data中，然后返回data
（三）Android APP端
1、基本的设计思路是什么？
当时是想着用户可以打开App，然后通过扫描二维码，然后向后台发出请求，后台查询数据库相关数据，然后返回给APP端，APP端接收数据，将所获得的点以AR浮层的形式展现给用户。
2、Android基础
3、该程序需要获取哪些权限？
4、数据是怎么进行解析的
==专门写了一个封装工具类FAST.java,使用了阿里的fastjson插件，可以将json格式解析成类、链表等，调用相关接口实现。==用户扫码过后，系统返回json数据，新建一个请求队列RequestQueue，它可以缓存所有的http请求，然后按照一定的算法并发的发出这些请求，非常适合高并发，因此我们不必为每一次的请求都创建一个RequestQueue对象，仅需创建一个即可。然后将通过FAST.java解析过的(数据)类，怎么封装的就怎么解析，然后加入UI 线程返回到AR效果生成页面。
5、扫码功能是如何实现的？
使用了一个github上面的开源组件z-xing，该组件就是专门实现扫码功能的，识别速度很快，效率高，调用相关api即可实现扫码识别功能。
6、AR效果是怎么实现的？
先获取要在ar浮层上面画的点的经纬高度，然后通过算法将GPS座标转换成手机导航座标系，然后在AR浮层（以camera作为背景）上面将点画上去，然后显示，注意这个点是动态的，会根据该点在浮层上面的座标系而浮动。
7、如何实现将一个GPS座标转换为局部平面座标系的?
详参考：算法设计思路
（四）其它
1、项目中用到的方法/重要知识点详解
（五）参考文献
【1】并发编程面试必备：乐观锁与悲观锁
【2】幻读和不可重复读的区别
【3】Springboot日志系统logback使用