导航相关知识梳理

接下来轮到了专业知识---》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,逻辑根本不用动。
好了,代码结构就分析到这里,没想到提出离职到走人这么快,意想不到

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

 

 

你可能感兴趣的:(常用知识点分类汇总,android)