Android渠道打包技术小结

简介:

导读

本文对比了渠道4种渠道打包方式:

与iOS的单一渠道(AppStore)不同,Android平台在国内的渠道多入牛毛。以我们的App为例,就有27个普通渠道(应用宝,百度,360这种)和更多的推广专用渠道。我们打包技术也经过了若干次的改进。

1.利用Gradle Product Favor打包

 
 
  1. android { 
  2.     productFlavors { 
  3.         base { 
  4.             manifestPlaceholders = [ CHANNEL:”0"] 
  5.         } 
  6.         yingyongbao { 
  7.             manifestPlaceholders = [ CHANNEL:"1" ] 
  8.         } 
  9.         baidu { 
  10.             manifestPlaceholders = [ CHANNEL:"2"
  11.         } 
  12.     } 
  13.  

AndroidManifest.xml

 
 
  1. <!-- 自用渠道号设置 --> 
  2. <meta-data 
  3.      android:name="CHANNEL" 
  4.      android:value="${CHANNEL}”/>  

原理很简单,gradle编译的时候,会根据这个配置,把manifest里对应的metadata占位符替换成指定的值。然后Android这边在运行期再去取出来就是:

 
 
  1. public static String getChannel(Context context) { 
  2.     String channel = ""
  3.     PackageManager pm = sContext.getPackageManager(); 
  4.     try { 
  5.         ApplicationInfo ai = pm.getApplicationInfo( 
  6.             context.getPackageName(), 
  7.             PackageManager.GET_META_DATA); 
  8.  
  9.         String value = ai.metaData.getString("CHANNEL"); 
  10.         if (value != null) { 
  11.             channel = value; 
  12.         } 
  13.     } catch (Exception e) { 
  14.         // 忽略找不到包信息的异常 
  15.     } 
  16.     return channel; 
  17. }    

这个办法,缺点很明显,每打一个渠道包都会完整得执行一遍apk的编译打包流程,非常慢。近30个包要打一个多小时…优点就是不依赖其他工具,gradle自己就能搞定。

2.替换Assets资源打包

assets用于存放一些资源。不同与res,assets里的资源编译时原样保留,不需要生成什么resouce id之类的东西。因此,我们可以通过替换assets里的文件打出不同的渠道包,而不用每次都重新编译。

我们知道apk本质上就是个zip文件,那么我们就可以通过解压缩->替换文件->压缩的办法来搞定:

这里给出一份Python3的实现

 
 
  1. # 解压缩 
  2. src_file_path = '原始apk文件路径' 
  3. extract_dir = '解压的目标目录路径' 
  4. os.makedirs(extract_dir, exist_ok=True
  5.  
  6. os.system(UNZIP_PATH + ' -o -d %s %s' % (extract_dir, src_file_path)) 
  7.  
  8. # 删除签名信息 
  9. shutil.rmtree(os.path.join(extract_dir, 'META-INF')) 
  10.  
  11. # 写入渠道文件assets/channel.conf 
  12. channel_file_path = os.path.join(extract_dir, 'assets''channel.conf')with open(channel_file_path, mode='w'as f: 
  13.     f.write(channel)  # 写入渠道号写进去 
  14. os.chdir(extract_dir) 
  15.  
  16. output_file_name = '输出文件名称' 
  17. output_file_path = '输出文件路径' 
  18. output_file_path_tmp = os.path.join(output_dir, output_file_name + '_tmp.apk'
  19.  
  20. # 压缩 
  21. os.system(ZIP_PATH + ' -r %s *' % output_file_path) 
  22. os.rename(output_file_path, output_file_path_tmp) 
  23.  
  24. # 重新签名 
  25. # jarsigner -sigalg MD5withRSA -digestalg SHA1 -keystore your_keystore_path 
  26. # -storepass your_storepass -signedjar your_signed_apk, your_unsigned_apk, your_alias 
  27. signer_params = ' -verbose -sigalg MD5withRSA -digestalg SHA1' + \ 
  28.           ' -keystore %s -storepass %s %s %s -sigFile CERT' % \      
  29.            ( 
  30.                     sign, # 签名文件路径 
  31.                     store_pass, # 存储密码 
  32.                     output_file_path_tmp, 
  33.                     alias # 别名                 
  34.            ) 
  35.  
  36. os.system(JAR_SIGNER_PATH + signer_params) 
  37.  
  38. # Zip对齐 
  39. os.system(ZIP_ALIGN_PATH + ' -v 4 %s %s' % (output_file_path_tmp, output_file_path)) 
  40. os.remove(output_file_path_tmp)  

在这里,几个PATH分别表示zip、unzip、jarsigner和zipalign这几个可执行文件的路径。

签名是apk的一个重要机制,它给apk里的每一个文件(META-INF目录下的除外)计算一个hash值,记录在META-INF下的若干文件里。Zip对齐能够优化运行时Android读取资源的效率,这一步虽然不是必须的,但还是推荐做一下。

采用这个方法,我们不需要再编译Java代码,速度有极大地提升。大约每10秒就能打一个包。

同时给出读取渠道号的实现代码:

 
 
  1. public static String getChannel(Context context) { 
  2.     String channel = ""
  3.     InputStream is = null
  4.     try { 
  5.         is = context.getAssets().open("channel.conf"); 
  6.         byte[] buffer = new byte[100]; 
  7.         int l = is.read(buffer); 
  8.  
  9.         channel = new String(buffer, 0, l); 
  10.     } catch (IOException e) { 
  11.         // 如果读不到,那么取缺省值 
  12.     } finally { 
  13.         if (is != null) { 
  14.             try { 
  15.                 is.close(); 
  16.             } catch (Exception ignored) { 
  17.             } 
  18.         } 
  19.     } 
  20.     return channel; 
  21.  

顺便说一下,还可以用aapt这个工具来替代zip&unzip来实现文件替换:

 
 
  1. # 替换assets/channel.conf 
  2. os.chdir(base_dir)    
  3. os.system(AAPT_PATH + ' remove %s assets/channel.conf' % output_file_path_tmp)    
  4. os.system(AAPT_PATH + ' add %s assets/channel.conf' % output_file_path_tmp)  

3.美团给出的一种方案

刚才上文提到META-INF目录对签名机制是豁免的,往这里面放东西就可以免去重签名这一步,美团技术团队就是这么做的。

 
 
  1. import zipfile 
  2. zipped = zipfile.ZipFile(your_apk, 'a', zipfile.ZIP_DEFLATED) 
  3. empty_channel_file = "META-INF/mtchannel_{channel}".format(channel=your_channel) 
  4. zipped.write(your_empty_file, empty_channel_file)  

给META-INFO目录加入一个名为“mtchannel_渠道号”的空文件,在Java这边查找到这个文件,取得文件名即可:

 
 
  1. public static String getChannel(Context context) { 
  2.     ApplicationInfo appinfo = context.getApplicationInfo(); 
  3.     String sourceDir = appinfo.sourceDir; 
  4.     String ret = ""
  5.     ZipFile zipfile = null
  6.     try { 
  7.         zipfile = new ZipFile(sourceDir); 
  8.         Enumeration<?> entries = zipfile.entries(); 
  9.         while (entries.hasMoreElements()) { 
  10.             ZipEntry entry = ((ZipEntry) entries.nextElement()); 
  11.             String entryName = entry.getName(); 
  12.             if (entryName.startsWith("mtchannel")) { 
  13.                 ret = entryName; 
  14.                 break; 
  15.             } 
  16.         } 
  17.     } catch (IOException e) { 
  18.         e.printStackTrace(); 
  19.     } finally { 
  20.         if (zipfile != null) { 
  21.             try { 
  22.                 zipfile.close(); 
  23.             } catch (IOException e) { 
  24.                 e.printStackTrace(); 
  25.             } 
  26.         } 
  27.     } 
  28.  
  29.     String[] split = ret.split("_"); 
  30.     if (split != null && split.length >= 2) { 
  31.         return ret.substring(split[0].length() + 1); 
  32.  
  33.     } else { 
  34.         return ""
  35.     } 
  36.  

这个方法省去了重签名这一步,速度提升也很大。他们的描述是“900多个渠道不到一分钟就能打完”,也就是不到0.06s一个包。

4.利用Zip文件comment的终极方案

另外给出了一个终极方案:我们知道Zip文件末尾有一块区域,可以用来存放文件的comment。改动这个区域,丝毫不会影响Zip文件的内容。

打包的代码很简单:

 
 
  1. shutil.copyfile(src_file_path, output_file_path) 
  2.  
  3. with zipfile.ZipFile(output_file_path, mode='a'as zipFile: 
  4.      zipFile.comment = bytes(channel, encoding=‘utf8') 

这个方法比前一个方法的区别在于,它不会修改Apk的内容,也就不必重新打包,速度又有提升!

按文档中的说法,这个方法1s内可以打300多个包,也就是说单个包的时间小于10毫秒!

读取的代码稍微复杂一些。

Java 7的ZipFile类,有getComment方法,可以轻易地读取comment值。然而这个方法只在Android 4.4以及更高版本才可用,我们就需要多花点时间把这段逻辑移植过来。所幸这里的逻辑不复杂,我们查看源码,可以看到主要逻辑都在ZipFile的一个私有方法readCentralDir里,一小部分读取二进制数据的逻辑在libcore.io.HeapBufferIterator,全部搬过来,整理一下就搞定了:

 
 
  1. public static String getChannel(Context context) { 
  2.    String packagePath = context.getPackageCodePath(); 
  3.  
  4.    RandomAccessFile raf = null
  5.    String channel = ""
  6.    try { 
  7.       raf = new RandomAccessFile(packagePath, "r"); 
  8.       channel = readChannel(raf); 
  9.    } catch (IOException e) { 
  10.       // ignore 
  11.    } finally { 
  12.       if (raf != null) { 
  13.          try { 
  14.             raf.close(); 
  15.          } catch (IOException e) { 
  16.             // ignore 
  17.          } 
  18.       } 
  19.    } 
  20.  
  21.    return channel;}private static final long LOCSIG = 0x4034b50;private static final long ENDSIG = 0x6054b50;private static final int ENDHDR = 22;private static short peekShort(byte[] src, int offset) { 
  22.    return (short) ((src[offset + 1] << 8) | (src[offset] & 0xff));}private static String readChannel(RandomAccessFile raf) throws IOException { 
  23.    // Scan back, looking for the End Of Central Directory field. If the zip file doesn't 
  24.    // have an overall comment (unrelated to any per-entry comments), we'll hit the EOCD 
  25.    // on the first try. 
  26.    // No need to synchronize raf here -- we only do this when we first open the zip file. 
  27.    long scanOffset = raf.length() - ENDHDR; 
  28.    if (scanOffset < 0) { 
  29.       throw new ZipException("File too short to be a zip file: " + raf.length()); 
  30.    } 
  31.  
  32.    raf.seek(0); 
  33.    final int headerMagic = Integer.reverseBytes(raf.readInt()); 
  34.    if (headerMagic == ENDSIG) { 
  35.       throw new ZipException("Empty zip archive not supported"); 
  36.    } 
  37.    if (headerMagic != LOCSIG) { 
  38.       throw new ZipException("Not a zip archive"); 
  39.    } 
  40.  
  41.    long stopOffset = scanOffset - 65536; 
  42.    if (stopOffset < 0) { 
  43.       stopOffset = 0; 
  44.    } 
  45.  
  46.    while (true) { 
  47.       raf.seek(scanOffset); 
  48.       if (Integer.reverseBytes(raf.readInt()) == ENDSIG) { 
  49.          break; 
  50.       } 
  51.  
  52.       scanOffset--; 
  53.       if (scanOffset < stopOffset) { 
  54.          throw new ZipException("End Of Central Directory signature not found"); 
  55.       } 
  56.    } 
  57.  
  58.    // Read the End Of Central Directory. ENDHDR includes the signature bytes, 
  59.    // which we've already read
  60.    byte[] eocd = new byte[ENDHDR - 4]; 
  61.    raf.readFully(eocd); 
  62.  
  63.    // Pull out the information we need. 
  64.    int position = 0; 
  65.    int diskNumber = peekShort(eocd, position) & 0xffff; 
  66.    position += 2; 
  67.    int diskWithCentralDir = peekShort(eocd, position) & 0xffff; 
  68.    position += 2; 
  69.    int numEntries = peekShort(eocd, position) & 0xffff; 
  70.    position += 2; 
  71.    int totalNumEntries = peekShort(eocd, position) & 0xffff; 
  72.    position += 2; 
  73.    position += 4; // Ignore centralDirSize. 
  74.    // long centralDirOffset = ((long) peekInt(eocd, position)) & 0xffffffffL; 
  75.    position += 4; 
  76.    int commentLength = peekShort(eocd, position) & 0xffff; 
  77.    position += 2; 
  78.  
  79.    if (numEntries != totalNumEntries || diskNumber != 0 || diskWithCentralDir != 0) { 
  80.       throw new ZipException("Spanned archives not supported"); 
  81.    } 
  82.  
  83.    String comment = ""
  84.    if (commentLength > 0) { 
  85.       byte[] commentBytes = new byte[commentLength]; 
  86.       raf.readFully(commentBytes); 
  87.       comment = new String(commentBytes, 0, commentBytes.length, Charset.forName("UTF-8")); 
  88.    } 
  89.    return comment; 

需要注意的是,Android 7.0加入了APK Signature Scheme v2技术。在Android Plugin for Gradle 2.2,这一技术是缺省启用的,这会导致第三、第四两种方法打出的包在Android 7.0下面校验失败。解决方法有二,一是把Gradle版本改低,二是在signingConfigs/release下面加上配置v2SigningEnabled false。详细说明见谷歌的文档

总结

用表格说话





作者:贼寇
来源:51CTO
目录
相关文章
|
1月前
|
安全 Android开发 iOS开发
安卓与iOS的较量:技术特性与用户体验的深度解析
在移动操作系统的战场上,安卓和iOS一直占据着主导地位。本文将深入探讨这两大平台的核心技术特性,以及它们如何影响用户的体验。我们将从系统架构、应用生态、安全性能和创新功能四个方面进行比较,帮助读者更好地理解这两个系统的异同。
52 3
|
9天前
|
安全 Android开发 数据安全/隐私保护
探索安卓与iOS的安全性差异:技术深度分析与实践建议
本文旨在深入探讨并比较Android和iOS两大移动操作系统在安全性方面的不同之处。通过详细的技术分析,揭示两者在架构设计、权限管理、应用生态及更新机制等方面的安全特性。同时,针对这些差异提出针对性的实践建议,旨在为开发者和用户提供增强移动设备安全性的参考。
|
12天前
|
监控 Android开发 iOS开发
深入探索安卓与iOS的系统架构差异:理解两大移动平台的技术根基在移动技术日新月异的今天,安卓和iOS作为市场上最为流行的两个操作系统,各自拥有独特的技术特性和庞大的用户基础。本文将深入探讨这两个平台的系统架构差异,揭示它们如何支撑起各自的生态系统,并影响着全球数亿用户的使用体验。
本文通过对比分析安卓和iOS的系统架构,揭示了这两个平台在设计理念、安全性、用户体验和技术生态上的根本区别。不同于常规的技术综述,本文以深入浅出的方式,带领读者理解这些差异是如何影响应用开发、用户选择和市场趋势的。通过梳理历史脉络和未来展望,本文旨在为开发者、用户以及行业分析师提供有价值的见解,帮助大家更好地把握移动技术发展的脉络。
|
16天前
|
开发工具 Android开发 iOS开发
掌握安卓与iOS应用开发:关键技术与未来展望
本文深入探讨了安卓和iOS平台下的应用开发技术,重点比较了两大平台的架构、开发工具和市场策略。通过分析最新的技术趋势和开发者社区的反馈,文章为读者提供了一个全面的对比视角,旨在帮助开发者做出更明智的平台选择和开发决策。
|
10天前
|
安全 Java Android开发
掌握安卓与iOS应用开发中的关键技术
本文深入探讨了安卓和iOS平台上应用开发的关键性技术,包括平台特性、开发工具选择、性能优化技巧及跨平台开发的可行性分析。通过对比两种平台的开发环境与实践案例,旨在为开发者提供全面的视角以理解和把握移动应用开发的核心技术。无论是安卓的Java与Kotlin之争,还是iOS的Swift语言革命,本文都将一一解析其优势与应用场景,帮助开发者在技术选型上有更明智的决策。此外,文章还将触及到当前流行的跨平台框架如React Native和Flutter,评估它们在项目实施中的实用性和限制,为有意进行多平台同步开发的团队提供参考。通过对这些关键技术的梳理,本文期望能够启发开发者深化对移动平台开发的理解,并
|
14天前
|
人工智能 vr&ar Android开发
探索安卓与iOS的无限可能:移动操作系统的技术革新与未来展望
本文旨在探讨安卓和iOS这两大主流移动操作系统在技术上的创新与突破,以及它们如何塑造我们的数字生活。通过深入分析两者的最新进展、面临的挑战以及未来的发展趋势,文章揭示了移动操作系统在推动科技进步和满足用户需求方面的关键作用。我们将从技术角度出发,解读安卓的开放性与iOS的封闭性如何影响应用生态和用户体验,并探讨这些差异背后的设计理念和商业考量。同时,我们还将关注两大系统在安全性、隐私保护、人工智能集成等方面的最新动态,以及它们如何应对日益增长的网络安全威胁和用户对隐私保护的需求。此外,文章还将展望未来移动操作系统的发展,分析5G、物联网等新兴技术如何为安卓和iOS带来新的机遇和挑战,以及这两大
37 6
|
16天前
|
安全 Linux Android开发
探索安卓与iOS的安全性差异:技术深度分析
本文深入探讨了安卓(Android)和iOS两个主流操作系统平台在安全性方面的不同之处。通过比较它们在架构设计、系统更新机制、应用程序生态和隐私保护策略等方面的差异,揭示了每个平台独特的安全优势及潜在风险。此外,文章还讨论了用户在使用这些设备时可以采取的一些最佳实践,以增强个人数据的安全。
|
22天前
|
API Android开发 iOS开发
掌握安卓与iOS应用开发中的依赖注入技术
本文探讨了在安卓和iOS应用开发中,如何有效利用依赖注入技术来提升代码的模块化、可测试性和可维护性。通过对比分析两种平台下依赖注入的实现方式与工具,本文旨在为开发者提供一套清晰、实用的依赖管理策略,助力打造高质量软件产品。
|
1月前
|
安全 Android开发 iOS开发
安卓与iOS的较量:技术特性与用户体验的深度剖析
在移动操作系统的战场上,安卓和iOS一直是两个重量级选手。本文将深入探讨两者的技术架构、安全性、应用生态以及用户体验等方面的差异,并尝试从用户和开发者的角度出发,分析这两个系统的优势与不足。通过比较,我们不仅能更好地理解各自的特点,还能洞察未来移动技术的发展趋势。
|
18天前
|
Android开发 Swift iOS开发
掌握安卓与iOS应用开发:关键技术与市场趋势
本文深入探讨了安卓和iOS平台的应用开发,通过分析关键技术如Kotlin、Swift及Flutter,并结合当前市场趋势,为开发者提供全面的技术指南。同时,比较了两大平台的优劣势,帮助开发者做出更明智的决策。
下一篇
无影云桌面