34岁！100天！学会Java编程（Day68-Day80）—Android开发基础

最近遇到了学习的瓶颈期，有些动力不足，于是花了些时间陪老婆看了部TVB老剧《创世纪》。剧中三兄弟的性格泾渭分明，没想明白怎么能做了十几年的兄弟，最后还做成了香港合伙人。这部老剧确实经典，不管是商场上的尔虞我诈，股市上的翻云覆雨，合伙人之间的矛盾与合作，朋友与敌人的不断转换都很有看头。在所有的变化之中，唯有一条兄弟情贯穿始终，却悲剧收场，不胜唏嘘。

（一）初识Android应用

（1）Android移动应用与PC应用的区别？

以上来自知乎的一份回答，这里我仅从技术实现的角度再稍微补充一下自己的理解。

PC应用如果在这里缩小范围，特指基于浏览器的Web应用，那么从结构上来说，Web应用是B/S结构，Android应用是C/S结构，两者有本质的区别。

前端：Web应用是瘦客户端，靠html、css、js，jsp分别控制静态样式和动态显示；Android应用是富客户端，靠xml和Java，其中前端的静态样式直接在xml中指定组件的布局和样式，动态显示由Java直接控制。

业务逻辑：Web应用的业务逻辑都依赖后端服务器，Android应用的业务逻辑大部分可在前端完成（也可以放在后端，需要平衡）。

后端：这里主要指服务器端，由于通信方式都采用http协议，两者的技术大体相同，除了业务逻辑的平衡之外，并无本质区别。

另外，两者技术上的区别更多来自操作系统的区别，android应用运行在Android操作系统上，PC应用则运行在Windows、IOS、Linus等众多不同的系统上，他们的运行逻辑不同。

（2）android与ios的市场份额？

众所周知，在移动市场上是android与ios双雄相争的局面，目前看来，在缺少应用支持的情况下，windows等搅局者在移动市场将越来越难以立足。

根据2017年五月份的一篇报道显示，截止当时，android的市占率为86.1%，ios的市占率为13.7%，且重量的天平仍在向android倾斜。同时，ios虽占比较小，但占据的是相对高端的市场，所以也不可小视。

（3）安卓移动应用的应用场景？

从本质上说，移动应用的兴盛并非源自技术的推动，而是技术的发展解放了人们本就存在的对自由的渴求。（而地产则是满足人们对稳定的需求，人性就是如此复杂。）

从硬件层面，由于安卓的开源和平民化，安卓移动应用已扩展到了几乎所有门类的智能硬件，这个清单包括：手机、平板、电视、腕表、眼镜、耳机、音箱、车载中控等等，随着智慧城市、智能家居等概念地深入渗透，这个清单还会越来越长。

从应用场景来说，有人提出软件定义一切，我觉得安卓会渗透一切。

（二）Android开发知识点

下面主要以图示的方式，梳理android开发的基本知识点，高手勿喷。

（1）两个常用IDE

Eclipse+ADT被人亲切地称为EA；
Android Sdudio被人牙痒痒地称为AS。

从EA到AS的时候，我有种转角遇到“爱”的感觉。这么熟悉的画风，加上AS启动时那句“Powered By the IntelliJ Platform”，这不是刚才学Spring时，折磨了我千百遍的IntelliJ IDEA嘛。应了那句话，你现在受的苦，总会照亮你未来的路。

回到IDE，EA和AS的渊源来自于google的喜新厌旧，在android最初弱小的时候，背靠JAVA这颗大树， 投入了Eclipse的怀抱。后来翅膀硬了，就嫌弃Eclipse人老珠黄，继而转投新秀IntelliJ Idea的怀抱。

AS最被人诟病的是卡成狗。由于使用了Gradle进行项目管理，本来先进的在线中央仓库管理模式，由于google的被墙以及仓库大部分在国外的缘故，于是时不时出现读进度条读到你怀疑人生。不过，如果你使用过Android SDK Manager下载SDK，体会过想撞墙的感觉，那么AS的慢还是可以接受的。

然鹅，由于我学Android的主教程是《Android编程权威指南》，最后我还是从了AS。

（2）六个基本组件

在Android中有一些非常常用的组件，按照网上流传的四大基本组件包括：Activity，Service，BroadcastReceiver，ContentProvider。这四大天王是按照地位（都必须注册才能使用），而不是使用频率来定义的，因此在这四大的基础上，我又加上了两个非常常用的组件：Fragment和View。姑且称为左右护法，在视图表现层具有无可替代的作用。

详细的定义和使用方法需要参阅相关书籍和网络文献。

（3）四个邮差

安卓中有三个常用的被用来传递数据的组件，分别是：Intent，Bundle，Parcel。它们可分别用来传递从简单基础数据、数组、集合和复杂数据结构的信息，可视情况选择使用。其中，Intent虽然可以传递的数据不多，但是地位要远比其他三者高，因为它是用来传递Activity调用的。Intent的调用分两种，显示Intent调用主要是应用内调用，隐式Intent调用主要是应用外调用。

除了以上三种数据传递组件，还有一种很基本的数据传递组件是使用单例模式，构造全局静态数据对象，供所有活动调用。这种模式使用简单，而且生命周期通常比Activity还久，但同样缺点也很明显，过度滥用会增加系统垃圾和负担。

（4）七种常用布局

强调一点，以上布局的属性既可以通过xml静态设置，也可以在Activity或Fragment中使用java进行动态设置。

其他如CoordinatorLayout，AppBarLayout，TabLayout，TextInputLayout先记下，回头有时间再做探索。

（5）常用UI组件

以上是Android中常用的UI组件，与Layout搭配，完成页面显示；与监听器搭配，完成与用户的交互。

（6）手机上常用的手势交互

目前，用户与智能设备之间交互分为可以粗略分为手势、按键、传感器动作、语音等。用户交互是一门很复杂的学问，目前有一个专门的职业就叫做交互设计师，目的就是以用户体验为中心，研究怎么样让用户获得更新、更好、更快的体验。

我对常用的手势动作做了一些练习，不考虑性能的话，目前已都能实现。后面还需要研究在这些基础手势的实现方法上，如何获得更好的性能，如何设计出一些新的交互方案。

（7）手机上常用的软硬件交互

除了与用户的交互，还需要考虑app与android系统内其他软硬件之间的交互。

可以将系统内的这些调用接口，看作是app本身功能的外延，那么作为设计师需要考虑的就是怎样去调动系统本身提供的丰富资源，去完成我们想要给用户提供的功能体验。

上面列了一些常用的功能调用，需要注意的很多调用需要在androidmanifest中配置相应的权限。其中部分常用的权限，如互联网权限只需在应用中配置好就可以；而一部分权限，如调用相机的权限在配置好后，使用前还需要获得用户许可。

（8）两个半常见的数据持久化方法

目前为止，开发的App还只能停留于设备上本地应用，对于应用过程中产生的数据也只能保存在内存中，应用关掉或手机重启后，数据将不复存在。

为了解决这个问题，还需要引入数据持久化方法。与Web应用不同，这里介绍两个半数据持久化方法。

首先是缓存，这里的缓存和CPU缓存与内存池等概念不太一样，而是App在手机里专门开辟的一个文件，用于存储临时数据的，主要用处是将网上下载的数据存在缓存区，这样下次再访问同一页面时就可以直接从缓存区读取，达到节省流量的目的。这种数据虽不是永久存在的，但是在不认为清除缓存的情况下，即使重启手机，缓存数据也不会消失。

其次是设备数据库SQLiteDatabase，类似于电脑上的MySQL，不过这个数据库是只服务于本机的。

最后是远程服务器存储。与Web应用相比，Android应用是典型的富客户端。

为了实现远程服务器请求与应答，我首先在我的Spring服务器的控制层，新增了一个专门用于应答Android请求的控制器，用于响应比如登录、注册、下载图片等。这里需强调的是，Spring不能给android返回jsp页面，而是返回JSON数据。

然后在Android端试用了几种网络通信框架发送Get和Post请求，其中HttpUrlConnection实现起来总有一些问题，没有成功。遂使用在目前开源框架界排名第一的Retrofit来实现，不过由于一些细节问题，还是费了九牛二虎之力才最终实现。

不过我还是要推荐使用Retrofit，因为这个使用的是当下最流行的注解风格，而且跟MyBatis画风很像有没有。

（9）XX种常用开源框架

网上有一份流传的 2017百大Android框架排行榜，试用了其中的几种：Retrofit2，OkHttp3，RxJava，其他的以后慢慢再试。

（10）XX种常用架构

其中，我们最熟悉的就是MVC架构，发现不光可以用在服务器端，还可以用在富客户端。不过由于Activity和Fragment太多，这里没法使用外观模式，所以应用功能丰富起来后，其内部关系会比较乱。

MVP架构则斩断了View层和Model层之间的联系，所有的数据交互都通过Presenter这个中间层来实现，因此各层之间的耦合性相对有所降低。

MVVM架构在MVP的基础上，实现了View层与ViewModel层的数据绑定，从代码实现的角度有了较大简化。

关于项目架构，这里有一篇文章有很精彩的分析，我就不罗嗦了。GUI 应用程序架构的十年变迁。

参考书目
《Android编程权威指南》