Android 开发 - 个人小结

1、前言

一般来说，对于小公司而言，往往都是一个人负责整个Android的编码工作，甚至还要兼测试，更恐怖的连设计和后台也一起搞定了。

本人所在公司所幸分的比较清楚，产品、后端、设计、开发、测试都有，算是比较齐全，但是彼此间的配合还是不太好。在开发一个App的过程中，在沟通上就是个蛋疼的问题，个人感觉没有一个主导人物来把控，每个过程的对接都会或大或小的出问题，尤其是产品不给力的情况下。

本文是个人在半年的Android开发工作中的小结，主要是给自己整理整理思路，把开发中遇到的问题写下来，以备日后查看。

2、大致流程

了解需求 --> 拿到设计图 --> 根据设计图，弄清楚不明确的地方 --> 整理出所有需要的接口，保证接口都有正确的数据以及状态 --> 编码、沟通 --> 测试 --> 发布 --> 维护 

3、了解需求

这点是重中之重，在公司决定要开发什么产品后，一般都会把开发人员叫过去了解需求，在这之前PM和老板应该已经把需求定好了，让你过去只是让你知道要干啥，这个时候你有问题一定要及时提出来，把你的想法大胆的说出来，不明确的问题一定要沟通好了，否则在开发过程中会很蛋疼。

4、设计图

在需求明确后，公司会让设计人员设计App的界面，这个过程是设计和PM的事，在这里有个建议给设计，设计在设计界面的时候，不要怕麻烦，有什么问题一定要和PM沟通清楚，自己要多思考合理性和App的使用流程，另外尽可能的考虑到极端的情况出现，否则你是把界面设计出来了，但是漏洞百出，开发人员也得找你协商，你还是得找PM协商，来来去去，时间就这么浪费了。

开发人员拿到设计图后，要根据设计图自己走一遍流程，可以从代码的角度出发，去思考流程中会有什么不明确的问题出现，通常要考虑到访问网络失败的情况，以及加载中应该显示什么。对于设计图有不明确的地方，及时找设计和PM沟通。

设计图要随着需求的改变而改变的，因为当完成编码进入测试阶段时，测试人员会以原设计图来判断是否正确，所以在某个地方改变了以后，设计图也要相应进行更改。设计人员可以开个文件夹，把所有的设计图纸共享在局域网上。

5、整理出所需接口

设计图明确后，根据流程整理出所需要的接口。

如果此时后端还没有做好接口，开发人员应该先把界面整出来。

如果此时后端还是没好，可以根据设计图自己弄假数据，先把能跑的流程跑通了。在这里建议在内网里自己的电脑上搭个服务器，将假数据直接返回给客户端即可。

关于接口：

接口文档至少要包含以下内容

1. 正确数据的结构，方便解析。
2. 错误数据的结构，方便提示用户哪里出错。
3. 各种状态值，方便根据值提示用户，比如登录的时候，用户不存在，密码错误，登录失败等状态。
4. 数据的字段解释，对于某些见名知意的，可以不用，但是对于设计图上要显示的数据，接口文档上必须做注释。
5. 接口的名称和接口的用途
6. 参数的含义。

对于接口不明确的地方，一定要和做接口的人沟通清楚，比如缺少接口，或者接口返回的数据字段含义不明白，或者接口无法访问等情况都要和后台说清楚。

当然，对于假数据的话，只要界面上的数据即可，毕竟只是用来铺垫的。

对于接口文档，想必后台人员都不想做，但是从实际出发，有份接口文档是非常省时间的做法，没错，就是省时间，因为如果你不整个文档出来，App开发人员就要问你拿接口地址，参数，参数含义，是get方式还是post方式，然后去访问，访问成功后，对于数据字段的含义是什么，如果访问失败会发生什么，各种问题烦死你，还不如你自己做好接口后，直接简单的测试一下，把相关的东西整成文档，就省时间多了。

6、编码 --> 以JSON作为数据接口

多人协作请看这里：使用git和github进行协同开发流程

单人负责全部编码请看这里：

(1) 访问网络：

网上有很多很多开源的网络框架，在这里介绍我常用的几种。

AsyncTask：

Android提供的异步加载类，很简单的，Google一下用法一大堆，不过我一般不用这个。

Android Asynchronous Http Client：

很好很强大的一个开源库，提供了许多的回调函数，具体用法详见链接，英文也很好翻译。

Android Volley完全解析(一)，初识Volley的基本用法：

Volley是Google开发的一个网络库，轻量级的。可以让你更加简单并且快速的访问网络数据。

以上3个我最常用的是第二个，并且在其基础上进行封装，加入了对话框。

除了这三个外，还有很多其他的网络库，这里就不一一介绍了。

(2) JSON解析：

就我所知的JSON解析库有以下常用的。

FastJSON：

号称解析速度最快的。也是我正在用的。

Gson：

Google自家的。

还有个JackJSON，没用过，感兴趣的可以自己上网搜搜。

(3) Parcelable传输：

Java本身支持Serializable，但是效率较低。

Android建议使用Parcelable，但是Parcelable使用起来比较麻烦，要写许多的代码。

如果IDE是AS的话，有一款插件可以快速生成Parcelable。插件名称是Android Parcelable code generate，在AS的插件里搜索就能搜索到。

一般来说，Parcelable传输的都是JavaBeans，我建议大家使用ParcelableGenerator，一个开源的Parcelable传输库。

(4) 注解框架：

我用过的有2种。

AndroidAnnotation：能大量减少代码，不过刚入手时错误多到容易把人吓着，不过上手了就会发现真的可以减少许多代码。不过我不喜欢这个东西。。。

Butter Knife：视图注入，事件绑定。挺好用的，虽然功能不及AndroidAnnotation，但是胜在简单，而且AS有插件可以生成代码。

ButterKnife Zelezny：ButterKnife 的AS插件。在Adapter中可以生成ViewHolder，不过现在有RecyclerView了，这点也不是特别突出。

(5) 图片加载：

这个就不用说了。。。直接上地址吧。

Android-Universal-Image-Loader

picasso

Cube ImageLoader

(6) 测试服务：

我只用过Testin。

在测试阶段，可以在应用主界面显眼又不占地方的位置，加上：“内网1”“外网1”之类的，方便BUG提交和修复，不过要记得在发布前去掉哦。

在提交测试前，自己把界面中的所有图片都点击一遍，确认都有正确的响应后方可提交测试。

对于部分没有做的模块，要告知测试，以免测试误以为是BUG。

对于JSON数据，要考虑到数据为null的情况，对于为null的，要做处理将其去掉。

(7) 本地崩溃Log捕捉，适合测试阶段用：

AndroidLogCollector：在测试阶段，如果发生了崩溃，Testin可能无法及时的收到崩溃信息。可以通过这个框架，捕捉崩溃日志，一旦发生崩溃，可以让测试人员把log日志发给开发人员，就能很方便的追踪崩溃信息。

可以在com.qihoo.linker.logcollector.utils包中的LogCollectorUtility类中的getExternalDir方法改变Log日志的路径。

(8) 软件更新、分享、统计分析：

更新：

可以使用Umeng的自动更新，挺好用的。

如果不喜欢友盟的，可以自己写一个，在github上有许多开源的库，都很好用。可以clone他们的项目来研究研究，在这里就不推荐了。因为实在是太多了。。。

分享：

至于分享的，现在都有第三方服务，比如Umeng，ShareSDK等。都有较好的文档，可以很好的满足分享的需求。

统计分析：

也有很好的第三方服务，不多说了。

以上总结了本人开发App会用到的东西，可以将这些项目中常用的东西整理成一个Android项目，如果要开发新东西，只要把项目中的东西拷进新项目中就行。

在做一个功能前，先把逻辑理清了，然后尽可能的解耦，不要因为简洁而放弃可读性。

必要的注释是非常需要的，而且最好保持注释的有效性，否则过些时间再来看你自己的代码，搞不好你自己都看不懂了。

对于第三方库，最好的方式就是通过引用的方式，将其弄成一个Module（在Eclipse中是library），这样子以后出问题了，想更换也会很方便。

在完成编码后，可以使用Android lint检查一下代码，去掉无用的资源。

对于金额类的，不要使用double，一定要使用BigDecimal，否则double值的不确定性，会让你抓狂。

7、发布

发布出去之前，首要考虑的是软件如何更新，这方面的第三方服务也不少，我比较喜欢用的还是Umeng的，新版本Umeng有增量更新，是个很不错的玩意，尤其是的对软件更新频繁的App，而且github上面也有不少增量更新的开源库，不过自己搭建比较费时间。

除了使用第三方服务外，也可以自己写一个，很简单，检查更新和下载新版本apk。

总体来说，开发一个小型App变得越来越简单，除非是有特殊需求的，基本的东西在网上都能找到。

以上就是我半年来的小结，处于能熟练使用工具的阶段，可以对别人的代码进行二次封装。但是要我真正的去做一个属于自己的东西，我现在还达不到。而且底层那一块也没有涉猎，Android的源代码也没有看过，也可以说看不懂吧。。。