1.当creator遇上protobufjs|相遇
2.JBoss Web和 Tomcat的区别
3.websphere和tomcat在使用中的区别
4.jsbsim学习飞行器模型配置文件解读
5.关于Cocos2dx-js游戏的jsc文件解密

当creator遇上protobufjs|相遇

       在探索cocos H5开发的最佳实践时，我已离不开nodejs、npm和各种脚手架工具。首先，从初始化package.json文件开始，通过npm init命令创建一个文件，商品推广系统源码用于管理项目中的nodejs第三方模块。

       在cocos creator项目中，protobufjs的使用至关重要。安装步骤如下：通过npm install protobufjs@5 --save命令引入protobufjs 5.x版本，若需要全局使用，可以使用npm install -g protobufjs@5。这个版本虽然不支持最新的6.x，但其动态编译功能在cocos creator中更为便利。

       在creator项目中，我们以Player.proto文件为例，展示了如何动态编译文件，生成js对象。utgard连接opc源码在静态语言中，我们会使用protoc命令将proto文件编译为c++/java代码，但在javascript中，protobufjs直接提供了动态编译的功能。

       然而，当尝试在cocos-jsb环境中运行protobufjs时，可能会遇到问题。这涉及到javascript在浏览器、nodejs和cocos-jsb上的不同文件接口。在cocos-jsb，我们需要处理的是jsb.fileUtils.getStringFromFile接口，这与浏览器和nodejs的文件操作有所不同。

       为了解决这个问题，可能需要修改protobufjs源码以适应cocos-jsb。此外，还需注意creator项目中资源路径的管理，通常需要将proto文件放在assets/resources/pb/目录下，销售综合商城源码并使用cc.url.raw获取正确的资源路径。

       尽管通过修改源码可以解决问题，但并不是长久之计。为寻求更稳定的方法，我已创建了一个creator和protobufjs的示例项目，未做任何源码改动，链接如下：[github.com/ShawnZhang...](github.com/ShawnZhang...)。继续关注我的系列文章《探索cocosH5正确的开发姿势》，以了解更多无需修改源码的解决方案和proto文件预编译的用法。

JBoss Web和 Tomcat的区别

       JBoss Web和 Tomcat的区别

       åœ¨Web2.0的浪潮中，各种页面技术和框架不断涌现，为服务器端的基础架构提出了更高的稳定性和可扩展性的要求。近年来，作为开源中间件的全 球领导者，JBoss在J2EE应用服务器领域已成为发展最为迅速的应用服务器。在市场占有率和服务满意度上取得了巨大的成功，丝毫不逊色于其它的非开源 竞争对手，如WebSphere、WebLogic、Application Server。JBoss Web的诸多优越性能，正是其广为流行的原因。

       åŸºäºŽTomcat内核，青胜于蓝

       Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可。其运行时占用的系统资源小，扩展性好，且支持负载平衡与邮件服务等开发应用系统常用的功能。作为一个小型的轻 量级应用服务器，Tomcat在中小型系统和并发访问用户不是很多的场合下被普遍使用，成为目前比较流行的Web 应用服务器。

       è€ŒJBoss Web采用业界最优的开源Java Web引擎， 将Java社区中下载量最大，用户数最多，标准支持最完备的Tomcat内核作为其Servlet容器引擎，并加以审核和调优。单纯的Tomcat性能有 限，在很多地方表现有欠缺，如活动连接支持、静态内容、大文件和HTTPS等。除了性能问题，Tomcat的另一大缺点是它是一个受限的集成平台，仅能运 行Java应用程序。企业在使用时Tomcat，往往还需同时部署Apache Web Server以与之整合。此配置较为繁琐，且不能保证性能的优越性。

       JBoss在Tomcat的基础上，对其进行本地化，将Tomcat 以内嵌的方式集成到 JBoss 中。JBoss Web通过使用APR和Tomcat本地技术的混合模型来解决Tomcat的诸多不足。混合技术模型从最新的操作系统技术里提供了最好的线程和事件处理。 结果，JBoss Web达到了可扩展性，性能参数匹配甚至超越了本地Apache HTTP服务器或者IIS。譬如JBoss Web能够提供数据库连接池服务，不仅支持 JSP 等 Java 技术，同时还支持其他 Web 技术的集成，譬如 PHP、.NET 两大阵营。

       æ ‡å‡†åŒ–是减小技术依赖风险，保护投资最好的方式。JBoss Web率先支持全系列JEE Web标准，从根本上保证了应用“一次开发，到处运行”的特点，使应用成品能方便地在JBoss Web和其他Java Web服务器之间轻易迁移。

websphere和tomcat在使用中的区别

       1、对技术的支持：

       Tomcat不支持EJB，JBoss是实现了EJB容器，再集成了Tomcat。

       WebSphere都是对业内多种标准的全面支持，包括EJB、JSB、JMS、JDBC、XML和WML，使Web应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。

       2、应用范围的区别：

       Tomcat æ˜¯ä¸€ä¸ªå°åž‹çš„轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP ç¨‹åºçš„首选。

       WebSphere是商业软件,功能齐全强大,主要应用于大型企业的大型项目。

       3、商业服务和技术支持的区别：

       Tomcat都是开源免费的，所有它俩也就没有任何商业服务和技术支持，而WebSphere的技术文档和相关服务还是很到位，如果你的服务器哪一天出问题了，只要你能出的起钱，他们的技术工程师立刻就能出现在你面前。

       4、安全性问题：

       Tomcat都是开源的，所以它们的安全性相对来说比较低，万一应用服务器本身有什么漏洞，你是没办法向Apache索赔的。

       WebSphere其容错、系统管理和安全性能已经在全球数以千记的关键任务环境中得以验证。

jsbsim学习飞行器模型配置文件解读

       jsbsim是用于飞行力学仿真的一款开源软件，旨在实现类似IL2/1战争雷霆的空战游戏。在Unity中通过C#封装一个简化版的气动仿真模型，使模型在接收飞行器当前状态后，能输出6个自由度上的力/力矩，以接入Unity的刚体组件。

       以jsbsim自带的f-模型配置文件f.xml为例，解析其中内容。dubbo 远程调用源码

       从xml根节点入手，metrics、mass_balance、aerodynamics等部分尤为关键。地面互动、推力、自动控制等稍后关注，因为jsbsim最初专注于自动控制策略仿真，因此flight_control模块较为详细。

       配置文件中的缩写繁多，不易理解，但只要直接导入Unity的刚体组件即可。metrics节点描述了飞行器尺寸、位置指标，明确了飞行器坐标系中的VRP概念，即确定飞行器“鼻尖”与坐标原点之间的偏移。

       mass_balance节点包含飞行器质量分布参数，app微信源码涉及惯性张量等理论力学知识点。对于三维情况下刚体角动量与瞬时角速度方向的差异，理解惯性张量有助于预测飞行器在力矩作用下的旋转行为。

       aerodynamics节点包含大量表格数据，jsbsim通过查表实现非线性公式/函数计算，采用线性插值处理。节点下包含轴对应飞行器沿x、y、z轴平动、绕轴转动的六个刚体运动自由度。

       重点分析了DRAG轴、SIDE轴、LIFT轴、PITCH轴、YAW轴，这些变量描述了飞行器在不同轴向的气动特性。若无法理解某个变量，可在Google搜索或探索jsbsim源代码中找到相关描述。

       完成f.xml配置文件解析后，下一步将编写程序加载配置文件并执行动力学运算。若遇到未在Google搜索到的变量，尝试在jsbsim源代码中进行全局搜索，可获得更多线索。

关于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版本的文件加解密需求，并提供较为简单的操作方法。同时，欢迎各位分享自己的解密方法和见解，共同推动社区的发展。