虽然有插件开发，但热更新少不了。


当我们需要更新插件的时候使用的是插件开发，当我们需要更新宿主程序就需要使用热更新
热更新使用框架bsdiff和bzip2
我们需要在服务端使用新版apk和旧版apk生成差分包，由于服务端在windows下，所以生成动态文件（dll）
通过寻找bsdiff的入口函数在bsdiff.cpp中在,因为截止到现在我主要了解了一点c，所以把bsdiff.cpp改成了bsdiff.c

int main(int argc,char *argv[])
{
	int fd;

	u_char *old,*_new;
	off_t oldsize,newsize;
	off_t *I,*V;
	off_t scan,pos,len;
	off_t lastscan,lastpos,lastoffset;
	off_t oldscore,scsc;
	off_t s,Sf,lenf,Sb,lenb;
	off_t overlap,Ss,lens;
	off_t i;
	off_t dblen,eblen;
	u_char *db,*eb;
	u_char buf[8];
	u_char header[32];
	FILE * pf;

	BZFILE * pfbz2;

	int bz2err;


	if(argc!=4) errx(1,"usage: %s oldfile newfile patchfile\n",argv[0]);

	/* Allocate oldsize+1 bytes instead of oldsize bytes to ensure
		that we never try to malloc(0) and get a NULL pointer */
	//org:
	//if(((fd=open(argv[1],O_RDONLY,0))<0) ||

	//	((oldsize=lseek(fd,0,SEEK_END))==-1) ||

	//	((old=malloc(oldsize+1))==NULL) ||

	//	(lseek(fd,0,SEEK_SET)!=0) ||

	//	(read(fd,old,oldsize)!=oldsize) ||

	//	(close(fd)==-1)) err(1,"%s",argv[1]);
	//new:
	//Read in chunks, don't rely on read always returns full data!

	if(((fd=open(argv[1],O_RDONLY|O_BINARY|O_NOINHERIT,0))<0) ||
		((oldsize=lseek(fd,0,SEEK_END))==-1) ||
		((old=(u_char*)malloc(oldsize+1))==NULL) ||
		(lseek(fd,0,SEEK_SET)!=0))

				err(1,"%s",argv[1]);

	int r=oldsize;

	while (r>0 && (i=read(fd,old+oldsize-r,r))>0) r-=i;

	if (r>0 || close(fd)==-1) err(1,"%s",argv[1]);




	if(((I=(off_t*)malloc((oldsize+1)*sizeof(off_t)))==NULL) ||
		((V=(off_t*)malloc((oldsize+1)*sizeof(off_t)))==NULL)) err(1,NULL);

	qsufsort(I,V,old,oldsize);

	free(V);
这里贴上前几行代码，只要调用这个函数就能得到差分包（.patch）,

而从if(argc!=4) errx(1,"usage: %s oldfile newfile patchfile\n",argv[0]);这行代码可以知道，argc这个参数必须等于4才可以正常执行，argv数组的第一个参数没有要求，从后面代码得到第二个参数为旧版apk的路径，第三个参数为新版apk的路径，第四个参数为生成的差分包的位置。

当我们差分的时候只要调用这个main函数并传递相应参数就可以得到差分包了，所以我们修改入口函数的名字，目的是当我们调用的时候采取执行。我们只需要在bsdiff这个文件下实现我们声明的native方法并调用入口函数。然后生成动态库文件放入服务端项目下用来辅助生成差分包

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_dongnaoedu_bsdiff_BsDiff */

#ifndef _Included_com_dongnaoedu_bsdiff_BsDiff
#define _Included_com_dongnaoedu_bsdiff_BsDiff
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     com_dongnaoedu_bsdiff_BsDiff
 * Method:    diff
 * Signature: (Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
 */
JNIEXPORT void JNICALL Java_com_dongnaoedu_bsdiff_BsDiff_diff
  (JNIEnv *, jclass, jstring, jstring, jstring);

#ifdef __cplusplus
}
#endif
#endif

public class BsDiff {

	/**
	 * 差分
	 * 
	 * @param oldfile
	 * @param newfile
	 * @param patchfile
	 */
	public native static void diff(String oldfile, String newfile, String patchfile);

	static{
		System.loadLibrary("bsdiff");
	}
}


这里只贴出了部分代码。这样我们就可以得到差分包，在服务器就可以获取这个差分包，然后我们需要从客户端下载这个差分包并与旧版apk进行合并生成新版apk，这样就可以省去部分流量。

合并的入口函数在bspatch文件中，下面为bspatch文件中native方法的实现，bspatch_main就是改了名字之后的入口函数

//合并
JNIEXPORT void JNICALL Java_com_dongnaoedu_appupdate_utils_BsPatch_patch
  (JNIEnv *env, jclass jcls, jstring oldfile_jstr, jstring newfile_jstr, jstring patchfile_jstr){
	int argc = 4;
	char* oldfile = (char*)(*env)->GetStringUTFChars(env,oldfile_jstr, NULL);
	char* newfile = (char*)(*env)->GetStringUTFChars(env,newfile_jstr, NULL);
	char* patchfile = (char*)(*env)->GetStringUTFChars(env,patchfile_jstr, NULL);

	//参数（第一个参数无效）
	char *argv[4];
	argv[0] = "bspatch";
	argv[1] = oldfile;
	argv[2] = newfile;
	argv[3] = patchfile;

	bspatch_main(argc,argv);

	(*env)->ReleaseStringUTFChars(env,oldfile_jstr, oldfile);
	(*env)->ReleaseStringUTFChars(env,newfile_jstr, newfile);
	(*env)->ReleaseStringUTFChars(env,patchfile_jstr, patchfile);

}
和差分类似，数组的第三个参数为生成的新版本apk路径


查分和合并使用bsdiff主要依赖于bzip2这个框架


然后我们就生成动态库文件（.so）,因为安卓运行在linux平台所以生成的动态库文件和前面不同。自此我们生成了两个动态库文件，分别运行在服务端进行差分和运行在客户端进行合并。
System.getProperty("os.name")能输出系统名字，能用于判断运行的操作系统
System.load("路径")加载指定文件下的库文件
差分算法：比较新旧文件，标识出翔通部分，压缩不同部分和额外部分（主要以来bzip2）生成patch文件
合并算法：生成的patch文件和旧文件合成新文件
当然这些算法内部实现非常复杂

热重载

所谓热重载就是页面每次改动，不需要手动去刷新，可自动刷新。

使用webpack的Hot Module Replacement API，Vuex支持开发过程中热重载mutation、module、action、getter。

 

热更新

热更新：浏览器的无刷新更新（即webpack里的HMR-hot module replacement模块热替换）【允许在运行时替换，添加，删除各种模块，而无需进行完全刷新重新加载整个页面】
目的：加快开发速度，所以只适用于开发环境下使用
思路：

保留在完全重新加载页面时丢失的应用程序的状态
	
只更新改变的内容，以节省开发时间
	
调整样式更加快速，几乎等同于在浏览器调试器中更改样式
使用：

引入webpack库
	
使用了new webpack.HotModuleReplacementPlugin()
	
设置devServer选项中的hot字段为true
 

Unity3D热更新全书-何谓热更新，为何热更新，如何热更新




首先来赞叹一下中文，何谓为何如何，写完才发现这三个词是如此的有规律。
为何赞叹中文？因为这是一篇针对新手程序员的文字，是一节语文课。
然后来做一下说文解字，也就是
何谓热更新

热更新，每个程序员一听就明白，但是它语出何处，究竟表达了什么含义，到底代表了什么，对技术有什么要求，对经验相对较少的程序员来说可能就有一层神秘面纱了。

热更新，是对hot update 或者 hot fix的翻译，计算机术语，表示在不停机的前提下对系统进行更改。
hot 就是热，机器运行会发烫，hot就是不停机的意思。
热更新，是个很形象的词，机器烫的时候更新，开着更新。
比如Windows 不重启的前提下安装补丁
比如Http服务器在不重启的前提下换掉一个文件
那么对于Unity3D来说，何谓热更新？
额……这个真相实在是不想讲出来，因为很多时候，这个词都用错了。
Unity3D是一个客户端工具，用户是否重启客户端，根本是我们不关心的问题。
很多时候我们用着热更新这个词汇，却不需要真的热更新。
只有少部分游戏，游戏资源在玩的过程中边玩边下，不重启的前提下变更了资源。
我们不需要用户不重启客户端就能实现资源代码的更新，我们需要的是用户重启客户端能实现资源代码的更新。
 
让我们暂时放过这个我们的需求连词汇都用错了这个基本事实，来总结一下何谓Unity3D热更新
Unity3D热更新就是指：用户重启客户端就能实现客户端资源代码更新的需求或者功能。
为何热更新

热更新，能够缩短用户取得新版客户端的流程，改善用户体验。

没有热更新：

pc用户：
下载客户端->等待下载->安装客户端->等待安装->启动->等待加载->玩
手机用户：
商城下载APP->等待下载->等待安装->启动->等待加载->玩

有了热更新

pc用户：
启动->等待热更新->等待加载->玩
有独立loader的pc用户：
启动loader->等待热更新->启动游戏->等待加载->玩
手机用户：
启动->等待热更新->等待加载->玩

通过对比就可以看出，有没有热更新对于用户体验的影响还是挺大的，主要就是省去用户自行更新客户端的步骤。
为了方便用户、留住用户、进而从留住的用户身上赚到钱，热更新如今已经成为了大部分游戏的标配功能。
如果你的游戏不标配这个功能，那么竞争力就会少一些，无论是主动还是被动，无论是方便用户还是被标配，你都必须面对热更新这个课题，虽然这个词用错了。
如何热更新

热更新是为了让用户获得资源和代码的变更，这里的代码不是指真的代码，用户不要代码，他要的是变化的业务逻辑。实现变更的具体过程是首先查并更新本地资源和业务逻辑，如需下载则下载。然后启动时资源均从本地资源创建，业务逻辑从本地执行。

Unity3D提供了一种机制AssetBundle，可以满足所有资源的比对下载加载，但是assetbundle每平台分别打包对于多平台项目而言比较麻烦，是一个明显的短板，而且assetbundle不能脱离unityeditor产生，也是一个麻烦，项目大了话，多人合作，把所有资源都放入assetbundle明显降低效率。
对于代码，Unity3D是不提供变更机制的。但是Unity3D执行核心是Mono，也就是dotnet，dotnet有一种符号反射机制，可以直接加载一个dll，然后反射出其中的类型进行操作。符号和反射的主要问题是有些平台不能使用，比如ios wp8。另外dotnet有一种emit机制，可以运行时调用编译器对代码进行编译，他的问题也是平台不支持。
以上两点是Unity3D免费赠送给你的帮助
如果不能满足你的需求，你就需要自己搞定三个模块：
资源下载模块
当assetbundle不能满足需要时，我们需要自己建立检查更新需要则下载的机制，也就是资源下载模块。
这个资源下载模块应该有一个版本生成工具，我们将一组文件生成一个一个版本待下载。
有一个Unity3D用的下载模块，下载模块会首先检查服务器上的版本信息，和本地信息做比对，需要的文件则下载。
资源加载模块
然后需要建立自己的从下载保存在本地的文件中加载出资源的机制，也就是资源加载模块。
资源加载模块负责从下载的文件中加载出资源。
如果你希望游戏带有一份初始资源文件，这里有两种思路
一种是资源加载模块直接提供从包内文件和下载文件两种加载路径
一种是游戏第一次启动时，将包内文件全部copy到下载文件
脚本模块
当符号反射不能满足需求时，业务逻辑更新就只有套用脚本语言这一条路，也就是脚本模块。
虽然dotnet世界里有很多脚本可以用 ironRuby ironPython,可是在unity这个特定环境下全部不可用。
你可以使用的一个选择是lua，这个由魔兽世界采用作为界面脚本，从而红遍整个游戏行业，十年经久不衰的脚本。
unity有了很多lua的绑定库，也有了unilua这样的pure c#移植实现。
你还有一个选择是C#Light/Evil，他是C#语法的，pure c#实现的一门新生脚本语言，就是为了Unity3D逻辑热更新而生。


参考文章：http://blog.gamerisker.com/archives/461.html
                 http://blog.csdn.net/janeky/article/details/25923151
 http://blog.csdn.net/cagehe/article/details/18017019



本文来自：http://www.cnblogs.com/crazylights/p/3884650.html

热更新

热更新：浏览器的无刷新更新，允许在运行时替换，添加，删除各种模块，而无需进行完全刷新重新加载整个页面

目的：加快开发速度，所以只适用于开发环境下使用

思路：
保留在完全重新加载页面时丢失的应用程序的状态

只更新改变的内容，以节省开发时间

调整样式更加快速，几乎等同于在浏览器调试器中更改样式
使用：

引入webpack库

使用了new webpack.HotModuleReplacementPlugin()

设置devServer选项中的hot字段为true
热重载 hot reload
开发阶段，如果每次文件变更后，都要手动去打包是很不方便的。

通常在开发阶段采用以下三种方式进行热重载
webpack的Watch Mode

webpack-dev-server

webpack-dev-middleware