软件的增量更新
由于转战C#了，之前许多东西都丢了。如今从头开始弄基本效劳，起首第一个就是客户端的自动更新。之前简朴搜了一下相干功用的完成。有一个文章我没有看懂，另一片文章里边说的应当是提交当地数据，然后盘算差别化包，让效劳器返回差别化数据包。固然如许不是不可。肯定是可行的，然则关于效劳器来讲这部份事变可以就有点贫苦了。由于你得让效劳器有这个盘算才能。参考Cocos2dx 3.9的Lua增量更新模块，简朴做了一个基本框架模子出来。
本来怎样做
掩盖装置
这个实在很简朴，就是从新下载一个完全的装置包，然后从新装置一遍，不论本来存不存在内容，假如本来存在内容那末久替换掉，假如本来不存在内容那末就增加上新内容就是了。实在这个说起来很简朴，然则可以会存在一些题目。
- 流量题目 可以如今看来这个题目并非多么大的题目，由于如今带宽已异常宽了。100M的内容依据10Mpbs的带宽来算，也就一分多钟就可以下载完了。 - 渣子题目 这类掩盖装置平常会存在一个渣子的题目。比方说，我在装置目次里边生成了一个不在后续装置包的文件，那末这个文件就没有办法被清算掉。这就可以够很为难了，比方说你的项目依靠体系供应的一个Dll，假如你的目次中直接存在这个Dll那末就会优先运用你对应目次中的Dll（假如我没记错应当是如许），假如是我作为攻击者的话，我很有可以会给你放一个我种下病毒的Dll。这就很为难了
打补丁
这个道理也比较简朴，实在就是我们都以为完全装置太费力了，那末我的软件又须要比较频仍的更新，比方说某些桌游可以过个节日要上节日相干的功用，如许就可以够增加新的Dll然后又不能出一个一个的完全装置包。那末我可以在完全装置包的基本上打补丁嘛。比方说，我出了版本1.0，过了十天半个月过端五了，我出个龙舟皮肤一类的，那我就可以够直接在1.0的基本上打个龙舟补丁，如许他就变成了最新的客户端1.1。假如未来要上别的功用了我就在1.1的基本上打个补丁，让客户端变成1.2。不过如许也会有他的题目。
- 递次装置 在装置的过程当中只能以此递增式装置，我只能1.0 => 1.1 => 1.2；不能1.0 =》 1.2。由于中心是没有对应的补丁的。 - 流量题目 实在这类解决方案可以会带来一些题目，比方说，如今端五节，我须要把屋子装潢成龙舟的款式；然后五一劳动节，我又须要把屋子装修成五一劳动节的模样。那末都是关于屋子的皮肤，我是没有办法都保存的，由于来年的时刻肯定就不能这么装修了，由于过期了太Low了。那末关于这部份的内容，假如你想一点一点的升级上来关于末了的版本来讲是没用的，你占用的流量一点用都没有。太为难了。 - 保护的庞杂度 由于你不能直接出了一个1.0今后全都是运用补丁，假如当你的版本号递增到肯定水平今后，补丁的大小可以远远超过了你从新去下载一个最新的客户端的大小。所以只能经由过程期间也好（比方半年或许一个季度）经由过程意义（比方说大版本号 2.0 3.0）来生成一个完全的客户端。如许用户在下载的时刻就可以够找一个近来的完全的客户端版本号。然后再打补丁的体式格局来取得最新的客户端，不过这类保护的庞杂度应当也不小。
理理我们最中心的需求吧
实在我们的需求很简朴，猎取最新的客户端。然后附加请求就是要省流量、下载轻易、效劳端宣布轻易。
省流量
实在说到省流量，就是能用当地的就直接运用当地。当地实在是没有的文件，那末就从收集上下载。如许基本上就做到了省流量的结果。
下载轻易
不须要做太多的操纵，固然这个许多软件都做到了这一点。上文中提到的实在也可以做到自动化，比方说，完全装置的那末我就直接下载最新的完全装置包就好了，假如是打补丁的这类，那末就下载最新的完全装置包以及后边的补丁就好了。实在这个真的要做，对用户来讲应当是没有感以为。都一样，不过关于顺序员来讲。可以面对的开辟就不太一样了。
效劳端宣布轻易
实在这个完全是针关于顺序员的了，平常来讲，假如这个事变可以顺序来自动完成那末就肯定交给顺序了。比方说完全晚装包的这类，肯定可以做到自动打包。打补丁的这类，不过也就是依据上一个版本生成一个补丁。或许再生成一个完全装置包。上传到适宜的文件效劳器就好了。实在打补丁也好，完全装置包也好，都有一个明显的上风就是可以很轻易的放到多个效劳器上来举行文件的负载平衡。
那末我们该怎样做
在斟酌这个题目的时刻，我想到了之前打仗的Cocos2dx 3.9 Lua 自动更新模块，他是这么做，经由过程一个设置文件，来讲明最新的客户端中都包含了那些文件，这些文件的MD5值是什么，然后收集途径是什么。如许客户端拿到这个设置清单的时刻，就可以够轻松的推断当地的那些文件是可以继承用的。那些文件是过期了的，如许客户端经由过程设置心中的收集途径位置猎取最新的对应文件就好了嘛。不过那也是良久之前的事变了，不然，我就不须要本身从新规划了。直接抄一份代码就好了嘛。照样本身整顿一套吧。如许来的更完全一些，想改什么就改什么。
文件的花样
{"VersionsCheckCode": "XC09VU4QCRD43LRF01BYOD26D45DWEEKX5KECUKIA7Q4160FKAWQBHXTKE63Z148","TimeStamp": 1496649771,"ServerUrl": "http://or2dwwrsz.bkt.clouddn.com","FileInfos": [{"FilePath": "JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\net40\\Moq.xml","FileMD5": "c7e9c70a19b84f31e51eb65f4ee38803","FileUrl": "LV4ZBB_c7e9c70a19b84f31e51eb65f4ee38803"},{"FilePath": "JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\sl4\\Moq.Silverlight.dll","FileMD5": "0ee20e7ccba7d6667c48efebe41503ff","FileUrl": "X057QT_0ee20e7ccba7d6667c48efebe41503ff"},{"FilePath": "JumpKick.HttpLib\\packages\\Moq.4.2.1409.1722\\lib\\sl4\\Moq.Silverlight.xml","FileMD5": "c25417228db2dd820f45e93112e8596c","FileUrl": "S0LO6G_c25417228db2dd820f45e93112e8596c"}]}
简朴的申明
VersionsCheckCode：当前的版本文件校验信息。
TimeStamp：做这个文件的的时候戳
ServerUrl：效劳器的地点，主如果用来跟后续的文件举行拼接来用的
FileInfos：对应的文件信息列表
FileInfos[?]:FilePath：当地文件途径，从收集下载今后对应的当地地点
FileInfos[?]:FileMD5：这个文件的MD5值，用来推断原始的对应位置的文件是不是与收集中的文件雷同
FileInfos[?]:FileUrl：这个文件在收集中存在的位置，固然这个是没有前边的URL途径的是ServerUrl后边的内容
项目地点
实在嘛全部项目最庞杂的处所时这个更新的主意与这个文件的制订。剩下的内容实在就比较简朴了，就是细致的代码的完成了。代码轻易我就懒得讲了，直接把项目的地点扔上来了事。
客户端
效劳端
如许做的优点
省流量、跟其他软件连系轻易、效劳器宣布轻易。省流量这个上边提到了我就说了。
跟其他软件连系轻易
实在很轻易明白，就是这个软件跟被更新的软件一毛钱关联没有。所以我可以直接跑起来就好了，不须要关联细致被更新的软件是怎样搞得。最多采纳这个的项目。从新改一下我们这边的UI就好了。
效劳器宣布轻易
实在最贫苦的事变就是效劳器这边。须要生成这个设置文件，我这边效劳器端实在并没有在运转指的就是生成这个文件的东西。我可以指定一个目次。然后生成这个文件，将对应目次的一切文件导出到一个输出目次。不过关于许多CDN不支持多级目次（比方七牛），所以我将一切的文件都换掉了名字，让他们只管的不反复，顺序可读就好了。
怎样用
起首运用我写好的效劳端生成对应的设置文件和更名文件。
生成的目次构造是如许色的，设置文件放到一个牢固的目次里边去。UpLoad文件夹上传到某一个文件效劳器上，这里我是用的七牛云
然后把UpLoad目次中的文件全都上传上来
上传完了就是这个模样的。
致辞效劳器就布置好了，等有了新版本反复一遍这个操纵就行。实在上传效劳器的这部份事变可以集成到效劳端中。上传内容就好了嘛，实在很简朴的。固然了，这个我懒。之前也没有研讨七牛的SDK这个可以作为一个功用上的扩大，横竖项目我已开源了，感兴趣的人可以本身扩大这部份功用。好吧我们继承来讲客户端怎样弄吧。
怎样用客户端呢
AutoUpdateHelper helper = new AutoUpdateHelper();
helper.WebXmlUrl = "http://7xs9hw.com1.z0.glb.clouddn.com/VersionInfo.json";
helper.ConfigXmlPath = "SynchronizeVersions.xml";
helper.TempXmlPath = "SynchronizeVersions_Temp.xml";
helper.FilePath = "Client";
helper.CallBack = obj =>
{
if (obj is Dictionary<UpdateDataType, object>)
{
var dic = obj as Dictionary<UpdateDataType, object>;
foreach (var item in dic)
{
if (Name2Action.ContainsKey(item.Key))
Name2Action[item.Key](item.Value);
}
}
};
try
{
helper.Start();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
实在就是一个简朴的设置网址跟设置文件。实在呢这个处所应当吧设置也放到设置文件里边去，为何没放呢？由于我懒，哈哈哈。
客户端的运转图
客户端跑完了就关了，实在应当是跑完了运转某一个细致的文件，然后自动更新的逻辑就完成了，这部份我会今后继承完美。
不妥的地方
这么样处置惩罚实在下载会变得很天真。然则也会带来其他的题目。比方之前提到的打包的题目。由于效劳器只是一个文件效劳器，所以效劳器并没有盘算出差别包的才能，所以一切的文件都是一个一个的下载的，如许就会涌现许多小文件的下载。如许的下载实际上是比较蛋疼的。这是设想上的坑。为了天真只能让步了。
完成的不妥的地方
实在到目前为止我只是完成了最基本的功用。以至还不全，比方今后的文件启动，不过大致的框架已搭建起来了。至于后边有许多完成不是很合理的处所，我先简朴列一列，轻易今后保护。
下载失利重试不存在
下载数目的限定不存在（如今是有若干下载若干，许多同时下载可以会存在超时的题目。）
完成了今后没有启动对应的文件
如今没有疾速启动的功用（如今每次启动都须要从新校验一切文件，实在可以防止这个题目的。）
后话
虽然这个项目只是一个并不完美的框架。然则这类更新体式格局应当会让更新变得更有意义。让我们一块来完美这个框架吧。比较愿望做一个胜利的开源项目，不忘初心。
以上就是软件的增量更新是什么？的细致内容，更多请关注ki4网别的相干文章！
