android 编译之后黑屏_抖音BoostMultiDex:Android低版本上首次启动时间减少80%(一)...

我们知道,Android 低版本(4.X 及以下,SDK < 21)的设备,采用的 Java 运行环境是 Dalvik 虚拟机。它相比于高版本,最大的问题就是在安装或者升级更新之后,首次冷启动的耗时漫长。这常常需要花费几十秒甚至几分钟,用户不得不面对一片黑屏,熬过这段时间才能正常使用 APP。

这是非常影响用户的使用体验的。我们从线上数据也可以发现,Android 4.X 及以下机型,其新增用户也占了一定的比例,但留存用户数相比新增则要少非常多。尤其在海外,像东南亚以及拉美等地区,还存有着很大量的低端机。4.X 以下低版本用户虽然比较少,但对于抖音及 TikTok 这样有着亿级规模的用户的 APP,即使占比 10%,数目也有上千万。因此如果想要打通下沉市场,这部分用户的使用和升级体验是绝对无法忽视的。

这个问题的根本原因就在于,安装或者升级后首次 MultiDex 花费的时间过于漫长。为了解决这个问题,我们挖掘了 Dalvik 虚拟机的底层系统机制,对 DEX 相关处理逻辑进行了重新设计,最终推出了 BoostMultiDex 方案,它能够减少 80%以上的黑屏等待时间,挽救低版本 Android 用户的升级安装体验。

我们先来简单看一个安装后首次冷启动加载 DEX 时间的对比数据:

a9964ff3086f4d218a745dac57ac4550.png

可以看到原始 MultiDex 方案竟然花了半分钟以上才能完成 DEX 加载,而 BoostMultiDex 方案的时间仅需要 5 秒以内。优化效果极为显著!

接下来,我们就来详细讲解整个 BoostMultiDex 方案的研发过程与解决思路。

起因

我们先来看下导致这个问题的根本原因。这里面是有多个原因共同引起的。

首先需要清楚的是,在 Java 里面想要访问一个类,必然是需要通过 ClassLoader 来加载它们才能访问到。在 Android 上,APP 里面的类都是由PathClassLoader负责加载的。而类都是依附于 DEX 文件而存在的,只有加载了相应的 DEX,才能对其中的类进行使用。

Android 早期对于 DEX 的指令格式设计并不完善,单个 DEX 文件中引用的 Java 方法总数不能超过 65536 个。

对于现在的 APP 而言,只要功能逻辑多一些,很容易就会触达这个界限。

这样,如果一个 APP 的 Java 代码的方法数超过了 65536 个,这个 APP 的代码就无法被一个 DEX 文件完全装下,那么,我们在编译期间就不得不生成多个 DEX 文件。我们解开抖音的 APK 就可以看到,里面确实包含了很多个 DEX 文件:

  8035972  00-00-1980 00:00   classes.dex  8476188  00-00-1980 00:00   classes2.dex  7882916  00-00-1980 00:00   classes3.dex  9041240  00-00-1980 00:00   classes4.dex  8646596  00-00-1980 00:00   classes5.dex  8644640  00-00-1980 00:00   classes6.dex  5888368  00-00-1980 00:00   classes7.dex

Android 4.4 及以下采用的是 Dalvik 虚拟机,在通常情况下,Dalvik 虚拟机只能执行做过 OPT 优化的 DEX 文件,也就是我们常说的 ODEX 文件。

一个 APK 在安装的时候,其中的classes.dex会自动做 ODEX 优化,并在启动的时候由系统默认直接加载到 APP 的PathClassLoader里面,因此classes.dex中的类肯定能直接访问,不需要我们操心。

除它之外的 DEX 文件,也就是classes2.dex、classes3.dex、classes4.dex等 DEX 文件(这里我们统称为 Secondary DEX 文件),这些文件都需要靠我们自己进行 ODEX 优化,并加载到 ClassLoader 里,才能正常使用其中的类。否则在访问这些类的时候,就会抛出ClassNotFound异常从而引起崩溃。

因此,Android 官方推出了 MultiDex 方案。只需要在 APP 程序执行最早的入口,也就是Application.attachBaseContext里面直接调MultiDex.install,它会解开 APK 包,对第二个以后的 DEX 文件做 ODEX 优化并加载。这样,带有多个 DEX 文件的 APK 就可以顺利执行下去了。

这个操作会在 APP 安装或者更新后首次冷启动的时候发生,正是由于这个过程耗时漫长,才导致了我们最开始提到的耗时黑屏问题。

原始实现

了解了这个背景之后,我们再来看 MultiDex 的实现,逻辑就比较清晰了。

首先,APK 里面的所有classes2.dex、classes3.dex、classes4.dex等 DEX 文件都会被解压出来。

然后,对每个 dex 进行 ZIP 压缩。生成 classesN.zip 文件。

接着,对每个 ZIP 文件做 ODEX 优化,生成 classesN.zip.odex 文件。

具体而言,我们可以看到 APP 的 code_cache 目录下有这些文件:

com.bytedance.app.boost_multidex-1.apk.classes2.dexcom.bytedance.app.boost_multidex-1.apk.classes2.zipcom.bytedance.app.boost_multidex-1.apk.classes3.dexcom.bytedance.app.boost_multidex-1.apk.classes3.zipcom.bytedance.app.boost_multidex-1.apk.classes4.dexcom.bytedance.app.boost_multidex-1.apk.classes4.zip

这一步是通过DexFile.loadDex方法实现的,只需要指定原始 ZIP 文件和 ODEX 文件的路径,就能够根据 ZIP 中的 DEX 生成相应的 ODEX 产物,这个方法会最终返回一个DexFile对象。

最后,APP 把这些DexFile对象都添加到PathClassLoader的pathList里面,就可以让 APP 在运行期间,通过ClassLoader加载使用到这些 DEX 中的类。

在这整个过程中,生成 ZIP 和 ODEX 文件的过程都是比较耗时的,如果一个 APP 中有很多个 Secondary DEX 文件,就会加剧这一问题。尤其是生成 ODEX 的过程,Dalvik 虚拟机会把 DEX 格式的文件进行遍历扫描和优化重写处理,从而转换为 ODEX 文件,这就是其中最大的耗时瓶颈。

普遍采用的优化方式

目前业界已经有了一些对 MultiDex 进行优化的方法,我们先来看下大家通常是怎么优化这一过程的。

异步化加载

把启动阶段要使用的类尽可能多地打包到主 Dex 里面,尽量多地不依赖 Secondary DEX 来跑业务代码。然后异步调用MultiDex.install,而在后续某个时间点需要用到 Secondary DEX 的时候,如果 MultiDex 还没执行完,就停下来同步等待它完成再继续执行后续的代码。

这样确实可以在 install 的同时往下执行部分代码,而不至于被完全堵住。然而要做到这点,必须首先梳理好启动逻辑的代码,明确知道哪些是可以并行执行的。另外,由于主 Dex 能放的代码本身就比较有限,业务在启动阶段如果有太多依赖,就不能完全放入主 Dex 里面,因此就需要合理地剥离依赖。

因此现实情况下这个方案效果比较有限,如果启动阶段牵扯了太多业务逻辑,很可能并行执行不了太多代码,就很快又被 install 堵住了。

模块懒加载

这个方案最早见于美团的文章,可以说是前一个方案的升级版。

它也是做异步 DEX 加载,不过不同之处在于,在编译期间就需要对 DEX 按模块进行拆分。

一般是把一级界面的 Activity、Service、Receiver、Provider 涉及到的代码都放到第一个 DEX 中,而把二级、三级页面的 Activity 以及非高频界面的代码放到了 Secondary DEX 中。

当后面需要执行某个模块的时候,先判断这个模块的 Class 是否已经加载完成,如果没有完成,就等待 install 完成后再继续执行。

可见,这个方案对业务的改造程度相当巨大,而且已经有了一些插件化框架的雏形。另外,想要做到能对模块的 Class 的加载情况进行判断,还得通过反射 ActivityThread 注入自己的 Instrumentation,在执行 Activity 之前插入自己的判断逻辑。这也会相应地引入机型兼容性问题。

多线程加载

原生的 MultiDex 是顺序依次对每个 DEX 文件做 ODEX 优化的。而多线程的思路是,把每个 DEX 分别用各自线程做 OPT。

这么乍看起来,似乎是能够并行地做 ODEX 来起到优化效果。然而我们项目中一共有 6 个 Secondary DEX 文件,实测发现,这种方式几乎没有优化效果。原因可能是 ODEX 本身其实是重度 I/O 类型的操作,对于并发而言,多个线程同时进行 I/O 操作并不能带来明显收益,并且多线程切换本身也会带来一定损耗。

后台进程加载

这个方案主要是防止主进程做 ODEX 太久导致 ANR。当点击 APP 的时候,先单独启动了一个非主进程来先做 ODEX,等非主进程做完 ODEX 后再叫起主进程,这样主进程起来直接取得做好的 ODEX 就可以直接执行。不过,这只是规避了主进程 ANR 的问题,第一次启动的整体等待时间并没有减少。

一个更彻底的优化方案

上述几个方案,在各个层面都尝试做了优化,然而仔细分析便会发现,它们都没有触及这个问题中根本,也就是就MultiDex.install操作本身。

MultiDex.install生成 ODEX 文件的过程,调用的方法是DexFile.loadDex,它会启动一个 dexopt 进程对输入的 DEX 文件进行 ODEX 转化。那么,这个 ODEX 优化的时间是否可以避免呢?

我们的 BoostMultiDex 方案,正是从这一点入手,从本质上优化 install 的耗时。

我们的做法是,在第一次启动的时候,直接加载没有经过 OPT 优化的原始 DEX,先使得 APP 能够正常启动。然后在后台启动一个单独进程,慢慢地做完 DEX 的 OPT 工作,尽可能避免影响到前台 APP 的正常使用。

突破口

这里的难点,自然是——如何做到可以直接加载原始 DEX,避免 ODEX 优化带来的耗时阻塞。

如果要避免 ODEX 优化,又想要 APP 能够正常运行,就意味着 Dalvik 虚拟机需要直接执行没有做过 OPT 的、原始的 DEX 文件。虚拟机是否支持直接执行 DEX 文件呢?毕竟 Dalvik 虚拟机是可以直接执行原始 DEX 字节码的,ODEX 相比 DEX 只是做了一些额外的分析优化。因此即使 DEX 不通过优化,理论上应该是可以正常执行的。

功夫不负有心人,经过我们的一番挖掘,在系统的 dalvik 源码里面果然找到了这一隐藏入口:

/* * private static int openDexFile(byte[] fileContents) throws IOException * * Open a DEX file represented in a byte[], returning a pointer to our * internal data structure. * * The system will only perform "essential" optimizations on the given file. * */static void Dalvik_dalvik_system_DexFile_openDexFile_bytearray(const u4* args,    JValue* pResult){    ArrayObject* fileContentsObj = (ArrayObject*) args[0];    u4 length;    u1* pBytes;    RawDexFile* pRawDexFile;    DexOrJar* pDexOrJar = NULL;    if (fileContentsObj == NULL) {        dvmThrowNullPointerException("fileContents == null");        RETURN_VOID();    }    /* TODO: Avoid making a copy of the array. (note array *is* modified) */    length = fileContentsObj->length;    pBytes = (u1*) malloc(length);    if (pBytes == NULL) {        dvmThrowRuntimeException("unable to allocate DEX memory");        RETURN_VOID();    }    memcpy(pBytes, fileContentsObj->contents, length);    if (dvmRawDexFileOpenArray(pBytes, length, &pRawDexFile) != 0) {        ALOGV("Unable to open in-memory DEX file");        free(pBytes);        dvmThrowRuntimeException("unable to open in-memory DEX file");        RETURN_VOID();    }    ALOGV("Opening in-memory DEX");    pDexOrJar = (DexOrJar*) malloc(sizeof(DexOrJar));    pDexOrJar->isDex = true;    pDexOrJar->pRawDexFile = pRawDexFile;    pDexOrJar->pDexMemory = pBytes;    pDexOrJar->fileName = strdup(""); // Needs to be free()able.    addToDexFileTable(pDexOrJar);    RETURN_PTR(pDexOrJar);}

这个方法可以做到对原始 DEX 文件做加载,而不依赖 ODEX 文件,它其实就做了这么几件事:

  1. 接受一个byte[]参数,也就是原始 DEX 文件的字节码。
  2. 调用dvmRawDexFileOpenArray函数来处理byte[],生成RawDexFile对象
  3. 由RawDexFile对象生成一个DexOrJar,通过addToDexFileTable添加到虚拟机内部,这样后续就可以正常使用它了
  4. 返回这个DexOrJar的地址给上层,让上层用它作为 cookie 来构造一个合法的DexFile对象

这样,上层在取得所有 Seconary DEX 的DexFile对象后,调用 makeDexElements 插入到 ClassLoader 里面,就完成 install 操作了。如此一来,我们就能完美地避过 ODEX 优化,让 APP 正常执行下去了。

寻找入口

看起来似乎很顺利,然而在我们却遇到了一个意外状况。

我们从Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个函数的名字可以明显看出,这是一个 JNI 方法,从 4.0 到 4.3 版本都能找到它的 Java 原型:

/* * Open a DEX file based on a {@code byte[]}. The value returned * is a magic VM cookie. On failure, a RuntimeException is thrown. */native private static int openDexFile(byte[] fileContents);

然而我们在 4.4 版本上,Java 层它并没有对应的 native 方法。这样我们便无法直接在上层调用了。

当然,我们很容易想到,可以用 dlsym 来直接搜寻这个函数的符号来调用。但是可惜的是,Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个方法是static的,因此它并没有被导出。我们实际去解析libdvm.so的时候,也确实没有找到Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个符号。

不过,由于它是 JNI 函数,也是通过正常方式注册到虚拟机里面的。因此,我们可以找到它对应的函数注册表:

const DalvikNativeMethod dvm_dalvik_system_DexFile[] = {    { "openDexFileNative",  "(Ljava/lang/String;Ljava/lang/String;I)I",        Dalvik_dalvik_system_DexFile_openDexFileNative },    { "openDexFile",        "([B)I",        Dalvik_dalvik_system_DexFile_openDexFile_bytearray },    { "closeDexFile",       "(I)V",        Dalvik_dalvik_system_DexFile_closeDexFile },    { "defineClassNative",  "(Ljava/lang/String;Ljava/lang/ClassLoader;I)Ljava/lang/Class;",        Dalvik_dalvik_system_DexFile_defineClassNative },    { "getClassNameList",   "(I)[Ljava/lang/String;",        Dalvik_dalvik_system_DexFile_getClassNameList },    { "isDexOptNeeded",     "(Ljava/lang/String;)Z",        Dalvik_dalvik_system_DexFile_isDexOptNeeded },    { NULL, NULL, NULL },};

dvm_dalvik_system_DexFile这个数组需要被虚拟机在运行时动态地注册进去,因此,这个符号是一定会被导出的。

这么一来,我们也就可以通过 dlsym 取得这个数组,按照逐个元素字符串匹配的方式来搜寻openDexFile对应的Dalvik_dalvik_system_DexFile_openDexFile_bytearray方法了。

具体代码实现如下:

    const char *name = "openDexFile";    JNINativeMethod* func = (JNINativeMethod*) dlsym(handler, "dvm_dalvik_system_DexFile");;    size_t len_name = strlen(name);    while (func->name != nullptr) {        if ((strncmp(name, func->name, len_name) == 0)            && (strncmp("([B)I", func->signature, len_name) == 0)) {            return reinterpret_cast(func->fnPtr);        }        func++;    }

捋清步骤

小结一下,绕过 ODEX 直接加载 DEX 的方案,主要有以下步骤:

  1. 从 APK 中解压获取原始 Secondary DEX 文件的字节码
  2. 通过 dlsym 获取dvm_dalvik_system_DexFile数组
  3. 在数组中查询得到Dalvik_dalvik_system_DexFile_openDexFile_bytearray函数
  4. 调用该函数,逐个传入之前从 APK 获取的 DEX 字节码,完成 DEX 加载,得到合法的DexFile对象
  5. 把DexFile对象都添加到 APP 的PathClassLoader的 pathList 里

完成了上述几步操作,我们就可以正常访问到 Secondary DEX 里面的类了

getDex 问题

然而,正当我们顺利注入原始 DEX 往下执行的时候,却在 4.4 的机型上马上遇到了一个必现的崩溃:

JNI WARNING: JNI function NewGlobalRef called with exception pending             in Ljava/lang/Class;.getDex:()Lcom/android/dex/Dex; (NewGlobalRef)Pending exception is:java.lang.IndexOutOfBoundsException: index=0, limit=0 at java.nio.Buffer.checkIndex(Buffer.java:156) at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:157) at com.android.dex.Dex.create(Dex.java:129) at java.lang.Class.getDex(Native Method) at libcore.reflect.AnnotationAccess.getSignature(AnnotationAccess.java:447) at java.lang.Class.getGenericSuperclass(Class.java:824) at com.google.gson.reflect.TypeToken.getSuperclassTypeParameter(TypeToken.java:82) at com.google.gson.reflect.TypeToken.(TypeToken.java:62) at com.google.gson.Gson$1.(Gson.java:112) at com.google.gson.Gson.(Gson.java:112)... ...

可以看到,Gson 里面使用到了Class.getGenericSuperclass方法,而它最终调用了Class.getDex,它是一个 native 方法,对应实现如下:

JNIEXPORT jobject JNICALL Java_java_lang_Class_getDex(JNIEnv* env, jclass javaClass) {    Thread* self = dvmThreadSelf();    ClassObject* c = (ClassObject*) dvmDecodeIndirectRef(self, javaClass);    DvmDex* dvm_dex = c->pDvmDex;    if (dvm_dex == NULL) {        return NULL;    }    // Already cached?    if (dvm_dex->dex_object != NULL) {        return dvm_dex->dex_object;    }    jobject byte_buffer = env->NewDirectByteBuffer(dvm_dex->memMap.addr, dvm_dex->memMap.length);    if (byte_buffer == NULL) {        return NULL;    }    jclass com_android_dex_Dex = env->FindClass("com/android/dex/Dex");    if (com_android_dex_Dex == NULL) {        return NULL;    }    jmethodID com_android_dex_Dex_create =            env->GetStaticMethodID(com_android_dex_Dex,                                   "create", "(Ljava/nio/ByteBuffer;)Lcom/android/dex/Dex;");    if (com_android_dex_Dex_create == NULL) {        return NULL;    }    jvalue args[1];    args[0].l = byte_buffer;    jobject local_ref = env->CallStaticObjectMethodA(com_android_dex_Dex,                                                     com_android_dex_Dex_create,                                                     args);    if (local_ref == NULL) {        return NULL;    }    // Check another thread didn't cache an object, if we've won install the object.    ScopedPthreadMutexLock lock(&dvm_dex->modLock);    if (dvm_dex->dex_object == NULL) {        dvm_dex->dex_object = env->NewGlobalRef(local_ref);    }    return dvm_dex->dex_object;}

结合堆栈和代码来看,崩溃的点是在 JNI 里面执行com.android.dex.Dex.create的时候:

jobject local_ref = env->CallStaticObjectMethodA(com_android_dex_Dex,                                                 com_android_dex_Dex_create,                                                 args);

由于是 JNI 方法,这个调用发生异常后如果没有 check,在后续执行到env->NewGlobalRef调用的时候会检查到前面发生了异常,从而抛出。

而com.android.dex.Dex.create之所以会执行失败,主要原因是入参有问题,这里的参数是dvm_dex->memMap取到的一块 map 内存。dvm_dex 是从这个 Class 里面取得的。虚拟机代码里面,每个 Class 对应是结构是ClassObject中,其中有这个字段:

struct ClassObject : Object {... ...    /* DexFile from which we came; needed to resolve constant pool entries */    /* (will be NULL for VM-generated, e.g. arrays and primitive classes) */    DvmDex*         pDvmDex;... ...

这里的pDvmDex是在这里加载类的过程中赋值的:

static void Dalvik_dalvik_system_DexFile_defineClassNative(const u4* args,    JValue* pResult){... ...    if (pDexOrJar->isDex)        pDvmDex = dvmGetRawDexFileDex(pDexOrJar->pRawDexFile);    else        pDvmDex = dvmGetJarFileDex(pDexOrJar->pJarFile);... ...

pDvmDex是从dvmGetRawDexFileDex方法里面取得的,而这里的参数pDexOrJar->pRawDexFile正是我们前面openDexFile_bytearray里面创建的,pDexOrJar是之前返回给上层的 cookie。

再根据dvmGetRawDexFileDex:

INLINE DvmDex* dvmGetRawDexFileDex(RawDexFile* pRawDexFile) {    return pRawDexFile->pDvmDex;}

可以最终推得,dvm_dex->memMap对应的正是openDexFile_bytearray时拿到的pDexOrJar->pRawDexFile->pDvmDex->memMap。我们在当初加载 DEX 字节数组的时候,是否遗漏了对memMap进行赋值呢?

我们通过分析代码,发现的确如此,memMap这个字段只在 ODEX 的情况下才会赋值:

/* * Given an open optimized DEX file, map it into read-only shared memory and * parse the contents. * * Returns nonzero on error. */int dvmDexFileOpenFromFd(int fd, DvmDex** ppDvmDex){... ...    // 构造memMap    if (sysMapFileInShmemWritableReadOnly(fd, &memMap) != 0) {        ALOGE("Unable to map file");        goto bail;    }... ...    // 赋值memMap    /* tuck this into the DexFile so it gets released later */    sysCopyMap(&pDvmDex->memMap, &memMap);... ...}

而只加载 DEX 字节数组的情况下并不会走这个方法,因此也就没法对 memMap 进行赋值了。看来,Android 官方从一开始对openDexFile_bytearray就没支持好,系统代码里面也没有任何使用的地方,所以当我们强制使用这个方法的时候就会暴露出这个问题。

虽然这个是官方的坑,但我们既然需要使用,就得想办法填上。

再次分析Java_java_lang_Class_getDex方法,我们注意到了这段:

    if (dvm_dex->dex_object != NULL) {        return dvm_dex->dex_object;    }

dvm_dex->dex_object如果非空,就会直接返回,不会再往下执行到取 memMap 的地方,因此就不会引发异常。这样,解决思路就很清晰了,我们在加载完 DEX 数组之后,立即自己生成一个dex_object对象,并注入pDvmDex里面。

详细代码如下:

jclass clazz = env->FindClass("com/android/dex/Dex");jobject dex_object = env->NewGlobalRef(        env->NewObject(clazz),        env->GetMethodID(clazz, "", "([B)V"),        bytes));dexOrJar->pRawDexFile->pDvmDex->dex_object = dex_object;

这样设置进去之后,果然不再出现 getDex 异常了。

小结

至此,无需等待 ODEX 优化的直接 DEX 加载方案已经完全打通,APP 的首次启动时间由此可以大幅减少。

我们距离最终的极致完整解决方案还有一小段路,然而,正是这一小段路,才最为艰险严峻。更大的挑战还在后面,我们将在下一篇文章为大家细细分解,同时也会详细展示最终方案带来的收益情况。大家也可以先思考一下这里还有哪些问题没有考虑到。

抖音/TikTok Android 基础技术团队是一个追求极致的深度技术团队,目前上海、北京、深圳、杭州都有大量人才需要,欢迎各位同学前来与我们共同建设亿级用户全球化 APP!

可以点击阅读原文,进入字节跳动招聘官网查询抖音 Android 相关职位「链接」,也可以联系 xiaolin.gan@bytedance.com 咨询相关信息或者直接发送简历内推!

敬请期待,抖音BoostMultiDex优化实践:Android低版本上APP首次启动时间减少80%(二)。

欢迎关注字节跳动技术团队

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/262539.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

[转]关于多线程并发:每个开发人员都应了解的内容(转自Mainz's)

Concurrency: What Every Dev Must Know About Multithreaded Apps 本文讨论: 多线程和共享内存线程模型争用及并发访问如何能够打破不变量作为争用标准解决方案的锁定何时需要锁定如何使用锁定&#xff1b;理解开销锁定如何能够各行其道十年前&#xff0c;只有核心系统程序员会…

Filter案例之登录验证

一、登录验证&#xff0c;权限控制 1、需求分析 其中&#xff0c;登录有关的资源被访问时要直接放行&#xff0c;不然会死循环&#xff1b; 2、代码实现 转载于:https://www.cnblogs.com/wmqiang/p/11604621.html

js导出excel单元格内换行符代码_前端和excel的那些事

前端和 excel 的那点事在开发需求中&#xff0c;经常会遇到需要和excel相关的需求&#xff0c;毕竟不是所有人都是程序员&#xff0c;很多的业务都是通过excel去进行数据的整理归类计算的&#xff0c;excel中提供的一系列快捷功能&#xff0c;统计功能也非常的实用&#xff0c;…

Filter案例之敏感词过滤和代理模式

一、需求分析 二 、代理模式 1、概念 2、代码实现 代理对象可以强转为真实对象&#xff0c;即对应的接口类&#xff1b; 3、通过代理增强方法 其中&#xff0c;方法对象invoke真实对象&#xff0c;反射原理&#xff1b; 三、过滤敏感词汇案例代码实现 本地的字符流和字节流创建…

555定时器回差电压计算公式_555时基电路引脚解析

555时基电路引脚解析凡是时基电路555&#xff0c;电路内部结构相同&#xff0c;性能都是相同的。 时基电路555有很多厂家型号&#xff0c;如MC555、CA555、XR555、LM555等&#xff1b;国产型号有SL555、FX555、5G1555等&#xff0c;典型的、也是最常用的是NE555。555前的字母只…

麻省理工学院(MIT)的公开课程

很早之前就听说麻省理工学院把很多课程公开了&#xff0c;今天偶尔搜到这个内容。还不错 http://www.core.org.cn/OcwWeb/index.htm 课程列表 http://www.core.org.cn/OcwWeb/Global/all-courses.htm转载于:https://www.cnblogs.com/chenxizhang/archive/2009/04/27/1444255.ht…

66319d电源使用说明书_矿用防爆交换机如何正确安装调试和使用?

矿用防爆交换机是矿山的通讯核心&#xff0c;它不同于普通交换机&#xff0c;因应用环境的特殊性&#xff0c;在安装以及后续使用过程中有更多要求。在使用过程中&#xff0c;出保障交换机本身的部件无损、性能不受影响外&#xff0c;还要注意使用环境&#xff0c;保证现场安全…

xcode7.1 安装不了Alcatraz怎么办.看这里

按照github上面的安装的方法,但是发现并没有成功.这是为什么呢? 解决的方法是什么呢? 看下面: 这个时候新的问题来了,要怎么获取7.1的UUIDs呢?看下面:   打开你的终端,输入下面的代码就可以了: defaults read /Applications/Xcode.app/Contents/Info DVTPlugInCompatibili…

epub 机器人系列 阿西莫夫_艾萨克·阿西莫夫是不是穿越来的,他怎么能那么准地预言机器人,互联网技术呢?...

机器人&#xff0c;纳米技术&#xff0c;网络图书馆&#xff0c;视频电话&#xff0c;当这些悄悄走进我们的生活&#xff0c;如果有人问你&#xff0c;是什么改变了我们的生活&#xff1f;你可能会回答&#xff0c;当然是科技的发展。如果再问你&#xff0c;这些科技的发展最初…

js怎么调用wasm_Long.js源码解析

基于现在市面上到处都是 Vue/React 之类的源码分析文章实在是太多了。(虽然我也写过 Vite的源码解析所以这次来写点不一样的。由于微信这边用的是 protobuf 来进行 rpc 调用。所以有时候需要将 JS 中的 Number 类型转换为 Long 类型传给后端。目前用的最多的就是 Long.js 了&am…

AOP快速入门

一、概念 AOP面向切面编程&#xff0c;是函数式编程的延申&#xff0c;是对OOP的补充&#xff1b; 代理模式&#xff1a;拦截增强作用&#xff0c;增强功能&#xff1b; 1、java继承&#xff0c;纵向共性抽取&#xff0c; 2、横向切面AOP织入增强代码方式 二、原理是通过代理机…

图形大小_PS图形复制——等距复制、旋转复制、大小变换复制

PS中图形复制是很常见的事&#xff0c;可能不同人的习惯可能会用不同的方法。这里糖糖主要讲的是图形的一些等距复制、旋转复制、大小变换旋转复制&#xff0c;相信看过本篇文章之后你也可以通过图形的不同需要的复制做一些很不错的图案哦~糖糖先在PS里用钢笔工具绘制了一个绿叶…

AOP联盟通知类型和Spring编写代理半自动

一、cglib功能更强大 二、Spring核心jar包 三、AOP联盟通知 三、代码实现Spring半自动代理 1、环绕通知的切面 2、bean.xml配置 3、创建bean容器&#xff0c;获取bean&#xff0c;即已经创建好的代理对象&#xff1a; 4、配置多个接口 转载于:https://www.cnblogs.com/wmqiang/…

1到30图片大全顺序_终于解决了!自媒体作者,如何给 Word 中的图片批量编号?...

今天这个技巧非常有用&#xff0c;特别是对小编这种每天都要写图文教程的人来说&#xff0c;简直是续命神技。如果 Word 中有大量的图片&#xff0c;经常需要个每个图片顺序编号&#xff0c;有没有同款需求&#xff1f;大家平时都一个个手工输入的吗&#xff1f;编到后来很可能…

Android Volley框架的使用(二)

此博文源码下载地址 https://github.com/Javen205/VolleyDemo.git 使用请求队列RequestQueue Volley中的Request都需要添加到RequestQueue中才能执行&#xff0c;所以首先需要创建一个RequestQueue RequestQueue Volley.newRequestQueue(mContext); 通常情况在一个应用中需要…

Spring全自动AOP和项目加入jar包

一、jar可以引进项目中&#xff0c;复制到路下后&#xff0c;要add as library&#xff0c;加载到工作空间中才能引入&#xff1b; 也jar包放在硬盘的项目目录外面&#xff0c;可以多个项目引入共用&#xff1a; 二、xml配置 1、aop全自动配置 2、xml装配bean,不是注解方式 3、…

中怎样载入选区_ps中快捷大全

使用ps时使用快捷键更方便&#xff0c;操作起来更能提高工作效率&#xff0c;下面给大家总结一下&#xff0c;希望对大家有帮助&#xff0c;当然大家有更好的技巧可以来魔课66网一起交流一下文件设置:Ctrln——新建Ctrlo——打开Ctrlp——打印Ctrls—— 存储Ctrlw——关闭Ctrl …

AspectJ——AOP框架快速入门

一、导包 二、bean.xml配置 三、环绕通知 四&#xff0c;表达式 转载于:https://www.cnblogs.com/wmqiang/p/11617042.html

linux桌面环境应用

为什么80%的码农都做不了架构师&#xff1f;>>> 通常的 Linux 发行版都使用 KDE 或者 GNOME 作为默认的桌面环境。它们都给用户提供了一个原始的并且有吸引力的桌面&#xff0c;并且内置了各式各样的多媒体软件、系统程序、游戏、实用程序、网页开发工具、编程 工具…

[转]C++的坑真的多吗?

http://coolshell.cn/articles/7992.html#jtss-tsina 先说明一下&#xff0c;我不希望本文变成语言争论贴。希望下面的文章能让我们客观理性地了解C这个语言。&#xff08;另&#xff0c;我觉得技术争论不要停留在非黑即白的二元价值观上&#xff0c;这样争论无非就是比谁的嗓门…