（一）數據庫
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使用