1.Android源码定制（3）——Xposed源码编译详解
2.Pixel ArtAseprite像素软件源码编译使用（白嫖19.99刀）
3.源码编译——Xposed源码编译详解
4.detectron2安装及微软最新state of the art目标检测模型DynamicHead训练自己数据全程指南
5.ART模式和Dalvik模式
6.dexopt 与 dex2oat 区别

Android源码定制（3）——Xposed源码编译详解

       Android源码定制（3）——Xposed源码编译详解

       在前文中，我们完成了Android 6.0源码从下载到编译的过程，接下来详细讲解Xposed框架源码编译和定制。本文将基于编译后的Android 6.0环境，分为两部分：Xposed源码编译和源码定制，期间遇到的hadoop 源码编译问题主要得益于大佬的博客指导。首先，感谢世界美景大佬的定制教程和肉丝大佬的详细解答。

       1. Xposed源码编译

       为了顺利编译，我们需要理解Xposed各模块版本和对应Android版本的关系，实验环境设为Android 6.0。首先，从Xposed官网下载XposedBridge，并通过Android Studio编译，推荐方式。编译过程涉及理解模块作用、框架初始化机制，以及mmm或Android Studio编译步骤。

       2. XposedBridge编译与集成

       从官网下载XposedBridge后，编译生成XposedBridge.jar，可以选择mmm或Android Studio。编译后，将XposedBridge.jar和api.jar分别放入指定路径，替换相应的系统文件。

       3. XposedArt与Xposed源码下载和替换

       下载并替换Android系统虚拟机art文件夹和Xposed源码，确保Xposed首字母为小写以避免编译错误。

       4. XposedTools编译与配置

       下载XposedTools，配置build.conf，解决编译时缺失的依赖包，如Config::IniFiles。

       5. 生成编译结果与测试

       编译完成后，替换system目录，生成镜像文件并刷入手机，onekey ghost源码激活Xposed框架，测试模块以确保功能正常。

       6. 错误解决

       常见错误包括Android.mk文件错误、大小写问题以及XposedBridge和Installer版本不匹配，通过查找和分析源码来修复。

       实验总结

       在源码编译过程中，遇到的问题大多可通过源码分析和调整源码版本解决。务必注意版本兼容性，确保Xposed框架能顺利激活并正常使用。

       更多详细资料和文件将在github上分享：[github链接]

       参考

       本文由安全后厨团队原创，如需引用请注明出处，未经授权勿转。关注微信公众号：安全后厨，获取更多相关资讯。

Pixel ArtAseprite像素软件源码编译使用（白嫖.刀）

       Aseprite像素图像软件，功能强大，本文为你提供源码编译使用指南。

       遵循步骤，成功编译源码。若使用预编译库，则可省略编译步骤。

       无需关注、转发、点赞或评论，直接获取完整内容。

       主页浏览我的笔记，涵盖图形学实战经验，助力快速学习与成长，避免走弯路。

       专注图形学领域，从研学到面试，提供有价值的eclipse jar 源码信息，确保工作高效，不加班。

       PerfectPixel 计算机图形学 首页资料目录汇总 - 知乎 (zhihu.com)

       探索Unreal Engine、实时渲染、路径追踪、图形研究等丰富内容。

源码编译——Xposed源码编译详解

       本文深入解析了基于Android 6.0源码环境，实现Xposed框架的源码编译至定制化全过程，提供一套清晰、系统的操作指南。实验环境选取了Android 6.0系统，旨在探索并解决源码编译过程中遇到的难点，同时也借助于社区中其他大神的宝贵资源，让编译过程更加高效且精准。

       致谢部分，首先对定制Xposed框架的世界美景大佬致以诚挚的感谢，其提供框架的特征修改思路和代码实例给予了深度学习的基础，虽然个人能力有限，未能完整复现所有的细节，但通过对比和实践，逐步解决了遇到的问题。特别提及的是肉丝大佬的两篇文章，《来自高纬的对抗：魔改XPOSED过框架检测(上)》和《来自高纬的对抗：魔改XPOSED过框架检测(下)》，这两篇文章是本文深入定制Xposed框架的基础指引，通过它们的学习，许多技术细节和解决方案得以明确。

       关于Xposed框架编译和配置的技术细节，参考文章《xposed源码编译与集成》提供了清晰的理论框架，而在《学习篇-xposed框架及高版本替代方案》中，能够找到关于Xposed安装、功能验证以及遇到问题时的解决策略，这两篇文档对理解Xposed框架运行机制、logicaldoc源码搭建安装流程以及后续的调试工作大有裨益。

       在编译流程中，我们首先对Xposed框架中的各个核心组件进行详细的解析和功能定位，包括XposedInstaller、XposedBridge、Xposed、android_art、以及XposedTools。每一步都精心设计，确保实现模块与Android系统环境的无缝对接。接下来，我们进行具体的编译步骤。

       首先是XposedBridge源码的下载，直接从GitHub上获取最新且与Android 6.0版本相适配的代码，这里选择下载Xposed_art。其次，通过Android.mk文件，我们可以配置编译环境，明确哪些源文件需要编译、生成的目标文件类型以及依赖的其他库文件。在Android.mk文件中，要确保针对特定的XposedBridge版本进行参数的调整，避免不必要的错误。

       后续的编译过程可通过mmm或Android Studio完成。mmm编译更倾向于手动操作，适合熟悉CMakebuild系统的开发者，而Android Studio提供了一站式的IDE解决方案，操作流程更为便捷且直观。无论是采用哪种编译方式，最终的目标是生成XposedBridge.jar文件，这个文件将成为Xposed框架的核心组件，用于在Android系统上运行模块化的iperf .apk 源码功能。

detectron2安装及微软最新state of the art目标检测模型DynamicHead训练自己数据全程指南

       首先，您需要从github.com/microsoft/Dy...仓库下载代码。

       同时，下载并安装detectron2源码。

       在Win系统中安装Detectron2时，有一些要点和避坑指南需要注意。

       安装命令为：python setup.py build develop。

       执行该命令可能会报错，提示找不到vc++ .0。这时，您需要在VS中安装C++组件。

       接下来，需要安装依赖库，如torch、torchvision、pycocotools和fvcore等。

       安装过程中，在Win上运行安装命令可能会遇到错误：nvcc.exe failed with exit status 1。

       要解决此错误，需要修改detectron2\layers\csrc ms_rotated ms_rotated_cuda.cu代码前几行，将条件编译#ifdef WITH_CUDA和#ifdef WITH_HIP全部注释掉，只保留#include "box_iou_rotated/box_iou_rotated_utils.h"。

       修改完成后，再次运行python setup.py build develop，并等待一段时间，就可以顺利编译并安装了。

       DynamicHead训练代码原版不包含注册数据集的代码，需要修改train_net.py文件，将注册数据集的代码加入其中。修改后的完整代码如下所示。

       请确保您的训练数据集符合coco格式，如果不是，需要编写代码将其转换为coco格式。

       修改数据集路径的代码如下，其中coco文件夹是训练和验证集json文件所在路径，train_path和val_path是训练和验证集所在路径。

       在以下代码中，需要修改数据集的类别信息和注册的训练验证集名字。

       训练的脚本命令是：python train_net.py --config configs/dyhead_swint_atss_fpn_2x_ms.yaml --num-gpus 1。

       命令中出现的configs文件夹中的yaml文件也需要修改，将其中的datasets修改为您代码中注册的数据集名字，并在代码中重写或覆盖选项。

       运行上述训练脚本可能会遇到的问题及解决方案如下：

       遇到"broken pipe"错误，即多进程数据加载错误，将加载进程数修改为1即可解决。

       如果训练报错weights_decay是none，打印cfg查看哪些是none，发现weight_decay_bias是none，将weight_decay_bias设置为0而不是none即可成功训练。

       Github上提供的预训练权重是在coco数据集上训练的，类别数与您的数据集不同，不能作为weights初始化。

       最后，成功训练的图示。

ART模式和Dalvik模式

       ART模式ART模式英文全称为:Android runtime，谷歌Android 4.4系统新增的一种应用运行模式，与传统的Dalvik模式不同，ART模式可以实现更为流畅的安卓系统体验，对于大家来说，只要明白ART模式可让系统体验更加流畅，不过只有在安卓4.4以上系统中采用此功能。

Dalvik模式

       如果要解释清楚什么是ART模式，我们就需要从Android系统的应用编译模式说起，我们都知道Android系统是以Linux系统为底层构建的，Android系统是开源(源代码公开)的，Android系统势必会适配到不同硬件配置的设备上，因此谷歌为了降低应用的开发难度在Linux底层之上构筑了一个名为“Dalvik”的虚拟机。

       因为Dalvik虚拟机的存在，Android系统的开发者只需使用谷歌提供的SDK(软件开发工具包)即可较为轻松的按照一套“规则”创建APP，不用顾忌硬件、驱动等问题，在每次执行应用的时候Dalvik虚拟机都会将程序的语言由高级语言编译为机器语言，这样当前设备才能够运行这一应用。

art模式有什么好处

       在ART模式下，系统体验到底有什么不同。要开启ART模式操作比较简单，首先是开启Android系统的开发者选项，具体开启方式同Android 4.3的一样，同样是连续

       点击7次版本号即可。接着进入开发者模式，在“选择运行环境中”将运行模式由默认的Dalvik的修改为“使用ART”，切换成功以后系统会自动重启并且自动更新系统，更新

       系统是因为系统程序也需要重新编译。切换模式后最明显的变化就是安装程序的空间明显增加，这是因为程序将编译后的机器语言会一同保存在手机中。还有一个变化

       就是运存的占用率明显降低了，这是因为开机后的系统程序已经不再需要虚拟机进行重新编译。而且最让我们欣喜的是，在ART模式下系统的流畅度有非常大的提升，不

       管是滑动界面还是运行程序，整个系统的流畅度已经达到了如丝般顺滑的地步，与iOS系统不相上下，注意这里说的如丝顺滑毫不夸张。

ART模式和Dalvik模式的不同

性能:

       ART面世以后很多人已做了测试。结果大多是ART模式下程序的加载和切换速度有一定的提升，某些特定条件下可以快%左右。Youtube上的这个视频( youtu.be 的页面)中，两部同样运行着KitKat的Nexus 7同时加载Photoshop Touch，使用ART的速度明显快于Dalvik。至于空间要求，我对底层了解不多，但ART是Ahead-Of-Time compiler，所以基本可以肯定空间上要求更高。

兼容性:

       ART只出现在开发者选项中，目前仍然处于测试阶段，兼容性仍不尽如人意。很多应用，例如，Pandora，Kingdom Rush等都无法正常运行，所以只适合用来测试和尝鲜。随着用户使用数据的收集和Google的进一步完善，相信兼容性不是大问题。而且ART只是Android底层的runtime，至少作为用户不需要担心使用上的差别。至于开发者，肯定需要在适当的时候调整开发策略，充分利用ART的优势。

取代:

       趋势上看，ART取代Dalvik只是迟早的事情。Android诞生已经5年有余，Google为了提升Android的性能已经从上到下做出了所有的努力，唯独一直没有触及Dalvik runtime。所以想进一步优化Android平台，Dalvik是非改不可的。

怎么开art模式

       1、手机待机界面，点击应用程序图标。

       2、在手机应用程序界面，找到并点击设定齿轮图标。

       3、进入手机设定界面后，找到并点击关于手机

       4、在此界面，连续点击7次内部版本号。

       5、返回后，即可看到开发者选项，点击进入开发者选项。

       6、在开发者选项菜单的底部选择切换到ART模式，切换需要重启系统。

dexopt 与 dex2oat 区别

        答：这道题目如果想深入理解就需要去看源码了，不过对于应用层开发来说有个原理上的大致理解也是必须掌握的，具体区别可用如下图概述（）。

        通过上图可以很明显的看出 dexopt 与 dex2oat 的区别，前者针对 Dalvik 虚拟机，后者针对 Art 虚拟机。

        除此之外在上图还可以看到 Dalvik 虚拟机中有使用 JIT 编译器，也就是说其也能将程序运行的热点 java 字节码编译成本地 code 执行，所以其与 Art 虚拟机还是有区别的。Art 虚拟机的 dex2oat 是提前编译所有 dex 字节码，而 Dalvik 虚拟机只编译使用启发式检测中最频繁执行的热点字节码。

ART 深入浅出 - 为何 Thread.getStackTrace() 会崩溃？

       ART 深入浅出：Thread.getStackTrace() 崩溃原因剖析

       Thread.getStackTrace() 在卡顿检测中常被调用，但频繁调用可能导致崩溃，崩溃堆栈通常显示为：VMStack_getThreadStackTrace() -> ThreadList::SuspendThreadByPeer() 等。本文将逐步解析其崩溃机制。

       在 ART (Android Runtime) 的源码 Android 版本中，VMStack.cc 的 GetThreadStack 函数是关键，它涉及线程挂起和回调生成调用栈的过程。首先，通过 SuspendThreadByPeer() 函数挂起线程，然后回调生成调用栈，最后恢复线程。然而，这个过程可能因超时引发问题，例如当 SuspendThreadByPeer() 在线程状态检查中判断线程未挂起时，超时会触发 ThreadSuspendByPeerWarning()，严重时会导致 Runtime::Abort。

       通常，使用 ThreadList::SuspendThreadByThreadId() 函数可以避免这种 Crash，因为它在超时后只会产生警告，而不是终止。超时时间默认为 秒，如果线程长时间未能挂起，可能源于 ART 挂起线程的机制。在旧版 ART 中，挂起线程通过 ModifySuspendCount() 函数设置标志位，但在新版本中，这个逻辑已有所改变。

       深入探究，Java 的 Check Point 概念在其中起关键作用。解释执行的 switch/case 语句和机器码执行都有检查点，这些检查点会暂停线程执行，进行垃圾回收、调试等操作。当 Thread.getStackTrace() 触发挂起时，会进入 CheckSuspend() 函数，依据状态标志位决定挂起或执行检查点。真正的挂起操作会在析构函数中执行，通过 wait 函数挂起线程，直到其他线程执行到唤醒操作。

       总结来说，Thread.getStackTrace() 崩溃源于线程挂起操作与检查点执行的同步问题。当线程未能及时进入检查点，getStackTrace() 的等待时间过长，从而导致崩溃。理解了这个机制，就能避免此类问题的发生。