『网易实习』周记(一)
『网易实习』周记(一)
来实习公司有一周多了，从熟悉工作环境到业务到参与项目这段时间，真的受益匪浅，get到很多新知识，也发现自己知识储备上的不足，特此开一个专题“实习随笔”来回顾每周的知识点和一些感悟，篇幅受限，只能简单记录，主要还是通过链接形式拓展和补充。本周知识清单：
-
git github命令行操作
-
MVP MVVM项目架构
-
插件化，组件化，模块化，热修复
-
网络IO
git github命令行操作
以前做项目托管代码时，选择的是Gitee开源平台，因为在AndroidStudio中有很好的集成了这一功能，只需要通过点击VCS选项卡下Git的几个命令即可，具体操作详见AS中Git与Gitee的使用入门所以并没有用过Git命令，但在公司发现大家更喜欢直接在AS终端下手写命令行，所以了解Git以及常用的几个指令还是很有必要的。
Git工作流程：
专业名词解释：
- Workspace：工作区
- Index / Stage：暂存区
- Repository：仓库区（或本地仓库）
- Remote：远程仓库
Workspace(工作区)：当前开发位置
git pull：从远程仓库拉取最新代码到工作区，相当于git fetch+git mergegit diff：查看修改但未暂存的文件
Index (暂存区)：
git add：工作区修改的内容提交到暂存区，交由Git管理git status：查看暂存区文件状态
Repository(本地仓库）
git commit：将暂存区的内容提交到本地仓库git clone或者git fetch：从远程仓库拷贝/拉取代码到本地仓库
Remote(远程仓库)
git push：将本地仓库的内容提交到远程仓库
b.常用Git指令:
分支git branch，关于Git分支那点事儿 以及实战
- master(主分支)：用于正式发布
- develop(开发分支)：用于日常开发。注意新的分支应基于develop分支，而不是master分支。
- release(预发布分布)：用于预发布测试
- hotfix(维护分支)：用于线上版本bug修复
参考链接：
- 一篇文章，教你学会Git
- 菜鸟教程-git
MVP MVVM项目架构
随着项目越来越复杂，为了减轻MVC模式里Activity过于臃肿，现在企业项目多应用MVP和MVVM模式。下图是MVC → MVP → MVVM的演进过程。
a.MVP模式
(1)含义：
- Model：数据层，负责存储、检索、操纵数据。
- View：UI层，显示数据，并向Presenter报告用户行为。
- Presenter：作为View与Model交互的中间纽带，从Model拿数据，应用到UI层，管理UI的状态，响应用户的行为。
(2)相比于MVC的优势：
- 分离了视图逻辑和业务逻辑，降低了耦合。
- Activity只处理生命周期的任务，代码变得更加简洁。
- 视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去，提高代码的可阅读性。
- Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单元测试。
- 把业务逻辑抽到Presenter中去，避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM。
(3)理解MVP必不可少要对官方Google给出的的todo-mvp示例进行学习，推荐阅读从google todo-mvp示例再次学习MVP。
(4)使用MVP最简单一个应用方法：
- 定义相应Model等数据类；
- 定义IPresenter接口，包含有关控制的抽象方法，注意为了避免由于持有view而引起的内存泄露，要有
release()方法去释放view； - 定义IView接口，包含和UI变化相关的一些抽象方法；
- 实现IPresenter接口，重写抽象方法，并包含一个对IView实现对象的引用；
- 在Activity里的
onCreate()中使用方法initView()绑定UI、initData()获取并显示初始数据，并实现IView接口，重写抽象方法。
应用实例：最适合android的MVP模式
b.MVVM模式
MVVM的目标和思想与MVP类似，利用数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一个更加灵活高效的架构。
Android搭建MVVM架构得依赖于Jetpack三个组件： DataBinding，ViewModel，LiveData
- DataBinding
DataBinding最厉害的功能是可以将我们的数据和view绑定。DataBinding可以将数据和xml绑定。而且还支持双向绑定：意思你改了bean里的数据，他会自动改变view里显示的数据。你改了xml里的数据，如editText里的数据，他会自动改变bean里的数据。推荐阅读 - **ViewModel
**ViewModel类旨在以注重生命周期的方式存储和管理界面相关的数据。ViewModel 类让数据可在发生屏幕旋转等配置更改后继续留存。推荐阅读 - **LiveData
**LiveData 是一种可观察的数据存储器类。与常规的可观察类不同，LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 Activity、Fragment 或 Service）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。LiveData 允许界面控制器观察者订阅更新。当 LiveData 对象存储的数据发生更改时，界面会自动更新以做出响应。推荐阅读
在常规的开发模式中，数据变化需要更新UI的时候，需要先获取UI控件的引用，然后再更新UI，获取用户的输入和操作也需要通过UI控件的引用，但在MVVM中，这些都是通过数据驱动来自动完成的，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据，不需要直接和UI打交道，在业务处理过程中简单方便很多。
推荐阅读：
如何构建Android MVVM应用程序
Android从零开始搭建MVVM架构
一道面试题：介绍一下 LiveData 的 postValue ？
插件化，组件化，模块化，热修复
组件化与模块化
模块化
模块化就是把一个功能完整的APP或者模块拆分成多个子模块，每个子模块可以独立编译和运行，也可以任意组成新的APP模块，模块指的是独立的业务模块，组件指的是单一的功能组件。如视频组件、支付组件。每个组件都可以以一个单独的module开发，并且可以单独抽取出来作为SDK对外发布使用。Android Studio出来了，多出来了一个新的概念， Project, Module… 模块；当时以包的形式分离的公共包common,现在成了AS中的Module。大家都知道，Module包含两种格式: application， library。也就是说，一个Module就是一个小的项目，也是AS概念中的模块。因此我们开始设计common模块， common_business模块，甚至db模块。模块的好处是什么？相比于包来讲，模块更灵活，耦合更低，随意插拔，想引入哪个就引入哪个。根据不同的关注点，将一个项目的可以共享的部分抽取出来，形成独立的Module，就是模块化。
当然，模块化不只包含公共部分，当然也可以是业务模块。
组件化
组件化和模块化有什么区别？其实这两个区别很小。组件化就是模块化的一个变种，组件化本来就是模块化的概念，组件化的核心就是 模块的可转换性
组件化的核心是角色转换。在打包时是library ；在调试时，是application
Module的模式分两种， application和library
library就是引用库，如你抽取的common。 而application就是一个apk， 是一个完整的项目。
推荐阅读：
Android Library和Android APP、Java Library的区别
Android工程师，不理解模块化、组件化、插件化的区别怎么行？
下面是真实项目架构图，可以对比看一下
插件化
什么是插件化 一个应用有10个功能模块，应用在打包时并10个功能模块并没有全部参与打包，apk中只有5个模块，另外5个模块放到网络上适时下载，在需要的时候动态加载，使apk获取打包时不存在的另外5个模块。
插件化和组件化又有什么区别呢？插件化严格意义来讲，其实也算是模块化的观念。将一个完整的工程，按业务划分为不同的插件，都是分治法的一种体现。化整为零，相互配合。越小的模块越容易维护。
组件化的单位是组件（module）。
插件化的单位是apk(一个完整的应用)。
组件化实现的是解耦与加快编译， 隔离不需要关注的部分。
插件化实现的也是解耦与加快编译，同时实现热插拔也就是热更新。
组件化的灵活性在于按加载时机切换，分离出独立的业务组件，比如微信的朋友圈
插件化的灵活性在于是加载apk, 完全可以动态下载，动态更新，比组件化更灵活。
组件化能做的只是， 朋友圈已经有了，我想单独调试，维护，和别人不耦合。但是和整个项目还是有关联的。
插件化可以说朋友圈就是一个app, 我需要整合了，把它整合进微信这个大的app里面
其实从框架名称就可以看出： 组 和 插。
组本来就是一个系统，你把微信分为朋友圈，聊天， 通讯录按意义上划为独立模块，但并不是真正意义上的独立模块。
插本来就是不同的apk， 你把微信的朋友圈，聊天，通讯录单独做一个完全独立的app, 需要微信的时候插在一起，就是一个大型的app了。
插件化的加载是动态的，这点很重要，也是灵活的根源。
插件化的原理推荐阅读：Android热修复，插件化理论与实战
热修复
专门用来修复bug的，假设同样的一个应用有10个功能模块，上线之后发现其中某个类出问题了。修复好bug之后，把修复的类打成补丁包，下发到应用，用修复类替换bug类，插件化与热修复的区别在于，插件化是新增功能，class的从无到有。热修复是原本有一个Class，但是这个Class出了问题，开发者需要更改class。热修复不能使用ClassLoader 新增类的方式解决问题，新增类之后，原有的bug类仍然存在，热修复不需要新增Class而是要对原有的类加载过程进行干预
插件化的原理推荐阅读：Android热修复，插件化理论与实战
网络IO
推荐阅读：一文搞懂，网络IO模型