1：代码混淆和apk加固

代码混淆就是删除无用代码，将代码中的各种元素，如包名、类名、函数名、变量名等改成无意义的符号，使得反编译你apk的人无法根据名字猜测代码的用途，这是一种加密手段。如果代码没经过混淆，发布出去后，别人只需要反编译即可查看你的源码，这是一种知识产权的保护手段。混淆的目的是为了加大反编译的成本,但是并不能彻底防止反编译

apk加固是每一个app发布之前必须要做的事情;如果一个apk没有加固那么别人就很容易被别人反编译，看到这其中的原码。那么apk加固说的简单点就是对源Apk的dex进行加密，然后在套上一层壳即可。

（1）：如何混淆

在build.gradle文件里android目录下的buildTypes下minifyEnabled属性改为true。

 buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

（2）：哪些不能混淆

使用Android Studio创建项目时会在项目根目录下生成一个proguard-rules.pro文件，该文件便是指定项目混淆规则的文件，使用的时候只需要在里面加入相应的混淆规则即可。也就是说，你在这个文件里面指定 哪些代码需要混淆，哪些不需要
1.反射中使用的元素,如一些ORM框架的使用,需要保证类名、方法不变, 不然混淆后, 就反射不了
2.枚举也不要混淆
3.四大组件不建议混淆,因为四大组件声明必须在manifest中注册,而混淆后类名会发生更改,此时混淆后的类名没有在manifest注册,这是不符合Android组件注册机制的。
4.注解不能混淆
5.JNI调用的java方法
6.Java的Native方法
7.JS调用Java的方法
8.WebView中JavaScript调用的方法方法不混淆
9.第三方库不建议混淆,使用第三方开源库或者引用其他第三方的SDK包时，需要在混淆文件中加入对应的混淆规则（关于第三方的库的, 一般都是看他们的官方文档
10.Parcelable的子类和Creator静态成员变量不混淆，否则会产生android.os.BadParcelableException异常
10.GSON的序列化与反序列化
11.继承了Serializable接口的类,在反序列化的时候, 需要正确的类名等, 在Android 中大多是实现 Parcelable来序列化的
12.Layout文件引用到的自定义View

（3）：三方加固和三方批量加固

2：多渠道打包产品（友盟，美团，360）

什么是多渠道打包

渠道包就是要在安装包中添加渠道信息，也就是channel,对应不同的渠道，例如:小米市场、360市场、应用宝市场等
产品在不同的应用市场可能有不同的统计需求，需要为每个应用市场的Android包设定一个可以区分应用市场的标识，这个为Android包设定应用市场标识的过程就是多渠道打包。

3：产品上线流程

第一步：测试（正式流程）（时间~不定时）

不定时测试，正式提交的各版本BUG测试
要求：
项目组提供一个相对稳定的版本（不能出现程序无法运行，频繁崩溃，影响产品正常运行的现象），若出现以上情况测试周期终端，进入下一个产品的测试周期，再次申请需另行进行排期。

第二步：外部测试（时间~2天）

说明：
提交第三方测试，包括兼容性测试、压力测试（建议本公司自己搭建性能测试团队自己进行测试

第三步：正式测试（时间~3天）

说明：
按照自测文档进行测试，测试完毕后给予相应反馈（不通过的问题及时反馈）
要求：
项目组首先需要过一下自测文档上内容是否已完成，另外产品需要稳定版本不能出现无法运行吗，频繁闪退，影响产品正常使用的现象

第四步：产品、运营对产品测试及轻微调整（时间~7天）

说明：
产品体验测试（主要针对产品本身，系统功能，bug，ui适配等问题）运营体验测试包含与研发的沟通，确认修改时间
要求：
提供使用说明文档，宣传图等

第五步：正式提审

要求：
需渠道接入完成，自测文档流程完成，产品版本稳定，不存在致命bug，且不能在提交审核阶段进行任何更新，产品本身没有影响正常进行的现象（闪退，卡死）

第六步：后台搭建及权限

说明：
可以与第四步同时进行，运营提出相关数据需求
要求：
产品上线前，必须要有相应的数据追踪

第七步：第一次上线封测

（时间~1个月）
说明：
第四步内容完成，并且提审通过，可以进行第一次上线测试（一般采取删档不收费的策略）

第八步：数据分析

（时间~1个月）
说明：
产品封测阶段，运营根据数据分析，提出相应的产品修改方案，并与研发进行沟通确认

第九步：项目首发

说明：
经过封测阶段的测试，并对产品的调整内容修改完成后，进行正式上线运营（运营根据阶段提出运营活动需求，项目组给出相关版本迭代规划）

4：消息推送

（1）：如何集成：

1.注册极光开发者账号
2.添加应用，获取AppKey

自动集成：

3.下载提供的demo，demo中的AppKey已自动生成为你自己的AppKey

手动集成

3.Module下的build.gradle中添加配置
4.配置 AndroidManifest.xml 文件
5.直接拷贝demo中的AndroidManifest.xml文件进行修改
6.初始化极光推送：
JPushInterface.setDebugMode(true); // 设置开启日志,发布时请关闭日志
7.JPushInterface.init(this); // 初始化 JPush

（2）：特殊设备（小米，华为，魅族）如何设置：

1.小米推送
小米推送小米的文档写的挺明白了，各项功能也还算完整，api逻辑跟极光差不多。最重要的是在小米MIUI系统上是系统级推送，可以在应用被杀死的情况下收到推送。另外小米还支持ios推送，也可以透传消息，所以完全替代极光是应该是行得通的。

2.华为推送

其实也不难，在服务器端就两个接口,①是从华为服务器获取 通行令牌，②是根据通行令牌调用华为接口推送就好了。但华为吐槽点不少。

（3）推送，拉取原理：

传统获取服务器数据使用的是pull模式，是客户端向服务器请求数据。从客户端发起连接请求，获取到服务器数据后就关闭连接。当连接断开后，服务器就会失去客户端的地址，因此无法主动向客户端发送消息。
推送(push)是服务主动向客户端发送数据。
它的原理是保持一个长连接，当客户端和服务器建立连接后不再断开，这样服务器随时有新消息都可以发送给客户端。

（4）：区别人群，机型的推送：

用户分群（Segment）
这是相对高级的使用方式了，开发者可以根据一些已知的条件，任意组合，创建一个 SegmentID。然后基于这个 SegmentID 进行推送。上面说到的可以用于用户分群的条件有：tags，App 版本，SDK 版本，平台版本，用户注册时间，用户活跃时间，用户所在城市等。

5：支付

（1）：支付流程和原理：

微信支付流程

1：首先在商品app中选择商品下单
2：然后商品app会请求生成支付订单发送给商家服务端
3：然后商品服务端，会调用微信支付的api，生成一个预付订单号
4：商家服务器将生成带签名的客户端支付信息，返回给我们的商品App中
6：然后拉起一个确认交易的页面
7：如果确定订单了，微信客户端会发起支付请求到微信服务端，微信服务端验证支付参数，app支付等权限。
8：验证成功了，微信服务端会返回需要的授权给微信客户端，然后就
进入了用户确认支付，输入密码，或者指纹支付的页面
9：输入密码，或者指纹之后，微信客户端会提交支付授权给微信服务端。然后再由微信服务端验证授权，完成支付交易。

支付宝支付流程

1：首先商户的apk携带商品信息到商户的服务器
2：商户服务器，对商户apk传递过来的数据进行校验，生成订单
3：通过后端集成的支付宝文档，拿我们的私钥签名向支付宝发起支付请求。并传递相关的参数发送给支付宝服务器。
4：支付宝收到参数后，拿着我们给的公钥进行验证
5：如果通过，就返回支付串码给商户服务器
6：商户服务器拿到串码后，需要返回给我们的用户app上，拉起支付宝界面完成支付。

（2）：退款流程：

1:用户发起退款后，运营人员打开退款审核页面
2:确认可以退款后，后台组装一个重定向的html到支付宝
3:输入密码后支付宝向notify_url发送退款结果通知

6：即时通讯：

（1）：集成流程（聊天功能）：

（2）：注册登录流程

App用户在手机上注册时,将用户名和用Hash算法加密后的密码,再次加密,连同用户名传入环信后台注册,成功后,才在自己服务器注册成功.
用户名可以选择加密或不加密,不加密的话,该用户名作为环信数据看的id,同时作为连接自己服务器数据库和环信服务器数据库的桥梁;如果为了更加安全,将用户名加密后,传入环信服
务器,将要在自己App服务端的数据库加一条字段,用来存储加密的用户名,来连接两个服务端
发送的信息起码要包括,接收者,发送人,和消息
要实现跨平台通讯,将AppKey一致即可
环信服务端提供批量注册和登录的方法,方便使用