Android中的动态加载机制

STC51单片机串口多字节数据接收的优化策略 本文深入探讨了STC51单片机串口多字节数据接收的优化策略。针对数据丢包、粘包等常见痛点,核心思路是采用“缓冲队列+定时器超时”模式,将实时处理转变为“先收纳,后处理”。文章详细讲解了硬件初始化、中断服务程序优化(快速入队与激活超时裁判)以及主循环的非阻塞设计,并进阶介绍了环形缓冲区实现与错误处理,旨在构建稳定可靠的串口通信系统。 阅读详情
  在目前的软硬件环境下,Native App与Web App在用户体验上有着明显的优势,但在实际项目中有些会因为业务的频繁变更而频繁的升级客户端,造成较差的用户体验,而这也恰恰是Web App的优势。本文对网上Android动态加载jar的资料进行梳理和实践在这里与大家一起分享,试图改善频繁升级这一弊病。
Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求。但是有些特殊问题,常常引发我们进一步的沉思。我们从沉思中产生顿悟,从而产生新的技术形式。
如何开发一个可以自定义控件的Android应用?就像eclipse一样,可以动态加载插件;如何让Android应用执行服务器上的不可预知的代码?如何对Android应用加密,而只在执行时自解密,从而防止被破解?……
熟悉Java技术的朋友,可能意识到,我们需要使用类加载器灵活的加载执行的类。这在Java里已经算是一项比较成熟的技术了,但是在Android中,我们大多数人都还非常陌生。
类加载机制
       Dalvik虚拟机如同其他Java虚拟机一样,在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中,类加载可以从class文件中读取,也可以是其他形式的二进制流,因此,我们常常利用这一点,在程序运行时手动加载Class,从而达到代码动态加载执行的目的
       然而Dalvik虚拟机毕竟不算是标准的Java虚拟机,因此在类加载机制上,它们有相同的地方,也有不同之处。我们必须区别对待

       例如,在使用标准Java虚拟机时,我们经常自定义继承自ClassLoader的类加载器。然后通过defineClass方法来从一个二进制流中加载Class。然而,这在Android里是行不通的,大家就没必要走弯路了。参看源码我们知道,Android中ClassLoader的defineClass方法具体是调用VMClassLoader的defineClass本地静态方法。而这个本地方法除了抛出一个“UnsupportedOperationException”之外,什么都没做,甚至连返回值都为空

    static void Dalvik_java_lang_VMClassLoader_defineClass(const u4* args,JValue* pResult){  
        Object* loader = (Object*) args[0];  
        StringObject* nameObj = (StringObject*) args[1];  
        const u1* data = (const u1*) args[2];  
        int offset = args[3];  
        int len = args[4];  
        Object* pd = (Object*) args[5];  
        char* name = NULL;  
        name = dvmCreateCstrFromString(nameObj);  
        LOGE("ERROR: defineClass(%p, %s, %p, %d, %d, %p)\n",loader, name, data, offset, len, pd);  
        dvmThrowException("Ljava/lang/UnsupportedOperationException;","can't load this type of class file");  
        free(name);  
        RETURN_VOID();  
    }  


Dalvik虚拟机类加载机制       那如果在Dalvik虚拟机里,ClassLoader不好使,我们如何实现动态加载类呢?Android为我们从ClassLoader派生出了两个类:DexClassLoader和PathClassLoader。其中需要特别说明的是PathClassLoader中一段被注释掉的代码:

    /* --this doesn't work in current version of Dalvik-- 
        if (data != null) { 
            System.out.println("--- Found class " + name 
                + " in zip[" + i + "] '" + mZips[i].getName() + "'"); 
            int dotIndex = name.lastIndexOf('.'); 
            if (dotIndex != -1) { 
                String packageName = name.substring(0, dotIndex); 
                synchronized (this) { 
                    Package packageObj = getPackage(packageName); 
                    if (packageObj == null) { 
                        definePackage(packageName, null, null, 
                                null, null, null, null, null); 
                    } 
                } 
            } 
            return defineClass(name, data, 0, data.length); 
        } 
    */  


这从另一方面佐证了defineClass函数在Dalvik虚拟机里确实是被阉割了。而在这两个继承自ClassLoader的类加载器,本质上是重载了ClassLoader的findClass方法。在执行loadClass时,我们可以参看ClassLoader部分源码:

    protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {  
    Class<?> clazz = findLoadedClass(className);  
        if (clazz == null) {  
            try {  
                clazz = parent.loadClass(className, false);  
            } catch (ClassNotFoundException e) {  
                // Don't want to see this.  
            }  
            if (clazz == null) {  
                clazz = findClass(className);  
            }  
        }  
        return clazz;  
    }  

因此DexClassLoader和PathClassLoader都属于符合双亲委派模型的类加载器(因为它们没有重载loadClass方法)。也就是说,它们在加载一个类之前,回去检查自己以及自己以上的类加载器是否已经加载了这个类。如果已经加载过了,就会直接将之返回,而不会重复加载。
DexClassLoader和PathClassLoader其实都是通过DexFile这个类来实现类加载的。这里需要顺便提一下的是,Dalvik虚拟机识别的是dex文件,而不是class文件。因此,我们供类加载的文件也只能是dex文件,或者包含有dex文件的.apk或.jar文件。

也许有人想到,既然DexFile可以直接加载类,那么我们为什么还要使用ClassLoader的子类呢?DexFile在加载类时,具体是调用成员方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要将包含包名的类名中的”.”转换为”/”我们看一下loadClass代码就清楚了:

    public Class loadClass(String name, ClassLoader loader) {  
            String slashName = name.replace('.', '/');  
            return loadClassBinaryName(slashName, loader);  
    }  

       在这段代码前有一段注释,截取关键一部分就是说:If you are not calling this from a class loader, this is most likely not going to do what you want. Use {@link Class#forName(String)} instead. 这就是我们需要使用ClassLoader子类的原因。至于它是如何验证是否是在ClassLoader中调用此方法的,我没有研究,大家如果有兴趣可以继续深入下去。
       有一个细节,可能大家不容易注意到。PathClassLoader是通过构造函数new DexFile(path)来产生DexFile对象的;而DexClassLoader则是通过其静态方法loadDex(path, outpath, 0)得到DexFile对象。 这两者的区别在于DexClassLoader需要提供一个可写的outpath路径,用来释放.apk包或者.jar包中的dex文件。换个说法来说,就是PathClassLoader不能主动从zip包中释放出dex,因此只支持直接操作dex格式文件,或者已经安装的apk(因为已经安装的apk在cache中存在缓存的dex文件)。而DexClassLoader可以支持.apk、.jar和.dex文件,并且会在指定的outpath路径释放出dex文件。

       另外,PathClassLoader在加载类时调用的是DexFile的loadClassBinaryName,而DexClassLoader调用的是loadClass。因此,在使用PathClassLoader时类全名需要用”/”替换”.”


实际操作

使用到的工具都比较常规:javac、dx、eclipse等其中dx工具最好是指明--no-strict,因为class文件的路径可能不匹配
加载好类后,通常我们可以通过Java反射机制来使用这个类但是这样效率相对不高,而且老用反射代码也比较复杂凌乱。更好的做法是定义一个interface,并将这个interface写进容器端。待加载的类,继承自这个interface,并且有一个参数为空的构造函数,以使我们能够通过Class的newInstance方法产生对象然后将对象强制转换为interface对象,于是就可以直接调用成员方法了,下面是具体的实现步骤了:
第一步:

编写好动态代码类:


    package com.dynamic.interfaces;  
    import android.app.Activity;  
    /** 
     * 动态加载类的接口 
     */  
    public interface IDynamic {  
        /**初始化方法*/  
        public void init(Activity activity);  
        /**自定义方法*/  
        public void showBanner();  
        public void showDialog();  
        public void showFullScreen();  
        public void showAppWall();  
        /**销毁方法*/  
        public void destory();  
    }  


实现类代码如下:

    package com.dynamic.impl;  
      
    import android.app.Activity;  
    import android.widget.Toast;  
      
    import com.dynamic.interfaces.IDynamic;  
      
    /** 
     * 动态类的实现 
     * 
     */  
    public class Dynamic implements IDynamic{  
      
        private Activity mActivity;  
          
        @Override  
        public void init(Activity activity) {  
            mActivity = activity;  
        }  
          
        @Override  
        public void showBanner() {  
            Toast.makeText(mActivity, "我是ShowBannber方法", 1500).show();  
        }  
      
        @Override  
        public void showDialog() {  
            Toast.makeText(mActivity, "我是ShowDialog方法", 1500).show();  
        }  
      
        @Override  
        public void showFullScreen() {  
            Toast.makeText(mActivity, "我是ShowFullScreen方法", 1500).show();  
        }  
      
        @Override  
        public void showAppWall() {  
            Toast.makeText(mActivity, "我是ShowAppWall方法", 1500).show();  
        }  
      
        @Override  
        public void destory() {  
        }  
      
    }  


这样动态类就开发好了


第二步:

将上面开发好的动态类打包成.jar,这里要注意的是只打包实现类Dynamic.java,不打包接口类IDynamic.java,


然后将打包好的jar文件拷贝到android的安装目录中的platform-tools目录下,使用dx命令:(我的jar文件是dynamic.jar)

dx --dex --output=dynamic_temp.jar dynamic.jar

这样就生成了dynamic_temp.jar,这个jar和dynamic.jar有什么区别呢?

其实这条命令主要做的工作是:首先将dynamic.jar编译成dynamic.dex文件(Android虚拟机认识的字节码文件),然后再将dynamic.dex文件压缩成dynamic_temp.jar,当然你也可以压缩成.zip格式的,或者直接编译成.apk文件都可以的,这个后面会说到。

到这里还不算完事,因为你想想用什么来连接动态类和目标类呢?那就是动态类的接口了,所以这时候还要打个.jar包,这时候只需要打接口类IDynamic.java了


然后将这个.jar文件引用到目标类中,下面来看一下目标类的实现:

    package com.jiangwei.demo;  
      
    import java.io.File;  
    import java.util.List;  
      
    import android.app.Activity;  
    import android.content.Intent;  
    import android.content.pm.ActivityInfo;  
    import android.content.pm.PackageManager;  
    import android.content.pm.ResolveInfo;  
    import android.os.Bundle;  
    import android.os.Environment;  
    import android.view.View;  
    import android.widget.Button;  
    import android.widget.Toast;  
      
    import com.dynamic.interfaces.IDynamic;  
      
    import dalvik.system.DexClassLoader;  
    import dalvik.system.PathClassLoader;  
      
    public class AndroidDynamicLoadClassActivity extends Activity {  
          
        //动态类加载接口  
        private IDynamic lib;  
          
        @Override  
        public void onCreate(Bundle savedInstanceState) {  
            super.onCreate(savedInstanceState);  
            setContentView(R.layout.main);  
            //初始化组件  
            Button showBannerBtn = (Button) findViewById(R.id.show_banner_btn);  
            Button showDialogBtn = (Button) findViewById(R.id.show_dialog_btn);  
            Button showFullScreenBtn = (Button) findViewById(R.id.show_fullscreen_btn);  
            Button showAppWallBtn = (Button) findViewById(R.id.show_appwall_btn);  
            /**使用DexClassLoader方式加载类*/  
            //dex压缩文件的路径(可以是apk,jar,zip格式)  
            String dexPath = Environment.getExternalStorageDirectory().toString() + File.separator + "Dynamic.apk";  
            //dex解压释放后的目录  
            //String dexOutputDir = getApplicationInfo().dataDir;  
            String dexOutputDirs = Environment.getExternalStorageDirectory().toString();  
            //定义DexClassLoader  
            //第一个参数:是dex压缩文件的路径  
            //第二个参数:是dex解压缩后存放的目录  
            //第三个参数:是C/C++依赖的本地库文件目录,可以为null  
            //第四个参数:是上一级的类加载器  
            DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDirs,null,getClassLoader());  
              
            /**使用PathClassLoader方法加载类*/  
            //创建一个意图,用来找到指定的apk:这里的"com.dynamic.impl是指定apk中在AndroidMainfest.xml文件中定义的<action name="com.dynamic.impl"/>    
            Intent intent = new Intent("com.dynamic.impl", null);    
            //获得包管理器    
            PackageManager pm = getPackageManager();    
            List<ResolveInfo> resolveinfoes =  pm.queryIntentActivities(intent, 0);    
            //获得指定的activity的信息    
            ActivityInfo actInfo = resolveinfoes.get(0).activityInfo;    
            //获得apk的目录或者jar的目录    
            String apkPath = actInfo.applicationInfo.sourceDir;    
            //native代码的目录    
            String libPath = actInfo.applicationInfo.nativeLibraryDir;    
            //创建类加载器,把dex加载到虚拟机中    
            //第一个参数:是指定apk安装的路径,这个路径要注意只能是通过actInfo.applicationInfo.sourceDir来获取  
            //第二个参数:是C/C++依赖的本地库文件目录,可以为null  
            //第三个参数:是上一级的类加载器  
            PathClassLoader pcl = new PathClassLoader(apkPath,libPath,this.getClassLoader());  
            //加载类  
            try {  
                //com.dynamic.impl.Dynamic是动态类名  
                //使用DexClassLoader加载类  
                //Class libProviderClazz = cl.loadClass("com.dynamic.impl.Dynamic");  
                //使用PathClassLoader加载类  
                Class libProviderClazz = pcl.loadClass("com.dynamic.impl.Dynamic");  
                lib = (IDynamic)libProviderClazz.newInstance();  
                if(lib != null){  
                    lib.init(AndroidDynamicLoadClassActivity.this);  
                }  
            } catch (Exception exception) {  
                exception.printStackTrace();  
            }  
            /**下面分别调用动态类中的方法*/  
            showBannerBtn.setOnClickListener(new View.OnClickListener() {  
                public void onClick(View view) {  
                   if(lib != null){  
                       lib.showBanner();  
                   }else{  
                       Toast.makeText(getApplicationContext(), "类加载失败", 1500).show();  
                   }  
                }  
            });  
            showDialogBtn.setOnClickListener(new View.OnClickListener() {  
                public void onClick(View view) {  
                   if(lib != null){  
                       lib.showDialog();  
                   }else{  
                       Toast.makeText(getApplicationContext(), "类加载失败", 1500).show();  
                   }  
                }  
            });  
            showFullScreenBtn.setOnClickListener(new View.OnClickListener() {  
                public void onClick(View view) {  
                   if(lib != null){  
                       lib.showFullScreen();  
                   }else{  
                       Toast.makeText(getApplicationContext(), "类加载失败", 1500).show();  
                   }  
                }  
            });  
            showAppWallBtn.setOnClickListener(new View.OnClickListener() {  
                public void onClick(View view) {  
                   if(lib != null){  
                       lib.showAppWall();  
                   }else{  
                       Toast.makeText(getApplicationContext(), "类加载失败", 1500).show();  
                   }  
                }  
            });  
        }  
    }  


这里面定义了一个IDynamic接口变量,同时使用了DexClassLoader和PathClassLoader来加载类,这里面先来说一说DexClassLoader方式加载:

    //定义DexClassLoader  
    //第一个参数:是dex压缩文件的路径  
    //第二个参数:是dex解压缩后存放的目录  
    //第三个参数:是C/C++依赖的本地库文件目录,可以为null  
    //第四个参数:是上一级的类加载器  
    DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDirs,null,getClassLoader());  

上面已经说了,DexClassLoader是继承ClassLoader类的,这里面的参数说明:

第一个参数是:dex压缩文件的路径:这个就是我们将上面编译后的dynamic_temp.jar存放的目录,当然也可以是.zip和.apk格式的

第二个参数是:dex解压后存放的目录:这个就是将.jar,.zip,.apk文件解压出的dex文件存放的目录,这个就和PathClassLoader方法有区别了,同时你也可以看到PathClassLoader方法中没有这个参数,这个也真是这两个类的区别:

PathClassLoader不能主动从zip包中释放出dex,因此只支持直接操作dex格式文件,或者已经安装的apk(因为已经安装的apk在手机的data/dalvik目录中存在缓存的dex文件)。而DexClassLoader可以支持.apk、.jar和.dex文件,并且会在指定的outpath路径释放出dex文件。


然而我们可以通过DexClassLoader方法指定解压后的dex文件的存放目录,但是我们一般不这么做,因为这样做无疑的暴露了dex文件,所以我们一般不会将.jar/.zip/.apk压缩文件存放到用户可以察觉到的位置,同时解压dex的目录也是不能让用户看到的。

第三个参数和第四个参数用到的不是很多,所以这里就不做太多的解释了。

这里还要注意一点就是PathClassLoader方法的时候,第一个参数是dex存放的路径,这里传递的是:

//获得apk的目录或者jar的目录    
String apkPath = actInfo.applicationInfo.sourceDir;  

指定的apk安装路径,这个值只能这样获取,不然会加载类失败的


第三步:

运行目标类:

要做的工作是:

如果用的是DexClassLoader方式加载类:这时候需要将.jar或者.zip或者.apk文件放到指定的目录中,我这里为了方便就放到sd卡的根目录中

如果用的是PathClassLoader方法加载类:这时候需要先将Dynamic.apk安装到手机中,不然找不到这个activity,同时要注意的是:

  1. //创建一个意图,用来找到指定的apk:这里的"com.dynamic.impl是指定apk中在AndroidMainfest.xml文件中定义的<action name="com.dynamic.impl"/>    
  2. Intent intent = new Intent("com.dynamic.impl", null);    
这里的com.dynamic.impl是一个action需要在指定的apk中定义,这个名称是动态apk和目标apk之间约定好的

运行结果


点击showBanner显示一个Toast,成功的运行了动态类中的代码!

其实更好的办法就是将动态的.jar.zip.apk文件从网络上获取,安全可靠,同时本地的目标项目不需要改动代码就可以执行不同的逻辑了


关于代码加密的一些设想
    最初设想将dex文件加密,然后通过JNI将解密代码写在Native层。解密之后直接传上二进制流,再通过defineClass将类加载到内存中。
    现在也可以这样做,但是由于不能直接使用defineClass,而必须传文件路径给dalvik虚拟机内核,因此解密后的文件需要写到磁盘上,增加了被破解的风险。
    Dalvik虚拟机内核仅支持从dex文件加载类的方式是不灵活的,由于没有非常深入的研究内核,我不能确定是Dalvik虚拟机本身不支持还是Android在移植时将其阉割了。不过相信Dalvik或者是Android开源项目都正在向能够支持raw数据定义类方向努力。
    我们可以在文档中看到Google说:Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.);在Android的Dalvik源码中我们也能看到RawDexFile的身影(不过没有具体实现)

    在RawDexFile出来之前,我们都只能使用这种存在一定风险的加密方式。需要注意释放的dex文件路径及权限管理,另外,在加载完毕类之后,除非出于其他目的否则应该马上删除临时的解密文件

原文地址:http://blog.youkuaiyun.com/jiangwei0910410003/article/details/17679823

大模型——Dify:知识库与外部知识库 摘要 Dify的知识库功能为开发者提供了动态知识管理解决方案,超越了大模型静态预训练数据的限制。知识库支持多种文档格式(如txt、pdf、docx等),通过文档分段、索引设置和检索优化机制提升LLM的响应准确性。系统提供高质量和经济两种索引模式,前者采用向量化检索技术,后者使用关键词匹配以降低成本。知识库支持元数据管理,包括自动生成的内置元数据和用户自定义元数据,便于内容分类和检索。对于高级需求,Dify还支持连接外部知识库,通过API实现跨平台数据共享和检索优化,满足企业级知识管理需求。 阅读详情

相关推荐

AI工程化之生成式UI & A2UI(二)

本文介绍了生成式UI框架A2UI的架构设计与核心实现。项目采用AI协作开发模式,通过ATDD(AI驱动的测试驱动开发)确保代码质量。前端SDK基于zustand实现框架无关的状态管理,包含协议解析器、存储管理、渲染器等核心模块。重点展示了基础store构建、A2UI协议解析器的实现过程,包括mock数据准备、测试用例生成和可视化调试。项目采用monorepo管理,利用vite实现高效开发构建。整个系统设计遵循模块化原则,通过清晰的接口定义实现各组件解耦,为后续功能扩展打下基础。

qq_34306228的博客 406

Android插件化学习之路(二)之ClassLoader完全解析

Java代码都是写在Class里面的,程序运行在虚拟机上时,虚拟机需要把需要的Class加载进来才能创建实例对象并工作,而完成这一个加载工作的角色就是ClassLoader。类加载器ClassLoader介绍Android的Dalvik/ART虚拟机如同标准JAVA的JVM虚拟机一样,在运行程序时首先需要将对应的类加载到内存中。因此,我们可以利用这一点,在程序运行时手动加载Class,从而达到代码动

一个码农的博客 8311

树莓派4B串口舵机控制全攻略:从pigpio库安装到Python脚本调试

本文详细介绍了如何在树莓派4B上通过pigpio库和Python脚本实现串口舵机的精确控制。从硬件串口配置、pigpio库安装到舵机通信协议解析和Python脚本开发,提供了完整的解决方案和调试技巧,适用于机械臂控制等实际项目应用。

k8s6orchestrator的博客 429

Android So加载的路径选择

我们在Android应用程序会常常的加载一些So文件来完成我们的目标,那么我们的APK加载So是有哪些平时我们没有注意到的事情呢? 首先我们一般开发会遇见两种APK(其实一般大部分只会遇到一种),一种为系统级APK,另外一种为普通APK。那么这个两种APK跟So加载有什么关系呢?别急,让我们先聊聊我们那些操作会产生这些类型的APK。 普通级AKP: pm install + 包名将会把APK安...

awodefengduanwu的博客 2615

HOPE:基于强化学习的混合策略路径规划器,适用于多样化停车场景

本文提出了一种混合策略路径规划器(HOPE),用于解决自动停车中的路径规划问题。HOPE结合了强化学习(RL)和Reeds-Shepp(RS)曲线,通过动作掩码机制引导RL智能体的探索,并利用Transformer融合环境感知信息与掩码。该方法在多样且复杂的停车场景中实现了超过97%的成功率,并通过真实实验验证了其泛化能力。此外,本文还提出了基于空间与障碍物分布的停车场景难度分级标准,进一步提升了训练与评估的效率。实验结果表明,HOPE在规划成功率和跨场景泛化能力上均优于传统的基于规则算法和朴素强化学习方法

weixin_42783201的博客 1466

在 ABAP Push Channel 里玩转 Detached Client:用 Attach Handle 把 WebSocket 连接交接给业务逻辑

摘要:本文介绍了ABAP Push Channels (APC)中的Detached Client技术,该技术通过将WebSocket连接建立与后续处理分离,实现更高效的实时通信。核心流程包括创建连接、使用connect_and_detach交接连接、以及通过attach handle重新附着发送消息。文章还探讨了PCP协议和AMC技术在企业级推送场景中的应用,并通过示例代码展示了Detached Client的具体实现方式。这种设计解决了传统轮询的资源浪费问题,特别适用于生产线监控、客服系统等需要服务端主

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 2315

Android类动态加载技术

转自大牛博客:http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html  把回复一同转载,便于学习只用。 Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求。但是有些特殊问题,常常引发我们进一步的沉思。我们从沉思中产生顿悟,从而产生新的技术形式。 如何开发一个可以自定义控件的And

2657

YOLOv11涨点改进 | 全网独家创新,注意力改进篇 | TGRS 2025 | 引入APCM自适应像素级协同机制,动态增强目标区域、抑制背景噪声,助力YOLOv11做红外小目标检测有效涨点

本文提出了一种基于APCM模块改进的YOLOv11网络模型,通过像素级局部-全局协同建模增强目标特征并抑制背景噪声。APCM模块采用轻量化设计,无需复杂参数,能有效提升小目标检测性能。文章详细介绍了APCM的原理、优势及其在红外小目标检测中的应用,包括模块结构、核心代码实现和YAML配置文件修改方法。实验结果表明,该方法在NUAA-SIRST和IRSTD-1K数据集上优于现有技术,显著提高了复杂场景下的检测精度与鲁棒性。

Ai缝合怪、助力小伙伴高效发论文 116

Android O: 获取APK中so的路径

APK中so的存储路径

橡果生长记的博客 1万+

RH850从0搭建Autosar开发环境【2X】- Davinci Configurator之EcuC模块配置详解(上)

RH850从0搭建Autosar开发环境【2X】- Davinci Configurator之EcuC模块配置详解(上)

weixin_42412049的博客 1530

使用SIMD思想进行memcpy的优化

arm64平台的memcpy的性能优化,相比C库提升30~40%,SIMD优化思路

zhaoxin1989的博客 1万+

Android中的class动态加载机制

Android中的动态加载机制 类加载机制        Dalvik虚拟机如同其他Java虚拟机一样,在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中,类加载可以从class文件中读取,也可以是其他形式的二进制流,因此,我们常常利用这一点,在程序运行时手动加载Class,从而达到代码动态加载执行的目的        然而Dalvik虚拟机毕竟不算是标准的Java虚拟机

sinat_21468979的博客 1073

Python GUI编程:视频播放器(opencv、tkinter、PIL、ffpyplayer、threading)

用了几天做了一个视频播放器,搞了几个版本,开始想的是运用cv2模块把视频转化成一张张图片,然后再用ffpyplayer模块下的相关类来播放视频。但是,结果画面和视频的音频播放不同步(原因是cv2将转换得到的图片展示到tk上canvas,花费的时间多于每张图片应该展示的时间[1/fps])。后面看到ffpyplayer这个模块官网的介绍,发现这个模块可以得到视频播放时的图片,只不过这个图片是一个对象,我对这个不是很了解,到网上找了很久,终于找到了一篇文章,说可以利用PIL模块下的相关类,把上述这个对象转化成。

坚持不懈的大白的博客 3407

Android中的动态加载机制--薛彦顺

在目前的软硬件环境下,Native App与Web App在用户体验上有着明显的优势,但在实际项目中有些会因为业务的频繁变更而频繁的升级客户端,造成较差的用户体验,而这也恰恰是Web App的优势。本文对网上Android动态加载jar的资料进行梳理和实践在这里与大家一起分享,试图改善频繁升级这一弊病。 Android应用开发在一般情况下,常规的开发方式和代码架构就能满足我们的普通需求。但是有些

tarena_3G的博客 3080

TMS_WebGMaps_1.9.8.0_Full_Source

TMS_WebGMaps_1.9.8.0_Full_Source 全源码 delphi cbuilder

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

上一篇: 游戏主循环FPS
下一篇: Java程序打包成jar包
cbbbc
博客等级 码龄15年 609粉丝 37原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值