iOS 浅谈 APP ipa包的结构

App.jpg

相信大家都知道，程序由 Xcode 编译 打包之后会生成一个 ipa 的包，那么包里面的内容是什么？以及各个文件代表什么？有兴趣的可以接着向下看

准备工作

• 一个 app 应用程序，后缀由.ipa 改为.zip。

浅谈各个结构

打开后会有下面 4 个文件。

• iTunesArtwork ：app 的高分辨率图标，通常是一个 JPG 图像文件。
• iTunesMetadata ：app 的属性列表文件，是个二进制的 plist 文件
• META-INF（文件夹）：作者猜测主要是描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件纪录等功能。
• Payload：里面有个 .app 的文件，右键显示包内容。打开后会发现里面很凌乱，咱们一个一个的来看。

.app 里面的内容

• _CodeSignature：文件的 hash 列表。里面有一个文件 CodeResources 这个文件很重要，它是一个属性列表，包含 bundle 中所有其他文件的列表。这个属性列表只有一项 files，这是一个字典，键是文件名，值通常是 Base64 格式的散列值。如果键表示的文件是可选的，那么值本身也是一个字典，这个字典有一个 hash 键和一个 optional 键（布尔值 true）。它的作用是用来判断一个应用程序是否完好无损，能够防止不小心修改或损坏资源文件。

• 见到一些后缀是 .bundle 的文件。

  bundle 概念不仅是应用程序的根基，也是框架、插件、甚至内核扩展的根基，因为这些组件都会被打包在 bundle 中。

  Apple 对 bundle 的定义： “一种标准化的层次结构，保存了可执行代码以及代码所需要的资源”。尽管具体的 bundle 类型可能会不同，而且 bundle 中的内容不同，但是所有的 bundle 都有同样的基本目录结构。

  例子：一个 OS X 应用程序的 bundle 内部结构

  Contents/
    CodeResources/
    Info.plist   包的主 manifest 文件
    MacOS/    包中的二进制文件内容
    PkgInfo     包的 8 字节标识符
    Resources/     .nib 文件（用于GUI）和.lproj 文件
    Version.plist     包版本信息
    CodeSignature/
    CodeResources
  

  通过 NSBundle 对象和 CoreFoundation 提供的 CFBundle 系列的 API 可以访问和加载 bundle。 或者在 终端 通过 ls 来查看里面有什么内容。

• archived-expanded-entitlements.xcent
  授权文件。 里面是这样的：

  
  
  
  
        aps-environment
        development
        keychain-access-groups
        
                L5275TG2BV.com.meituan.qcs.c
                L5275TG2BV.com.meituan.access
        
  
  
  

• Assets.car
  大家对 Assets.xcassets 不陌生吧，现在一般都把图片放在里面。好处是
  1、组织清晰
  2、不同功用的图片有专门的格式
  3、不同分辨率的图片好管理
  4、工程打包后会对图片进行压缩
  如果将图片直接放在工程目录下面，项目打包后图片文件也是散落在包里面，而且不会对图片进行压缩，而如果放在xcassets中，在打包后会将这些图片（除了AppIcon和LaunchImage，这两种图片是直接放在包中的）统一压缩成一个Assets.car的文件，大大减小包的大小，具体是几倍的关系我记不清了，但是相当的可观。

  说完Assets.xcassets，那么说说由它生成的Assets.car文件，这个文件是一种压缩文件。
  我们在开发过程中肯定会遇到一种情况就是把一个ipa的包解压出来看看里面有哪些图片，不管是不是自己的项目，总可能会有这种需求，那如果图片都在Assets.car中该怎么获取呢，直接解压是不行的，这时候就需要用到一个命令行工具叫cartool，这是一个开源软件，可以从github下载，这里给出github地址：https://github.com/steventroughtonsmith/cartool

• info.plist
  info.plist 文件位于应用程序的 Contents/ 子目录下，这个文件保存了 bundle 的元数据信息，这个文件是必备的，操作系统通过这个文件判定依赖关系和其他属性。

  • 3 种保存属性列表的格式：
    1、XML：人类可读的格式，很容易通过文件头部的 XML 签名和文档类型定义（DTD）识别出来。属性列表中的所有元素都包含在一个 元素内，这个元素定义了一个数组或一个字典。
    2、二进制格式：也称为 BPlists，可通过文件头部的魔数 bplist 识别。这种文件是编译后的 plist 文件，因此人类可读性很差，但对操作系统却是高度优化的。
    3、JSON：易阅读，也很容易解析，使用不如 XML 格式和二进制常见。

  一个标准的 info.plist 文件包含以下条目

  • CFBundleDevelopmentRegion: 如果找不到用户指定的语言，就表示默认的语言。
  • CFBundleDisplayName：显示给用户的 bundle 名称。
  • CFBundleDocumentTypes：这个 bundle 关联的文档类型。
  • CFBundleExecutable：这个 bundle 中实际的可执行文件（二进制文件或库文件）。
  • CFBundleLconFile：在 Finder 视图中显示的图标文件。
  • CFBundleIdentifier：逆 DNS 表示法的标识符。
  • CFBundleName：bundle 的名称（限制在 16 个字符之内）。
  • CFBundlePackageType：表示一个 4 字母的代码，例如 APPL = application
  • CFBundleSignature：bundle 的4 字母短命。
  • CFBundleURLTypes：这个 bundle 关联的 URL。这是一个字典，值指定了这个 bundle 处理的 URL scheme 以及处理方式。

• NIB文件
  .nib 文件是二进制的 plist 文件，其中保存了 应用程序中 GUI 组件的位置信息和设置信息。这些文件是通过 Xcode 的 Interface Builder 创建的。Interface Builder 编辑.xib 文件的文本版本，然后再将这些文件打包成二进制格式。
  如果想把 .nib 反编译回 XML 表示形式肯定会丢失信息，因为 .nib 文件本来就不应该被编辑，如果可以随意编辑的话， 那么应用程序的用户界面就可以外部随意修改了。

代码签名的实际过程

加入我们 一同进步.png