1.什么是跨终端
2.jsc反编译工具编写探索之路
3.关于Cocos2dx-js游戏的jsc文件解密
4.RStudio用户界面中文汉化翻译介绍与使用说明
5.Windows平台下QuickJS开发及相应C版DLL Module制作简介
6.jsc是什么意思
什么是跨终端
链接：/post/
鉴于很多人对跨端技术感觉很神秘，虽然我实际上还没有写过一个从0到1的跨端框架，但是我曾经用Yoga(布局引擎Yoga(React-Native)做过一些简单的跨端的事情，后来用了Weex。研究跨端有一段时间了，想科普一下。ccodingconv 源码
科普之前，首先你要知道，为什么需要跨端技术？我们通常会把Weex和React-Native(本文统称为RN)说成是跨端技术吗(Flutter没有单独提到)？
其实不是，好像Android/iOS本来是两个人的，但最终变成了一个人。我的人力减少了一半！
但前提是这个人力需要懂Android，iOS，JavaScript，更懂，不然出了问题，怎么修？
所以在中国的互联网环境下，很难招到这样的人。大家都在研究PPT架构技术，职场生存理论，岁如何解脱财富。我们如何有时间扩展我们的技术堆栈？
端上开发很惨，总有崩溃(使用崩溃，闪退)而且没有办法远程修复。只能等下一个版本给使用市场推一个修复bug的新版本。
但如果推送新版本，用户可能不会升级。因此，许多公司研究了各种热修复框架，尤其是在Android平台上。有很多热修复框架，主要是由DexClassLoader来完成。
但是，最早的时候，WebView有一个很大的问题，尤其是Android。而且加载网页肯定要花时间，过程中屏幕会一片空白等等。所以很多人围绕这些做了很多优化。我个人觉得最有用的其实是线下套餐。同时，每一代WebView也在更新升级。然后一些有实力的公司开发了自己的所谓浏览器内核，各种黑科技，如何提速，支持各种特性等等。但是好像没有开源：dog:
不算。这只是跨安卓和iOS，不把我的PC当目的？
其实浏览器是跨端的，每个平台都可以用Chrome(其他浏览器主要是想做不做)！但是它也有自己的问题，因为各家都有自己的浏览器，内核不同，gpt-2 源码划分越来越大。chrome(Blink)/Safari(WebKit)/Firefox(Gecko？)等等，尤其是对css的支持。
Developer.mozilla.org/zh-CN/docs/.这个网站可以检查一些浏览器的兼容性。例如，边框宽度的兼容性如下：
其实也不是不可以，但是这样做相当于直接为OpenGL或者其他图形引擎编程，而且要自下而上的搭建一套渲染机制，打包各种基础UI组件给开发者使用，或者留下很多漏洞让开发者自定义自己的UI，非常复杂。但其实Flutter就是这么做的，所以Flutter2.0又开始向桌面端发展了，而且不局限于Android/iOS，但不知道能走多远。还有的是搞React-Native-Skia的，所以用js代码直接调Skia(2D图形渲染引擎)？(具体没看过)
你写的JavaScript代码为什么能运行？这取决于JavaScript引擎。
扔给它一段js代码(实际上是一个文本字符串)，它就能帮你计算结果，处理逻辑。
常见的Weex、RN、Hippy也依赖于此(MLN使用Lua)进行逻辑处理。
这个时候会有很多概念。
有些人喜欢把JavaScript引擎称为JavaScriptCore(不知道为什么，可能是因为iOS开发者才是研究这些比较深入的人，因为苹果的JavaScript引擎叫JavaScriptCore。苹果的这个JavaScriptCore呢？很多人喜欢称之为JSCore或者JSC)。所以，后来看到这些名词，我总是把它们带入语境中去感受他想说的是JavaScript引擎还是苹果的JavaScript引擎 JavaScript Core (JSCore/JSC)。
先说JavaScript引擎。
是的，有这么多！当然还有JavaScriptCore(不在图中)。
最后一行是跑分，越多越好。有JIT的V8在3w挂所有东西。其中QuikJS极小，得分很高。估计很多人会用QuikJS做跨端JavaScript引擎吧？赫尔墨斯是由脸书创造的。看来Android目前在RN中使用的JavaScript引擎已经取代了之前使用的JavaScriptCore。RN为什么一直不用V8？这个我也不知道.
但是很多人都在搞Android的V8项目，Github上也有一些开源项目。其次，iOS不支持JIT，有自己的JavaScriptCore，没有JIT改V8似乎意义不大。
一个正常的跨端框架最简单的情况如下(后面会讨论问题，逐步丰富):
用一个
简单的例子看
假设我的 js 文件中就是要 展示一个红色的 div 方块 。那么首先，端会把这个文本传给 JavaScript Runtime，它解析完后形成一个约定的插件源码修改命令格式，比如如下的 JSON 格式(里面的值用来描述是一个*红色方块，我随便定义的)
{ "name":"div", "width":"", "height":"", "background":"red"}
通过 JavaScript Runtime 和 端(Android/iOS) 通信，把这个消息传回去。
端拿到了消息，发现要创建一个 * 的叫做 div 的东西，没有 div 啊！这就需要端上提前埋好代码，比如 Android 里有 FrameLayout，那么就有类似的注册代码
// 伪代码register("div", FrameLayout.class);
然后端就知道了，oh！我需要创建一个长宽的正方形。
首先，这是框架设计提前思考好的，究竟要支持哪些基础组件，比如 image 、text 等等。而且一般这里都会开个口子，让开发者可以自己扩展组件，比如你需要一个横滑列表，没提供怎么办？看看 div 怎么注册的，按照它的过程注册一个列表就好了。这也可以 PPT 吹成： 扩展跨端框架 ，其实 门槛比自定义 View 还要低 。
前面说了 JavaScript Engine，这里咋又来了个 Runtime？
JavaScript Engine 能做什么？
什么都做不了，只能解析执行 js 代码
那么问题来了，我怎么去 描述 我写的 js 代码代表的 视图 呢？其实不用描述，js 代码只要在 内存中 维护好一个树形结构就好了，就是一个 Object，因为实体在具体的端上，怎么理解呢？
左边只要在内存中维护好这样一个树形结构就好了，传递给客户端时，转为
{ "name":"div", "children":[ { "name":"image" }, { "name":"div", "children":[] } // 等等 ]}
端上拿到消息，创建视图为右图中的结构即可。
如何维护好这个模型呢？调用什么 js 的方法发送消息呢？怎么给这些个 div 加上 css 来描述它的大小形状呢？等等更复杂的一系列的前端问题，都需要 写代码 来实现。
所以一般都会有个 core.js 或者 framework.js 类似的一堆 js 代码，就是用来处理这些事情，而这些代码同样依靠 JavaScript Engine 来执行。
从而所谓的 JavaScript Runtime ，我觉得可以单纯的理解为 JavaScript Engine 自身的代码跑起来后的环境，也可以理解为 core.js 等被跨端框架所需要的、包含了各种逻辑的前端代码被加载运行后的环境。
当你用这些跨端框架的时候，你会发现他们只支持 css 子集 ，而且布局方式基本都是 flexbox(一种布局模型) 。
那么比如你写了一个横着容纳了三个小方块的大方块，你的前端 css 代码肯定要写成， flex-diretion:row ，那么抛给端上的消息可能如下：
{ "name":"div", "attribute":{ // 使用布局 "flex-diretion":"row" }, "children":[ { "name":"div" }, { "name":"div" }, { "name":"div" } ]}
端上拿到这个消息，都不知道 flex-direction 是什么。当然，你可以自己写一个解析库来解，常州商城源码价格但是 Yoga 帮你做了这件事！
所以 RN 使用的是 Yoga 布局引擎(支持 flexbox，也是 Facebook 搞的)。
Weex 似乎一开始是用的 Yoga，后来自己写了一套？
这个地方就出现了一个名词 Layout Engine ，它就是帮我们处理各种布局参数的，然后帮我们算好每个视图的坐标，然后端上拿到坐标后设置对应的视图的坐标，一个井井有条的视图便展示了出来。如果你觉得你写的布局解析算法超越了 Yoga 等等，那么你完全可以自己写一套。
比如从 JavaScript Runtime 处理完各种属性了，要渲染视图了！传了一段 JSON 给端。
端上手指点了一下这个视图，那也要封装成一个消息传递给 JavaScript Runtime，然后触发你之前写的 js 的监听代码，比如点击后弹一个弹窗，那就又要封装一个调用弹窗方法的消息给端。
就是这样来来回回。
所以两边都有自己的消息队列。
而且当你做动画还想监听动画过程的时候，肯定在短时间内发送了大量消息，这些过程肯定是 需要优化 的。
并且！据我个人用 Weex 的经验，有的 flexbox 属性两端都不统一(可能是 Weex 的 Bug，毕竟 KPI 项目，都不维护了)
我记得当时还开玩笑说，用了 Weex 终于领悟了跨端的真谛：
if(platform === 'Andoird') { // 差异化逻辑} else if(platform === 'iOS') { // 差异化逻辑}
跨端的代价就是，你 本以为 真的可以一套代码两端跑，后来发现真的有点做梦了(连 H5 有时候 Andoird/iOS 都不一致，因为用的内核都不是一个)，代码里有不少的 if-else。
所以经过上面的一系列科普，一个跨端框架成了这样：
这其中一般是需要一个客户端、一个前端、一个懂 JavaScript Engine 会 C/C 的来分别开发。
我虽然没开发过，但是感觉会有很多问题。
比如 JavaScript Runtime 在另一个进程的话，跨进程通信？
比如消息通信过于频繁是不是就会有各种连锁反应，掉帧啊、事件响应不及时、动画不流畅啊，怎么优化？
其实我本身一直自诩喜欢研究原理，但是直至今日我也没真的一行行看过跨端框架的源码，我知道的这些也未必是对的，只是之前做过 Weex 的一些工作稍微研究了一下，还是挺惭愧的。
既然你自称喜欢研究原理，为什么不看呢？
链接：/post/
相关问答：相关问答：手机端和电脑端各是什么？
电脑端和手机端，实际上说的源码正常的价格就是平台问题。
当我们使用电脑的时候，电脑基本使用的操作平台是windows，或者苹果等常用操作系统。
而手机上用的平台，如安卓，苹果的IOS，当年诺基亚的塞班，黑莓的系统，都叫做手机端。
那么怎么定义手机端和电脑端呢，我们可以这么理解，如果用电脑操作系统的设备，即便是平板电脑，你也可以理解成是电脑端。
如微软平板电脑surface，他的定位是平板也是电脑，
我们很多的平板，多数使用的是安卓系统，苹果的当然就是IOS，但是平板使用基本使用的移动平台，也就可以看成是手机端。
但是，如果这个移动设备的平台使用的是电脑的操作系统的时候，他所使用的平台，也就成了电脑端。
jsc反编译工具编写探索之路
研究逆向分析时，若遇到使用Cocos2dx编写的JavaScript游戏，理解其打包流程与开发工具是关键。Cocos2dx支持多种语言进行游戏开发，其中JavaScript与C++的结合尤其常见。在新版本中，编写的JavaScript代码经过编译生成jsc文件，这种二进制优化提升了游戏性能，同时也增加了逆向分析的难度。本篇内容将探索如何编写一款针对jsc文件的二进制反编译器。
首先，理解Cocos2dx+JavaScript的创建与打包流程是基础。通过下载Cocos2dx，配置环境，执行相关命令，可以创建并编译一个JavaScript游戏工程。此过程生成的jsc文件是经过编译与优化的，用于提升游戏性能。
在进行逆向分析时，首先要分析正向过程。以Cocos2dx+JavaScript的游戏为例，通过下载并运行测试工程，观察生成的MyJSGame-desktop.app游戏程序，发现默认生成的js文件未加密，但需要通过jscompile命令将js编译为jsc格式。
网络上搜索jsc反编译工具时，发现可能存在工具限制或兼容性问题。在尝试使用dead仓库中的工具进行反编译时，遇到了失败的情况。这提示我们，寻找现成工具并非万能，可能需要深入理解底层技术。
SpiderMonkey作为一款由Mozilla公司开发的JavaScript执行引擎，提供了方便的API接口，用于执行和编译JavaScript脚本文件。通过研究dead.c文件中的相关代码，可以初步了解jsc反编译的工作流程。核心在于JS_DecompileScript()函数，它负责完成反编译工作。然而，Cocos2dx在编译jsc时并未包含源代码数据，导致反编译工具无法获取有效的源代码信息。
深入分析Cocos2dx中关于jscompile的调用插件，发现其底层调用的是bin/jsbcc程序来编译js脚本。通过GitHub上的记录可以找到其实现代码，关键在于JS::Compile()函数，它负责生成script对象，并调用JS_EncodeScript()编码生成jsc文件。在编译选项中，设置了不包含源代码的选项，因此生成的jsc文件在反编译时会返回"[no source]"。
尽管如此，通过调用JS_DecodeScript()解码指令与js_Disassemble()进行反汇编，可以实现部分反汇编功能。然而，要实现完整的反编译功能，需要深入理解jsc文件的结构与编码方式。这涉及到高级的逆向工程知识与技术，是未来探讨的方向。
探索之路并未结束，尽管完成了一些初步的反汇编功能，但真正的反编译挑战在于理解和解析机器码到可读的源代码。这需要深入研究JavaScript编译器与解释器的底层实现，以及Cocos2dx在编译过程中对JavaScript代码的特定处理。未来，期待能与更多开发者一起探讨这一高级话题，共同推进游戏安全逆向分析领域的发展。
关于Cocos2dx-js游戏的jsc文件解密
上期关于Cocos2dx-js游戏的jsc文件解密教程引发了一些疑问，本文将解答一些常见问题。
首先，我们通过CocosCreator开发工具构建并编译一个案例js工程，发现游戏中存在脚本加密选项。构建后，得到一个简单的样本APK。在APK中，我们通过Jadx-gui工具解析Java层源码，关注assets目录下二进制源代码的加载情况。在入口Cocos2dxActivity的onLoadNativeLibraries函数中，我们找到了加载libcocos2djs.so文件的步骤，该文件位于AndroidManifest.xml中。
初步分析显示，加载Assets目录资源的操作不在Java层进行。接着，我们参考“jsc反编译工具编写探索之路”一文，将注意力转移到libcocos2djs.so文件上。在Cocos2dx源码中，我们发现其使用的是xxtea加密和解密算法，与Cocos2dx-lua的加密解密过程类似。
在游戏实例分析部分，我们以两个游戏案例为例进行解密。对于游戏A，通过十六进制编辑器搜索libcocos2djs.so文件中的Cocos Game字符串，未发现相关信息。使用IDA分析工具对libcocos2djs.so进行深入研究，发现导出函数名清晰，没有添加额外的安全手段。通过搜索xxtea / key相关函数，我们找到了几个相关函数。在jsb_set_xxtea_key函数中，我们尝试直接设置key值，并发现一个可疑的参数v，用于解密jsc文件。通过回溯该函数的调用路径，我们成功获取了Key值，并成功解密游戏文件。
对于游戏B，虽然Key值不像游戏A那样明文显示，但通过搜索附近的字符串，我们发现可疑的Key值与常规的Cocos Game字符串共存。尝试使用此Key值解密游戏文件，同样取得了成功。对比游戏A和游戏B的关键代码，我们发现密匙都在applicationDidFinishLaunching函数内部体现。此函数在Cocos2d-x应用入口中，当应用环境加载完成时回调。理解CocosCreator构建项目的过程后，我们知道游戏应用环境加载完毕后，该函数内部将Key值传入解密函数中，解密函数将jsc文件转换为js文件，并拷贝到内存中，游戏开始调用js文件，进入游戏界面。
在其他关键函数的分析中，我们注意到在xxtea_decrypt函数中存在memcpy和memset操作，表明在进行内存拷贝数据。通过CocosCreator源代码jsb_global.cpp文件，我们得知传入xxtea_decrypt函数的第三个参数即为解密的Key值。因此，我们可以通过Hook libcocos2djs.so文件加载时的xxtea_decrypt函数来获取Key值。使用Frida框架编写简单的js脚本进行Hook操作，可以成功获取Key值。在获取Key值后，可以参照CocosCreator源代码实现解密逻辑，或者利用封装好的解密程序进行文件解密。
最后，对于解密工具的选择，我们推荐使用一些已封装的加解密程序，例如jsc解密v1.，它能够满足当前Cocos2dx版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。
RStudio用户界面中文汉化翻译介绍与使用说明
RStudio用户界面中文汉化翻译介绍与使用说明
为了解决R语言新手在使用RStudio时的语言障碍，作者对RStudio的用户界面进行了中文汉化，特别是针对主要使用中文的用户群体，简化了学习和使用过程，使得界面更为直观易懂。翻译部分与未翻译部分
部分RStudio用户界面已经成功翻译，主要包括关键部分，但全局选项(Global option)下的大部分内容还未完成翻译。适用于RStudio的特定版本。使用步骤
由于RStudio基于Electron技术，用户界面信息存储在安装目录下的JavaScript文件中。在Windows系统中，你需要替换以下路径的两个文件:C:\Program Files\RStudio\resources\app.webpack\main\index.js
C:\Program Files\RStudio\resources\app\www\rstudio\7EA4A6E4EF0C7CA8CA.cache.js
替换前请备份原文件，以防出现问题。 然而，非正式汉化可能导致RStudio无法正常运行，仅供学习和测试使用，不建议在生产环境或商业用途中使用。参与与贡献
欢迎参与翻译工作，一起完善这份中文汉化，贡献你的专业知识。翻译源代码可在github.com/s/rstudi...找到。已知问题与解决办法
部分窗口可能无法正常打开，遇到此问题，请移除翻译文件并恢复原始文件以恢复正常使用。对于特定版本的"7EA4A6E4EF0C7CA8CA.cache.js"文件可能引发启动异常，可考虑使用旧版版本进行替换。未来展望
目前没有进一步的翻译计划，期待RStudio官方未来能实现原厂级的中文版。更新说明
部分情况下，新版本翻译可能导致启动异常，建议使用旧版"7EA4A6E4EF0C7CA8CA.cachechs-菜单基本翻译完成"文件作为替代，具体问题正在调查中。Windows平台下QuickJS开发及相应C版DLL Module制作简介
QuickJS是一个小型且可嵌入的JavaScript引擎，由Fabrice Bellard和Charlie Gordon共同创建。它支持ES规范，包含模块、异步生成器、代理和BigInt等功能。可选数学扩展如大十进制浮点数、大二进制浮点数和运算符重载。最新版为quickjs---。在Linux平台下安装很容易，但在Windows平台上安装却较为困难。
在Windows平台上制作qjs和qjsc可执行文件，可通过使用mingw在Win 和Win XP系统上安装成功。GitHub上有基于Visual Studio和MSYS2的实现，但都只实现了qjs.exe，无法实现qjsc.exe的功能，因此无法编译js源码或利用quickjs的高级功能。借助gcc，可以将qjsc生成的C代码制作成可执行文件，完美模拟了Linux平台下的基础功能。
在Windows平台下，可利用mingw实现制作C语言的dll版的Modules。虽然原始源代码在Windows下并未实现，但通过自己实现，可在examples目录下的fib.c文件中找到demo。使用gcc在Windows平台下制作fib.dll动态链接库，然后QuickJS将其当作模块进行调用。生成的dll文件与Linux平台下的fib.so文件功能相同，但输出内容稍有不同，方便查看。
在Windows平台上使用qjsc反编译调用dll的js脚本，第一种写法能够完美通过，但第二种写法报错，因为dll不是quickjs的系统关键字。生成的test_fib.c文件形式与之前相同，使用gcc可以运行可执行文件，输出效果与js版相同，计算时间也一致。
对于性能测评，利用examples目录下的fibonacci计算函数，测试了各个版本（含nodejs）的fib()的计算时间。Dll版qjs计算性能比nodejs提升了.5%，而普通js版的qjs则较为缓慢。QuickJS的计算性能大致处于脚本语言中等水平，比Python强，但比Lua慢。
对于Windows平台下的QuickJS开发及相应C版DLL Module制作，借助mingw与Linux平台的实现基本相同。然而，使用Visual Studio可能无法实现，因为代码量修改太大。在Windows平台下，通过制作dll模块可提升QuickJS的性能。如果需要此功能，欢迎联系提供包含Windows平台下制作qjs.exe和qjsc.exe的quickjs源码和可执行文件的资源，以及提供mingw和cmake，以及简单的使用说明。通过这些资源，可以学习gcc的使用方法、cmake制作大型软件的方法、QuickJS和C的互操作方法、动态链接库模块的使用、对C语言的深刻理解以及对JS语言的深刻理解。
jsc是什么意思
JSC的意思是JavaScript Compiler，即JavaScript编译器。 关于JSC的详细解释如下： 一、JSC的基本含义 JSC是JavaScript Compiler的缩写，它主要的功能是将JavaScript源代码编译成机器码，从而提高了代码的运行效率。这是一种将高级语言转化为机器可执行的指令的过程。 二、JavaScript编译器的工作机制 JavaScript编译器（JSC）是前端开发中的重要工具。它负责将JavaScript代码转化为机器能够理解并执行的语言。这个转化过程包括词法分析、语法分析、优化和生成机器码等步骤。编译器可以将源代码编译成字节码，然后在运行时由JavaScript引擎解释执行，这样可以提高代码的运行速度。 三、JSC在开发中的应用 在Web开发中，JSC扮演着重要的角色。随着Web应用的复杂性不断提高，对代码的性能要求也越来越高。使用JSC可以提高JavaScript代码的运行效率，使得复杂的Web应用能够更加流畅地运行。此外，编译器还可以进行代码优化，帮助开发者提高代码的质量。 四、JavaScript编译器的未来发展 随着前端技术的不断发展，JavaScript编译器也在不断进步。未来，JavaScript编译器可能会支持更多的优化技术，提高代码的运行效率和质量。同时，随着新的编程语言和技术的出现，JavaScript编译器可能需要与其他技术融合，以适应不断变化的技术环境。 总的来说，JSC是JavaScript编译器的重要缩写，它在Web开发中扮演着重要的角色，提高了JavaScript代码的运行效率和质量。随着技术的不断发展，JavaScript编译器也在不断进步，为前端开发带来更多的可能性。