最近一个多月，没写博客，主要是因为公司最近的需求比较勤，在加上有点业余时间，自己去看Kotlin和React了。这几天有人跟我说mvp这个架构不会用，甚至看不太懂，即使网上有很多介绍，博客，也看不透。这些人大部分是工作了2年左右时间，大家感觉自己的技术还是不行，在公司看些老代码，改改bug，技术没有啥提升。听到这些，我最近有了些思考。于是写写，与大家共勉！
先说下mvc，从android一开始，我们新建一个工程时，它就是一个mvc，然后我们会根据不同的业务，不同的功能，新建不同的package。这样写没啥毛病。但是在写代码的时候，毛病就来了。比如对Recyclerview泛型构建基类、封装不理解，或者不会。甚至一个一个去写Adapter，碰到多种不同Type的布局，然后一个一个去写，判断不同的Type。在比如对网络层的封装，压根不利于扩展，封装网络层喜欢放到一个工具类里面，当做一个工具类来看。这种代码很多人写过，我当初也写过。但是我现在看来，这种写法比较low，比如要增加一个下载的功能，或者要更换一个网络库，是不是要动以前的代码，甚至要动很多。举了两个简单例子，我相信很多人都碰到过、写过，我当初写过这种代码。为什么会这样，因为很多中小公司，android开发人员1-3个人，就别谈代码ReView了，有个技术总监对Android有深入的学习，有经验还好些，旁边有人带你，会好很多。但是也有很多技术总监是不会android的。现在想想，以上两个例子的代码维护起来，看起来，或者离职了，留给别人看，不都是一个个“坑”。像这种类型的代码还有很多例子，时间久了，app的业务量多了，代码还怎么写下去，维护下去？是否可以考虑下重构下别人写的代码，或者一些基类可以自己写，多考虑下代码如何扩展？如何封装？是否可以采用设计模式？如果碰到代码风格乱来，只能欲哭无泪了!
在说下Android的mvp架构设计，我们都知道mvp架构设计，是为了解决mvc的痛点，随着业务增加，Activity会有很多的代码，会很臃肿，与后台的交互会越来越多，与Model层的耦合性很高，更加不利于单元测试。于是有人提出了mvp的架构设计，mvp中的Presenter就解决了这个问题，与后台的交互，业务的处理交给Presenter，Activity显示下数据就行，Activity和Model层没有了直接的联系。利于维护，也利于单元测试。但是在设计mvp时，会有很多问题，一、Activity需要实现View层的接口，Presenter对这个又要持有引用（是为了解决View层中的接口回调出来，显示数据）。如果Activity退出了怎么办，Presenter对这个Activity持有引用，会不会造成内存泄漏呢？二、多个Presenter怎么解决？因为一个Activity可能会涉及到多个业务逻辑处理。三、mvp中会很多的类接口，怎么处理？ 以上几个问题，我之前的博客有介绍，具体的怎么解决，我在这不阐述，因为涉及到的知识点比较多！
说了下mvc和mvp，是不是该说下mvvm呢，mvvm对于mvp来说，是为了解决mvp的痛点，p层去回调v层的接口，一是接口类多，二是生命周期难以控制。于是Google出了DataBinding绑定数据，在也不需要那么多的类接口了。Android Jetpack架构组件又有了LiveData和ViewModel，简单介绍下LiveData和ViewModel，LiveData是一个可被观察的数据持有者类。与常规的Observable不同，LiveData能意识到应用程序组件的生命周期变化， 这意味着它能遵守Activity、Fragment等组件的生命周期。这种意识确保LiveData只更新处于活跃状态的应用程序组件Observer。ViewModel从字面上理解的话，我们也能想到它肯定是跟视图(View)以及数据(Model)相关的。 正像它字面意思一样，它是负责准备和管理和UI组件(Fragment/Activity)相关的数据类，也就是说ViewModel是用来管理UI相关的数据的。同时ViewModel还可以用来负责UI组件间的通信。看了介绍，想想看，这不是基于观察者设计模式设计的嘛，dataBinding、LiveData和ViewModel 这三者是不是解决了mvp的痛点呢！至于LiveData和ViewModel会用很多种用法，比如用LiveData替换RxJava2中的Observable，用LiveData支持Room，如果我们项目中用到了对数据库的操作，是不是该换Room了，Room使用起来很简单，我们只关心接口Dao层和如何创建数据库，利于维护和扩展。Android Jetpack新一代架构组件，反正很好用，大家多看看，多运用。都是Google Android工程师写的，这么好的代码不看，还看什么代码？
mvc、mvp、mvvm三者如何选型呢？这三者没有那个不好，只不过是随着业务的增加，某架构设计缺点突出来了。如果一些工具类、针对部分用户群少或者app的业务量少。这些类型的app完全可以用mvc。如果后台与业务逻辑交互比较多，app更新比较频繁，那就得考虑用mvp了，比如电商类型的app。至于mvvm呢，列表展示数据比较多，比如新闻媒体类型的app。
总结下，上面描述了一些问题，主要是为了总结和我的一些思考，很多人对泛型看不懂、不理解，泛型不会灵活运用。编译时注解和运行时注解不会，反射用的少。比如常用的设计模式，观察者设计模式、适配器设计模式、静态和动态代理设计模式等等，这些设计模式能看懂简单的例子，但是不太会用到项目中。接口不会灵活运用。常用数据结构看不懂，不会，比如栈、堆、链表、队列。多线程不太理解。列举的这些知识点，其实每个app都会用到，我们每天敲代码，也会碰到和运用。如果这些不会，大家赶快去补补基础的知识，在看看别人优秀的app，优秀成型的架构，看看别人怎么设计的。看懂了，然后自己敲敲代码，自己多多体会。写一些开源的东西，然后自己维护，不单单要运用到公司的app中。知识点运用起来，才会对知识点有更深的理解。学的东西，一定要多运用！
谷歌官方架构组件的sample，现在谷歌官方的simple，很多都是用Kotlin写的，正好学习下Kotlin。看看Google工程师写的代码、设计思路，还有代码风格，一个项目经过不同的人开发，有的人代码风格low，命名乱来，没有统一的规范，我认为程序员代码要有自己的风格，形成敲代码的一种习惯。
https://github.com/googlesamples/android-architecture-components
这小子（辉哥）写的博客，讲的视频不错，android整个知识体系都有，而且思路很清晰，讲解的视频基本上都是项目上运用到的。ndk、数据结构都有讲。我从17年下半年和18年上半年他讲的视频，我几乎每集都看了，很不错的！
https://www.jianshu.com/u/35083fcb7747
在推荐我经常看的博客JessYan和Tamic，列出了简书的，人家还有掘金、公众号，大家感兴趣，可以关注！
https://www.jianshu.com/u/1d0c0bc634db
https://www.jianshu.com/u/3bbb1ddf4fd5
以上那里有说的不对，哪里总结的不对，欢迎大家指出来，互相交流切磋武艺，大家都在江湖漂~
网友评论