一直想写一篇关于独立开发的博客，由于事情的耽搁拖到现在（好吧，我承认是我懒）。现在越来越多的Android初级程序员（媛），也越来越多的公司要求独立开发，也有很多童鞋一到搭建框架的时候就四肢无力、头昏眼花、无从下手。那么，对于一个初级小白，怎么从零开始搭建一个框架呢？

先看一个目录

• 开发前的准备
  • 包名
  • 应用名称
  • keystore/jks
  • 测试手机
  • 第三方SDK
  • 效果图
  • 需求文档
  • 接口文档
  • 框架选用
  • 开源库选用
• 开发中的注意事项
  • build.gradle
  • 分包
  • 工具类
  • 页面状态
  • base基类的封装
  • 权限申请
  • 启动页
  • 注释
  • 刷新与加载
  • colors.xml
  • string.xml
  • 常量存放
  • 更新与强制更新
  • 混淆
• 总结

包名

• Android系统使用包名(Package Name)作为应用的唯一标识。

即：包名必须唯一，一个包名代表一个应用，不允许两个应用使用同样的包名。包名主要用于系统识别应用，几乎不会被最终用户看到。

• 包名的命名规则

可以包含大写字母(A到Z)、小写字母(a到z)、数字和下划线，可以用点(英文句号)分隔，隔开的每一段都必须以字母开头。

• 避免包名冲突

因为包名是唯一标识，为了避免与其他应用的包名重复，产生冲突，您可以这样命名：将您的域名反转过来作为前缀，比如如果您的域名是zan.com，那么包名可以用com.zan开头，这样可以有效的避免重复。在后面增加描述产品名称的字符，比如果果您的应用是视频应用，可以命名为com.zan.video
如果您没有域名，可以使用自己的邮箱作为前缀，比如 com.163.WoDeYouXiang

• 包名冲突如何处理？

如果您发现您尚未发布的应用，包名和其他开发者已经发布的应用重复了，建议立刻修改应用的包名，避免冲突。
如果您的应用已经发布了，但是在小米开发者站上传应用时，被告知已经有其他开发者上传了同包名的应用，可以按照指示，联系应用市场开发人员处理。

• 注意

应用发布后，请不要修改包名，一旦您修改了包名，就会被当作一个新的应用，旧版用户也无法收到应用商店的升级提醒。

应用程序包名.png

总结：我们到公司开发，包名一般是根据公司的网站来的，iOS、Android、后台三方尽量统一，在某些第三方SDK申请的时候可以避免一些麻烦。

应用名称

这个比较简单，例如：微信、QQ、快美妆等等，这个不用急，在发布apk之前都可以改，最好是提前定下来，因为申请一些第三方SDK的时候需要。

KeyStore

Keytool是一个Java数据证书的管理工具 ,Keytool将密钥（key）和证书（certificates）存在一个称为keystore的文件中。在以前，我们叫它KeyStore，在Android Studio后缀名改为了.jks

在我们Android Studio里面的 build -> Generate Signed APK 可以选择创建一个新的签名。

证书，包括项目源代码都是属于公司，请在申请的时候保存相关申请资料以备后续使用。

如果你进入公司的时候，项目已经开始一段时间了，请记得在交接的时候务必要拿到这个签名文件，包括签名文件申请时候的一切资料，这个签名文件相当重要，很多重要的第三方都需要这个签名文件，例如微信SDK。如果更换了签名文件，就相当于一个新应用了。

KeyStore.png

测试手机

很多时候有童鞋可能遇到这样一种情况，公司刚起步，而且是一个人独立开发，老板对开发这方面懂得不是太多，当我们需要Android测试机的时候，找老板申请，这个时候，我们先得做好准备工作，我们都知道，作为一个好的员工或者下属，尽量是让上级主管做选择题，而不是问答题。

Android的机型千千万万种，如果我们需要全部购买显然不太现实。个人认为根据公司实力，测试机数量在5-10台都是可以接受的。这时候我们需要拿出一些数据来说服老板。

• 首先我们需要做Android系统统计，这个简单。当你创建一个新的Android项目的时候Google就会提供每个系统版本的占比。

Android系统版本分布.png

从上图中我们可以看到，Android4.0以下已经没有使用的了。最低SDK选择到15就能适配到市面上所有的Android系统。

• 其次，我们如果是国内的应用，需要对国内手机品牌厂商的占比做统计。
  【友盟+】2016年手机生态发展报告H1

• Android设备品牌分布

Android设备品牌分布.png

从上图可以看出三星、华为、红米、vivo、OPPO、小米、联想、酷派、魅族、金立这几种手机占据了70%的市场。

• Android设备分辨率分布

Android设备分辨率分布.png

最后我们结合系统、品牌、分辨率列出一个表格交给老板或者技术总监，让他们根据实际情况来购买测试机，我们一般不具体到某款型号的手机，因为无论你选的手机是便宜还是贵都算数，这些头疼的事情就交给有最终决定权的人去头疼吧！最终买几台根据公司实际情况来决定。

最终我们得出一个表格：

Android测试机购买表.png

表格数据仅供参考，也许有的手机并没有该系统或者该分辨率，自己灵活搭配就好。

第三方SDK

目前，几乎所有的应用都要用到一些第三方SDK，例如登录、分享、支付、统计、推送等等。公司刚起步的时候是没有这些的，有的童鞋可能不知道这些到底该由谁来申请。

一般申请第三方的SDK都需要使用到一些跟公司法人相关信息，作为一个Android开发者你显然不具备拥有这些资料的权限。一般是由有权限的领导去负责申请。然后拿到我们需要的一些app_key 或者一些app_id等信息。

这里额外提到一个叫做 计算机软件著作权的东西。目前应用宝上架app要求提供计算机软件著作权。

国务院于1991年6月4日发布了《计算机软件保护条例》。该条例指出：计算机软件是指计算机程序及有关文档。受保护的软件必须由开发者独立开发，即必须具备原创性，同时，必须是已固定在某种有形物体上而非存在于开发者的头脑中。

效果图

公司之间相互沟通是必须的，有时候要主动找对应的同事进行沟通，更何况UI还大部分是妹子呢？

效果图一般是由UI设计提供，包括切图、效果图、ic_launcher、loading、刷新动画等等。

UI只是先我们一段时间进行设计，开发的时候肯定没有把所有的图都准备好，我们可以让其先准备一些我们搭建框架需要的图。

例如：底部navigation图标、启动页、splash、下拉刷新动画、页面loading动画等。

UI妹子提供的图目前我给分为三类：

• 直接在图片上面标注

这种以前很常见，UI妹子需要在图片上面做各种标注，密密麻麻，看起来很麻烦，UI妹子标注也很累。拿到这样一张图以后，我们需要了解这张图到底是多大尺寸的，然后根据尺寸换算px成相应的dp。也有直接标注成dp的，这个就看你怎么跟UI妹子谈判了。

UI标注.jpg

• 给PSD文件

这种方法就要借助一些网站来做了，例如：标你妹啊。
将你的psd文件上传到该网站，它能根据psd文件自动生成各种尺寸，比较方便。缺点：要上传很大的psd文件。浪费时间。

• sketch软件导出的效果（推荐）

这种方式比较不错，但是有一个前提，UI妹子要会sketch软件和UI妹子的电脑必须是Mac电脑（只是UI妹子用Mac电脑的sketch开发出来，然后其他任何电脑都能打开，不要混淆了）。 导出的是HTML文件供没有安装sketch的开发等人员查看标注和导出切图。

sketch软件导出的UI效果.gif

另外，开发中也许你遇到过这种情况：

很多页面的颜色明明一样，UI标注却有那么一点点的差异例如：#898989 和 #888888，估计是由于UI取色器差异造成的，稍微有一点经验的UI会给你一个规范图，如下图：

UI设计的APP标准规范.png

需求文档

这个文档一般是有产品编写，上面告诉你每个功能的具体需求。我们开发者只需要按照需求来做就行。这个比较简单，不多讲。

接口文档

我以聚合数据的接口文档为例：

接口文档详解.png

根据上图我们拆解出来host：http://api.juheapi.com/

接口名：japi/toh

请求方式：get/post

参数：

   key     string  是   应用APPKEY(应用详细页查询)
   v       string  是   版本，当前：1.0
   month   int     是   月份，如：10
   day     int     是   日，如：1

框架选型

现在准备工作做得差不多了，你就要开始思考到底使用什么框架了。MVC? MVP? MVVM + DataBinding?

确定了主框架模式，接着就确定网络请求，目前流行的大概是: RxJava + Retrofit + OkHttp

紧接着就是图片加载框架：Glide、Picasa、Fresco等等。选择一个自己喜欢的就好。

开源框架选用

“不要重复造轮子 Stop Trying to Reinvent the Wheel”， 可能是每个程序员入行被告知的第一条准则（其实是初学者现阶段还没能力造轮子，还有就是你造的轮子没有别人的好用）。但是随着经验和技术的慢慢积累还是要去写轮子，毕竟有句话说的好：“是时候展现真正的技术了”。

作为一个新人，你目前需要的是要学会如何快速找到适合你的轮子，当然不能百分百符合你的需求，这时候你就要学会去改轮子了，大多时候都是一些小改动就能符合项目需求。毕竟国内很多APP都是你抄我我抄你。

找开源框架的注意事项：

1、你需要明白你这功能叫什么，最差也得见过哪个APP用过类似的功能。例如：Android 仿探探 w滑动

关键词第一步.png

2、根据上图我们抽取出来2个关键词，card-slide-panel、cardSwipeLayout。

3、拿着这两个关键词我们就可以去GitHub上面搜索。注意拆分关键词：Swipe、Card、panel。根据不同的关键词组合然后搜索按照star顺序排序，找到适合自己的框架。

build.gradle

将上面的准备好的包名，项目名，以及SDK范围等用来创建一个新的project。一个新的project创建好了以后如下图：

Android项目目录结构.png

可以看到build.gradle有2个文件，上面的是整个项目的gradle文件，而第二个才是我们常用的module的gradle文件，如果有多个module，这里会对应的有多个gradle文件。需要注意的是我们的依赖是写在对应的module下的build.gradle里面的dependencies节点下。

分包

APP分包.png

根据自己的习惯将不同的类放在对应的包下面。例如：base放基类、util放工具类、view放自定义类。值得一提的是JavaBean类的书写。下面我们来举个例子如何将JavaBean类抽取出来。

抓包json数据.png

例如上图这样一段json数据，我想肯定有一部分的人会将json数据直接复制进GsonFormat进行格式化生成bean，取其名：HomeBean。那实际上这里面应该拆分出来几个类：BaseBean、Post（data字段的数组中的一个）、User（userinfo字段）等三个。

Bean抽取.png

在BaseBean中data字段是T泛型类型。user类里面后续或者其他页面会有更多的字段的时候，只需要往user这个类里面添加字段就可以了。调用的时候呢如图：

api调用.png

这里的解析就只传入了data字段对应的JavabBean，具体在代码中，使用了RxJava的map操作符解析后再将data中的bean返回。

注意：这是使用MVVM+dataBinding最要注意的地方。虽然我们不使用MVVM，但是这样做会更好。

工具类

这个比较简单了，一般每个开发者都有收藏自己的代码库，是时候将你的工具类都贴上来了。如果没有咋办？问我师傅去吧！

页面状态

例如首页它会有几种状态呢？一般来说一个页面包含 加载中、加载成功、加载失败、空等四种状态。详情查看
高效抽取loading，再多的加载页面也不怕

基类抽取

基类的抽取好坏直接决定整个项目的复杂程度，基类抽取得越好，后续写代码越轻松。当然，每个人有自己风格的基类抽取，这里不能给出一个标准，只能作为一个参考，具体查看源码中的BaseActivity、BaseFragment。

权限申请

这里权限申请有两个意思：

• 一是在manifests文件中申请权限（有项目调试了半天才发现是网络权限没申请的吗？请自觉举手）。
• 二是做Android6.0动态权限申请，这个迟早得做，还不如在项目开发中见一个做一个，当项目完成了以后再来做的话，又得去走一遍逻辑。

启动页

启动页作为一个APP的入口，也需要认真对待。各位一定遇到过点击APP启动后白屏好久的情况吧！下图就能很好解决这个问题：

windowBackGround.png

其他的就很简单了，根据公司的需求来完成其他工作就OK了。接着也许会有splash页面，这个也没得说的。

注释

这块对于不同的开发者来说有不同的感受，有的人自己一点注释不写，但是当他去看别人没注释的代码的时候就开始怼了。如果对于有强迫症的我来说，不写不舒服啊（小小装逼一把）。

有人会说，你这不是独立开发吗？写注释给谁看啊？三个方面：养成习惯、你总有忘了的时候、为你以后离职能快速交接准备。

个人认为在开发中的注释分为四个部分：

• 类注释

这是最起码的，起码得告诉别人你这个类是干什么，作者是谁把，这类的创建时间是什么时候等等。

• API注释

这是必须的，而且要非常详细，对API中的每个字段的描述都要从接口文档中原原本本的复制过来，方便开发中查看与理解。

• 方法注释

个人认为，除开一些继承的方法外，其他的抽取与封装的方法都要添加一个方法注释，告诉别人你这个方法是做什么事情的。

• 重要部分注释

代码中某些地方有重要意义或者不太好理解的地方添加单行注释。

最后，提供一个类注释模板：

/**
 * @ 文件名:   $FileName$
 * @ 创建者:   ty
 * @ 时间:    $date$ $time$
 * @ 描述: 
 */

liveTemplates.png

下拉刷新与加载更多

android-Ultra-Pull-To-Refresh 是我在开发中一直很喜欢的一个库。作者是廖祜秋，他提到一个观点：

下拉刷新是很多View都具备的特点，如：ListView、WebView、甚至是TextView。而加载更多并不是所有View都需要具备的特性，应该由（ListView、GridView、RecyclerView）之类的View本身去实现。

也就是说，我们要集成统一的下拉刷新，而加载更多去使用例如loadMoreRecyclerView之类的控件。

这里需要注意的是，有的时候我们喜欢选择一些支持将下拉刷新与加载更多整合到一起的View。当然，我们项目中有时候并不是只使用一个RecyclerView就能完全实现功能的，而一个APP它的下拉刷新应该是一个统一的效果，这时候就出现一个问题了。你需要将两个View的下拉刷新做成一模一样。

colors.xml

先说一个场景：

当我们开发中的时候，UI妹子的标注是字体的颜色:#FF3386 这样的标注,而我们在xml中定义的也许是英文名称，当颜色太多的时候，我们必须得打开colors.xml文件进去查看我们定义的名称和色值对应的哪个。这样无形中效率太低了。看图：

colors.png

我们可以用色值来作为颜色的名称，单独只使用色值的话，自动提示有问题，所以我就在色值前面统一添加两个自己定义的英文字母。

strings.xml

我想作为一个开发者都知道xml布局文件中的中文尽量全部在string.xml中定义，如果不知道，那就显得比较low了哈。这个比较简单就不多赘述了。

常量存放

开发中必不可少的有很多常量，我们应该根据常量的用途来分类，对不同类型的常量分不同的类来存放，方便区分以及使用。

更新与强制更新

说个真实故事吧

我的上家公司，App看起来很不错，也迭代过很多版本了，入职后我就了解到一个情况：App的1.0.5 、1.0.6这两个版本的用户联系不上，只有推送，没有强制升级，一直有部分用户活跃在这两个版本上，并且量还不少。当时要对后台进行重构改版，面临的问题是用户一直不愿意升级。那么这部分用户又不能放弃，只能维护这两套系统。费时又费力！

另外一个故事：

慕课网大家都知道，前段时间在慕课网买了一套视频，想把视频下载下来看，但是只能用它的App才能打开，于是乎，我就冒出一个大胆的想法。抓包他的数据然后去下载，猜怎么着？json数据加密了，没办法了。我又查询资料了解到它以前的版本是可以抽取视频地址的，于是乎我去找它以前的App版本，安装->运行，然后就直接弹出了强制更新，不更新就用不了。最后还是放弃了。

从上面两个故事可以看出强制更新还是很有必要的，可能有时候会引起用户反感，但是从整体利弊程度上来说还是利大于弊。还记得当支付宝出AR红包的时候，也必须要求升级到10.+的版本才能使用。这是符合正常逻辑的，大部分用户也能理解。

混淆

混淆上演的是一场 Android安全攻防战，反编译与混淆相互出招。目前，混淆和加固两种方式比较流行。这里介绍一种混淆的快速方法。

• 在SDK中有一个Google官方的标准混淆文件，路径是：/tools/proguard/proguard-android.txt 这里面是Google对原生代码一些标准混淆代码，我们将这里面的代码拷贝到我们的混淆文件中

• 接着就去将你使用过的第三方开源框架所标明的混淆代码拷贝到混淆文件中，直到全部拷贝并且打包不报错就可以了。如果有报错，那肯定就是你漏掉了某些开源框架的混淆代码。

总结：作为开发者，我们有时候要把眼光与思维放远一些，某些功能需要预留以防万一。移动端和后端不一样，我们的apk一旦发布出去了就不能再更改了，虽然有热修复，但是它也不是万能的。思维才是最重要的！

本文只能给没有独立开发过的童鞋们一点印象，如果有什么不对的地方欢迎大家吐槽。最后，附上示例Demo WarWolf