为什么叫麻雀

麻雀虽小，五脏俱全。

其实本app并不叫做麻雀，只是本人认为它比较符合麻雀的特点：小而全。

小，即轻量级，一是指app只专注于实现常见app基础的逻辑业务功能，并没有在某个功能点或者UI上做更为细节的实现；二是指app使用了简洁的的Kotlin语言作为实现语言，使用了相对简单的一种MVP实现方式，使用了一种比较轻量级的组件化方案。

全，当然是相对的，一是指app的后端也是本人开发，这能让整个业务逻辑更为全面，也能让感兴趣读者能更为全面的了解此app；二是指app涉及了当前技术趋势下安卓开发的多个技术点，包括kotlin,mvp,组件化,rxjava,retrofit等；三是指本app实际上可以作为一个快速开发框架，这主要得益于组件化的实现，具体怎么使用，后续会提到。

此app名字不叫麻雀，而是叫做KtDevBox。

仓库地址：

App实现-KtDevBox

后端实现-KtDevBox-backend

为什么要写这个app

诚然，网上关于Kotlin，MVP，组件化的研究、分享已经有很多，但是多数博客仅仅是泛泛而谈，代码库没有提供不说，博客中的代码甚至都有问题，有些更是抄来抄去。虽然有些好资源的确有挺好的借鉴意义，比如KotlinMvp、Reading等【本文仅着眼于项目级别实现，一些好的library并不在此讨论中】，但以下几点还是让我觉得有些不足：

这些项目的接口，基本都是爬来的，大多数都是get方式实现，很难形成比较完整的一个功能逻辑，也很难从更全的角度去来展示某些技术点的实现；
Kotlin的使用，Java的味道较重，特别是网络请求的封装部分；
组件化几乎没有涉及，项目是个app，并不能方便的转为另一项目的实现框架；
文档等介绍略少

KtDevBox当然也存在的一些不足，但该项目的初衷，也仅做学习交流之用，以期对该方面技术的发展，起到一点点帮助。

为什么用Kotlin

仅说自己体会，至少有这几个原因吧：

语言切换，对老手真不是问题，况且kotlin与java的兼容性很好，所以学习成本不应作为不使用kotlin的理由；
真正摆脱了控件从布局到使用的查找问题，简洁明了；
函数地位的提升，带来的编程思想的改变，对开发者开发思维是有提升的，当然，代码的灵活、更好的扩展是可视的效果；
闭包、扩展函数、命名参数等语法糖带来的诸多便利。

为什么用MVP

有关MVP的讨论真是太多了，不过正如本人之前的博客提到，MVX不管怎么叫，核心在于分层，至于是C、P或是VM，要看项目自身情况来，甚至可以在同一项目中出现。本项目使用的是MVP的一种简化些的实现方式，至于好不好用，仁者见仁，这里只谈使用，不谈优劣，手动滑稽。再简略叨叨下MVP的发展吧，以表原因。

MVC中C重，于是功能转移，出现来了xxModel、xxLogic党，主要分担数据获取的职责；
C和xxModel的强依赖、空指针问题和内存泄露问题，促进了Presenter的出现，其主要处理业务逻辑，并绑定View的生命周期，面向接口，更为松耦合；此时C转为P。
完全面向接口之后，难以避免的V和P接口爆炸，也过于分散，出现了Contract，人工约束，首见于github上谷歌的MVP官方示例。

个人认为，M结构相对很稳定，View并无太大必要通过持有P的接口引用去使用P，再者通过Contract的维护并不能真正降低接口太多造成的注意力分散问题。本项目app的MVP实现较为简单些，也是一种比较常见的方式，具体可阅读项目代码。

为什么用组件化

组件化是近两年才较为突出的一种项目管理实现方案，本人认为其符合基本的分而治之的思想，是同MVX一样，应该出现在任何一个打算长期维护的项目中的技术方案。其实，不仅在安卓端，在ios端、前端(Vue)、后端(Java、Python)都有组件化的使用。至于什么是组件化，组件化有什么好处以及如何实现，我想网上有太多优秀博客和开源库提及，这里就不再赘述。

本app虽然小，但也涉及了组件化，选择的是一种很轻量级、侵入性小的方案--Appjoint，方案虽然轻量级，但是本人认为：组件化思维，入侵性小、能在最初的时候将业务进行组件化管理是组件化的核心，而这个库很好的符合了要求。

主要功能点

用户注册、登录以及资料管理功能；
博客创建、更新、删除和查看等功能；
博客的收藏、评论、点赞功能；
爬了网易新闻和一些电台的接口以展示，主要做组件化演示。

项目架构

项目核心架构如图所示：

项目中的shell只含有MyApplication这一个类文件，目前app涉及的业务也仅usercenter和media这两个module，其中usercenter和module并无依赖关系。因此，此项目完全可以作为一个快速开发框架。简单做法：新建几个module编写自身的业务，仅需要被shell依赖，它们并不会受到原业务usercenter和module的影响。然后更改入口Activity之后，就是一个新项目，也不会被打包进apk中。更多组件化的使用可见Appjoint的介绍。

目录结构

每个组件和一般app的目录结构基本一致，主要多出了一个package，用来盛放与其它组件通信用到的类，项目中media组件有实例展示。

router库的结构如下图，其中每个组件都单独拥有一个package，里面分别盛放组件间通信的服务接口和共享的数据（组件通信数据实体类，或者面向json编程，手动哈哈，另一个话题）。

主要使用的第三方库

感谢：

本项目仅做学习交流之用。

仓库地址：

App实现-KtDevBox

后端实现-KtDevBox-backend

喜欢请记得Star一下。

后续还有更为详细的项目介绍。

最后，可能有些童鞋还对下面这张图感兴趣。不过，本文只谈技术，不谈“风月”，微笑。