导航相关知识梳理

接下来轮到了专业知识---》android知识--》通用的知识

导航相关的知识整理开始了，应该是要一个星期差不多的。每天加一点

百度地图，高德地图，百度地图相关的虽然比较全面，每个模块都有了解，毕竟自己带了多个相关项目，但目前市面上应该不需要百度地图的定制开发了，所以很可惜，跳过

高德地图，由于高德是sdk开发模式，比较纯碎，基于sdk的HMI定制开发。所以没有比较深的难点，但可以从开发效率，app性能，app稳定性 三个方面来评价自己的app是否优秀（目前对比高德公版app）。然后是具体的专业知识相关的总结，我这边主要是引导，巡航，主页，以及提供第三方接口。

先说开发效率，我接触了好几种代码结构（框架），接下来我会对比他们，以及我自己弄的代码结构，累了，歇一歇。

 

一：看下高德sdk demo 的代码结构：
autoui 对view的封装                 依赖 无
basemap 对 主页view的封装   依赖common + business
bussness 对sdk 接口的封装     依赖 autoui
common 对 mvp结构的封装    依赖 autoui
driver 实现mvp及对view封装   依赖common + business
search 实现mvp及对view封装  依赖common + business
user 用户中心                               依赖common + business
app 启动激活 依赖所有

二：再看下我们的项目:
autoui 对view的封装                依赖 bussness
basemap 对 主页view的封装  依赖 driver
bussness 对sdk 接口的封装   依赖 无
common 对 mvp结构的封装    依赖 autoui
driver 实现mvp及对view封装   依赖 search
search 实现mvp及对view封装 依赖 naviinteface
naviinteface通过aidl对外接口  依赖 common
app 启动激活+用户中心             依赖 basemap

一目了然，我们的开发人员没有意识到分层的概念，为了项目中的具体问题，随意改动了依赖关系
其实高德原来的demo有明显的分层的概念：

底层是 common + business 上层是 driver，search，user等功能模块。
每层模块之间是独立的，且下层模块是不能依赖上层模块。

我也是中途接手引导模块，一直也没等到自己负责新项目的机会，有点遗憾。

我们的另一个项目对代码依赖有了改观

hmi ：对ui逻辑处理

core ： 对高德sdk的封装

把 bussniss层下移到一个独立app里面，并将各个模块的服务类也放到了bussniss里面
把hmi相关的放到另一个app里面，APP之间通过aidl进行交互。

这样物理上将两层进行分割开，这样的目的主要是为了兼容不同的引擎，到时候只需切换core app 就能实现百度，高德，腾讯的切换，不过这种想法很傻叉，没有厂商愿意支付多个导航APP的钱，但代码结构得到了改善。

我但从代码结构上看
比之前的项目是不是好了很多。代价是性能降低。分层还是分app？（但各个app内部模块还是一团），其实还是要跟每个开发人员讲清楚里面的分层理念（强制要求：不要改动依赖项），分APP 更耗人力，更费性能，但对开发人员要求降低了。

但这些都没有 解决view的混乱，以往出问题70%的地方都出在view里面，这里经常改动，经常变更，我只改造了引导 + 主页 两个模块，因为我负责这两个模块（项目很少了，只有一个项目了，只能大家分着搞，
以前我一个人都搞一两个项目，有什么想法都能自己改造，现在只能自己模块搞搞，其他项目都是换UI，是的，部门快黄了）。
引导和主页中的控件全都是自定义控件，根据lifecycle监听生命周期，根据eventbus（我们消息分发用的是eventbus，我更愿意lister）监听各自想要的底层事件。
自己控制自己的显示隐藏，数据更新等。我改动后感觉很好用，而且更换UI的时候，只需调整各个自定义view自己的xml，逻辑根本不用动。
好了，代码结构就分析到这里，没想到提出离职到走人这么快，意想不到

明天还要继续，继续分析模块内部的代码结构，一层一层的来，但愿时间充足