接下来轮到了专业知识---》android知识--》通用的知识
导航相关的知识整理开始了，应该是要一个星期差不多的。每天加一点
百度地图，高德地图，百度地图相关的虽然比较全面，每个模块都有了解，毕竟自己带了多个相关项目，但目前市面上应该不需要百度地图的定制开发了，所以很可惜，跳过
高德地图，由于高德是sdk开发模式，比较纯碎，基于sdk的HMI定制开发。所以没有比较深的难点，但可以从开发效率，app性能，app稳定性 三个方面来评价自己的app是否优秀（目前对比高德公版app）。然后是具体的专业知识相关的总结，我这边主要是引导，巡航，主页，以及提供第三方接口。
先说开发效率，我接触了好几种代码结构（框架），接下来我会对比他们，以及我自己弄的代码结构，累了，歇一歇。
文章来源地址https://www.toymoban.com/news/detail-790754.html
一：看下高德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，逻辑根本不用动。
好了，代码结构就分析到这里，没想到提出离职到走人这么快，意想不到
明天还要继续，继续分析模块内部的代码结构，一层一层的来，但愿时间充足
文章来源：https://www.toymoban.com/news/detail-790754.html
到了这里，关于导航相关知识梳理的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
