本发明涉及android系统的基本功能领域，尤其涉及一种android应用程序的在线云更新方法。
背景技术
随着手机的普及，android应用的繁荣，各应用厂商为适应市场，不断迭代更新，开发新版本的应用。目前市场上大部分的应用和游戏应用，依然使用的是传统的版本更新，而传统更新方式因为涉及到的分发渠道过多，需要渠道-cp-发行配合处理，导致整个更新过程异常繁琐；在应用游戏更新时，还经常会遇到因网络不稳定而导致的更新缓慢异常乃至崩溃的情况，浪费用户大量的流量和宝贵时间，影响用户的正常体验。版本升级方式则需要用户到指定链接下载新版apk进行版本升级，或者由应用（游戏）自己下载，下载完成后，然后需要用户在手机上覆盖安装或者卸载旧版本再安装新版本。
此技术中存在着以下缺点，即多渠道更新繁琐、更新不稳定，浪费下载流量、更新过程时间长、更新过程中影响用户操作、用户需自己手动完成更新、无法统计各渠道版本更新的成功率等问题。
技术实现要素：
本发明的目的在于提供一种android应用程序的在线云更新方法，以解决上述现有技术不足的问题。
为实现上述发明目的，本发明采用如下技术方案：
本发明提供了一种android应用程序的在线云更新方法，其包括如下的步骤：
步骤1，在应用程序内部写入渠道标示tag，通过客户端和服务端的数据交互，由服务端判断tag，确定安装了该渠道的设备是否更新应用，若未更新应用，则由客户端发送更新请求至服务端；
步骤2，在更新过程中由服务端对比新旧应用程序，使用补丁生成工件生成新旧版本之间产生的补丁，并搭配优化的afinal网络下载框架下载更新补丁；
步骤3，所述更新过程中采用静默更新的方式，采用多线程的方式，在后台下载更新补丁，并使用c层的合并补丁代码去合并补丁，产生新版本apk；
步骤4，采用classloader动态加载的方式，去加载通过合并补丁生成的新版本apk，并通过hook四大组件，application，动态代理组件和加入新版本资源的方式，通过使用旧版本的云更新外壳去完成新版本apk的加载，使之不用通过系统安装运行起来，即完成更新；
步骤5，在更新过程前、更新过程后，向服务端发送对应的设备，版本信息，以及更新的结果，由服务端统计各参数并在服务器前台向用户展示。
作为本发明对上述方案的优选，所述客户端通过3g、4g、5g、wifi或nfc技术与服务端连接，实现数据的通讯。
作为本发明对上述方案的优选，所述步骤1中客户端发出的更新请求的同时，会在应用程序界面出现版本更新提示框。
作为本发明对上述方案的优选，所述服务端获取客户端所发出的更新请求后，会对更新请求的合法性进行验证。
本发明的有益效果在于：本发明通过在应用程序写入tag标示，从而客户端和服务端通过数据交互，由服务端判断tag标示，从而避免了多分发渠道导致的更新过程繁琐问题；本发明的更新过程中只需下载新旧版本之间产生的补丁，而非完整的新版本应用，从而节省下载流量，减少下载时间；本发明采用静默更新的方式，利用多线程在后台更新补丁，能够不影响用户操作；此外，本发明还解决了用户下载完成新版本后，需自己手动完成更新的问题，以及统计各渠道版本更新的成功率的问题。
附图说明
图1为本发明所述的一种android应用程序的在线云更新方法的wifi环境下的更新过程流程图；
图2为本发明所述的一种android应用程序的在线云更新方法的默认更新过程流程图；
图3为本发明所述的一种android应用程序的在线云更新方法的强制认更新过程流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1至图3的一种android应用程序的在线云更新方法，具体包括如下步骤：
针对应用型包体，将原apk反编译后，插入云更新的代码，如果方法数超过65535，就对dex进行分包处理，将云更新的启动代码作为class.dex而用户原dex作为class2.dex，如果未超过就直接合成一个class.dex。并在androidmanifest.xml中写入云更新需要声明的权限和组件，在资源assets下放入对应的ui资源图片，回包生成集成云更新后的apk。
针对游戏型的apk，与上面不同的是，不再判断方法数，直接进行分包，即将云更新的代码打成class.dex而将原包的dex封装成libijm_packet..so，放入lib目录下。
apk启动时，会动态代理apk的application，优先启动云更新的application，在其中完成云更新一系列的初始化操作，如本地配置写入，启动hook框架，多dex的加载，动态加载apk，签名校验，完整性校验，执行完之后，再启动原包apk的application，接着再动态代理四大组件，启动相对应的组件，完成外壳程序对原有程序生命周期的接管。最后启动入口activity，完成apk的启动。
启动完成后，云更新将开启后台服务，开启一条线程去检测更新，这里使用的是afinal网络框架，客户端将本地的相关配置用protobuf封装后发送给服务端，服务端根据用户的更新策略（这里以静默更新为例），将更新策略，下载地址，校验信息等数据返回给客户端，客户端根据策略，静默下载对应的补丁文件，下载完毕后，调用c层的合并补丁功能，静默合并补丁，合成新版本的apk，并计算该apk的crc32值，与服务器返回的检验信息进行比对，如果不同，证明合并失败，将重新从服务器下载完整的apk放入sdcard中对应的obb目录下，以保证下载合并环节的可靠性。完成后，释放新版本的so到/data/data/包名/files/plugin……下，保存新版的配置信息，写入到本地sharedpreference中，并开启服务对新版dex进行优化，以减少下次启动的时间。同时在回报线程中，发送更新成功的相关信息给服务器，如系统版本、更新版本、设备型号等，以方便服务器进行统计，并将更新成功率和版本分布，型号分布，在服务器前台展示给用户。
以上过程即已完成更新，而在更新过程中，将不影响用户的正常操作，待用户重新启动应用，则进入该应用的新版本。该种方法能够把多渠道更新变得简单，更新过程更加稳定，节省下载流量，缩短更新过程的时间、更新过程中不会影响用户操作、无需用户手动自动完成更新，并且可以直观看到各渠道版本更新的成功率。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换,凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。