概述

本文以SpringBoot應用為基礎，嘗試分析基於註解@Configuration的配置類是如何向Spring容器註冊BeanDefinition的過程

其中主要分析了 ConfigurationClassPostProcessor 這個BeanDefinitionRegistryPostProcessor 即Bean定義註冊後置處理器，在Spring啟動過程中對@Configuration配置類的處理，主要體現在 解析並發現所有配置類，處理配置類的相關邏輯（如配置類上的@ComponentScan、@Import、@Bean註解等），註冊其中的BeanDefinition

SpringBoot版本：2.0.9.RELEASE

Spring版本：5.0.13.RELEASE

ConfigurationClassPostProcessor如何被引入

首先看一下ConfigurationClassPostProcessor的類繼承關係

從紅框中可以看出ConfigurationClassPostProcessor是BeanDefinitionRegistryPostProcessor接口的實現類，即是一個Bean定義註冊的後置處理器，會在Spring容器啟動時被調用，具體時機為

// 調用鏈
AbstractApplicationContext.refresh()
    => invokeBeanFactoryPostProcessors()
    => PostProcessorRegistrationDelegate#invokeBeanFactoryPostProcessors()

invokeBeanFactoryPostProcessors()會先調用所有的BeanDefinitionRegistryPostProcessor之後，再調用所有的BeanFactoryPostProcessor

ConfigurationClassPostProcessor又是如何被引入Spring的呢？？

SpringBoot應用會在ApplicationContext應用上下文被創建的構造函數中new AnnotatedBeanDefinitionReader這個用於註冊基於註解的BeanDefinition的Reader，在其構造中又會調用AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry)使用工具類向Spring容器中註冊一些所謂的註解配置處理器，其中就包含ConfigurationClassPostProcessor

// ConfigurationClassPostProcessor被註冊
AnnotationConfigServletWebServerApplicationContext構造
    => new AnnotatedBeanDefinitionReader(registry)
        => AnnotationConfigUtils.registerAnnotationConfigProcessors(registry)
            => 註冊ConfigurationClassPostProcessor到Spring容器

ConfigurationClassPostProcessor處理過程簡述

首先，ConfigurationClassPostProcessor後置處理器的處理入口為postProcessBeanDefinitionRegistry()方法。其主要使用了ConfigurationClassParser配置類解析器解析@Configuration配置類上的諸如@ComponentScan、@Import、@Bean等註解，並嘗試發現所有的配置類；還使用了ConfigurationClassBeanDefinitionReader註冊所發現的所有配置類中的所有Bean定義；結束執行的條件是所有配置類都被發現和處理，相應的bean定義註冊到容器

大致流程如下：

1、通過BeanDefinitionRegistry查找當前Spring容器中所有BeanDefinition

2、通過ConfigurationClassUtils.checkConfigurationClassCandidate() 檢查BeanDefinition是否為 “完全配置類” 或 “簡化配置類”，並對配置類做標記，放入集合待後續處理

Spring配置類的分類可以

3、通過 ConfigurationClassParser解析器 parse解析配置類集合，嘗試通過它們找到其它配置類

4、使用 ConfigurationClassBeanDefinitionReader 註冊通過所發現的配置類中找到的所有beanDefinition

5、處理完一輪配置類后，查看BeanDefinitionRegistry中是否存在新加載的且還未被處理過的 “完全配置類” 或 “簡化配置類”，有的話繼續上面步驟

其中第3、4步後面重點分析

ConfigurationClassParser#parse()：解析構建配置類

對於SpringBoot應用來說，參与解析的種子配置文件即為SpringBoot的Application啟動類

解析構建配置類流程

通過ConfigurationClassParser解析器parse解析配置類集合，嘗試通過它們找到其它配置類

• 循環解析所有配置類 ConfigurationClassParser#processConfigurationClass()

  • 根據@Conditional的ConfigurationPhase.PARSE_CONFIGURATION階段條件判斷是否跳過配置類

    注意：有些@Conditional是在當前這個PARSE_CONFIGURATION解析配置階段使用的，有些是在REGISTER_BEAN註冊beanDefinition階段使用的

  • 【重點】調用ConfigurationClassParser#doProcessConfigurationClass()循環解析配置類，直到不存在未處理過的父類

    • 1、處理配置類的成員內部類： 檢查其是否為“完全/簡化配置類”，是則對其繼續分析處理並將其放入分析器的屬性configurationClasses
    • 2、處理@PropertySource： 將找到的PropertySource添加到environment的PropertySource集合
    • 3、處理@ComponentScan： 掃描到的@Component類BeanDefinition就直接註冊到Spring容器；如果組件為配置類，繼續分析處理並將其放入分析器的屬性configurationClasses
    • 4、處理@Import：
      • （1）處理ImportSelector： 如果是DeferredImportSelector，如SpringBoot的自動配置導入，添加到deferredImportSelectors，延遲進行processImports()；其它通過ImportSelector找到的類，繼續調用processImports()，要麼是@Configuration配置類繼續解析，要麼是普通組件導入Spring容器
      • （2）處理ImportBeanDefinitionRegistrar： 調用當前配置類的addImportBeanDefinitionRegistrar()，後面委託它註冊其它bean定義
      • （3）其它Import：調用processConfigurationClass()繼續解析，最終要麼是配置類放入configurationClasses，要麼是普通組件導入Spring容器
    • 5、處理@ImportResource： 添加到配置類的importedResources集合，後續ConfigurationClassBeanDefinitionReader#loadBeanDefinitions()時再使用這些導入的BeanDefinitionReader讀取Resource中的bean定義並註冊
    • 6、處理@Bean： 獲取所有@Bean方法，並添加到配置類的beanMethods集合
    • 7、處理配置類接口上的default methods
    • 8、檢查是否有未處理的父類： 如果配置類有父類，且其不在解析器維護的knownSuperclasses中，對其調用doProcessConfigurationClass()重複如上檢查，直到不再有父類或父類在knownSuperclasses中已存在

• processDeferredImportSelectors()：處理推遲的ImportSelector集合，其實就是延遲調用了processImports()

  SpringBoot的自動配置類就是被DeferredImportSelector推遲導入的

解析構建配置類源碼分析

ConfigurationClassParser#processConfigurationClass()

包含了處理單個配置類的大體流程，先根據ConfigurationPhase.PARSE_CONFIGURATION解析配置階段的@Conditional條件判斷當前配置類是否應該解析，之後調用ConfigurationClassParser#doProcessConfigurationClass()循環解析配置類，直到不存在未處理過的父類

/**
 * 解析單個配置類
 * 解析的最後會將當前配置類放到configurationClasses
 */
protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
    /**
     * 根據@Conditional條件判斷是否跳過配置類
     * 注意：當前這個PARSE_CONFIGURATION解析配置階段只會使用這個階段的@Conditional條件，有些REGISTER_BEAN註冊beanDefinition階段的條件不會在此時使用
     */
    if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
        return;
    }

    ConfigurationClass existingClass = this.configurationClasses.get(configClass);
    // 如果configClass在已經分析處理的配置類記錄中已存在
    if (existingClass != null) {
        //如果配置類是被@Import註冊的，return
        if (configClass.isImported()) {
            if (existingClass.isImported()) {
                existingClass.mergeImportedBy(configClass);
            }
            // Otherwise ignore new imported config class; existing non-imported class overrides it.
            return;
        }
        // 否則，清除老的記錄，在來一遍
        else {
            // Explicit bean definition found, probably replacing an import.
            // Let's remove the old one and go with the new one.
            this.configurationClasses.remove(configClass);
            this.knownSuperclasses.values().removeIf(configClass::equals);
        }
    }

    // Recursively process the configuration class and its superclass hierarchy.
    /**
     * 遞歸處理配置類及其超類層次結構
     * 從當前配置類configClass開始向上沿着類繼承結構逐層執行doProcessConfigurationClass，直到遇到的父類是由Java提供的類結束循環
     */
    SourceClass sourceClass = asSourceClass(configClass);
    /**
     * 循環處理配置類configClass直到sourceClass變為null，即父類為null
     * doProcessConfigurationClass的返回值是其參數configClass的父類
     * 如果該父類是由Java提供的類或者已經處理過，返回null
     */
    do {
        sourceClass = doProcessConfigurationClass(configClass, sourceClass);
    }
    while (sourceClass != null);

    this.configurationClasses.put(configClass, configClass);
}

ConfigurationClassParser#doProcessConfigurationClass()：真正解析配置類

通過解析配置類上的註解、內部成員類和方法構建一個完整的ConfigurationClass配置類，過程中如果發現了新的配置類可以重複調用此方法

真正解析過程中會處理成員內部類、@PropertySource、@ComponentScan、@Import、@ImportSource、@Bean方法等，流程如下：

• 1、處理配置類的成員內部類： 檢查其是否為“完全/簡化配置類”，是則對其繼續分析處理並將其放入分析器的屬性configurationClasses
• 2、處理@PropertySource： 將找到的PropertySource添加到environment的PropertySource集合
• 3、處理@ComponentScan： 掃描到的@Component類BeanDefinition就直接註冊到Spring容器；如果組件為配置類，繼續分析處理並將其放入分析器的屬性configurationClasses
• 4、處理@Import：
  • （1）處理ImportSelector： 如果是DeferredImportSelector，如SpringBoot的自動配置導入，添加到deferredImportSelectors，延遲進行processImports()；其它通過ImportSelector找到的類，繼續調用processImports()，要麼是@Configuration配置類繼續解析，要麼是普通組件導入Spring容器
  • （2）處理ImportBeanDefinitionRegistrar： 調用當前配置類的addImportBeanDefinitionRegistrar()，後面委託它註冊其它bean定義
  • （3）其它Import： 調用processConfigurationClass()繼續解析，最終要麼是配置類放入configurationClasses，要麼是普通組件導入Spring容器
• 5、處理@ImportResource： 添加到配置類的importedResources集合，後續ConfigurationClassBeanDefinitionReader#loadBeanDefinitions()時再使用這些導入的BeanDefinitionReader讀取Resource中的bean定義並註冊
• 6、處理@Bean： 獲取所有@Bean方法，並添加到配置類的beanMethods集合
• 7、處理配置類接口上的default methods
• 8、檢查是否有未處理的父類： 如果配置類有父類，且其不在解析器維護的knownSuperclasses中，對其調用doProcessConfigurationClass()重複如上檢查，直到不再有父類或父類在knownSuperclasses中已存在

/**
 * Apply processing and build a complete {@link ConfigurationClass} by reading the
 * annotations, members and methods from the source class. This method can be called
 * multiple times as relevant sources are discovered.
 * @param configClass the configuration class being build
 * @param sourceClass a source class
 * @return the superclass, or {@code null} if none found or previously processed
 */
@Nullable
protected final SourceClass doProcessConfigurationClass(ConfigurationClass configClass, SourceClass sourceClass)
        throws IOException {

    // Recursively process any member (nested) classes first
    /**
     * 1、處理配置類的成員類(配置類內嵌套定義的類)
     * 內部嵌套類也可能是配置類，遍歷這些成員類，檢查是否為"完全/簡化配置類"
     * 有的話，調用processConfigurationClass()處理它們，最終將配置類放入configurationClasses集合
     */
    processMemberClasses(configClass, sourceClass);

    // Process any @PropertySource annotations
    /**
     * 2、處理 @PropertySource
     * 將找到的PropertySource添加到environment的PropertySource集合
     */
    for (AnnotationAttributes propertySource : AnnotationConfigUtils.attributesForRepeatable(
            sourceClass.getMetadata(), PropertySources.class,
            org.springframework.context.annotation.PropertySource.class)) {
        if (this.environment instanceof ConfigurableEnvironment) {
            processPropertySource(propertySource);
        }
        else {
            logger.warn("Ignoring @PropertySource annotation on [" + sourceClass.getMetadata().getClassName() +
                    "]. Reason: Environment must implement ConfigurableEnvironment");
        }
    }

    // Process any @ComponentScan annotations
    /**
     * 3、處理 @ComponentScan
     * 處理用戶手工添加的@ComponentScan，SpringBoot創建ApplicationContext時的ClassPathBeanDefinitionScanner是為了掃描啟動類下的包
     * 為的是找到滿足條件的@ComponentScan，即@Component相關的組件，先掃描一下，掃描到的就註冊為BeanDefinition
     * 看其中是否還有配置類，有的話parse()繼續分析處理，配置類添加到configurationClasses集合
     */
    Set<AnnotationAttributes> componentScans = AnnotationConfigUtils.attributesForRepeatable(
            sourceClass.getMetadata(), ComponentScans.class, ComponentScan.class);
    // 如果當前配置類上有@ComponentScan，且使用REGISTER_BEAN註冊beanDefinition的條件判斷也不跳過的話
    if (!componentScans.isEmpty() &&
            !this.conditionEvaluator.shouldSkip(sourceClass.getMetadata(), ConfigurationPhase.REGISTER_BEAN)) {
        for (AnnotationAttributes componentScan : componentScans) {
            // The config class is annotated with @ComponentScan -> perform the scan immediately
            // 立即掃描，掃描到的就註冊為BeanDefinition，並獲得掃描到的所有beanDefinition
            // 在處理SpringBoot啟動類上的@ComponentScan時，雖然指指定了excludeFilters，但會根據啟動類所在包推測basePackage，就會掃描到SpringBoot啟動類包以下的Bean並註冊
            Set<BeanDefinitionHolder> scannedBeanDefinitions =
                    this.componentScanParser.parse(componentScan, sourceClass.getMetadata().getClassName());

            // Check the set of scanned definitions for any further config classes and parse recursively if needed
            // 檢查掃描到的beanDefinition中是否有配置類，有的話parse()繼續分析處理，，配置類添加到configurationClasses集合
            for (BeanDefinitionHolder holder : scannedBeanDefinitions) {
                BeanDefinition bdCand = holder.getBeanDefinition().getOriginatingBeanDefinition();
                if (bdCand == null) {
                    bdCand = holder.getBeanDefinition();
                }
                if (ConfigurationClassUtils.checkConfigurationClassCandidate(bdCand, this.metadataReaderFactory)) {
                    parse(bdCand.getBeanClassName(), holder.getBeanName());
                }
            }
        }
    }

    // Process any @Import annotations
    /**
     * 4、處理 @Import
     * (1)處理ImportSelector
     * 如果是DeferredImportSelector，如SpringBoot的自動配置導入，添加到deferredImportSelectors，延遲進行processImports()
     * 其它通過ImportSelector找到的類，繼續調用processImports()，要麼是@Configuration配置類繼續解析，要麼是普通組件導入Spring容器
     * (2)處理ImportBeanDefinitionRegistrar
     * 調用當前配置類的addImportBeanDefinitionRegistrar()，後面委託它註冊其它bean定義
     * (3)其它
     * 調用processConfigurationClass()繼續解析，最終要麼是配置類放入configurationClasses，要麼是普通組件導入Spring容器
     */
    processImports(configClass, sourceClass, getImports(sourceClass), true);

    // Process any @ImportResource annotations
    /**
     * 5、處理 @ImportResource
     * 添加到配置類的importedResources集合，後續loadBeanDefinitions()加載bean定義時再讓這些導入BeanDefinitionReader自行讀取bean定義
     */
    AnnotationAttributes importResource =
            AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
    if (importResource != null) {
        String[] resources = importResource.getStringArray("locations");
        Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
        for (String resource : resources) {
            String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
            configClass.addImportedResource(resolvedResource, readerClass);
        }
    }

    // Process individual @Bean methods
    /**
     * 6、處理個別@Bean方法
     * 獲取所有@Bean方法，並添加到配置類的beanMethods集合
     */
    Set<MethodMetadata> beanMethods = retrieveBeanMethodMetadata(sourceClass);
    for (MethodMetadata methodMetadata : beanMethods) {
        configClass.addBeanMethod(new BeanMethod(methodMetadata, configClass));
    }

    // Process default methods on interfaces
    /**
     * 7、處理配置類接口上的default methods
     */
    processInterfaces(configClass, sourceClass);

    // Process superclass, if any
    /**
     * 8、檢查父類是否需要處理，如果父類需要處理返回父類，否則返回null
     * 如果存在父類，且不在knownSuperclasses已經分析過的父類列表裡，返回並繼續分析
     */
    if (sourceClass.getMetadata().hasSuperClass()) {
        String superclass = sourceClass.getMetadata().getSuperClassName();
        if (superclass != null && !superclass.startsWith("java") &&
                !this.knownSuperclasses.containsKey(superclass)) {
            this.knownSuperclasses.put(superclass, configClass);
            // Superclass found, return its annotation metadata and recurse
            return sourceClass.getSuperClass();
        }
    }

    // No superclass -> processing is complete
    return null;
}

ConfigurationClassBeanDefinitionReader#loadBeanDefinitions()：讀取配置類，基於配置信息註冊BeanDefinition

讀取配置類，基於配置信息註冊BeanDefinition流程

在上面解析配置類的過程中，除了構建了一個完整的ConfigurationClass配置類，其實已經向BeanDefinitionRegistry中添加了一些beanDefinition了，比如在處理@ComponentScan時，掃描到的@Component相關組件就已經註冊了

而ConfigurationClassBeanDefinitionReader會繼續讀取已經構建好的ConfigurationClass配置類中的成員變量，從而註冊beanDefinition

構建好的ConfigurationClass配置類中在本階段可用的成員變量包括：

1. Set<BeanMethod> beanMethods： @Bean的方法
2. Map<String, Class<? extends BeanDefinitionReader>> importedResources：配置類上@ImportResource註解的類存入此集合，會使用BeanDefinitionReader讀取Resource中的BeanDefinition並註冊
3. Map<ImportBeanDefinitionRegistrar, AnnotationMetadata> importBeanDefinitionRegistrars：ImportBeanDefinitionRegistrar集合

通過構建好的配置類的配置信息，使用ConfigurationClassBeanDefinitionReader註冊所有能夠讀取到的beanDefinition：

• 根據ConfigurationPhase.REGISTER_BEAN階段條件判斷配置類是否需要跳過

  循環判斷配置類以及導入配置類的類，使用ConfigurationPhase.REGISTER_BEAN階段條件判斷是否需要跳過只要配置類或導入配置類的類需要跳過即返回跳過​

• 如果configClass.isImported()，將配置類自身註冊為beanDefinition

• 註冊配置類所有@Bean方法為beanDefinition

• 註冊由@ImportedResources來的beanDefinition，即通過其它類型Resource的BeanDefinitionReader讀取BeanDefinition並註冊，如xml格式的配置源 XmlBeanDefinitionReader

• 註冊由ImportBeanDefinitionRegistrars來的beanDefinition

讀取配置類，基於配置信息註冊BeanDefinition源碼分析

/**
 * Read a particular {@link ConfigurationClass}, registering bean definitions
 * for the class itself and all of its {@link Bean} methods.
 * 讀取特定配置類，根據配置信息註冊bean definitions
 */
private void loadBeanDefinitionsForConfigurationClass(
        ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {

    /**
     * 根據ConfigurationPhase.REGISTER_BEAN階段條件判斷配置類是否需要跳過
     * 循環判斷配置類以及導入配置類的類，使用ConfigurationPhase.REGISTER_BEAN階段條件判斷是否需要跳過
     * 只要配置類或導入配置類的類需要跳過即返回跳過
     */
    if (trackedConditionEvaluator.shouldSkip(configClass)) {
        String beanName = configClass.getBeanName();
        if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
            this.registry.removeBeanDefinition(beanName);
        }
        this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
        return;
    }

    // 1、如果當前配置類是通過內部類導入 或 @Import導入，將配置類自身註冊為beanDefinition
    if (configClass.isImported()) {
        registerBeanDefinitionForImportedConfigurationClass(configClass);
    }

    // 2、註冊配置類所有@Bean方法為beanDefinition
    for (BeanMethod beanMethod : configClass.getBeanMethods()) {
        loadBeanDefinitionsForBeanMethod(beanMethod);
    }

    // 3、註冊由@ImportedResources來的beanDefinition
    // 即通過其它類型Resource的BeanDefinitionReader讀取BeanDefinition並註冊
    loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());

    // 4、註冊由ImportBeanDefinitionRegistrars來的beanDefinition
    loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}

思維導圖

請放大觀看

參考

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

一、前言

1.核心技術

• Web Real-Time Communication：網頁即時通信，可以在瀏覽器進行實時語音或者視頻對話的API
• Canvas：HTML5中的新元素,可以用來來繪製圖形、圖標、以及其它任何視覺性圖像

2.音頻採集的基本概念

• 攝像頭：用於採集圖像和視頻
• 麥克風：採集音頻數據
• 幀率：一秒鐘採集圖像的次數。幀率越高，越平滑流暢
• 軌：借鑒了多媒體的概念，每條軌數據都是獨立的，如MP4中的音頻軌、視頻軌，是分別被存儲的
• 流：可以理解為容器。在WebRTC中，流可以分為媒體流（MediaStream）和數據流（DataStream）。
• 分辨率：2K、1080P、720P等，越清晰，佔用帶寬越多

3.音視頻設備的基本原理

• 音頻設備
  音頻輸入設備主要是採集音數據，而採集音頻數據的本質是模擬信號轉成数字信號，
  採集到的數據經過量化、編碼，最終開成数字信號，這就是音頻設備要完成的工作。
  人的聽覺範圍的頻率是20Hz~20kHz之間，日常語音交流8kHz就哆了。
  為了追求高品質、高保真，需要將音頻輸入設備採樣率設置在40kHz上才能完整保留原始信號

• 視頻設備
  當實物光通過鏡頭進行攝像機后，它會通過視頻設備的模數轉換（A/D）模塊，即光學傳感器，將光轉換成数字信號，即RGB數據，獲得RGB數據后，再通過DSP進行優化處理，如自動增強、白平衡、色彩飽和等，等到24位的真彩色圖片

模數轉換使用的採集定理稱為奈奎斯特定理：

在進行模擬 / 数字信號的轉換過程中，當採樣率大於信號中最高頻率的 2 倍時，採樣之後的数字信號就完整地保留原始信號中的信息。

talk is cheap, 上代碼，以下示例運行的時候會請求攝像頭權限，同意即可，接下來就是見證奇迹的時刻！

二、示例

1.示例1-打開攝像頭

這就是照像的核心功能，以後可以用來化妝，擠痘痘，整理髮型

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>打開攝像頭</title>
</head>
<body>
<h1>打開攝像頭</h1>
<video autoplay playsinline></video>
</body>
</html>

<script>
    const mediaStreamContrains = {
        video: {
            frameRate: {min: 20},
            width: {min: 640, ideal: 1280},
            height: {min: 360, ideal: 720},
            aspectRatio: 16 / 9
        },
        audio: {
            echoCancellation: true,
            noiseSuppression: true,
            autoGainControl: true
        }
    };

    const localVideo = document.querySelector('video');

    function gotLocalMediaStream(mediaStream) {
        localVideo.srcObject = mediaStream;
    }

    function handleLocalMediaStreamError(error) {
        console.log('navigator.getUserMedia error: ', error);
    }

    navigator.mediaDevices.getUserMedia(mediaStreamContrains).then(
        gotLocalMediaStream
    ).catch(
        handleLocalMediaStreamError
    );
</script>

運行結果如下

示例2-拍照保存

這裏展示了兩個按鈕，拍照和保存，yes，就是自拍的核心功能！

<html>
<head>
    <meta charset="UTF-8">
    <title>拍照一分鐘，P圖兩小時</title>
</head>

<body>
<section>
    <div>
        <video autoplay playsinline id="player"></video>
    </div>

</section>
<section>
    <div>
        <button id="snapshot">拍照</button>
        <button id="download">下載</button>
    </div>
    <div>
        <canvas id="picture"></canvas>
    </div>
</section>
</body>
</html>


<script>
    'use strict';

    var videoplay = document.querySelector('video#player');

    function gotMediaStream(stream) {
        window.stream = stream;
        videoplay.srcObject = stream;
    }

    function handleError(err) {
        console.log('getUserMedia error:', err);
    }

    function start() {
        var constraints = {
            video: {
                width: 1280,
                height: 720,
                frameRate: 15,
                facingMode: 'enviroment'
            },
            audio: false
        }

        navigator.mediaDevices.getUserMedia(constraints)
            .then(gotMediaStream)
            .catch(handleError);
    }


    //拍照
    var snapshot = document.querySelector('button#snapshot');
    snapshot.onclick = function () {
        var picture = document.querySelector('canvas#picture');
        picture.width = 1280;
        picture.height = 720;
        picture.getContext('2d').drawImage(videoplay, 0, 0, picture.width, picture.height);
    };


    //下載
    function downLoad(url) {
        var oA = document.createElement("a");
        oA.download = 'photo';// 設置下載的文件名，默認是'下載'
        oA.href = url;
        document.body.appendChild(oA);
        oA.click();
        oA.remove(); // 下載之後把創建的元素刪除
    }

    document.querySelector("button#download").onclick = function () {
        downLoad(picture.toDataURL("image/jpeg"));
    };

    start();

</script>

運行結果如下

就是這麼簡單！

重點方法和參數解釋

• 1.方法：avigator.mediaDevices.getUserMedia(constraints);
  返回一個promise對象，調用成功，可以通過promise對象獲取MediaStream對象，

• 2.參數：mediaStreamContrains
  傳入的constraints參數類型為 MediaStreamConstraints，可以指定 MediaStream 中包含哪些類型的媒體軌（音頻軌、視頻軌），並且可為這些媒體軌設置一些限制。

    視頻的幀率最小 20 幀每秒；
    寬度最小是 640，理想的寬度是 1280；
    高度最小是 360，最理想高度是 720；
    寬高比是 16:9；
    對於音頻則是開啟迴音消除、降噪以及自動增益功能。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

2019 年台灣電動機車市場百家爭鳴，也帶動市場熱度，越來越多消費者願意選擇電動機車。電動機車大廠 Gogoro 宣布旗下總掛牌數正式達 20 萬輛，寫下新的里程碑。

根據工研院產科國際所推估，台灣電動機車年銷量可以突破 15 萬輛，成長速度超過全球平均。2019 年夏季包括 Gogoro、光陽（Kymco）、山葉（YAMAHA）、中華汽車 eMOVING 和宏佳騰等品牌都推出新的電動機車，代表車廠也清楚了解市場對電動機車的需求。

受惠於暑假旺季提前發酵，加上受到新車效應與即將到來的開學季影響，Gogoro 從 2019 年 5 月以來已連續 4 個月單月掛牌數破萬，這也讓 Gogoro 總掛牌數正式達到 20 萬輛。在全新發表的 Gogoro S2 ABS 車款助攻之下，讓 Gogoro 在 8 月單月掛牌市占率達 16.35%，即使 8 月整體機車市場下滑 20%，仍然保持穩定成長。

Gogoro 資深行銷總監陳彥揚表示：「今年夏天對 Gogoro 來說深具意義，連續 4 個月掛牌破萬，帶動 Gogoro 總車主數超越 20 萬大關，除了非常感謝車主的熱情支持，業界的投入及政府政策的推動，也是電動機車產業發展向前邁進的關鍵要素，期盼能快速跟上全球化電動車趨勢的腳步。」

每年最具代表性的車主活動「快閃台北橋」將於 9 月 29 日舉辦，2018 年活動以 1,303 台機車創下「世界最大規模電動機車遊行」的金氏世界紀錄，Gogoro 也將擴大邀請所有電動機車車主，今年活動時集結台北橋。

8 月推出的「暢快騎 0 元起」購車方案廣受歡迎，Gogoro 為了慶祝車主數量突破 20 萬大關，宣布活動時間將延長至 9 月 30 日，購買 Gogoro 全車系即贈送 6 個月電池服務資費 299 元，無論選擇什麼方案每個月都可抵扣電池資費 299 元。即日起至 9 月 30 日購買 Gogoro 全車系並符合學生資格的車主，即可享有 12 期 0 利率分期優惠，同時再送「1 年期車碰車險」。

（合作媒體：。首圖來源：Gogoro）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※公開收購3c價格,不怕被賤賣!

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置，台北網頁設計，各種案例分享

本博客系列是學習併發編程過程中的記錄總結。由於文章比較多，寫的時間也比較散，所以我整理了個目錄貼（傳送門），方便查閱。

併發和并行

在真正開始聊本文的主題之前，我們先來回顧下兩個老生常談的概念：併發和并行。

• 併發：是指多個線程任務在同一個CPU上快速地輪換執行，由於切換的速度非常快，給人的感覺就是這些線程任務是在同時進行的，但其實併發只是一種邏輯上的同時進行；
• 并行：是指多個線程任務在不同CPU上同時進行，是真正意義上的同時執行。

下面貼上一張圖來解釋下這兩個概念：

上圖中的咖啡就可以看成是CPU，上面的只有一個咖啡機，相當於只有一個CPU。想喝咖啡的人只有等前面的人製作完咖啡才能製作自己的開發，也就是同一時間只能有一個人在製作咖啡，這是一種併發模式。下面的圖中有兩個咖啡機，相當於有兩個CPU，同一時刻可以有兩個人同時製作咖啡，是一種并行模式。

我們發現并行編程中，很重要的一個特點是系統具有多核CPU。要是系統是單核的，也就談不上什麼并行編程了。那麼是什麼原因導致了現代CPU架構都是多核架構？如果CPU架構都是單核的架構我們是不是就能不要研究什麼并行編程了？

“摩爾定律”失效

上面章節中留下了一個問題：為什麼現代CPU都是多核架構。為了回答這個問題，我們先來了解一個定律–摩爾定律。

1965年，英特爾聯合創始人戈登·摩爾提出以自己名字命名的「摩爾定律」，意指集成電路上可容納的元器件的數量每隔 18 至 24 個月就會增加一倍，性能也將提升一倍。

根據摩爾定律，CPU的性能每隔18到24個月就能增長一倍。但是從現在的情況來看，單核CPU的主頻已經逼近了極限，以現在的製造工藝，很難再繼續提升單核CPU的主頻。也就是說摩爾定律已經失效。

雖然摩爾定律失效了，但是科技的進度對CPU性能的需求沒有停止。這個也難不倒我們偉大的硬件工程師。一個CPU的性能提升有限，我將兩個CPU拼在一起性能不就提升一倍了么。於是多核CPU的架構就出現了。

提高CPU工作主頻主要受到生產工藝的限制。由於CPU是在半導體硅片上製造的，在硅片上的元件之間需要導線進行聯接，由於在高頻狀態下要求導線越細越短越好，這樣才能減小導線分佈電容等雜散干擾以保證CPU運算正確。因此製造工藝的限制，是CPU主頻發展的最大障礙之一。

多核架構引發并行編程

為了繼續保持性能的高速發展，硬件工程師破天荒地想出了將多個CPU內核塞進一個CPU里的奇妙想法。由此，并行計算就被非常自然地推廣開來，隨之而來的問題也層出不窮，程序員的黑暗時期也隨之到來。簡化的硬件設計方案必然帶來軟件設計的複雜性。換句話說，軟件工程師正在為硬件工程師無法完成的工作負責，他們將摩爾定律失效的責任推給了軟件開發者。

所以，如何讓多個CPU有效並且正確地工作也就成了一門技術，甚至是很大的學問。比如，多線程間如何保證線程安全，如何正確理解線程間的無序性、可見性，如何盡可能地設計并行程序，如何將串行程序改造為并行程序。而對并行計算的研究，也就是希望給這片黑暗帶來光明。

總結

世界就是這樣一個矛盾體，併發編程能讓我們充分地利用CPU資源，提升系統性能。但是同時也給我們帶來了很多問題，比如線程上下文切換對性能消耗的問題、共享變量的線程安全問題、線程死鎖問題和線程間通信等問題。研究并行編程就是研究怎麼在享受多線程編程給我們帶來便利的同時又能規避多線程帶來的坑。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※高價收購3C產品,價格不怕你比較

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※3c收購,鏡頭 收購有可能以全新價回收嗎?

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!