皮皮网

1.umi3源码解析之核心Service类初始化
2.pyc文件是怎么创建的？

umi3源码解析之核心Service类初始化

       前言

       umi是一个插件化的企业级前端应用框架，在开发中后台项目中应用颇广，确实带来了许多便利。借着这个契机，便有了我们接下来的“umi3源码解析”系列的分享，初衷很简单就是whms破解源码从源码层面上帮助大家深入认知umi这个框架，能够更得心应手的使用它，学习源码中的设计思想提升自身。该系列的大纲如下：

       开辟鸿蒙，今天要解析的就是第一part，内容包括以下两个部分：

       邂逅umi命令，看看umidev时都做了什么？

       初遇插件化，了解源码中核心的Service类初始化的过程。

       本次使用源码版本为?3.5.，地址放在这里了，接下来的每一块代码笔者都贴心的为大家注释了在源码中的位置，先clone再食用更香哟！

邂逅umi命令

       该部分在源码中的路径为：packages/umi

       首先是第一部分umi命令，umi脚手架为我们提供了umi这个命令，当我们创建完一个umi项目并安装完相关依赖之后，通过yarnstart启动该项目时，执行的命令就是umidev

       那么在umi命令运行期间都发生了什么呢，先让我们来看一下完整的流程，如下图：

       接下来我们对其几个重点的步骤进行解析，首先就是对于我们在命令行输入的umi命令进行处理。

处理命令行参数//packages/umi/src/cli.tsconstargs=yParser(process.argv.slice(2),{ alias:{ version:['v'],help:['h'],},boolean:['version'],});if(args.version&&!args._[0]){ args._[0]='version';constlocal=existsSync(join(__dirname,'../.local'))?chalk.cyan('@local'):'';console.log(`umi@${ require('../package.json').version}${ local}`);}elseif(!args._[0]){ args._[0]='help';}

       解析命令行参数所使用的yParser方法是基于yargs-parser封装,该方法的两个入参分别是进程的可执行文件的绝对路径和正在执行的JS文件的路径。解析结果如下：

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}

       在解析命令行参数后，对version和help参数进行了特殊处理：

       如果args中有version字段，并且args._中没有值，将执行version命令，并从package.json中获得version的值并打印

       如果没有version字段，args._中也没有值，将执行help命令

       总的shadowsocksr源码来说就是，如果只输入umi实际会执行umihelp展示umi命令的使用指南，如果输入umi--version会输出依赖的版本，如果执行umidev那就是接下来的步骤了。

       提问：您知道输入umi--versiondev会发什么吗？

       运行umidev

//packages/umi/src/cli.tsconstchild=fork({ scriptPath:require.resolve('./forkedDev'),});process.on('SIGINT',()=>{ child.kill('SIGINT');process.exit(0);});//packages/umi/src/utils/fork.tsif(CURRENT_PORT){ process.env.PORT=CURRENT_PORT;}constchild=fork(scriptPath,process.argv.slice(2),{ execArgv});child.on('message',(data:any)=>{ consttype=(data&&data.type)||null;if(type==='RESTART'){ child.kill();start({ scriptPath});}elseif(type==='UPDATE_PORT'){ //setcurrentusedportCURRENT_PORT=data.portasnumber;}process.send?.(data);});

       本地开发时，大部分脚手架都会采用开启一个新的线程来启动项目，umi脚手架也是如此。这里的fork方法是基于node中child_process.fork()方法的封装，主要做了以下三件事：

       确定端口号，使用命令行指定的端口号或默认的，如果该端口号已被占用则prot+=1

       开启子进程，该子进程独立于父进程，两者之间建立IPC通信通道进行消息传递

       处理通信，主要监听了RESTART重启和UPDATE_PORT更新端口号事件

       接下来看一下在子进程中运行的forkedDev.ts都做了什么。

//packages/umi/src/forkedDev.ts(async()=>{ try{ //1、设置NODE_ENV为developmentprocess.env.NODE_ENV='development';//2、InitwebpackversiondeterminationandrequirehookinitWebpack();//3、实例化Service类，执行run方法constservice=newService({ cwd:getCwd(),//umi项目的根路径pkg:getPkg(process.cwd()),//项目的package.json文件的路径});awaitservice.run({ name:'dev',args,});//4、父子进程通信letclosed=false;process.once('SIGINT',()=>onSignal('SIGINT'));process.once('SIGQUIT',()=>onSignal('SIGQUIT'));process.once('SIGTERM',()=>onSignal('SIGTERM'));functiononSignal(signal:string){ if(closed)return;closed=true;//退出时触发插件中的onExit事件service.applyPlugins({ key:'onExit',type:service.ApplyPluginsType.event,args:{ signal,},});process.exit(0);}}catch(e:any){ process.exit(1);}})();

       设置process.env.NODE_ENV的值

       initWebpack（接下来解析）

       实例化Service并run（第二part的内容）

       处理父子进程通信，当父进程监听到SIGINT、SIGTERM等终止进程的信号，也通知到子进程进行终止；子进程退出时触发插件中的onExit事件

       initWebpack

//packages/umi/src/initWebpack.tsconsthaveWebpack5=(configContent.includes('webpack5:')&&!configContent.includes('//webpack5:')&&!configContent.includes('//webpack5:'))||(configContent.includes('mfsu:')&&!configContent.includes('//mfsu:')&&!configContent.includes('//mfsu:'));if(haveWebpack5||process.env.USE_WEBPACK_5){ process.env.USE_WEBPACK_5='1';init(true);}else{ init();}initRequreHook();

       这一步功能是检查用户配置确定初始化webpack的版本。读取默认配置文件.umirc和config/config中的配置，如果其中有webpack5或?mfsu等相关配置，umi就会使用webpack5进行初始化，否则就使用webpack4进行初始化。这里的mfsu是webpack5的模块联邦相关配置，umi在3.5版本时已经进行了支持。

初遇插件化

       该部分在源码中的路径为：packages/core/src/Service

       说起umi框架，最先让人想到的就是插件化，这也是框架的核心，该部分实现的touch源码核心源码就是Service类，接下来我们就来看看Service类的实例化和init()的过程中发生了什么，可以称之为插件化实现的开端，该部分的大致流程如下

       该流程图中前四步，都是在Service类实例化的过程中完成的，接下来让我们走进Service类。

Service类的实例化//packages/core/src/Service/Service.tsexportdefaultclassServiceextendsEventEmitter{ constructor(opts:IServiceOpts){ super();this.cwd=opts.cwd||process.cwd();//当前工作目录//repoDirshouldbetherootdirofrepothis.pkg=opts.pkg||this.resolvePackage();//package.jsonthis.env=opts.env||process.env.NODE_ENV;//环境变量//在解析config之前注册babelthis.babelRegister=newBabelRegister();//通过dotenv将环境变量中的变量从.env或.env.local文件加载到process.env中this.loadEnv();//1、getuserconfigconstconfigFiles=opts.configFiles;this.configInstance=newConfig({ cwd:this.cwd,service:this,localConfig:this.env==='development',configFiles});this.userConfig=this.configInstance.getUserConfig();//2、getpathsthis.paths=getPaths({ cwd:this.cwd,config:this.userConfig!,env:this.env,});//3、getpresetsandpluginsthis.initialPresets=resolvePresets({ ...baseOpts,presets:opts.presets||[],userConfigPresets:this.userConfig.presets||[],});this.initialPlugins=resolvePlugins({ ...baseOpts,plugins:opts.plugins||[],userConfigPlugins:this.userConfig.plugins||[],});}}

       Service类继承自EventEmitter用于实现自定义事件。在Service类实例化的过程中除了初始化成员变量外主要做了以下三件事：

       1、解析配置文件

//packages/core/src/Config/Config.tsconstDEFAULT_CONFIG_FILES=[//默认配置文件'.umirc.ts','.umirc.js','config/config.ts','config/config.js',];//...if(Array.isArray(opts.configFiles)){ //配置的优先读取this.configFiles=lodash.uniq(opts.configFiles.concat(this.configFiles));}//...getUserConfig(){ //1、找到configFiles中的第一个文件constconfigFile=this.getConfigFile();this.configFile=configFile;//潜在问题：.local和.env的配置必须有configFile才有效if(configFile){ letenvConfigFile;if(process.env.UMI_ENV){ //1.根据UMI_ENV添加后缀eg:.umirc.ts-->.umirc.cloud.tsconstenvConfigFileName=this.addAffix(configFile,process.env.UMI_ENV,);//2.去掉后缀eg:.umirc.cloud.ts-->.umirc.cloudconstfileNameWithoutExt=envConfigFileName.replace(extname(envConfigFileName),'',);//3.找到该环境下对应的配置文件eg:.umirc.cloud.[ts|tsx|js|jsx]envConfigFile=getFile({ base:this.cwd,fileNameWithoutExt,type:'javascript',})?.filename;}constfiles=[configFile,//eg:.umirc.tsenvConfigFile,//eg:.umirc.cloud.tsthis.localConfig&&this.addAffix(configFile,'local'),//eg:.umirc.local.ts].filter((f):fisstring=>!!f).map((f)=>join(this.cwd,f))//转为绝对路径.filter((f)=>existsSync(f));//clearrequirecacheandsetbabelregisterconstrequireDeps=files.reduce((memo:string[],file)=>{ memo=memo.concat(parseRequireDeps(file));//递归解析依赖returnmemo;},[]);//删除对象中的键值require.cache[cachePath]，下一次require将重新加载模块requireDeps.forEach(cleanRequireCache);this.service.babelRegister.setOnlyMap({ key:'config',value:requireDeps,});//requireconfigandmergereturnthis.mergeConfig(...this.requireConfigs(files));}else{ return{ };}}

       细品源码，可以看出umi读取配置文件的优先级：自定义配置文件?>.umirc>config/config，后续根据UMI_ENV尝试获取对应的配置文件，development模式下还会使用local配置，不同环境下的配置文件也是有优先级的

       例如：.umirc.local.ts>.umirc.cloud.ts>.umirc.ts

       由于配置文件中可能require其他配置，这里通过parseRequireDeps方法进行递归处理。在解析出所有的配置文件后，会通过cleanRequireCache方法清除requeire缓存，这样可以保证在接下来合并配置时的引入是实时的。

       2、获取相关绝对路径

//packages/core/src/Service/getPaths.tsexportdefaultfunctiongetServicePaths({ cwd,config,env,}:{ cwd:string;config:any;env?:string;}):IServicePaths{ letabsSrcPath=cwd;if(isDirectoryAndExist(join(cwd,'src'))){ absSrcPath=join(cwd,'src');}constabsPagesPath=config.singular?join(absSrcPath,'page'):join(absSrcPath,'pages');consttmpDir=['.umi',env!=='development'&&env].filter(Boolean).join('-');returnnormalizeWithWinPath({ cwd,absNodeModulesPath:join(cwd,'node_modules'),absOutputPath:join(cwd,config.outputPath||'./dist'),absSrcPath,//srcabsPagesPath,//pagesabsTmpPath:join(absSrcPath,tmpDir),});}

       这一步主要获取项目目录结构中node_modules、dist、src、pages等文件夹的绝对路径。如果用户在配置文件中配置了singular为true，那么页面文件夹路径就是src/page，默认是src/pages

       3、收集preset和plugin以对象形式描述

       在umi中“万物皆插件”，preset是对于插件的描述，可以理解为“插件集”，pandownload源码是为了方便对插件的管理。例如：@umijs/preset-react就是一个针对react应用的插件集，其中包括了plugin-access权限管理、plugin-antdantdUI组件等。

//packages/core/src/Service/Service.tsthis.initialPresets=resolvePresets({ ...baseOpts,presets:opts.presets||[],userConfigPresets:this.userConfig.presets||[],});this.initialPlugins=resolvePlugins({ ...baseOpts,plugins:opts.plugins||[],userConfigPlugins:this.userConfig.plugins||[],});

       在收集preset和plugin时，首先调用了resolvePresets方法，其中做了以下处理：

       3.1、调用getPluginsOrPresets方法，进一步收集preset和plugin并合并

//packages/core/src/Service/utils/pluginUtils.tsgetPluginsOrPresets(type:PluginType,opts:IOpts):string[]{ constupperCaseType=type.toUpperCase();return[//opts...((opts[type===PluginType.preset?'presets':'plugins']asany)||[]),//env...(process.env[`UMI_${ upperCaseType}S`]||'').split(',').filter(Boolean),//dependencies...Object.keys(opts.pkg.devDependencies||{ }).concat(Object.keys(opts.pkg.dependencies||{ })).filter(isPluginOrPreset.bind(null,type)),//userconfig...((opts[type===PluginType.preset?'userConfigPresets':'userConfigPlugins']asany)||[]),].map((path)=>{ returnresolve.sync(path,{ basedir:opts.cwd,extensions:['.js','.ts'],});});}

       这里可以看出收集preset和plugin的来源主要有四个：

       实例化Service时的入参

       process.env中指定的UMI_PRESETS或UMI_PLUGINS

       package.json中dependencies和devDependencies配置的，需要命名规则符合?/^(@umijs\/|umi-)preset-/这个正则

       解析配置文件中的，即入参中的userConfigPresets或userConfigPresets

       3.2、调用pathToObj方法：将收集的plugin或preset以对象的形式输出

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}0

       umi官网中提到过：每个插件都会对应一个id和一个key，id是路径的简写，key是进一步简化后用于配置的唯一值。便是在这一步进行的处理

       形式如下：

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}1

       思考：为什么要将插件以对象的形式进行描述？有什么好处？

执行run方法，初始化插件

       在Service类实例化完毕后，会立马调用run方法，run()执行的第一步就是执行init方法，init()方法的功能就是完成插件的初始化，主要操作如下：

       遍历initialPresets并init

       合并initpresets过程中得到的plugin和initialPlugins

       遍历合并后的plugins并init

       这里的initialPresets和initialPlugins就是上一步收集preset和plugin得到的结果，在这一步要对其逐一的init，接下来我们看一下init的过程中做了什么。

       Initplugin

//输入umidev经yargs-parser解析后为：//args={ //_:["dev"],//}2

       这段代码主要做了以下几件事情：

       getPluginAPI方法：newPluginAPI时传入了Service实例，通过pluginAPI实例中的registerMethod方法将register方法添加到Service实例的pluginMethods中，后续返回pluginAPI的代理，以动态获取最新的register方法，以实现边注册边使用。

//输入umidev经yargs-parser解析后为：/

pyc文件是怎么创建的？

       pyc文件的触发

       前面我们提到，每一个代码块(code block)都会对应一个PyCodeObject对象，Python会将该对象存储在pyc文件中。但不幸的是，事实并不总是faxcomlib 源码这样。有时，当我们运行一个简单的程序时并没有产生pyc文件，因此我们猜测：有些Python程序只是临时完成一些琐碎的工作，这样的程序仅仅只会运行一次，然后就不会再使用了，因此也就没有保存至pyc文件的必要。

       如果我们在代码中加上了一个import abc这样的语句，再执行你就会发现Python为其生成了pyc文件，这就说明import会触发pyc的生成。

       实际上，在运行过程中，如果碰到import abc这样的语句，那么Python会在设定好的path中寻找abc.pyc或者abc.pyd文件。如果没有这些文件，而是只发现了abc.py，那么Python会先将abc.py编译成PyCodeObject，然后创建pyc文件，并将PyCodeObject写到pyc文件里面去。

       接下来，再对abc.pyc进行import动作，对，并不是编译成PyCodeObject对象之后就直接使用。而是先写到pyc文件里面去，然后再将pyc文件里面的PyCodeObject对象重新在内存中复制出来。

       关于Python的import机制，我们后面会剖析，这里只是用来完成pyc文件的触发。当然得到pyc文件还有其它方法，比如使用py_compile模块。

#a.pyclassA:a=1#b.pyimporta

       执行b.py的时候，会发现创建了a.cpython-.pyc。另外关于pyc文件的创建位置，会在当前文件的同级目录下的__pycache__目录中创建，名字就叫做：py文件名.cpython-版本号.pyc。

pyc文件里面包含哪些内容

       上面我们提到，Python通过import module进行加载时，如果没有找到相应的pyc或者pyd文件，就会在py文件的基础上自动创建pyc文件。而创建之后，会往里面写入三个内容：

       1. magic number

       这是Python定义的一个整数值，不同版本的Python会定义不同的magic number，这个值是为了保证Python能够加载正确的pyc。

       比如Python3.7不会加载3.6版本的pyc，因为Python在加载pyc文件的时候会首先检测该pyc的magic number，如果和自身的magic number不一致，则拒绝加载。

       2. pyc的创建时间

       这个很好理解，判断源代码的最后修改时间和pyc文件的创建时间。如果pyc文件的创建时间比源代码的修改时间要早，说明在生成pyc之后，源代码被修改了，那么会重新编译并生成新的pyc，而反之则会直接加载已存在的pyc。

       3. PyCodeObject对象

       这个不用说了，肯定是要存储的。

pyc文件的写入

       下面就来看看pyc文件是如何写入上面三个内容的。

       既然要写入，那么肯定要有文件句柄，我们来看看：

//位置：Python/marshal.c//FILE是C自带的文件句柄//可以把WFILE看成是FILE的包装typedefstruct{ FILE*fp;//文件句柄//下面的字段在写入信息的时候会看到interror;intdepth;PyObject*str;char*ptr;char*end;char*buf;_Py_hashtable_t*hashtable;intversion;}WFILE;

       首先是写入magic number和创建时间，它们会调用PyMarshal_WriteLongToFile函数进行写入：

voidPyMarshal_WriteLongToFile(longx,FILE*fp,intversion){ //magicnumber和创建时间，只是一个整数//在写入的时候，使用char[4]来保存charbuf[4];//声明一个WFILE类型变量wfWFILEwf;//内存初始化memset(&wf,0,sizeof(wf));//初始化内部成员wf.fp=fp;wf.ptr=wf.buf=buf;wf.end=wf.ptr+sizeof(buf);wf.error=WFERR_OK;wf.version=version;//调用w_long将x、也就是版本信息或者时间写到wf里面去w_long(x,&wf);//刷到磁盘上w_flush(&wf);}

       所以该函数只是初始化了一个WFILE对象，真正写入则是调用的w_long。

staticvoidw_long(longx,WFILE*p){ w_byte((char)(x&0xff),p);w_byte((char)((x>>8)&0xff),p);w_byte((char)((x>>)&0xff),p);w_byte((char)((x>>)&0xff),p);}

       w_long则是调用 w_byte 将 x 逐个字节地写到文件里面去。

       而写入PyCodeObject对象则是调用了PyMarshal_WriteObjectToFile，我们也来看看长什么样子。

voidPyMarshal_WriteObjectToFile(PyObject*x,FILE*fp,intversion){ charbuf[BUFSIZ];WFILEwf;memset(&wf,0,sizeof(wf));wf.fp=fp;wf.ptr=wf.buf=buf;wf.end=wf.ptr+sizeof(buf);wf.error=WFERR_OK;wf.version=version;if(w_init_refs(&wf,version))return;/*callermushcheckPyErr_Occurred()*/w_object(x,&wf);w_clear_refs(&wf);w_flush(&wf);}

       可以看到和PyMarshal_WriteLongToFile基本是类似的，只不过在实际写入的时候，PyMarshal_WriteLongToFile调用的是w_long，而PyMarshal_WriteObjectToFile调用的是w_object。

staticvoidw_object(PyObject*v,WFILE*p){ charflag='\0';p->depth++;if(p->depth>MAX_MARSHAL_STACK_DEPTH){ p->error=WFERR_NESTEDTOODEEP;}elseif(v==NULL){ w_byte(TYPE_NULL,p);}elseif(v==Py_None){ w_byte(TYPE_NONE,p);}elseif(v==PyExc_StopIteration){ w_byte(TYPE_STOPITER,p);}elseif(v==Py_Ellipsis){ w_byte(TYPE_ELLIPSIS,p);}elseif(v==Py_False){ w_byte(TYPE_FALSE,p);}elseif(v==Py_True){ w_byte(TYPE_TRUE,p);}elseif(!w_ref(v,&flag,p))w_complex_object(v,flag,p);p->depth--;}

       可以看到本质上还是调用了w_byte，但这仅仅是一些特殊的对象。如果是列表、字典之类的数据，那么会调用w_complex_object，也就是代码中的最后一个else if分支。

       w_complex_object这个函数的源代码很长，我们看一下整体结构，具体逻辑就不贴了，我们后面会单独截取一部分进行分析。

staticvoidw_complex_object(PyObject*v,charflag,WFILE*p){ Py_ssize_ti,n;//如果是整数的话，执行整数的写入逻辑if(PyLong_CheckExact(v)){ //......}//如果是浮点数的话，执行浮点数的写入逻辑elseif(PyFloat_CheckExact(v)){ if(p->version>1){ //......}else{ //......}}//如果是复数的话，执行复数的写入逻辑elseif(PyComplex_CheckExact(v)){ if(p->version>1){ //......}else{ //......}}//如果是字节序列的话，执行字节序列的写入逻辑elseif(PyBytes_CheckExact(v)){ //......}//如果是字符串的话，执行字符串的写入逻辑elseif(PyUnicode_CheckExact(v)){ if(p->version>=4&&PyUnicode_IS_ASCII(v)){ //......}else{ //......}}else{ //......}}//如果是元组的话，执行元组的写入逻辑elseif(PyTuple_CheckExact(v)){ //......}//如果是列表的话，执行列表的写入逻辑elseif(PyList_CheckExact(v)){ //......}//如果是字典的话，执行字典的写入逻辑elseif(PyDict_CheckExact(v)){ //......}//如果是集合的话，执行集合的写入逻辑elseif(PyAnySet_CheckExact(v)){ //......}//如果是PyCodeObject对象的话//执行PyCodeObject对象的写入逻辑elseif(PyCode_Check(v)){ //......}//如果是Buffer的话，执行Buffer的写入逻辑elseif(PyObject_CheckBuffer(v)){ //......}else{ W_TYPE(TYPE_UNKNOWN,p);p->error=WFERR_UNMARSHALLABLE;}}

       源代码虽然长，但是逻辑非常单纯，就是对不同的对象、执行不同的写动作，然而其最终目的都是通过w_byte写到pyc文件中。了解完函数的整体结构之后，我们再看一下具体细节，看看它在写入对象的时候到底写入了哪些内容？

staticvoidw_complex_object(PyObject*v,charflag,WFILE*p){ //......elseif(PyList_CheckExact(v)){ W_TYPE(TYPE_LIST,p);n=PyList_GET_SIZE(v);W_SIZE(n,p);for(i=0;i<n;i++){ w_object(PyList_GET_ITEM(v,i),p);}}elseif(PyDict_CheckExact(v)){ Py_ssize_tpos;PyObject*key,*value;W_TYPE(TYPE_DICT,p);/*ThisoneisNULLobjectterminated!*/pos=0;while(PyDict_Next(v,&pos,&key,&value)){ w_object(key,p);w_object(value,p);}w_object((PyObject*)NULL,p);}//......}

       以列表和字典为例，它们在写入的时候实际上写的是内部的元素，其它对象也是类似的。

deffoo():lst=[1,2,3]#把列表内的元素写进去了print(foo.__code__.co_consts)#(None,1,2,3)

       但问题来了，如果只是写入元素的话，那么Python在加载的时候怎么知道它是一个列表呢？所以在写入的时候不能光写数据，类型信息也要写进去。我们再看一下上面列表和字典的写入逻辑，里面都调用了W_TYPE，它负责将类型信息写进去。

       因此无论对于哪种对象，在写入具体数据之前，都会先调用W_TYPE将类型信息写进去。如果没有类型信息，那么当Python加载pyc文件的时候，只会得到一坨字节流，而无法解析字节流中隐藏的结构和蕴含的信息。

       所以在往pyc文件里写入数据之前，必须先写入一个标识，诸如TYPE_LIST、TYPE_TUPLE、TYPE_DICT等等，这些标识正是对应的类型信息。

       如果解释器在pyc文件中发现了这样的标识，则预示着上一个对象结束，新的对象开始，并且也知道新对象是什么样的对象，从而也知道该执行什么样的构建动作。当然，这些标识也是可以看到的，在底层已经定义好了。

//marshal.c#defineTYPE_NULL'0'#defineTYPE_NONE'N'#defineTYPE_FALSE'F'#defineTYPE_TRUE'T'#defineTYPE_STOPITER'S'#defineTYPE_ELLIPSIS'.'#defineTYPE_INT'i'/*TYPE_INTisnotgeneratedanymore.Supportedforbackwardcompatibilityonly.*/#defineTYPE_INT'I'#defineTYPE_FLOAT'f'#defineTYPE_BINARY_FLOAT'g'#defineTYPE_COMPLEX'x'#defineTYPE_BINARY_COMPLEX'y'#defineTYPE_LONG'l'#defineTYPE_STRING's'#defineTYPE_INTERNED't'#defineTYPE_REF'r'#defineTYPE_TUPLE'('#defineTYPE_LIST'['#defineTYPE_DICT'{ '#defineTYPE_CODE'c'#defineTYPE_UNICODE'u'#defineTYPE_UNKNOWN'?'#defineTYPE_SET'<'#defineTYPE_FROZENSET'>'

       到了这里可以看到，其实Python对PyCodeObject对象的导出实际上是不复杂的。因为不管什么对象，最后都为归结为两种简单的形式，一种是数值写入，一种是字符串写入。

       上面都是对数值的写入，比较简单，仅仅需要按照字节依次写入pyc即可。然而在写入字符串的时候，Python设计了一种比较复杂的机制，有兴趣可以自己阅读源码，这里不再介绍。

PyCodeObject的包含关系

       有下面一个文件：

//位置：Python/marshal.c//FILE是C自带的文件句柄//可以把WFILE看成是FILE的包装typedefstruct{ FILE*fp;//文件句柄//下面的字段在写入信息的时候会看到interror;intdepth;PyObject*str;char*ptr;char*end;char*buf;_Py_hashtable_t*hashtable;intversion;}WFILE;0

       显然编译之后会创建三个PyCodeObject对象，但是有两个PyCodeObject对象是位于另一个PyCodeObject对象当中的。

       也就是foo和A对应的PyCodeObject对象，位于模块对应的PyCodeObject对象当中，准确的说是位于co_consts指向的常量池当中。举个栗子：

//位置：Python/marshal.c//FILE是C自带的文件句柄//可以把WFILE看成是FILE的包装typedefstruct{ FILE*fp;//文件句柄//下面的字段在写入信息的时候会看到interror;intdepth;PyObject*str;char*ptr;char*end;char*buf;_Py_hashtable_t*hashtable;intversion;}WFILE;1

       我们看到f2对应的PyCodeObject确实位于f1的常量池当中，准确的说是f1的常量池中有一个指针指向f2对应的PyCodeObject。

       不过这都不是重点，重点是PyCodeObject对象是可以嵌套的。当在一个作用域内部发现了一个新的作用域，那么新的作用域对应的PyCodeObject对象会位于外层作用域的PyCodeObject对象的常量池中，或者说被常量池中的一个指针指向。

       而在写入pyc的时候会从最外层、也就是模块的PyCodeObject对象开始写入。如果碰到了包含的另一个PyCodeObject对象，那么就会递归地执行写入新的PyCodeObject对象。

       如此下去，最终所有的PyCodeObject对象都会写入到pyc文件当中。因此pyc文件里的PyCodeObject对象也是以一种嵌套的关系联系在一起的，和代码块之间的关系是保持一致的。

//位置：Python/marshal.c//FILE是C自带的文件句柄//可以把WFILE看成是FILE的包装typedefstruct{ FILE*fp;//文件句柄//下面的字段在写入信息的时候会看到interror;intdepth;PyObject*str;char*ptr;char*end;char*buf;_Py_hashtable_t*hashtable;intversion;}WFILE;2

       这里问一下，上面那段代码中创建了几个PyCodeObject对象呢？

       答案是6个，首先模块是一个，foo函数一个，bar函数一个，类A一个，类A里面的foo函数一个，类A里面的bar函数一个，所以一共是6个。

       而且这里的PyCodeObject对象是层层嵌套的，一开始是对整个全局模块创建PyCodeObject对象，然后遇到了函数foo，那么再为函数foo创建PyCodeObject对象，依次往下。

       所以，如果是常量值，则相当于是静态信息，直接存储起来便可。可如果是函数、类，那么会为其创建新的PyCodeObject对象，然后再收集起来。

小结

       以上就是pyc文件相关的内容，源文件在编译之后会得到pyc文件。因此我们不光可以手动导入 pyc，用Python直接执行pyc文件也是可以的。

       以上就是本次分享的所有内容，想要了解更多欢迎前往公众号：Python编程学习圈，每日干货分享