皮皮网

1.[Dev] Xcode的信息信息记录
2.在网上找人做了一个网站，担心被骗，记录记录客服说源码这些都给你，源码源码他们拿着也没用，信息信息是记录记录真的吗
3.易语言做键盘记录器的源码
4.cloud-init介绍及源码解读(上)

[Dev] Xcode的记录

       构建过程可以分为预处理(preprocess) -- 编译(build) -- 汇编(assemble) -- 连接(link)这几个大的过程。

       LLVM(Low Level Virtual Machine)是源码源码java 播放器 源码强大的编译器开发工具套件，其核心思想是信息信息通过生成中间代码IR，分离前后端（前端编译器，记录记录后端目标机器码）。源码源码这样做的信息信息好处是，前端新增编译器，记录记录不用再单独去适配目标机器码，源码源码只需要生成中间代码，信息信息LLVM就可以生成对应的记录记录目标机器码。下面就是源码源码LLVM的架构。

       预处理：头文件引入、宏替换、注释处理、条件编译等操作；

       词法分析：读入源文件字符流，组成有意义的词素（lexeme）序列，生成词法单元（token）输出；

       语法分析：Token流解析成一颗抽象语法树(AST)；

       CodeGen：遍历语法树，生成LLVM IR代码，这是前端的输出文件；

       汇编：LLVM对IR进行优化，针对不同架构生成不同目标代码，以汇编代码格式输出；

       汇编器生成.o文件：将汇编代码转换为机器代码，输出目标文件（object file）；

       连接器：将目标文件和(.dylib、.a、.tbd、.framework)进行连接，生成可执行mach-o文件。

       dwarf：debugging with attribute record formats，人数统计源码一种源码调试信息的记录格式，用于源码级调试；

       dSym：debug Symboles，调试符号，即符号表文件。符号对应着类、函数、变量等，是内存与符号如函数名、文件名、行号等的映射，崩溃日志解析非常重要。可以用dwarfdump 命令来查看dwarf调试信息。

       DW_AT_low_pc表示函数的起始地址 DW_AT_high_pc表示函数的结束地址 DW_AT_frame_base表示函数的栈帧基址 DW_AT_object_pointer表示对象指针地址 DW_AT_name表示函数的名字 DW_AT_decl_file表示函数所在的文件 DW_AT_decl_line表示函数所在的文件中的行数 DW_AT_prototyped为一个 Bool 值, 为 true 时代表这是一个子程序/函数(subroutine) DW_AT_type表示函数的返回值类型 DW_AT_artificial为一个Bool值，为true时代表这是一个由编译器生成而不是源程序显式声明

       使用symbolicatecrash命令行

       使用dwarfdump和atos工具

       xcode-project-file-format这里对xcodeproj文件格式进行了说明。

       xcodeproj文件包含以下元素

       总体说明

       结合上面的说明，对project.phxproj文件结构进行说明

       项目中setting有2处，project和target中都有，那么他们之间的关系是怎样的？

       在Xcode中添加代码块步骤

       1、选择代码，右键选择 create code snippet，或者在顶部导航，选择Editor-create code snippet；

       2、编辑信息和代码即可，其中completion表示输入的快捷方式；

       3、需要修改的参数用形式添加 ；

       4、所在目录~/Library/Developer/Xcode/UserData/CodeSnippets 。

       还需要注意xcshareddata目录下

       参考

       Xcode build过程中都做了什么 Xcode编译疾如风-3.浅谈 dwarf 和 dSYM iOS崩溃日志解析&原理 - 掘金 LLVM编译流程 & Clang插件开发 8. Xcode 工程文件解析 - 掘金 XCode工程文件结构及Xcodeproj框架的使用( 二 ) XCode: Target Settings和Project Settings的区别 Xcode-项目重命名

在网上找人做了一个网站，担心被骗，客服说源码这些都给你，他们拿着也没用，littlenavmap源码配置是真的吗

       说法有一定的道理

       但是这说明另一个问题，那就是他们如果习惯这么做，一般都会服务不好

       除非收费很高

       你要明白这里面的道理和关系

       网站，服务，本身和源码归谁没多大关系。

       但价格和管理模式，才是一个网站能不能稳定运营的关键。

       我们做了十三年的企业网站运营，策划。见过太多太多的企业用户，其实网站很多时候本身没有问题，但是误操作却产生了巨大的影响。

       比如有些时候，明明改一个就可以了，但是企业呢？自己并没有专业的网站技术人员，只是一个小客服，小秘书在打理网站。或许自己有点小经验于是就动手改代码，但是经验尚浅又没有备份习惯，改错一行代码，全站瘫痪。。。又不得不找技术公司售后服务，而这些，都是没有必要的，额外的售后成本付出。

       小公司的网络公司客户少，可能无所谓，但是github驱动源码我们动辄都是几百上千个客户的时候，这种无谓的成本就显得很重要，不可能总去因为这些不必要的事，影响其他正常客户的服务。

       所以并不是不给源码，也不是不给网站代码权限，而是在可以做到的时候没有必要拥有太高权限，权力越大，责任越大，如果没能力，尽量不要去过多干涉网站技术运作。

       还有一点大家心里都明白的，如果说，你拿到代码就能为所欲为的情况，那你根本没必要要源码。。。既然你有那能力做代码方面的工作，那就有能力自己做网站了。。。对不对？无非是慢点，但是很多都是自己既没能力，又觉得略知一二。。。以为拿了源码就能代表什么。

       其实你是不知道，对于一般的企业而言，我们有经验的网络公司，稍微加点技术，cas验证源码代码就算给你，你也不可能做其他用处。。。所以不要认为拿到代码能有什么额外的用处。

       这也是一个正规的公司或团队必备的管理方案

       如果一个公司不论价钱不论协议，随便谁都可以给源码

       那就意味着，这个公司的业务是任人复制的，也就意味着你的网站，明天就有另一个副本，另一个公司跟你的一模一样。。。因为他们可以给你，就可以给别人。。。没原则可言。

       对于服务而言，源码在哪是很重要的，像我们的客户，都会源码和服务器统一管理

       服务器什么环境，代码什么状态，谁改了哪里，都一一记录在案。这样某天出现问题，可以最短时间内排查故障，恢复企业网络的运营。

       但是你拿走了呢?

       网站我们做好的，服务器你们自己去找，代码自己维护，突然出现问题了，问谁都说没动过。。。服务器环境，权限都不是我们的，代码哪里改过都不熟悉，本来一小时就解决的问题，甚至三五天都搞不定，还要各个不同公司，不同的人去协调，去配合。

       这段时间的直接损失，间接业务影响，其实是企业的。

       说了这么多，明白人可以看的出来其实最重要的不是代码，而是服务，所以对于企业要接入网络的时候，选择的并不是你拥有什么权限，而是你能够得到什么样的服务，服务好，无论代码，服务器在哪，网站都会稳定的运转，花钱再多都是值得的。

       但是！！！如果没能力，代码在哪，出了问题没人管，花钱再少也是最大的损失。

       而且很多时候，并不是代码能够解决的问题。需要的是经验。

       我们现在为企业做的网站，实现的都是智能四维系统，一个网站实现电脑网站+手机网站+企业微信公众平台+APP，全方位的网络支持。这样才能更好的接触 互联网+

       而这些，不是说代码给你，你拿走了你就能维护的起来。。。需要很多运维经验和管理精力。

       而对于企业而言，我们做好一切后备支持，企业只需管理信息数据即可。

       用合适的成本，找合适的人，去做合适的事，这叫良性循环

       不需要自己费心，才叫服务。。。什么都想要，什么都拿走，啥都得自己去干。。。那叫负担。

       您说呢。

易语言做键盘记录器的源码

       易语言做键盘记录器的源码如下：

       程序集

       窗口程序集1

       子程序

       __启动窗口_创建完毕

       SkinH_Attach

       ()

       编辑框1禁止

       ＝

       真

       停止按钮禁止

       ＝

       真

       信息框

       (“欢迎使用小天键盘记录系统，在关闭此记录系统后，会自动保存记录的内容到运行目录！”,

       #信息图标,

       “欢迎使用！”)

       子程序

       _停止按钮_被单击

       开始按钮禁止

       ＝

       假

       编辑框1禁止

       ＝

       真

       时钟1时钟周期

       ＝

       0

       停止按钮禁止

       ＝

       真

       子程序

       _开始按钮_被单击

       开始按钮禁止

       ＝

       真

       编辑框1禁止

       ＝

       假

       时钟1时钟周期

       ＝

       

       停止按钮禁止

       ＝

       假

       子程序

       _时钟1_周期事件

       编辑框1加入文本

       (看看按键

       ())

       子程序

       _按钮1_被单击

       编辑框1内容

       ＝

       “

       ”

       子程序

       __启动窗口_可否被关闭,

       逻辑型

       写到文件

       (取运行目录

       ()

       ＋

       “\记录内容txt”,

       到字节集

       (编辑框1内容))

       销毁

       ()

       子程序

       _按钮2_被单击

       删除文件

       (取运行目录

       ()

       ＋

       “\记录内容txt”)

cloud-init介绍及源码解读(上)

       cloud-init介绍及源码解读(上)

       cloud-init的基本概念

       metadata包含服务器信息，如instance id，display name等。userdata包含文件、脚本、yaml文件等，用于系统配置和软件环境配置。datasource是cloud-init配置数据来源，支持AWS、Azure、OpenStack等，定义统一抽象类接口，所有实现都要遵循规范。

       模块决定定制化工作，metadata决定结果。cloud-init配置有4个阶段：local、network、config、final。cloud-init支持多种userdata类型，如自定义Python代码、MIME文件等。用户数据类型包括User-Data Script（MIME text/x-shellscript）和Cloud Config Data（MIME text/cloud-config）。

       cloud-init支持多种datasource，包括NoCloud、ConfigDrive、OpenNebula等。通过Virtual-Router获取metadata和userdata信息。

       cloud-init在云主机上创建目录结构以记录信息。cloud.cfg文件定义各阶段任务。

       cloud-init工作原理

       cloud-init通过从datasource获取metadata，执行四个阶段任务完成定制化工作。在systemd环境下，这些阶段对应的服务在启动时执行一次。

       local阶段从config drive中获取配置信息写入网络接口文件。network阶段完成磁盘格式化、分区、挂载等。config阶段执行配置任务。final阶段系统初始化完成，运行自动化工具如puppet、salt，执行用户定义脚本。

       cloud-init使用模块指定任务，metadata决定结果。set_hostname模块根据metadata设置主机名。设置用户初始密码和安装软件是典型应用。

       cloud-init源码解读

       cloud-init核心代码使用抽象方法实现，遵循接口规范。主要目录包括定义类和函数、网络配置、模块初始化、系统发行版操作、配置文件管理、模块处理、数据源、事件报告等。

       模块通过handle函数解析cloud config配置，并执行逻辑。数据源类扩展实现接口。handler处理用户数据。reporting框架记录事件信息。

       cloud-init提供文件操作、日志管理、配置解析等辅助类。其他文件包括模板处理、日志格式定义、版本控制等。

       cloud-init通过模块、datasource和配置文件实现云主机元数据管理和定制化。源码结构清晰，功能全面，是云环境定制的强大工具。