[阿里Hao]Android无线开发的几种经常使用技术

Posted 2020-09-30 gccbuaa

本文由阿里巴巴移动安全client、YunOS资深project师Hao（嵌入式企鹅圈原创团队成员）撰写，是Hao在嵌入式企鹅圈发表的第一篇原创文章。对android无线开发的几种经常使用技术进行综述。

嵌入式企鹅圈现拥有七个专栏（Linux内核驱动情景分析、资源紧缺型SOC嵌入式架构设计、嵌入式交叉工具链及其应用、嵌入式设计和编程、微信硬件平台和物联网解决方式、Android开发、开发资源共享）。

很多其它Android、Linux、嵌入式和物联网原创技术分享敬请关注微信公众号：嵌入式企鹅圈。我们百分百原创，资深project师毫无保留分享研发经验！

完整的开发一个android移动App须要经过从分解需求、架构设计到开发调试、測试、上线公布等多个阶段。在公布后还会有产品功能上的迭代演进，此外还会面对性能、安全、无线网络质量等多方面的问题。

移动App的产品形态各不同样。有的是内容类，有的是工具类，有的是社交类，所以它们的业务逻辑所偏重的核心技术有些区别。但它们都会用到一些经常使用的技术方案。

今天我们就先来简介一下这些经常使用技术，以后会专门分专题来具体介绍这些技术的原理和使用场景。

1.    Multidex

在Dalvik虚拟机所使用的dex文件格式中，用原生类型short来索引文件里的方法数。也就是最多仅仅能有4个字节65536个method。在打包apk的过程中会把project所须要的所有class文件都合并压缩到一个dex文件里，也就是说自己开发的代码加上外部引用的库的方法总数不能超过65535。

随着业务逻辑的不断增长。非常easy就会超过这个限制，在编译期间就会遇到这样一个错误：

还好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的心跳机制，和client维持一个长连接。

用处是向client推送消息。或者取代client定时去从serverpull的策略，改为client接收到push消息后再去pull。

假设每一个应用都自己实现push通道的话，cpu就会不定时地经常被唤醒，耗电量达到难以容忍的程度，并且自己搭建push平台的成本也非常大。实时性和效率也存在问题。一般都直接使用一些服务商提供的push方案，这些push平台一般都经过了优化设计，在跨平台和网络穿透性、长连接心跳包、多clientApp链路复用、服务和连接保活等技术上做了优化。

比方Agoo最初是淘宝无线事业部开发的push服务，在逐渐完好和支撑淘系其它app后，通过服务端容量、通讯协议优化、业务和开放能力的拓展改进后，与友盟等合作。開始向第三方提供推送服务。

5.    应用加固

一款热门的移动app或游戏公布后会受到非常多的关注。经常会遇到二次打包的盗版行为，破解者要么改动游戏的资源文件、道具、分值甚至直接把訪问的网站指向自己架设的server，损害了开发人员的利益；要么偷偷植入自己的恶意代码。表面上看起来跟正版的app全然一样，在后台却盗取用户隐私，植入木马；要么通过反向project学习原app的核心技术。打破技术上的竞争壁垒。

为了防止被破解仅仅通过混淆是远远不够的。即使是在native层混淆也还是会被人熟练的反编译。所以须要一套对apk的保护方案来反调试、防逆向和防篡改。一般的加固方法都是对原apk先进行加密，然后和壳合并生成新的apk。

壳是用来解密apk的dex文件。

当应用启动时。壳先解密原apk。准备好自定义的ClassLoader。然后获取源程序中的Application名称。通过反射找到正确的Application对象，执行它的onCreate方法，这样原apk才干被真正执行。其它一些反调试的方法有针对反编译工具，在源程序中增加一些无效的指令或无效的指针，引发反编译工具的崩溃，还有就是加花指令，利用一些跳转，堆栈操作等指令。让破解者无法清楚地理解反汇编后的内容。

6.    其它

除了上述几点外。在服务端还会涉及灰度策略、链路流量优化、动态更新配置、防DNS劫持等技术，在client会涉及用户埋点上报、在线监控、进程保活、H5和native混合开发、注入框架等。

对于以上技术。本人会在后面慢慢铺开。深入分析。完整地展示给大家。敬请关注！

很多其它Android、Linux、嵌入式和物联网原创技术分享敬请关注微信公众号：嵌入式企鹅圈。