自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数HarmonyOS鸿蒙开发工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年HarmonyOS鸿蒙开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上HarmonyOS鸿蒙开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注鸿蒙获取)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
在MVC架构中,Controller是业务的主要承载者,几乎所有的业务逻辑都在Controller中进行编写。而View主要负责UI逻辑,而Model是数据逻辑,彼此分工。
MVC的本质就是按照UI、业务、数据不同的职责分三大模块,彼此分工。
但是一般的开发中
- 几乎所有的业务逻辑代码都在controller中进行,会导致非常臃肿,降低项目的可测试性与可维护性。
- view直接持有controller和model实例,不同职责的代码进行耦合,导致代码耦合性高,模块分工不清晰。
MVC好处:简单。他不需要写很多的代码来让代码解耦,这在在初创公司的小型项目非常有用。小型项目总体的代码量级小,可以提高开发效率
MVP
MVP全名是Model-View-Presenter。图解如下:
- View:UI模块,负责界面显示和与用户交汇。
- Presenter:负责业务逻辑,起着连接View和Model桥梁的作用。
- Model:专注于数据逻辑。
MVP和MVC的区别很明显就在这个Presenter中。为了解决MVC中代码的耦合严重性,把业务逻辑都抽离到了Presenter中。这样View和Model完全被隔离,实现了单向依赖,大大减少了耦合度。view和prensenter之间通过接口来通信。
不同的view可以通过实现相同的接口来共享prensenter。presenter也可以通过实现接口来实现动态更换逻辑。Model是完全独立开发的,向外暴露的方法参数中含有callBack参数,可以直接调用callBack进行回调。
- MVP通过模块职责分工,抽离业务逻辑,降低代码的耦合性
- 实现模块间的单向依赖,代码思路清晰,提高可维护性
- 模块间通过接口进行通信,降低了模块间的耦合度,可以实现不同模块独立开发或动态更换
MVP的最大特点就是接口通信,接口的作用是为了实现模块间的独立开发。presenter的作用就是接受view的请求,然后再model中获取数据后调用view的方法进行展示,因为每个界面都是不同的,这就导致了每个Activity/Fragment都必须写一个IView接口,然后还需要再写个IPresenter接口,从而产生了非常多的接口,需要编写大量的代码来进行解耦。 其次,prensenter并没有真正解耦,他还需要调用view的接口进行UI操作,解耦没有彻底。
因此,MVP缺点有:
- 过度设计导致接口过多造成了接口地狱的问题,编写大量的代码来实现模块解耦,降低了开发效率
- 并没有彻底进行解耦,prensenter需要同时处理UI逻辑和业务逻辑,presenter臃肿
MVVM
终于到了MVVM,可能很多人都感觉“卧槽这么牛逼的架构我肯定学不会”然后被劝退了继续使用MVC或者MVP。在我看来,MVVM和上面两种架构模式一样都是一种架构思想,只是谷歌推出了jetpack架构组件来让我们更好的使用这种架构模式。
MVVM,全名为Model-View-ViewModel。图解:
- View:和前面的MVP、MVC中的View一样,负责UI界面的显示以及与用户的交汇。
- Model:同样是负责网络数据获取或者本地数据库数据获取。
- ViewModel:负责存储view的数据映像以及业务逻辑。
MVVM的view和model和前面的两种架构模式是差不多的,重点在ViewModel。viewModel通过将数据和view进行绑定,修改数据会直接反映到view上,通过数据驱动型思想,彻底把MVP中的Presenter的UI操作逻辑给去掉了。而viewModel是绑定于单独的view的,也就不需要进行编写接口了。但viewModel中依旧有很多的业务逻辑,但是因为把view和数据进行绑定,这样可以让view和业务彻底的解耦了。view可以专注于UI操作,而viewModel可以专注于业务操作。因而:
- MVVM通过数据驱动型思想,彻底把业务和UI逻辑进行解耦,各模块分工职责明确。
View只需要关注Viewmodel的数据部分,而无需知道数据是怎么来的;而ViewModel只需要关注数据逻辑,而不需要知道UI是如何实现的。View可以随意更换UI实现,但ViewModel却完全不需要改变。
但依旧存在的问题是:viewModel会依旧很臃肿;上手也有一定的难度。
- MVVM的viewModel依旧很臃肿。
- MVVM需要学习数据绑定框架,具有一定的上手难度。
为了解决上面两个问题,google推出了上手难度相对较低的mvvm+Jetpack框架
做个简单的解析:
- View对应的就是Activity和Fragment,在这里进行UI操作。
- ViewModel中包含了LiveData,这是一种可观察数据类型框架。View通过向LIveData注册观察者,当LiveData发生改变时,就会直接调用观察者的逻辑把数据更新到view上。
- ViewModel完全不需要关心UI操作,只需要专注于数据与业务操作。
- Repository代表了Model层,Repository对ViewModel进行了减压,把业务操作般到了Repository中,避免了viewModel臃肿。
- Repository对请求进行判断是要到本地数据库获取还是网络请求获取分别调用不同的模块。
jetpack的架构组件库是一整套完整的架构组件库,包括了:DataBinding,LiveData,ViewModel,Navigation,Lifecycle。下面我们简单了解一下每个组件的功能: 访问基于 activity 构建的可组合 API。
是网络请求获取分别调用不同的模块。
jetpack的架构组件库是一整套完整的架构组件库,包括了:DataBinding,LiveData,ViewModel,Navigation,Lifecycle。下面我们简单了解一下每个组件的功能: 访问基于 activity 构建的可组合 API。