这是我参与11月更文挑战的第18天，活动详情查看：2021最后一次更文挑战

iOS整体框架

通常我们称iOS的框架为cocoa框架. 话不多说,官方的整体框架图如下:

简单解释一下:

• Cocoa (Application) Layer（触摸层）
• Media Layer （媒体层）
• Core Services Layer（核心服务层）
• Core OS Layer （核心系统操作层）
• The Kernel and Device Drivers layer（内核和驱动层）

注:Cocoa (Application) Layer（触摸层）其实包含cocoa Touch layer(触摸层) 和Application Layer (应用层).应用层原本在触摸层上面,因为应用层是开发者自己实现,所以和触摸层合在一起.

其实每一层都包含多个子框架, 如下图:

简单解释下(瞄一眼就得了):

• Cocoa Touch Layer：触摸层提供应用基础的关键技术支持和应用的外观。如NotificationCenter的本地通知和远程推送服务，iAd广告框架，GameKit游戏工具框架，消息UI框架，图片UI框架，地图框架，连接手表框架，UIKit框架、自动适配等等

• Media Layer：媒体层提供应用中视听方面的技术，如图形图像相关的CoreGraphics,CoreImage,GLKit,OpenGL ES,CoreText,ImageIO等等。声音技术相关的CoreAudio,OpenAL,AVFoundation,视频相关的CoreMedia,Media Player框架，音视频传输的AirPlay框架等等

• Core Services Layer：系统服务层提供给应用所需要的基础的系统服务。如Accounts账户框架，广告框架，数据存储框架，网络连接框架，地理位置框架，运动框架等等。这些服务中的最核心的是CoreFoundation和Foundation框架，定义了所有应用使用的数据类型。CoreFoundation是基于C的一组接口，Foundation是对CoreFoundation的OC封装

• Core OS Layer：系统核心层包含大多数低级别接近硬件的功能，它所包含的框架常常被其它框架所使用。Accelerate框架包含数字信号，线性代数，图像处理的接口。针对所有的iOS设备硬件之间的差异做优化，保证写一次代码在所有iOS设备上高效运行。CoreBluetooth框架利用蓝牙和外设交互，包括扫描连接蓝牙设备，保存连接状态，断开连接，获取外设的数据或者给外设传输数据等等。Security框架提供管理证书，公钥和私钥信任策略，keychain,hash认证数字签名等等与安全相关的解决方案。

想看更详细的可以移步:iOS总体框架介绍和详尽说明

我们只需要知道其中重要的框架就是UIKit和Function框架.下面说说这两个框架.

Function框架

Foundation框架为所有应用程序提供基本的系统服务。应用程序以及 UIKit和其他框架，都是建立在 Foundation 框架的基础结构之上。 Foundation框架提供许多基本的对象类和数据类型，使其成为应用程序开发的基础。

话不多说，我们先来看看Foundation框架，三个图，包括了Foundation所以的类，图中灰色的是iOS不支持的，灰色部分是OS X系统的。

这里只需要知道绝大部分Function框架的类都继承NSObject, 小部分继承NSProxy

对于Foundation框架中的一些基本类的使用方法详情参见：iOS开发系列—Objective-C之Foundation框架

UIKit框架

UIKit框架提供一系列的Class(类)来建立和管理iOS应用程序的用户界面( UI )接口、应用程序对象、事件控制、绘图模型、窗口、视图和用于控制触摸屏等的接口。

UIKit框架的类继承体系图如下图所示：

在图中可以看出，responder 类是图中最大分支的根类，UIResponder为处理响应事件和响应链定义了界面和默认行为。当用户用手指滚动列表或者在虚拟键盘上输入时，UIKit就生成事件传送给UIResponder响应链，直到链中有对象处理这个事件。相应的核心对象，比如：UIApplication ，UIWindow，UIView都直接或间接的从UIResponder继承 。

这里需要知道一点:UIKit框架所有的类都继承NSObject

UIKit框架的各个类的简单介绍戳后面的链接：UIKit框架各个类的简要说明 

在「 Swift接入例子 」中介绍了Swift项目如何接入SOT。但是要求SDK解压到特定目录中，编译配置的路径也是绝对路径，不适合多人协作合开。文本介绍适合多人开发协作的接入方法。

还是以开源的「 SwiftMessages 」Demo为例，该工程全部用Swift语言开发。这里把修改好的版本上传到了git上，分支为 「 sotcollaboration 」，SotDebug接入免费版，SotRelease接入网站版，读者只需要进行下面的 Step1.配置编译环境 就可以直接用该分支测试。

现在开始从头讲解，git clone原本的工程后(我的路径为/Applications/SwiftMessages)，命令行cd /Applications/SwiftMessages进入根目录，使用版本切换命令：git checkout 1e49de7b3780b699（因本文档制作于21年10月21号，以当日版本为准）。首先进入Demo目录，打开Demo.xcodeproj工程，scheme默认就已经选中了Demo：

我使用的是Xcode12.4，可以直接编译成功，启动APP能看到画面（模拟器）：

点击最上面的MESSAGE VIEW控件，会弹出一个错误提示窗口，今天我们就来用SOT热更的方式修改错误提示的文案：

Step1: 配置编译环境

「 下载SOT的SDK 」，解压到项目目录下 /Applications/SwiftMessages/Demo/sotsdk

在terminal运行命令：sh /Applications/SwiftMessages/Demo/sotsdk/compile-script/install.sh安装SOT编译工具链，需要输入密码。

用文本编辑器打开 /Applications/SwiftMessages/Demo/sotsdk/project-script/sotconfig.sh，修改EnableSot=1:新版SDK已经不会再使用sotconfig.sh里的sdkdir，sotbuilder和objbuilder路径了，所以不用修改这些配置了，删掉也可以。

Step2: 增加Configuration

增加两个Configuration，只有切换到这两个Configuration才使用SOT编译模式，平时还是用原来的Configuration做开发，步骤如下：

1. 选中Demo Project，然后选择Info面板，点击Configurations的下面加号，复制Debug的编译配置，并且命名为SotDebug，用来接入免费版的SOT。再选择复制Release编译配置，命名为SotRelease，用来配置网站版的SOT，注意名字都不要留有空格：加完就是：


2. 给SwiftMessages也加上这两个Configuration：

注意：读者应用到自己项目中时，需要把所有的工程都加上这两个Configuration，否则编译会报找不到文件等等的错误。所以加完这两个Configuration的之后，就马上切换到它们去Build和Run一下，看是否有编译错误，如果没有再进行下面的操作，如果有，请检查是否漏了一些工程没有添加上。

Step3: 修改编译选项

添加热更需要的编译选项，添加SOT虚拟机静态库等，步骤如下：

1. 
   

   选中Demo工程，然后选择Demo这个Target，再选择Build Settings:

   
   


2. 
   

   在Other Linker Flags的SotDebug中添加-sotmodule $(PRODUCT_NAME) sotsdk/libs/libsot_free.a -sotsaved $(SRCROOT)/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh

   
   

   在SotRelease中添加-sotmodule $(PRODUCT_NAME) sotsdk/libs/libsot_web.a -sotsaved $(SRCROOT)/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh。

   
   

   每个选项的意义如下：

   
   
   
   
   • -sotmodule是module的名字，可以直接用$(PRODUCT_NAME)，也可以自定义名字，名字不要有空格
   
   
   • -sotsaved是编译中间产物保存的目录，补丁自动化生成需要对比前后编译的产物来生成补丁
   
   
   • -sotconfig指定了项目sotconfig.sh的路径，该脚本控制sot编译器的工作
   
   
   • sotsdk/libs/libsot_free.a是SOT虚拟机静态库的路径，链接的是免费版的虚拟机
   
   
   • sotsdk/libs/libsot_web.a是SOT虚拟机静态库的路径，链接的是网站版的虚拟机
   
   
   
   


3. 
   

   在Other C Flags以及Other Swift Flags的SotDebug和SotRelease下添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh，意义跟上一步是一样的，需要保持一致。经过上面两步，相关的编译配置结果如下图：

   
   


4. 
   

   在Preprocessor Macros添加USE_SOT=1，后面用来控制是否编译调用SDK的代码

   
   


5. 
   

   因为SOT SDK库文件编译时不带Bitcode，所以也需要把Enable Bitcode设为No。

   
   


6. 
   

   为了模拟器架构时不编译arm64，给SotRelease增加如下配置或者把Build Active Architecture Only设为Yes

   
   

Step4: 增加拷贝补丁脚本

SDK里提供了一个便利脚本，路径在sdk目录的project-script/sot_package.sh，它会把生成的补丁拷贝到Bundle文件夹下，在每次项目编译成功时调用该脚本，添加步骤如下：

脚本内容为：

    if [[ "$CONFIGURATION" == "SotDebug" || "$CONFIGURATION" == "SotRelease" ]];then

      sh "$SOURCE_ROOT/sotsdk/project-script/sot_package.sh" "$SOURCE_ROOT/sotsdk/project-script/sotconfig.sh" "$SOURCE_ROOT/sotsaved/$CONFIGURATION" Demo

    fi

    

复制代码

把Based on dependency analysis的勾去掉。

Step5: 链接C++库

SOT需要压缩库和c++标准库的支持，还是在这个页面下，打开Link Binary With Libraries页

点击加号，分别加入这两，libz.tbd和libc++.tbd

Step6: 调用SDK API

需要用Swift代码调用OC代码，已经提供了一个样例代码在SDK的swift-call-objc目录中，先把callsot.h和callsot.m拷贝到Demo目录下

再添加到Demo工程中。点击Xcode软件的File按钮，找到Demo目录下的callsot.h和callsot.m，接着点击Add Files to "Demo"，如下图所示：

点击Add按钮，添加后会弹出询问：是否创建桥接文件。点击按钮Create Bridging Header：

然后可以看到项目中多了3个文件，分别是callsot.h，callsot.m和Demo-Bridging-Header.h：

打开Demo-Bridging-Header.h，加入一行代码#import "callsot.h"

打开callsot.m，修改代码为

#import <Foundation/Foundation.h>

#import "callsot.h"

#import "../sotsdk/libs/SotWebService.h"

@implementation CallSot:NSObject

-(void) InitSot

{

#ifdef USE_SOT

#ifdef DEBUG

    [SotWebService ApplyBundleShip];

#else

    

    [SotWebService Sync:@"1234567" is_dev:false cb:^(SotDownloadScriptStatus status)

  {

    if(status == SotScriptStatusSuccess)

    {

      NSLog(@"SotScriptStatusSuccess");

    }

    else

    {

      NSLog(@"SotScriptStatusFailure");

    }

  }];

    

#endif

#endif

}

@end

复制代码

注意SotWebService.h的头文件路径不再依赖于绝对路径，并且代码里用了#ifdef USE_SOT宏来隔开API调用代码，不影响正常编译：

打开AppDelegate.swift，加入两行代码let sot = CallSot()和sot.initSot()

注意：读者在应用到自己项目中时，以上这些配置的路径不要生搬硬套。例如找不到SotWebService.h文件，找不到sotconfig.sh文件等等，读者自己要清楚SDK的目录与自己工程目录的相对关系，灵活调整这些配置的路径。

测试热更-免费版

按上面配置完之后，先测试免费版热更功能

Step1: 热更注入

1. 将Build Configuration切换到SotDebug


2. 确保sotconfig.sh的配置是，EnableSot=1以及GenerateSotShip=0，先Clean Build Folder一下，然后再Build：

然后看编译日志的输出，Link日志可以看到run sot link等输出，会告诉你每个文件里哪些函数可以被热更等信息：

项目编译成功了，该APP可以正常启动。同时它具备了热更能力，可以加载补丁改变程序的代码逻辑，下面介绍如何生成补丁来测试它。

Step2: 生成补丁

上一步进行了热更注入的编译，当时的代码保存到了Demo/sotsaved这个文件夹下，用来和新代码比较生成补丁。生成补丁步骤如下：

1. 首先启动SOT生成补丁模式，修改sotconfig.sh为EnableSot=1，GenerateSotShip=1


2. 


3. 接下来直接在Xcode里修改源代码，把ViewController.swift文件的”Something is horribly wrong!“改成了”SOT is great“，修改前：修改后：


4. Swift项目生成补丁，每次都需要先Clean项目，再Build项目。然后查看编译日志输出，可以看到生成了补丁并且被脚本拷贝到了Bundle目录下，可以展开Link Demo（x86_64)的编译日志：点击展开后，可看到生成补丁的Link日志，日志里显示了函数demoBasics被修改了：


5. 生成出来的补丁原始文件保存到了Demo/sotsaved/SotDebug/x86_64/ship/ship.sot，还记得之前加了一个script到Build Phase中吗？它会每次编译结束时，会把这个补丁拷贝到了Bundle目录中，并且添加CPU架构到文件名中。可以在Bundle中看到这个补丁，至此完毕。

Step3: 加载补丁

启动APP，API会判断Bundle内是否有补丁，有则加载，加载成功的日志大概如下，提示有一个模块加载了热更补丁：之后点击最上面的MESSAGE VIEW控件，发现弹出的文案变成了SOT is great：

如果去Xcode断点调试demoBasics，会发现无法断住了，因为实际执行补丁代码的是SOT虚拟机。

顺便提一嘴，GenerateSotShip=1时，编译APP用的是保存在sotsaved目录下的代码，所以无论怎么修改Xcode里的代码，如果没有把补丁拷贝到Bundle目录里，那么APP都是最后一次GenerateSotShip=0热更注入时的样子。

如果怀疑，可以把拷贝补丁的Script脚本从Build Phases删除，可以发现GenerateSotShip=1怎么改代码都不会生效了。

注意：如果读者接入自己的一个很简单项目进行测试，例如设置某个控件的颜色，热更前是红色，修改后是绿色，发现无法生效。那是因为这样的项目太过于简单，寥寥几行代码。热更前没有访问过绿色的这个全局变量，在热更时也无法访问到了，SOT只能利用原有的能力，无法无中生有。所以不要这样测试，更具体的原因在「 热更能力-语言特性 」说明。通常完整的项目代码比较多，所以就不会有这样的缺陷。

接入网站版

按上面的教程，已经对APP实现了免费版和网站版的接入。它俩区别只是链接的库不一样，具体就是Other Linker Flags根据Configuration区别配置，SotRelease下接入了网站版。但除了APP接入了网站版SDK，还需要用配合网站来管理补丁的发布。

Step1: 注册网站

1. 第一步当然是注册网站，成为会员。点击跳转注册页面，免费注册，注册需要验证邮箱，然后登录。


2. 从导航栏进入我的APP：


3. 点击创建APP，弹出弹窗填写APP的名字：


4. 进入APP页面，点击右上角的创建新版本按钮，会弹出弹窗，需要选择网站版，SDK版本选择1.0，目前只有1.0版本，然后输入版本号，版本号可以是随意字符串，方便区分就行。


5. 创建版本成功后，点击版本，进入版本页面，左上角是唯一标识该版本的VersionKey，后面API接口需要这个Key。

Step2: 修改VersionKey

打开callsot.m，修改网站版的Sync接口，第一个参数填入你在网站创建的版本的VersionKey。至此，网站版热更就算接入完成了。

Step3: 测试网站热更

• 
  

  网站版生成补丁的步骤免费版是一样的，需要经历热更注入->出包->修改代码->生成补丁，这里不再赘述。

  
  

  唯一不同的是，生成出来的补丁要上传到网站上，然后才能通过网络同步到手机上实现热更。通过之前的免费版教程，知道生成的补丁会被拷贝到Bundle目录下，所以去Bundle目录里就能找它，在Xcode导航栏里右键选择Products下的Demo.app，选择Show in Finder：

  
  


• 
  

  右键Demo文件，选择Show Package Contents:

  
  


• 
  

  找到目录下的sotship_arm64.sot，这里用手机测试，cpu是arm64类型，补丁名字带有cpu后缀，这就是补丁了：

  
  


• 
  

  回到网站的版本页面，点击右侧上传补丁按钮：

  
  


• 
  

  弹出页面里，真机的架构一般选择arm64，除非是老的armv7的机器，并把补丁文件拖到框里，点击上传：

  
  


• 
  

  上传成功并且补丁文件无异常（补丁最大支持5MB)，则会添加成功，补丁默认是停用状态，需要点击编辑来启用它：

  
  


• 
  

  这里选择全量启用，点击下面的提交按钮，然后补丁就会成功启用了：

  
  


• 
  

  上一步更新了补丁状态，通常很快生效，但CDN有时也需要1到2分钟才能生效。之后手机打开APP，如果成功下载补丁和加载的话，就能看到下面的日志：这里输出的md5也跟网站上的补丁md5是一致的。

  
  


• 
  

  打开APP后，点击最上面的MESSAGE VIEW控件，发现弹出的文案变成了SOT is great：

  
  

注意：使用网站版，需要考虑到网络传输延迟的问题，只有看到了下载补丁和成功加载补丁的日志之后，调用的函数才会使用热修后的函数。例如有的开发问我，首屏代码怎么无法热更生效？那是因为首屏代码调用的时机太早了，SOT去网站上拿补丁，是异步的，不会一直卡住等着，而且在异步线程中等待结果。在补丁没传输回来之前，首屏的代码都已经调用结束了，这种情况下当然调用的还是老的代码了。而免费版没有这个问题，因为免费版是同步加载补丁的，直接去Bundle里加载，不是异步的。

构建热更注入版本和构建补丁必须是同一台机器，同一个Xcode版本。例如上架前APP用Xcode12进行了热更注入，而之后用Xcode13来构建补丁，那么将得到无效甚至错误的补丁。请使用同一个版本Xcode。

Step4: 几点提示

• 网站版跟免费版主要接入流程差不多，可以用免费版测试，功能通过测试之后再接入网站版。


• 网站版需要有网络的情况下才能生效，如果手机没有网，即使之前已经下载过了补丁，也无法加载。


• 网站版费用很低，日活10万的APP，一个月几百块就够了。


• 网站版补丁和配置都放在CDN上，支持高并发。

非主Target接入热更

上面的教程都是针对主Target，也就是Demo。这个工程还有一个名为SwiftMessages的Framework，也可以热更，下面介绍如何配置。

可以看到SwiftMessages的Mach-O Type是Dynamic Library，通过下图方式查看得到：

这种类型的话，配置相对麻烦些。还有一种是Static Library，配置起来会简单得多。但本例改成Static Library启动会崩溃，所以按Dynamic Library的方式来介绍。

Step1: 修改编译选项

1. 选中SwiftMessages.xcodeproject工程，然后选择SwiftMessages这个Target，再选择Build Settings:


2. 在Other Linker Flags的SotDebug中添加-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_free.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh


3. 在Other Linker Flags的SotRelease中添加-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_web.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh


4. 在Other C Flags以及Other Swift Flags的SotDebug和SotRelease中，添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh，意义跟上一步是一样的，需要保持一致。经过上面两步，相关的编译配置结果如下图：这一步跟Demo的配置差不多，区别在于有些路径写法不一样，以达到复用Demo配置的目的，读者可以仔细比较一下。


5. 在Preprocessor Macros添加USE_SOT=1，后面用来控制是否编译调用SDK的代码


6. 需要把Target的Enable Bitcode设为No。


7. 为了模拟器架构时不编译arm64，给SotRelease增加如下配置

Step2: 链接C++库

点击Build Phases页面，打开Link Binary With Libraries页，点击加号，分别加入这两，libz.tbd和libc++.tbd

Step3: 调用SDK API

因为SwiftMessages是动态库，所以需要在它的编译文件中调用SDK的热更初始化接口。跟Demo一样，添加OC文件。先从Demo文件夹中复制callsot.h和callsot.m文件到SwiftMessages文件夹中

选中SwiftMessages工程，点击Xcode软件的File按钮，接着点击Add Files to "SwiftMessages.xcodeproject"，如下图所示：

选择到SwiftMessages目录，同时选中callsot.h和callsot.m两个文件，勾选下面的Copy items if needed，勾选Add to targets：中的SwiftMessages target，如下图所示：

点击Add按钮，然后可以看到项目中多了2个文件，分别是callsot.h，callsot.m，修改CallSot类名为CallSotMessage：

去到右边面板，把文件属性改成public：

打开callsot.m，做相应路径和类名的修改：

打开Demo-Bridging-Header.h，加入一行代码#import "SwiftMessages/callsot.h"：

打开AppDelegate.swift，加入两行代码let sot1 = CallSotMessage()和sot1.initSot()

因为这时候有两个Target都可以生成补丁，Demo和SwiftMessages，需要修改拷贝补丁的脚本，加入SwiftMessages：

Step4: 测试热更

1. 
   

   测试热更的流程跟之前是一模一样的，只是输出的日志可能会有所区别，我们过一遍。EnableSot=1和GenerateSotShip=0热更注入，先Clean后Build，如果去看编译日志的Link SwiftMessages，也可以看到热更注入的信息。

   
   


2. 
   

   然后修改MessageView.swift的代码，错误提示的文案会加上“SOT is great”：

   
   


3. 
   

   GenerateSotShip=1开启生成补丁模式，Clean后Build，查看Link SwiftMessages日志，有提示该函数被热更：

   
   


4. 
   

   接下来可以看到补丁拷贝脚本日志输出的信息，这里它检测到有两个Target都生成了补丁文件，会把它们两个合成一个，拷贝到Bundle目录下：

   
   


5. 
   

   启动APP，会看到两条加载补丁的日志，因为我们Demo Target和SwiftMessages Target都调用了API接口：

   
   


6. 
   

   点击MESSAGE VIEW控件，可以看到错误提示文案后面多了“SOT is great”，热更成功：

   
   

   网站版的测试跟以前也是一样的，这里不再重复了。

   
   

Step5: 几点提示

1. Dynamic Library的热更编译改法其实跟主Target，也就是Mach-O Type为Executable的改法是一样，只是这里复用了主Target的一些配置，例如sotsaved目录和sotconfig.sh的路径。增加再多的Target也可以按同样的改法修改它们。


2. 补丁拷贝脚本只需要主Target有就行了，把要热更的sotmodule对应的名字加上即可，条件就是sotsaved目录必须是同一个。


3. 如果需要接入网站版，那么每个需要热更的Target都需要调用API跟网站同步，它们的消耗是独立计费的。

Static Library的改法

上面说到Dynamic Library的改法步骤比较多，而且有诸多缺点，如果能把Framework的Mach-O Type改成Static Library是最好的，会少很多步骤和配置。由于本例无法修改，这里简单说一下步骤：

1. 在Other Libraian Flags添加-sotmodule $(PRODUCT_NAME) -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh ，注意是Other Libraian Flags而不是Other Linker Flags了。还有这里比Dynamic Library加的配置少一个，即没有链接SDK的.a库文件了。


2. 在Other C Flags以及Other Swift Flags添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh，这步跟之前是一模一样的。


3. 需要把Target的Enable Bitcode设为No。


4. 修改拷贝补丁的脚本，加入该Target的名字，例如本例加入SwiftMessages，跟之前也是一模一样的：

然后就配置完了，如果是使用网站版，同步一次消耗，就能实现所有Target的热更，修改简单，对包体影响最小。

总结

本文完整介绍Swift项目如何接入免费版和网站版。

本文的方式是把SDK拷贝到了工程文件夹里，让它可以跟随项目一起进行版本管理，路径也配置成了相对路径，更加灵活。

通过新增Configuration的方式，也做到了不影响原来的开发，Debug和Release相当于没有接入SOT，适合大多数开发平时使用。只需上线前改成SotRelease出包，就能让APP就得到热更能力。

2021 最火的新概念，莫过于元宇宙。2021 年 10 月 29 日，Facebook 宣布改名 Meta；2021 年 11 月 1 日，“元宇宙第一股” Roblox 经过短暂调整，宣布重新上线。元宇宙概念的热度可见一斑，国内外都在研究，我们程序员能否借用元宇宙概念进行技术延申，今天这篇文章或许会给到你一些启发。

一、什么是元宇宙？

1)元宇宙概念的提出

元宇宙在很长一段时间内仅存在于文学与影视作品中。元宇宙（Metaverse）由Meta和Verse两个词根组成，Meta表示“超越”“元”，verse表示“宇宙Universe”。Metaverse一词最早来自1992年的科幻小说《雪崩》。小说描绘人们在虚拟现实世界中通过控制自己的数字化身相互竞争以提升社会地位。在其后的接近30年间，元宇宙的概念在《黑客帝国》《头号玩家》《西部世界》等影视作品，《模拟人生》等游戏中有所呈现。在这一阶段，元宇宙的概念比较模糊，更多地被理解为平行的虚拟世界。

2）元宇宙八大要素

根据元宇宙概念上市公司Roblox的定义，元宇宙应具备身份、朋友、沉浸感、低延迟、多元化、随地、经济系统、文明等八大要素。元宇宙的表现形式大多以游戏为起点，并逐渐整合互联网、数字化娱乐、社交网络等功能，长期来看甚至可以整合社会经济与商业活动。

3)元宇宙第一股Roblox上市

2021年3月10日，Roblox采取直接挂牌模式（DPO）在纽约证券交易所上市。Roblox认为元宇宙用于描述虚拟宇宙中持久的、共享的、三维虚拟空间的概念。

4）元宇宙总结了前期科技的发展方向

在迸发元宇宙概念前，5G基础设施、用于智能终端的显示屏、AI芯片等技术不断发展演进，同时工业互联网、产业互联网、数字孪生、VR游戏等概念均不断成熟。而在元宇宙概念诞生后，可以很好地总结这一时期大部分技术的发展方向。。

二、元宇宙的架构？

51aspx认为，元宇宙的载体与内容这两个概念十分宽泛，主要分三部分：

• 元宇宙的底层由基础设施与终端硬件设备组成：包括但不限于人机交互、3D引擎、GIS、设计工具、游戏渲染、画面渲染、隐私计算、AI、操作系统、工业互联网、内容分发、应用商店以及智能合约；


• 在此基础上，元宇宙还需要大量的软件与技术协同：包括但不限于：基础设施端的5G、6G、云计算、区块链节点、边缘计算节点、DPU；用户端的路由器、传感器、芯片、VR头显、显示器、脑机接口；


• 基于此，元宇宙可以衍生出相应的应用，并基于元宇宙各类应用发展出潜在的内容载体。

三、元宇宙的发展模式？

1）元宇宙的发展是循序渐进的过程，技术端、内容端、载体端都在不断演变

• 技术端，区块链技术在不断演进；


• 内容端，元宇宙概念的游戏不断增加，生态不断加强，用户数也随之增长。以Roblox、Sandbox为代表的UGC元宇宙概念游戏得益于玩家的参与而不断丰富自己游戏的内容；


• 载体端，通信技术、虚拟现实、芯片等底层技术也在不断演进。

四、元宇宙的渗透路径？

这个问题也可以理解成我们距离元宇宙的距离，东方证券张颖表示，元宇宙的内容短期将集中于游戏端与艺术端（NFT艺术藏品），长期来看，元宇宙的渗透路径预计将为“游戏/艺术-工作-生活”。

1）游戏端：以Roblox为代表

Roblox平台主要由三个产品构成：

• 客户端：允许用户探索3D数字世界的应用程序。（面向用户）；


• 工作室：允许开发人员和创作者构建、发布和操作Roblox客户端访问的3D体验和其他内容的工具群。（面向开发者）


• Roblox云：为共同体验平台提供动力的服务和基础设施。

Roblox的主要营收来源为用户的游戏内支出。玩家需要充值换取游戏中的代币Robux获取Roblox的各种功能，这也是Roblox的营收来源。

并且，Roblox的激励机制十分明确，除掉25%支付给APPStore的营收以及用于平台各种费用的营收（约26%），剩下约49%的营收基本由公司和开发者平分。

其实，游戏UGC平台的概念可以追溯至魔兽争霸3：魔兽争霸3WE地图编辑器支持开发者创造出许多RTS（即时战略游戏）、MOBA（多人在线战术竞技）的游戏地图和游戏类型。但魔兽3对于开发者的奖励机制缺失，导致整体商用化程度不高。

2）艺术端：NFT构建元宇宙经济基础

非同质化代币（NFT）具有不可互换性、独特性、不可分性、低兼容性以及物品属性。并且产品流通渠道单一，市场透明度、价格发现能力均有较高提升空间。

目前，多家互联网大厂正试水NFT领域：2021年6月，阿里巴巴发售支付宝付款码皮肤NFT，2021年8月，腾讯围绕NFT进行一系列战略布局。

3）工作端：Facebook与英伟达的布局

Infinite office是Facebook元宇宙战略中重要环节。2020年9月，Facebook宣布推出VR虚拟办公应用InfiniteOffice，支持用户们创建虚拟办公空间，提高工作效率。

英伟达推出了NVIDIA Omniverse，一个专为虚拟协作和物理属性准确的实时模拟打造的开放式平台。并且已经开始投入使用，宝马公司正在内部推进NVIDIAOmniverse平台，以协调全球31座工厂的生产。而根据英伟达官网披露的信息，NVIDIA Omniverse将宝马的生产规划效率提高30%。

4）生活端：面向体验场景

东方证券认为，元宇宙的未来在于探索其应用场景的共性。这些应用场景均需考量用户的体验，元宇宙未来的商业模式与智能手机类似，即通过体验感增加用户的使用时间，进而提高用户粘性。这些时间（体验）成为元宇宙中各项服务的基础。

五、元宇宙时代有哪些确定性趋势？

元宇宙主要的载体（基础设施）主要包括如下几部分

1）网络（通信）

5G作为具有高速率、低时延和大连接特点的新一代宽带移动通信技术，是实现人机物互联的网络基础设施。

2）芯片（算力）

元宇宙的内容、网络、区块链、图形显示等功能均需要更为强大的算力。

云端算力方面，DPU芯片（数据处理芯片）通过分流、加速和隔离各种高级网络、存储和安全服务，为云、数据中心或边缘等环境中的各种工作负载提供安全的加速基础设施。

终端算力方面，异构芯片可以让SoC中的CPU、GPU、FPGA、DPU、ASIC等芯片协同工作，不断提升算力以提升用户体验。

3）云与边缘计算

云计算与边缘计算为用户提供所需的计算资源，降低用户触达元宇宙的门槛。

4）AI

AI在元宇宙中应用渗透较广泛。AI可以帮助创建元宇宙资产、艺术品和其他内容（AIGC），并可以改进我们用来构建所有这些内容的软件和流程。

六、元宇宙在产业端如何发挥价值？

全球范围内许多互联网企业、工业软件企业就工业元宇宙的相关技术已有长期的布局，其中包括数字孪生、工业互联网、仿真测试、数字化工厂、CAD、CAE、EDA等工业软件。

1）英伟达：Omniverse平台

Omniverse的架构包括Connect、Nucleus、Kit、Simulation、RTXrenderer等五个部分，他们与第三方数字内容创建工具（DCC）以及基于Omniverse的微服务构成了Omniverse的生态。

黄仁勋在参加Computex2021线上会议表示未来虚拟世界与现实世界将产生交叉融合，元宇宙与NFT将在其中扮演重要角色。其中Omniverse平台主要面向建筑、工程和施工；制造业；媒体和娱乐以及超级计算场景。

根据英伟达官网对于Omniverse平台的介绍，通过Omniverse平台，用户可以完成实时虚拟协作、模拟现实的设计、模拟环境以及搭建未来工厂等操作。

2）微软：数字孪生探索

2021年9月，微软CEO Satya Nadella在Inspire2021演讲中提出全新“企业元宇宙”概念。微软的元宇宙计划中期望元宇宙可以打破现在的通信和业务流程之间的障碍，把他们融合在一起，让工业场景更为便捷。在宣布“企业元宇宙”概念之前，微软就已通过Azure数字孪生及AI等技术建立了工业元宇宙的底座。

Azure数字孪生是一个物联网(IoT)平台，可用于创建真实物品、地点、业务流程和人员的数字表示形式。通用电气航空的数字集团使用Azure数字孪生构建了一个实时和自动演变的模型，因此客户将随时可以访问其飞机的更新、准确和可用的数据模型。并且，通过内置数字可追溯性，可以实时记录每架飞机上每一个实物资产和部件。

3）能科股份：布局仿真与测试

能科股份主要业务包括智能制造、智能电气两个板块，其中公司智能制造业务基于数字孪生理念，整合业内先进工业软件和数字化IOT设备，虚拟世界内定义生产力中台并为客户开发个性化的工业微应用，物理世界内建立数字化、智能化的生产线和测试台，满足制造业企业产品全生命周期的数据与业务协同需求，帮助企业实现其自主创新、运营成本、生产效率、不良品率和客户满意度等业务目标。

4）阿里云：数字工厂“新基建”

根据德国工程师协会的定义，数字工厂（DF）是由数字化模型、方法和工具构成的综合网络，包含仿真和3D虚拟现实可视化，通过连续的没有中断的数据管理集成在一起。

阿里云工业互联网平台助力制造企业数字化转型，打造工厂内、供应链、产业平台全面协同的新基建，将工厂的设备、产线、产品、供应链、客户紧密地连接协同起来，为企业提供可靠的基础平台和上层丰富的工业应用，结合全面的产业支撑，助力企业完成数字化转型。

七、元宇宙是否需要去中心化？

1）个人信息可携带权

在个人信息可携带权的时代，用户成为关键参与者，由用户主动发起个人信息数据传输并自行上传，从而实践个人数据可携带权，去中心化成为必不可少的条件。

2）去中心化不等于没有中心、没有监管

在去中心化概念下，仍有较为高级的节点参与治理或运营，这与分布式架构完全舍弃中心的概念不同。在去中心化概念下，有效的监管和治理仍可存在。

3）去中心化如何践行？参考DAO

去中心化自治组织（DecentralizedAutonomousOrganization，DAO）是基于区块链核心思想理念，由达成同一个共识的群体自发产生的共创、共建、共治、共享的协同行为衍生出来的一种组织形态，是区块链解决信任问题后的附属产物。

DAO将组织的管理和运营规则以智能合约的形式编码在区块链上，从而在没有集中控制或第三方干预的情况下自主运行。DAO具有充分开放、自主交互、去中心化控制、复杂多样以及涌现等特点，可成为应对不确定、多样、复杂环境的有效组织。

八、元宇宙是否需要NFT？

1）什么是NFT？区块链的主流资产之一。

NFT代表不可替代的代币，是可以用来表示独特物品所有权的代币。NFT让艺术品、收藏品甚至房地产等事物标记化。他们一次只能拥有一个正式所有者，并且他们受到以太坊等区块链的保护，没有人可以修改所有权记录或复制/粘贴新的NFT。

NFT具有不可互换性、独特性、不可分性、低兼容性以及物品属性，可应用于流动性挖矿、艺术品交易、游戏/VR以及链下资产NFT化等场景，大幅提升数据流转效率。

2）NFT应用：一种潜在的元宇宙经济模式

NFT由于自身的数字稀缺性被率先运用于收藏、艺术品以及游戏场景。51aspx认为，NFT在元宇宙中将扮演关键角色。

九、元宇宙时代，互联网形态是否会发生变化？

51aspx认为，基于元宇宙的发展，互联网的协议可能发生改变，互联网会针对于打造可信化的数字底座进行演进。而区块链技术也在攻克自身的缺陷：交易吞吐量低、与外界沟通困难等。

未来会发展成什么样还是未知的，但是目前的理念技术还是很值得我们去探讨。关于相应的源码可以点击查看51aspx.com。

文章系转载：wallstreetcn.com/articles/36…

设计排版：51aspx.com

近日超火的“元宇宙”，被说成是互联网的未来，它以各种姿势吸金，让创业族们看到闪着金光的未来。然而，关于元宇宙究竟是什么？ 小编相信大多数人都有听过这一热词，但是都不清楚它究竟是什么？

那么，元宇宙究竟是什么呢？为什么互联网科技和数字科技等各大巨头纷纷入局元宇宙？

准确来说，元宇宙到目前为止，尚无公认的定义 ，因为元宇宙不是一个新的概念，它算是一个原有的经典概念的重组词，是在扩展现实（XR）、区块链、云计算、数字孪生等新技术下的概念具化。同时也是集互联网、物联网、大数据、5G等为一体的运用，是虚拟世界与现实世界的结合，元宇宙的运用在未来会有很大的发展空间。

继续深入发掘，会了解到元宇宙一词诞生于1992年出版的科幻小说《雪崩》，小说里提到了“Met aver se（元宇宙）”和“Avat ar（化身）”两个概念。在小说描绘的虚拟世界里，人们拥有自己的虚拟替身，这个虚拟世界就叫元宇宙。当然，关于元宇宙的争论还在继续，而且我们能够从不同的角度分析能够得出差异性极大的结论报告，但是关于元宇宙的特征情况已获得了业界的认可。

在今年8月份以来，元宇宙概念火遍全球，甚至日本社交巨头GREE宣布将开展元宇宙业务、英伟达发布会上出场了十几秒的“数字替身”、微软在Inspire全球合作伙伴大会上宣布了企业元宇宙解决方案等

但实际上，不仅有各大科技巨头在争相布局元宇宙赛道，同时还有一些国家的政府相关部门也积极参与其中。5月18日，韩国科学技术和信息通信部发起成立了以现代、SK集团、LG集团等200多家韩国本土企业和组织的名叫“元宇宙联盟”的组织，其目的是想要打造国家级别以及增强线下现实平台，并在未来向社会提供公共虚拟服务；今年都的7月13日，日本发布了《关于虚拟空间行业未来可能性与课题的调查报告》，总结了日本虚拟空间行业相关问题，同时也期望能够占据主导地位在全球虚拟空间行业里；今年8月31日，韩国财政部发布了下一年的预算情况报告，计划斥资2000万美元用于元宇宙平台开发。

以上种种报告显示，元宇宙深受科技巨头、政府部门的青睐，那么究竟是什么原因元宇宙可以做到“人见人爱”的这种现象呢？

从企业的角度来看，目前还处于初级阶段的元宇宙，无论是基础的技术还是基本的应用场景，与未来的成熟形态相比较还是有一定的差距，但这也意味着元宇宙相关产业可拓展的空间巨大。 因此，如果想要守住市场，数字科技领域初创企业要获得超速的机会，就要学会提前布局，甚至还要加强马力。

从政府层面来看，元宇宙不仅代表着重要的新兴产业，同时也是需要被重视的社会会治理领域。 伴随着元宇宙这一新兴产业的不断发展，随之而来的将会是一系列的革命性发展和挑战。

同时，元宇宙也算一个具有极致开放的、复杂且巨大的系统，它涵盖了全部的网络空间、多个基础的硬件设备和最为基本的现实条件，是由多类型建设者共同构建的超大型数字科学技术的应用生态。

因此，我们再来从技术的角度来看，技术局限性是元宇宙目前发展的最大瓶颈，XR、区块链、人工智能等相应底层技术距离元宇宙落地应用的需求仍有较大差距。需要做大量的基础研究才能支撑元宇宙产业的成熟。对此，我们不仅要谨防元宇宙成为炒作噱头，还要鼓励各大相关的企业更进一步加强技术创新能力提高产业技术的成熟度。

BI“元宇宙”也是人们热议的话题，大数据有望最先受益于元宇宙放量，就以国内著名BI厂商Smartbi为例，Smartbi持续完善数据产业链，以“Smartb一站式大数据分析平台”为核心引擎，打造大数据运营管理能力，拓展场景应用，加速企业数据化转型。

数据可视化，简单来说就是将一种将相对复杂的表达形式、抽象的数据通过可视化转化为更容易理解的图形显示的一种形式。数据可视化可以更为生动形象地展现出数据所表达的内在价值，同时也十分方便企业利用数据智能更好地开展业务。 关于数据可视化，Smartbi支持完整的ECharts图库及多种图形，包括瀑布、热力图、树图等数l十种动态交互的图形，可视化功能十分地灵活，同时页面也展现的十分清晰明了，该功能也深受客户喜爱。

数据安全是每个企业的重中之重，我们这里说的数据安全是狭义的，指的是采用现代信息存储手段对数据进行主动防护。 Smartbi在数据的收集、存储、使用、加工、传输、公开等各个环节，都提供了安全、可控的保护手段。其安全管理体系就是通过对多种权限进行控制，从而保障了数据资源的使用安全。另外还提供了定期备份、水印设置、分享设置等功能，大大降低了数据破坏、外泄的风险。

最后，我们可以肯定的是，在技术的不断提高进步和人类不断增多的生活需求的共同推动下，元宇宙场景的实现，元宇宙产业的成熟，只是一个时间问题。它对于我们之后的发展，无论是经济方面还是其他方面都是有着巨大的机遇和革命性作用

本篇文章基于Android6.0源码分析

相关源码文件：

/system/core/rootdir/init.rc

/system/core/rootdir/init.zygote64.rc



/frameworks/base/cmds/app_process/App_main.cpp

/frameworks/base/core/jni/AndroidRuntime.cpp



/frameworks/base/core/java/com/android/internal/os/

- ZygoteInit.java

- Zygote.java

- ZygoteConnection.java



/frameworks/base/core/java/android/net/LocalServerSocket.java

/system/core/libutils/Threads.cpp

 

Zygote进程启动前的概述

通过init.rc的文件解析会启动zygote相关的服务从而启动zygote进程。通过import导入决定启动哪种类型的zygote服务脚本，这里分为32位和64位架构的zygote服务脚本

import /init.${ro.zygote}.rc

 

在/system/core/rootdir目录中有四个zygote相关的服务脚本

init.zygote32.rc // 支持32位的zygote

init.zygote32_64.rc // 即支持32位也支持64位的zygote，其中以32位为主，64位为辅

init.zygote64.rc // 支持64位的zygote

init.zygote64_32.rc // 即支持64位也支持32位的zygote，其中以64位为主，32位为辅



 

下面我们分析只分析64位的zygote服务脚本的Android初始化语言：

service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server

 class main

 socket zygote stream 660 root system

 onrestart write /sys/android_power/request_state wake

 onrestart write /sys/power/state on

 onrestart restart media

 onrestart restart netd

 writepid /dev/cpuset/foreground/tasks



 

zygote进程的执行程序为/system/bin/app_process64中，其中参数为：-Xzygote /system/bin --zygote --start-system-server，classname为main 。除了在Init进程解析时创建Zygote进程，在servicemanager、surfaceflinger、systemserver进程被杀时Zygote进程也会进行重启。

其中/system/bin/app_process64的映射的执行文件为：/frameworks/base/cmds/app_process/app_main.cpp

Zygote进程启动

如图1所示，zygote进程启动时会先启动app_main类的main()方法：

  // 参数argv为 ：  -Xzygote /system/bin --zygote --start-system-server

  int main(int argc, char* const argv[])

  {

      // 创建一个AppRuntime实例，AppRuntime 继承 AndoirdRuntime

      AppRuntime runtime (argv[0], computeArgBlockSize(argc, argv));

      //忽略第一个参数

      argc--;

      argv++;



  

      // 解析参数并对变量赋值

      bool zygote = false;

      bool startSystemServer = false;

      bool application = false;

      String8 niceName;

      String8 className;



      ++i;  // Skip unused "parent dir" argument.

      while (i < argc) {

          const char * arg = argv [i++];

          if (strcmp(arg, "--zygote") == 0) {

               // 参数中有--zygote

              zygote = true;

              niceName = ZYGOTE_NICE_NAME;

          } else if (strcmp(arg, "--start-system-server") == 0) {

              // 参数中有--start-system-server

              startSystemServer = true;

          } else if (strcmp(arg, "--application") == 0) {

              application = true;

          } else if (strncmp(arg, "--nice-name=", 12) == 0) {

              niceName.setTo(arg + 12);

          } else if (strncmp(arg, "--", 2) != 0) {

              className.setTo(arg);

              break;

          } else {

              --i;

              break;

          }

      }





      if (zygote) {

         //如果zygote为true,则调用AndroidRuntime的start方法，并传入了"com.android.internal.os.ZygoteInit"参数

         runtime.start("com.android.internal.os.ZygoteInit", args, zygote);

      } else if (className) {

          runtime.start("com.android.internal.os.RuntimeInit", args, zygote);

      } else {

          fprintf(stderr, "Error: no class name or --zygote supplied.\n");

          app_usage();

          LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied.");

          return 10;

      }

  }

 

在app_main的mian()方法中，主要是根据zygote的脚本的参数进行解析，在解析到有--zygote字符后，则确定执行AndroidRuntime.start方法，并且第一个参数传为com.android.internal.os.ZygoteInit。

AndroidRuntime.start()

在此方法中，主要做了三件事：
· 创建虚拟机实例
· JNI方法的注册
· 调用参数的main()方法

  // 这里的className为：com.android.internal.os.ZygoteInit

  void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote)

  {

      

      /* start the virtual machine */

      JniInvocation jni_invocation;

      jni_invocation.Init(NULL);

      JNIEnv * env;

       // 1. 创建虚拟机

      if (startVm(& mJavaVM, &env, zygote) != 0) {

      return;

       }

      onVmCreated(env);

      // 2. JNI方法注册

      if (startReg(env) < 0) {

          ALOGE("Unable to register all android natives\n");

          return;

      }



      // 解析classname参数

     //将"com.android.internal.os.ZygoteInit"转换为"com/android/internal/os/ZygoteInit"

      char * slashClassName = toSlashClassName(className);

      jclass startClass = env->FindClass(slashClassName);



      if (startClass == NULL) {

      } else {

          //  得到ZygoteInit的main方法

          jmethodID startMeth = env->GetStaticMethodID(startClass, "main",

          "([Ljava/lang/String;)V");

          if (startMeth == NULL) {

          } else { env ->

                // 3. 执行ZygoteInit的main方法

              CallStaticVoidMethod(startClass, startMeth, strArray);

          }

      }

      free(slashClassName);



  }

 

对start方法进行了一些删减后，主要是通过startVm 创建虚拟机，通过startReg(env)进行JNI方法注册，最后解析className参数，去执行ZygoteInit.main方法。下面将逐一分析这三种状态。

1. 创建虚拟机实例

startVm：

int AndroidRuntime::startVm(JavaVM** pJavaVM, JNIEnv** pEnv, bool zygote)

  {

      // ... 

      // JNI检测功能

      bool checkJni = false;

      property_get("dalvik.vm.checkjni", propBuf, "");

      if (strcmp(propBuf, "true") == 0) {

          checkJni = true;

      } else if (strcmp(propBuf, "false") != 0) {

          /* property is neither true nor false; fall back on kernel parameter */

          property_get("ro.kernel.android.checkjni", propBuf, "");

          if (propBuf[0] == '1') {

              checkJni = true;

          }

      }

      ALOGD("CheckJNI is %s\n", checkJni ? "ON" : "OFF");

      if (checkJni) {

          addOption("-Xcheck:jni");

      }



       // /虚拟机产生的trace文件，主要用于分析系统问题，路径默认为/data/anr/traces.txt

      parseRuntimeOption("dalvik.vm.stack-trace-file", stackTraceFileBuf, "-Xstacktracefile:");



      //对于不同的软硬件环境，这些参数往往需要调整、优化，从而使系统达到最佳性能

      parseRuntimeOption("dalvik.vm.heapstartsize", heapstartsizeOptsBuf, "-Xms", "4m");

      parseRuntimeOption("dalvik.vm.heapsize", heapsizeOptsBuf, "-Xmx", "16m");



      parseRuntimeOption(

          "dalvik.vm.heapgrowthlimit",

          heapgrowthlimitOptsBuf,

          "-XX:HeapGrowthLimit="

      );

      parseRuntimeOption("dalvik.vm.heapminfree", heapminfreeOptsBuf, "-XX:HeapMinFree=");

      parseRuntimeOption("dalvik.vm.heapmaxfree", heapmaxfreeOptsBuf, "-XX:HeapMaxFree=");

      parseRuntimeOption(

          "dalvik.vm.heaptargetutilization",

          heaptargetutilizationOptsBuf,

          "-XX:HeapTargetUtilization="

      );

      // ...

      // 初始化虚拟机

      if (JNI_CreateJavaVM(pJavaVM, pEnv, & initArgs) < 0) {

      ALOGE("JNI_CreateJavaVM failed\n");

      return -1;

  }



      return 0;

  }



 

startVm方法里面有很多代码，但主要分为三步，第一步是检测，第二步是软硬件参数的设置，第三步是初始化虚拟机。

2. JNI方法的注册

startReg

  int AndroidRuntime::startReg(JNIEnv* env)

  {

      androidSetCreateThreadFunc((android_create_thread_fn) javaCreateThreadEtc);



      ALOGV("--- registering native functions ---\n");

      env->PushLocalFrame(200);

      //进程JNI方法的注册

      if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0) { env ->

          PopLocalFrame(NULL);

          return -1;

      }

      env->PopLocalFrame(NULL);

      return 0;

  }



  // 这里的array[]是gRegJNI,它是一个映射了很多方法的数组

  static int register_jni_procs(const RegJNIRec array[], size_t count, JNIEnv* env)

  {

      // 执行很多映射的方法

      for (size_t i = 0; i < count; i++) {

      if (array[i].mProc(env) < 0) {

          return -1;

      }

  }

      return 0;

  }

 

startReg方法是对JNI方法的注册，它通过一个有很多宏定义的数组，并执行数组定义的方法，进行对JNI和Java层方法一一映射。

3. 调用ZygoteInit.main方法

在AndroidRuntime.start()方法的最后，通过反射执行了其ZygoteInit.main()方法。

    if (startClass == NULL) {

    } else {

        //  得到ZygoteInit的main方法

        jmethodID startMeth = env->GetStaticMethodID(startClass, "main",

        "([Ljava/lang/String;)V");

        if (startMeth == NULL) {

        } else { env ->

              // 3. 执行ZygoteInit的main方法

            CallStaticVoidMethod(startClass, startMeth, strArray);

        }

    }

 

通过反射去执行ZygoteInit.main方法，也是第一次进入java语言的世界。所以AndroidRuntime的start方法做了三件事，一是初始化虚拟机，二是JNI方法的注册，三是通过反射执行ZygoteInit.main方法。

ZygoteInit.main

Zygote进程用于创建管理framework层的SystemServer进程，还用于创建App进程，就是应用App启动创建进程时，是由Zygote进程创建的，并且Zygote创建子进程将使用copy on write的技术，就是子进程直接继承父进程的现有的资源，在子进程对于共有的资源是读时共享，写时复制。
ZygoteInit.main方法中主要做了四件事：
· 注册服务端的socket，用于接收创建子进程的信息
· 提前预加载类和资源，用于子进程共享
· 创建SystemServer进程，其管理着framework层
· 循环监听服务socket,创建子进程

  public static void main(String argv[])

  {

      try {

          // 创建服务端Soctet，用于接收创建子进程信息

          registerZygoteSocket(socketName);

         // 提前预加载类和资源

          preload();

          // gc操作

          gcAndFinalize();

          // 创建SystemServer进程

          if (startSystemServer) {

              startSystemServer(abiList, socketName);

          }

         // 用服务socket监听创建进程信息，并创建子进程

          runSelectLoop(abiList);



          closeServerSocket();

      } catch (MethodAndArgsCaller caller) {

          caller.run();

      } catch (RuntimeException ex) {

          Log.e(TAG, "Zygote died with exception", ex);

          closeServerSocket();

          throw ex;

      }

  }



 

通过registerZygoteSocket方法去创建服务端的socket，preload()方法去提前加载类和资源，startSystemServer方法去创建SystemServer进程去管理framework层，runSelectLoop方法循环监听创建子进程。

1. 注册服务端Socket

registerZygoteSocket

  private static void registerZygoteSocket(String socketName)

  {

      if (sServerSocket == null) {

          int fileDesc;

          final String fullSocketName = ANDROID_SOCKET_PREFIX + socketName;

          try {

              String env = System . getenv (fullSocketName);

              fileDesc = Integer.parseInt(env);

          } catch (RuntimeException ex) {

              throw new RuntimeException (fullSocketName + " unset or invalid", ex);

          }



          try {

               // 创建服务端的socket

              FileDescriptor fd = new FileDescriptor();

              fd.setInt$(fileDesc);

              sServerSocket = new LocalServerSocket (fd);

          } catch (IOException ex) {

              throw new RuntimeException (

                      "Error binding to local socket '" + fileDesc + "'", ex);

          }

      }

  }

 

创建一个服务端的socket用于接口多个客户端的信息接收，在后面的runSelectLoop方法用于监听服务端的socket信息，以便创建子进程。

2. 预加载资源

preload

  static void preload()

  {

      preloadClasses();  //预加载位于/system/etc/preloaded-classes文件中的类

      preloadResources();  //预加载资源，包含drawable和color资源

      preloadOpenGL(); //预加载OpenGL 

      preloadSharedLibraries(); //预加载"android","compiler_rt","jnigraphics"这3个共享库

      preloadTextResources(); //预加载 文本连接符资源

      WebViewFactory.prepareWebViewInZygote(); //仅用于zygote进程，用于内存共享的进程

  }

 

preloadClasses()方法通过Class.forName()反射的方法去加载类，preloadResources方法主要是加载位于com.android.internal.R.array.preloaded_drawables和com.android.internal.R.array.preloaded_color_state_lists的资源。
提前加载资源的好处是，在复制创建子进程时，提前加载好的资源可以给子进程直接使用，不用第二次创建，但不好的地方是每个创建的子进程都有拥有很多资源，而不管是否需要。

3. 启动SystemServer进程

startSystemServer

  private static boolean startSystemServer(String abiList, String socketName)

  throws MethodAndArgsCaller, RuntimeException

  {

      // 通过数组保存创建systemserver进程的信息

      String args [] = {

          "--setuid=1000",

          "--setgid=1000",

          "--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,1021,1032,3001,3002,3003,3006,3007",

          "--capabilities=" + capabilities + "," + capabilities,

          "--nice-name=system_server",

          "--runtime-args",

          "com.android.server.SystemServer",

      };

      ZygoteConnection.Arguments parsedArgs = null;



      int pid;



      try {

          parsedArgs = new ZygoteConnection . Arguments (args);

          ZygoteConnection.applyDebuggerSystemProperty(parsedArgs);

          ZygoteConnection.applyInvokeWithSystemProperty(parsedArgs);



          // 创建systemserver进程

          pid = Zygote.forkSystemServer(

              parsedArgs.uid, parsedArgs.gid,

              parsedArgs.gids,

              parsedArgs.debugFlags,

              null,

              parsedArgs.permittedCapabilities,

              parsedArgs.effectiveCapabilities

          );

      } catch (IllegalArgumentException ex) {

          throw new RuntimeException (ex);

      }



      /* pid==0 则是子进程，就是systemserver */

      if (pid == 0) {

          if (hasSecondZygote(abiList)) {

              waitForSecondaryZygote(socketName);

          }



          // 完成system_server进程剩余的工作

          handleSystemServerProcess(parsedArgs);

      }



      return true;

  }



 

通过Zygote.forkSystemServer去创建SystemServer进程，其进程是管理着framework的，我们将在下一篇分析SystemServer进程进程的启动。

4. 循环等待孵化进程

runSelectLoop

  private static void runSelectLoop(String abiList) throws MethodAndArgsCaller

  {

      // FileDescriptor数组

      ArrayList<FileDescriptor> fds = new ArrayList<FileDescriptor>();

       // ZygoteConnection数组

      ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteConnection>();

      //sServerSocket是socket通信中的服务端，即zygote进程。保存到fds[0]

      fds.add(sServerSocket.getFileDescriptor());

      peers.add(null);



      while (true) {

          // StructPollfd数组，并将相应位置fds的值赋值

          StructPollfd[] pollFds = new StructPollfd[fds.size()];

          for (int i = 0; i < pollFds.length; ++i) {

              pollFds[i] = new StructPollfd ();

              pollFds[i].fd = fds.get(i);

              pollFds[i].events = (short) POLLIN;

          }

          try {

               //处理轮询状态，当pollFds有事件到来则往下执行，否则阻塞在这里

              Os.poll(pollFds, -1);

          } catch (ErrnoException ex) {

              throw new RuntimeException ("poll failed", ex);

          }

          for (int i = pollFds.length - 1; i >= 0; --i) {



              //采用I/O多路复用机制，当接收到客户端发出连接请求 或者数据处理请求到来，则往下执行；

             // 否则进入continue，跳出本次循环。

              if ((pollFds[i].revents & POLLIN) == 0) {

              continue;

             }

              if (i == 0) {

                  ZygoteConnection newPeer = acceptCommandPeer (abiList);

                  peers.add(newPeer);

                  fds.add(newPeer.getFileDesciptor());

              } else {

                   //i>0，则代表通过socket接收来自对端的数据，并执行相应操作

                  boolean done = peers.get (i).runOnce();

                  if (done) {

                      peers.remove(i);

                      fds.remove(i);

                  }

              }

          }

      }

  }

 

在runSelectLoop方法中有一个轮询的状态，如果有事件接收则会去执行runOnce()的方法操作：

  boolean runOnce() throws ZygoteInit.MethodAndArgsCaller

  {



      String args [];

      Arguments parsedArgs = null;

      FileDescriptor[] descriptors;



      try {

          //读取socket客户端发送过来的参数列表

          args = readArgumentList();

          descriptors = mSocket.getAncillaryFileDescriptors();

      } catch (IOException ex) {

          Log.w(TAG, "IOException on command socket " + ex.getMessage());

          closeSocket();

          return true;

      }



      if (args == null) {

          // EOF reached.

          closeSocket();

          return true;

      }



   

      try {

           //将binder客户端传递过来的参数，解析成Arguments对象格式

          parsedArgs = new Arguments (args);

          ...

         // fork创建一个新的进程

          pid = Zygote.forkAndSpecialize(

              parsedArgs.uid, parsedArgs.gid, parsedArgs.gids,

              parsedArgs.debugFlags, rlimits, parsedArgs.mountExternal, parsedArgs.seInfo,

              parsedArgs.niceName, fdsToClose, parsedArgs.instructionSet,

              parsedArgs.appDataDir

          );

      } catch (ErrnoException ex) {

          logAndPrintError(newStderr, "Exception creating pipe", ex);

      } catch (IllegalArgumentException ex) {

          logAndPrintError(newStderr, "Invalid zygote arguments", ex);

      } catch (ZygoteSecurityException ex) {

          logAndPrintError(

              newStderr,

              "Zygote security policy prevents request: ", ex

          );

      }



      try {

          if (pid == 0) {

             // 处理子进程

              IoUtils.closeQuietly(serverPipeFd);

              serverPipeFd = null;

              handleChildProc(parsedArgs, descriptors, childPipeFd, newStderr);



              // should never get here, the child is expected to either

              // throw ZygoteInit.MethodAndArgsCaller or exec().

              return true;

          } else {

              // 父进程

              IoUtils.closeQuietly(childPipeFd);

              childPipeFd = null;

              return handleParentProc(pid, descriptors, serverPipeFd, parsedArgs);

          }

      } finally {

          IoUtils.closeQuietly(childPipeFd);

          IoUtils.closeQuietly(serverPipeFd);

      }

  }



 

所以在runSelectLoop方法中，通过客户端的socket不断的和服务端的socket通信的监听，通过调用起runOnce方法去不断的创建新的进程。

总结

Zygote进程的启动过程主要有:

1. 创建虚拟机和JNI方法的注册


2. 注册服务Socket和提前加载系统类和资源


3. 创建SystemServer进程


4. 循环等待孵化进程