① 2016年，移动开发领域有哪些最佳实践值得参考
参考下面
从开发角度看，移动相关的架构、开发也有很多独特之处。在即将于4月21~23日举行的QCon北京2016上，就准备了很多移动开发方面的最佳实践，来自腾讯、阿里巴巴、网络、京东、华为、美团、网易、和滴滴出行等公司的专家将分享他们的一手经验。
本次QCon，有“移动开发挑战”和“移动测试技术”两个移动相关的专题，其他专题也有与移动相关的产品设计、大数据和架构方面的演讲。
移动开发挑战
移动开发挑战专题，出品人是美团网高级技术专家、美团客户端平台团队负责人陈晓亮。先来看看这个专题会有哪些精彩内容。
随着3G、4G网络的普及，Wi-Fi热点的增多，移动网络上的音视频需求越来越多。移动互联网的很多领域对音视频通话有强需求，例如社交、情侣、在线教
育、移动医疗、O2O
等。让App能通话，是一件既炫酷又实用的事情。不过移动互联网的音视频通话存在方方面面的挑战，比如中国东北网通用户，和中国南方电信用户通话，网
络不好怎么办；通话卡顿，如何诊断问题出在哪里；如何评估某次通话的传输质量好不好；机场、学校、公司这些场所，有防火墙封端口怎么办。种种问题，声网首
席音视频架构师孙雨润将在演讲《移动互联网的音视频传输挑战》中一一解答。
手机App在音视频方面的应用产品，近两年呈井喷状态。观众在流畅地观看着视频画面的同时，背后其实包含了大量的技术难题。网易杭州研究院多媒体技术专家
郭再荣也将谈谈《移动端音视频应用优化之道》。本次分享将从手机摄像头数据采集开始，把视频编码、数据传输、视频解码、画面显示整条链路中的技术难点和优
化方法进行详细讲解。另外，还会对音视频开发者最关心的一些问题如直播延时、画面清晰度、手机端资源消耗等展开讨论。
很多团队要同时维护多个项目，还要快速迭代，稳定性、容错能力都非常重要。网络的凤巢App团队就是这样，在同一时间要开发和维护数个项目。网络移动开发
平台针对android和iOS两个平台，通过对基础功能抽取并单独封装SDK完成非业务剥离，剥离后的通用功能整体为一个SDK，每个独立功能又单独封
装为SDK，即SDK插件化；这样SDK不但具备可插拔功能，而且在开发者角度上具备自动获取更新功能。网络移动端架构师李祎嵩将分享《网络移动开发平台
最佳实践》。
随着移动互联网蓬勃发展，App规模越来越大，对App发布迭代速度和质量有更高的要求，技术开发同学面临着更大的挑战。怎样让App发布更快更灵活，以
及上线后更快地修复各种Crash和紧急Bug，让用户免去下载安装的操作，在最短的时间内升级用户手中的App，是Android开发人员面临的一个重
要的技术课题。腾讯社交平台部Android平台组组长俞尚将分享《Android超级补丁包技术》。QQ空间团队在去年实现class替换热补丁包技术
的基础上，更进一步在业内首创超级补丁包技术，实现了App上Dex和资源替换覆盖，在开发人员和用户都完全透明无感知的情况下，可把任意App直接升级
到最新版本。补丁技术已经在空间、微信和QQ等腾讯公司重量级产品上得到推广和应用，在此希望和业内其他团队在技术上做些分享和交流。
前端技术和移动端开发结合越来越紧密。Weex是阿里巴巴提出的移动应用的全新技术解决方案，能够将传统Native的性能和HTML5的灵活和开发体验
巧妙结合，同时在大规模工程实践和在微观问题上的无侵入性运用方面具备非常大的优势。淘宝无线前端架构负责人赵锦江（勾股）和阿里技术专家徐凯（鬼道）将
分享《Weex——灵活的移动端高性能动态化方案》，希望从前端开发体验和理念上，以及从Native端的渲染能力上，完整的呈现。
② Android无线开发的几种常用技术（阿里巴巴资深
完整的开发一个android移动App需要经过从分解需求、架构设计到开发调试、测试、上线发布等多个阶段，在发布后还会有产品功能上的迭代演进，此外还会面对性能、安全、无线网络质量等多方面的问题。
移动App的产品形态各不相同，有的是内容类，有的是工具类，有的是社交类，所以它们的业务逻辑所偏重的核心技术有些差别，但它们都会用到一些常用的技术方案。今天我们就先来简单介绍一下这些常用技术，以后会专门分专题来详细介绍这些技术的原理和使用场景。
1. Multidex
在Dalvik虚拟机所使用的dex文件格式中，用原生类型short来索引文件中的方法数，也就是最多只能有4个字节65536个method，在打包apk的过程中会把工程所需要的全部class文件都合并压缩到一个dex文件中，也就是说自己开发的代码加上外部引用的库的方法总数不能超过65535。
随着业务逻辑的不断增长，很容易就会超过这个限制，在编译期间就会遇到这样一个错误：
还好google官方给出了一个解决方案Multidex，它会把dex文件拆成两个或多个，第二个dex文件叫classes2.dex，在Application实例化后会从apk中解压出classes2.dex并将其拷贝到应用的目录下，通过反射将其注入到当前的ClassLoader中。但是这个方案非但不能解决一切问题也不能直接拿来用，而要加入自己的一些改造，来解决NoClassDefFoundError、INSTALL_FAILED_DEXOPT等问题，以保证自己的dex被顺利的加载流畅的执行。
2. Plugin
Multidex虽然可以解决方法数的限制，但随着业务逻辑越来越多，apk的大小也变得越来越多，而且有一些功能并非全部用户都想用的，所以会把一些功能模块独立出来做成插件，让用户可以按需下载更新，这样既减小了包大小，又改善了用户体验。
插件类似于windows的dll文件，放在某个特定目录，应用程序主框架会用LoadLibrary加载各dll文件，按插件接口去访问插件。Android的插件技术也是这样，利用一个进程可以运行多个apk的机制，用ClassLoader将宿主apk之外的类加载进来，插件的context可以通过createPackageContext方法创建。因为插件中的activity，service等组件如果没有在AndroidManifest.xml中声明将不能运行，所以需要预先在AndroidManifest.xml中声明一个代理类（ProxyActivity），将这个ProxyActivity传给插件，让插件的activity也有访问资源的能力。
3. Hot Patch
有时一些严重的crash bug或漏洞需要紧急修复，但有些用户不会或不愿意立即升级，而且频繁升级，没有特别的功能更新只是修复bug的升级，对活跃用户是一种伤害。热补丁就可以解决这样的窘境，它是一种可以线上修复的技术方案，有动态改变方法的能力，一般大型的移动应用都会使用热补丁来处理紧急事件。
Hot Patch可以通过hook来修改java的method，注入自己的代码，实现非侵入式的runtime修改，或者采用正向编程，通过工具生成patch文件，通过jni bridge指向补丁文件中的方法。还有就是利用ClassLoader，在dex中查找class时，如果找到类则返回，找不到就从下一个dex文件中继续查找，由此可以想到，在把问题修复后，可以单独生成一个dex，通过反射插入到dexElements数组的最前面，这样就能让dalvik加载补丁里的类了。
4. Push通道
Push是移动App常用的一种无线技术，基础是基于TCP的心跳机制，和客户端维持一个长连接。用处是向客户端推送消息，或者代替客户端定时去从服务器pull的策略，改为客户端接收到push消息后再去pull。
如果每个应用都自己实现push通道的话，cpu就会不定时地经常被唤醒，耗电量达到难以容忍的程度，而且自己搭建push平台的成本也很大，实时性和效率也存在问题，一般都直接使用一些服务商提供的push方案，这些push平台一般都经过了优化设计，在跨平台和网络穿透性、长连接心跳包、多客户端App链路复用、服务和连接保活等技术上做了优化。比如Agoo最初是淘宝无线事业部开发的push服务，在逐渐完善和支撑淘系其他app后，通过服务端容量、通讯协议优化、业务和开放能力的拓展改进后，与友盟等合作，开始向第三方提供推送服务。
5. 应用加固
一款热门的移动app或游戏发布后会受到很多的关注，经常会遇到二次打包的盗版行为，破解者要么修改游戏的资源文件、道具、分值甚至直接把访问的站点指向自己架设的服务器，损害了开发者的利益；要么偷偷植入自己的恶意代码，表面上看起来跟正版的app完全一样，在后台却盗取用户隐私，植入木马；要么通过反向工程学习原app的核心技术，打破技术上的竞争壁垒。
为了防止被破解只通过混淆是远远不够的，即使是在native层混淆也还是会被人熟练的反编译，所以需要一套对apk的保护方案来反调试、防逆向和防篡改。一般的加固方法都是对原apk先进行加密，然后和壳合并生成新的apk。壳是用来解密apk的dex文件。当应用启动时，壳先解密原apk，准备好自己定义的ClassLoader，然后获取源程序中的Application名称，通过反射找到正确的Application对象，运行它的onCreate方法，这样原apk才能被真正运行。其他一些反调试的方法有针对反编译工具，在源程序中加入一些无效的指令或无效的指针，引发反编译工具的崩溃，还有就是加花指令，利用一些跳转，堆栈操作等指令，让破解者无法清楚地理解反汇编后的内容。
6. 其他
除了上述几点外，在服务端还会涉及灰度策略、链路流量优化、动态更新配置、防DNS劫持等技术，在客户端会涉及用户埋点上报、在线监控、进程保活、H5和native混合开发、注入框架等。
③ 有谁使用过阿里巴巴的AndFix框架，android热修复
AndFix是一个Android App的在线热补丁框架。使用此框架，咱们能够在不重复发版的情况下，在线修改App中的Bug。AndFix就是 “Android Hot-Fix”的缩写。
就目前来说，AndFix支持Android 2.3到6.0版本，并且支持arm 与 X86系统架构的设备。完美支持Dalvik与ART的Runtime。
AndFix 的补丁文件是以 .apatch 结尾的文件。
AndFix是阿里巴巴开源项目。
AndFix
在Android Studio使用
在Eclipse使用
代码混淆ProGuard
AndFix介绍
Android上如何使用
patch文件的生成
Android上如何使用
1.在自定义Application中初始化，为了更早的修复应用中的bug。
package com.euler.andfix;
import android.app.Application;
import com.alipay.euler.andfix.patch.PatchManager;
/**
* MainApplication 2015-11-12 下午2:07:11
*
* @author 乔晓松 965266509@qq.com
*/
public class MainApplication extends Application {
public PatchManager mPatchManager;
@Override
public void onCreate() {
super.onCreate();
// 初始化patch管理类
mPatchManager = new PatchManager(this);
// 初始化patch版本
mPatchManager.init("1.0");
// 加载已经添加到PatchManager中的patch
mPatchManager.loadPatch();
}
}
2.如果有新的补丁需要修复，下载完成后，进行以下操作
//添加patch，只需指定patch的路径即可，补丁会立即生效
mPatchManager.addPatch(path);12
3.当apk版本升级，需要把之前patch文件的删除，需要以下操作
//删除所有已加载的patch文件
mPatchManager.removeAllPatch();12
patch文件的生成
使用工具：apkpatch-1.0.3
原理：根据两个apk包，生成一个差异文件，就是所谓的补丁文件即patch文件。
命令 : apkpatch.bat -f new.apk -t old.apk -o output1 -k debug.keystore -p android -a androiddebugkey -e android
-f <new.apk> ：新版本
-t <old.apk> : 旧版本
-o <output> ： 输出目录
-k <keystore>： 打包所用的keystore
-p <password>： keystore的密码
-a <alias>： keystore 用户别名
-e <alias password>： keystore 用户别名密码123456789
执行完命令，就会在输出目录中输出.apatch文件:
new-.apatch：就是patch文件。
.apatch文件根目录内容：
META_INF文件下内容：
PATCH.MF文件内容：注：Patch-Classes就是改动过的class.
客户端请求服务器接口(api)，服务器根据用户传递的数据分析是否有需要修复的bug。
如果有bug需要修复，就下载服务器指定的.apatch文件的链接，下载完后及时加载并修复，使用addpatch(path)方法，补丁会立即生效。
④ Android开发Tinker热更新的问题
通过阅读官方的技术文档，始终没有发现有对这个情况的相关配置项，所以只能从别处下手，最后发现，通过在 app mole 的 “build.gradle” 文件中，注释掉依赖插件脚本，最终解决掉这个问题：
说两句：
目前运行调试一切正常，不过要始终留意后续是否会出现问题；重要的一点是，当要打包新版本时，一定要解开这个注释。
2、can’t the get signConfig for this build
问题：
执行 buildTinkerPatchRelease 打 Release 版本补丁包时报以下错误：
Error:Execution failed for task ':app:tinkerPatchRelease'.
> can't the get signConfig for this build
1
2
解决：
android {
...
// 签名配置【buildTypes中调用了signingConfigs，则signingConfigs{}要置于buildTypes{}前面】
signingConfigs {
release {
try {
storeFile file("MyProject.jks")
storePassword "111111"
keyAlias "zhangzeqiao"
keyPassword "111111"
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
}
buildTypes {
release {
...
signingConfig signingConfigs.release
}
debug {
...
signingConfig signingConfigs.release
}
}
...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
其中要特别注意，signingConfigs{} 方法体要置于 buildTypes{} 方法体前面，不然会报以下错误：
⑤ google android有没有热补丁修复app
目前没有,网上的方法其实本质也是更新
⑥ android热更新框架哪个好
一.基础知识
1.阿里的热更新框架已经开源 了。但已经很久没有更新过新版本了。当前的版本只支持到了 Android 4.4。由于 5.0 起新的 ART 虚拟机、更严格的 SELinux 策略以及对 64 位的支持之类的事，使得 Xposed 都在开发上做了很多调整。我不知道 Dexposed 现在是否支持，但至少阿里没有开源。
2.在本地动态执行远端下发的代码是极度危险的行为。利用此方法执行非法代码等或用于绕过 Google Play 等市场的审查是违反相关协议的，也是对用户极度不负责任的行为。
3.在一些访问非常密集的地方使用热更新可能会对效率产生相对比较大的影响，应该避免使用.
4.我们可以对 Java 的 ScriptEngine 进行一些封装成为一个 HotPatch 类使得它更适合做热更新的工作。
5.首先,检查热更新补丁的管道一定要建立在 https 上，因为下发代码是极其危险的，如果被劫持，后果是无法想象的。其次,请求时最好自动带上 Android 版本、手机型号、地区、版本号等信息，以方便更精确地下发，千万不能下发错。
6.Java在运行时加载对应的类是通过ClassLoader来实现的，ClassLoader本身是一个抽象来，Android中使用PathClassLoader类作为Android的默认的类加载器
7.我们的如果想做hotpatch，一定要保证我们的hotpacth dex文件出现在dexElements列表的前面。
二.常用的热更新技术框架:
基于QQ空间的HotFix →→ 要使用到android dex分包方案→拆分dex的项目的话，可以参考一下谷歌的multidex方案实现.
大众点评的NuWa←项目补丁自动化做的很完整
alibaba/AndFix
阿里巴巴的DexPosed
dalvik_patch实现multidex
使用React-Native实现app热部署的一次实践
alibaba/AndFix
三、常用的热更新技术框架比较
Advantage
disadavantage
NuWa
1，可以新增类和字段，
2，兼容到6.0系统
1，基本原理是classloader,类加载器
2，不能修改资源文件，如图片布局等（可通过动态布局实现）
AndFix
1， 支持Android2.3到6.0版本
2， 支持arm与x86系统架构
3， 支持dalvik和ART的runtime
4， 不需要重启App即可应用补丁
1，不能新增类和字段，
2，不能修改资源文件,
3，不能修改manifest文件
4，不能新增成员变量
5，不能使用加固后的apk制作pacth文件
四、github地址
网络的同学的实现 HotFix
点评的同学的实现 Nuwa
阿里的同学的实现 AndFix
另：AndFix对static的支持不太好，下面是试验的Demo:
添加了一个静态的字段addString：
通过AndFix来制作patch会直接报错：
⑦ Android Studio创建项目后，修改代码后，需要保存吗
不需要，androidstudio编写代码，都是自动保存的，不需要手动保存。不过建议把代码放到服务器保存一份，比如GitHub，这样一个可以算是备份，二来你在其他地方也可以拉代码编写
⑧ Android插件化和热修复的区别和联系
针对Android平台，Dexposed支持函数级别的在线热更新，例如对已经发布在应用市场上的宿主APK，当我们从crash统计平台上发现某个函数调用有bug，导致经常性crash，这时，可以在本地开发一个补丁APK，并发布到服务器中，宿主APK下载这个补丁APK并集成后，就可以很容易修复这个crash。
Dexposed是基于久负盛名的开源Xposed框架实现的一个Android平台上功能强大的无侵入式运行时AOP框架。
Dexposed的AOP实现是完全非侵入式的，没有使用任何注解处理器，编织器或者字节码重写器。集成Dexposed框架很简单，只需要在应用初始化阶段加载一个很小的JNI库就可以，这个加载操作已经封装在DexposedBridge函数库里面的canDexposed函数中，源码如下所示：
/**
* Check device if can run dexposed, and load libs auto.
*/
public synchronized static boolean canDexposed(Context context) {
if (!DeviceCheck.isDeviceSupport(context)) {
return false;
}
//load xposed lib for hook.
return loadDexposedLib(context);
}
private static boolean loadDexposedLib(Context context) {
// load xposed lib for hook.
try {
if (android.os.Build.VERSION.SDK_INT > 19){
System.loadLibrary("dexposed_l");
} else if (android.os.Build.VERSION.SDK_INT == 10
|| android.os.Build.VERSION.SDK_INT == 9 ||
android.os.Build.VERSION.SDK_INT > 14){
System.loadLibrary("dexposed");
}
return true;
} catch (Throwable e) {
return false;
}
}
Dexposed实现的hooking，不仅可以hook应用中的自定义函数，也可以hook应用中调用的Android框架的函数。Android开发者将从这一点得到很多好处，因为我们严重依赖于Android SDK的版本碎片化。
⑨ andfix原理
AndFix，全称是Android hot-fix，是一个Android热补丁框架。
原理是：apkpatch将两个apk做一次对比，然后找出不同的部分。可以看到生成的apatch了文件，后缀改成zip再解压开，里面有一个dex文件。通过jadx查看一下源码，里面就是被修复的代码所在的类文件,这些更改过的类都加上了一个_CF的后缀，并且变动的方法都被加上了一个叫@MethodReplace的annotation，通过clazz和method指定了需要替换的方法。然后客户端sdk得到补丁文件后就会根据annotation来寻找需要替换的方法。最后由JNI层完成方法的替换。
如果本地保存了多个补丁，那么AndFix会按照补丁生成的时间顺序加载补丁。具体是根据.apatch文件中的PATCH.MF的字段Created-Time。
局限性：不支持YunOS
无法添加新类和新的字段
需要使用加固前的apk制作补丁，但是补丁文件很容易被反编译，也就是修改过的类源码容易泄露。
使用加固平台可能会使热补丁功能失效。
andfix与Nuwa对比，
Nuwa是另一个热补丁框架。
⑩ 微信开源的 android 热补丁框架 tinker 什么来头
他是参考国外的框架而来，如下内容：
Tinker v1.0－性能极致追求之路
为了稳定性与兼容性，微信选择了Java流派。当前最大难点在于如何突破Qzone方案的性能问题，这时通过研究Instant Run的冷插拔与buck的exopackage给了我们灵感。它们的思想都是全量替换新的Dex。
简单来说，我们通过完全使用了新的Dex，那样既不出现Art地址错乱的问题，在Dalvik也无须插桩。当然考虑到补丁包的体积，我们不能直接将新的Dex放在里面。但我们可以将新旧两个Dex的差异放到补丁包中，这里我们可以调研的方法有以下几个：
BsDiff；它格式无关，但对Dex效果不是特别好，而且非常不稳定。当前微信对于so与部分资源，依然使用bsdiff算法；
DexMerge；它主要问题在于合成时内存占用过大，一个12M的dex，峰值内存可能达到70多M；
DexDiff；通过深入Dex格式，实现一套diff差异小，内存占用少以及支持增删改的算法。