分類
發燒車訊

.NET高級特性-Emit(2)類的定義,.NET高級特性-Emit(1)

  在上一篇博文發了一天左右的時間,就收到了博客園許多讀者的評論和推薦,非常感謝,我也會及時回復讀者的評論。之後我也將繼續撰寫博文,梳理相關.NET的知識,希望.NET的圈子能越來越大,開發者能了解/深入.NET的本質,將工作做的簡單又高效,拒絕重複勞動,拒絕CRUD。

  ok,咱們開始繼續Emit的探索。在這之前,我先放一下我往期關於Emit的文章,方便讀者閱讀。

  《》

一、基礎知識

  既然C#作為一門面向對象的語言,所以首當其沖的我們需要讓Emit為我們動態構建類。

  廢話不多說,首先,我們先來回顧一下C#類的內部由什麼東西組成:

  (1) 字段-C#類中保存數據的地方,由訪問修飾符、類型和名稱組成;

  (2) 屬性-C#類中特有的東西,由訪問修飾符、類型、名稱和get/set訪問器組成,屬性的是用來控制類中字段數據的訪問,以實現類的封裝性;在Java當中寫作getXXX()和setXXX(val),C#當中將其變成了屬性這種語法糖;

  (3) 方法-C#類中對邏輯進行操作的基本單元,由訪問修飾符、方法名、泛型參數、入參、出參構成;

  (4) 構造器-C#類中一種特殊的方法,該方法是專門用來創建對象的方法,由訪問修飾符、與類名相同的方法名、入參構成。

  接着,我們再觀察C#類本身又具備哪些東西:

  (1) 訪問修飾符-實現對C#類的訪問控制

  (2) 繼承-C#類可以繼承一個父類,並需要實現父類當中所有抽象的方法以及選擇實現父類的虛方法,還有就是子類需要調用父類的構造器以實現對象的創建

  (3) 實現-C#類可以實現多個接口,並實現接口中的所有方法

  (4) 泛型-C#類可以包含泛型參數,此外,類還可以對泛型實現約束

  以上就是C#類所具備的一些元素,以下為樣例:

public abstract class Bar
{
    public abstract void PrintName();
}
public interface IFoo<T> { public T Name { get; set; } } //繼承Bar基類,實現IFoo接口,泛型參數T
public class Foo<T> : Bar, IFoo<T>
  //泛型約束
  where T : struct {
//構造器 public Foo(T name):base() { _name = name; } //字段 private T _name; //屬性 public T Name { get => _name; set => _name = value; } //方法 public override void PrintName() {
    Console.WriteLine(_name.ToString()); }
}

  在探索完了C#類及其定義后,我們要來了解C#的項目結構組成。我們知道C#的一個csproj項目最終會對應生成一個dll文件或者exe文件,這一個文件我們稱之為程序集Assembly;而在一個程序集中,我們內部包含和定義了許多命名空間,這些命令空間在C#當中被稱為模塊Module,而模塊正是由一個一個的C#類Type組成。

 

 

 

   所以,當我們需要定義C#類時,就必須首先定義Assembly以及Module,如此才能進行下一步工作。

二、IL概覽

   由於Emit實質是通過IL來生成C#代碼,故我們可以反向生成,先將寫好的目標代碼寫成cs文件,通過編譯器生成dll,再通過ildasm查看IL代碼,即可依葫蘆畫瓢的編寫出Emit代碼。所以我們來查看以下上節Foo所生成的IL代碼。

  

 

 

   從上圖我們可以很清晰的看到.NET的層級結構,位於樹頂層淺藍色圓點表示一個程序集Assembly,第二層藍色表示模塊Module,在模塊下的均為我們所定義的類,類中包含類的泛型參數、繼承類信息、實現接口信息,類的內部包含構造器、方法、字段、屬性以及它的get/set方法,由此,我們可以開始編寫Emit代碼了

三、Emit編寫

  有了以上的對C#類的解讀和IL的解讀,我們知道了C#類本身所需要哪些元素,我們就開始根據這些元素來開始編寫Emit代碼了。這裏的代碼量會比較大,請讀者慢慢閱讀,也可以參照以上我寫的類生成il代碼進行比對。

  在Emit當中所有創建類型的幫助類均以Builder結尾,從下錶中我們可以看的非常清楚

元素中文 元素名稱 對應Emit構建器名稱
程序集  Assembly AssemblyBuilder
模塊  Module ModuleBuilder
 Type TypeBuilder
構造器  Constructor ConstructorBuilder
屬性  Property PropertyBuilder
字段  Field FieldBuilder
方法  Method MethodBuilder

  由於創建類需要從Assembly開始創建,所以我們的入口是AssemblyBuilder

  (1) 首先,我們先引入命名空間,我們以上節Foo類為樣例進行編寫

using System.Reflection.Emit;

  (2) 獲取基類和接口的類型

var barType = typeof(Bar);
var interfaceType = typeof(IFoo<>);

  (3) 定義Foo類型,我們可以看到在定義類之前我們需要創建Assembly和Module

//定義類
var assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName("Edwin.Blog.Emit"), AssemblyBuilderAccess.Run);
var moduleBuilder = assemblyBuilder.DefineDynamicModule("Edwin.Blog.Emit");
var typeBuilder = moduleBuilder.DefineType("Foo", TypeAttributes.Public | TypeAttributes.Class | TypeAttributes.AutoClass | TypeAttributes.AnsiClass | TypeAttributes.BeforeFieldInit);

  (4) 定義泛型參數T,並添加約束

//定義泛型參數
var genericTypeBuilder = typeBuilder.DefineGenericParameters("T")[0];
//設置泛型約束
genericTypeBuilder.SetGenericParameterAttributes(GenericParameterAttributes.NotNullableValueTypeConstraint);

  (5) 繼承和實現接口,注意當實現類的泛型參數需傳遞給接口時,需要將泛型接口添加泛型參數后再調用AddInterfaceImplementation方法

//繼承基類
typeBuilder.SetParent(barType);
//實現接口
typeBuilder.AddInterfaceImplementation(interfaceType.MakeGenericType(genericTypeBuilder));

  (6) 定義字段,因為字段在構造器值需要使用,故先創建

//定義字段
var fieldBuilder = typeBuilder.DefineField("_name", genericTypeBuilder, FieldAttributes.Private);

  (7) 定義構造器,並編寫內部邏輯

//定義構造器
var ctorBuilder = typeBuilder.DefineConstructor(MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.SpecialName | MethodAttributes.RTSpecialName, CallingConventions.Standard, new Type[] { genericTypeBuilder });
var ctorIL = ctorBuilder.GetILGenerator();
//Ldarg_0在實例方法中表示this,在靜態方法中表示第一個參數
ctorIL.Emit(OpCodes.Ldarg_0);
ctorIL.Emit(OpCodes.Ldarg_1);
//為field賦值
ctorIL.Emit(OpCodes.Stfld, fieldBuilder);
ctorIL.Emit(OpCodes.Ret);

  (8) 定義Name屬性

//定義屬性
var propertyBuilder = typeBuilder.DefineProperty("Name", PropertyAttributes.None, genericTypeBuilder, Type.EmptyTypes);

  (9) 編寫Name屬性的get/set訪問器

//定義get方法
var getMethodBuilder = typeBuilder.DefineMethod("get_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, genericTypeBuilder, Type.EmptyTypes);
var getIL = getMethodBuilder.GetILGenerator();
getIL.Emit(OpCodes.Ldarg_0);
getIL.Emit(OpCodes.Ldfld, fieldBuilder);
getIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(getMethodBuilder, interfaceType.GetProperty("Name").GetGetMethod()); //實現對接口方法的重載
propertyBuilder.SetGetMethod(getMethodBuilder); //設置為屬性的get方法
//定義set方法
var setMethodBuilder = typeBuilder.DefineMethod("set_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, null, new Type[] { genericTypeBuilder });
var setIL = setMethodBuilder.GetILGenerator();
setIL.Emit(OpCodes.Ldarg_0);
setIL.Emit(OpCodes.Ldarg_1);
setIL.Emit(OpCodes.Stfld, fieldBuilder);
setIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(setMethodBuilder, interfaceType.GetProperty("Name").GetSetMethod()); //實現對接口方法的重載
propertyBuilder.SetSetMethod(setMethodBuilder); //設置為屬性的set方法

   (10) 定義並實現PrintName方法

//定義方法
var printMethodBuilder = typeBuilder.DefineMethod("PrintName", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.Virtual, CallingConventions.Standard, null, Type.EmptyTypes);
var printIL = printMethodBuilder.GetILGenerator();
printIL.Emit(OpCodes.Ldarg_0);
printIL.Emit(OpCodes.Ldflda, fieldBuilder);
printIL.Emit(OpCodes.Constrained, genericTypeBuilder);
printIL.Emit(OpCodes.Callvirt, typeof(object).GetMethod("ToString", Type.EmptyTypes));
printIL.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new Type[] { typeof(string) }));
printIL.Emit(OpCodes.Ret);
//實現對基類方法的重載
typeBuilder.DefineMethodOverride(printMethodBuilder, barType.GetMethod("PrintName", Type.EmptyTypes));

  (11) 創建類

var type = typeBuilder.CreateType(); //netstandard中請使用CreateTypeInfo().AsType()

  (12) 調用

var obj = Activator.CreateInstance(type.MakeGenericType(typeof(DateTime)), DateTime.Now);
(obj as Bar).PrintName();
Console.WriteLine((obj as IFoo<DateTime>).Name);

四、應用

  上面的樣例僅供學習只用,無法運用在實際項目當中,那麼,Emit構建類在實際項目中我們可以有什麼應用,提高我們的編碼效率

  (1) 動態DTO-當我們需要將實體映射到某個DTO時,可以用動態DTO來代替你手寫的DTO,選擇你需要的字段回傳給前端,或者前端把他想要的字段傳給後端

  (2) DynamicLinq-我的第一篇博文有個讀者提到了表達式樹,而linq使用的正是表達式樹,當表達式樹+Emit時,我們就可以用像SQL或者GraphQL那樣的查詢語句實現動態查詢

  (3) 對象合併-我們可以編寫實現一個像js當中Object.assign()一樣的方法,實現對兩個實體的合併

  (4) AOP動態代理-AOP的核心就是代理模式,但是與其對應的是需要手寫代理類,而Emit就可以幫你動態創建代理類,實現切面編程

  (5) …

五、小結

  對於Emit,確實初學者會對其感到複雜和難以學習,但是只要搞懂其中的原理,其實最終就是C#和.NET語言的本質所在,在學習Emit的同時,也是在鍛煉你的基本功是否紮實,你是否對這門語言精通,是否有各種簡化代碼的應用。

  保持學習,勇於實踐;Write Less,Do More;作者之後還會繼續.NET高級特性系列,感謝閱讀!

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

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

分類
發燒車訊

Java虛擬機詳解(十)——類加載過程

  在上一篇文章中,我們詳細的介紹了Java,那麼這些Class文件是如何被加載到內存,由虛擬機來直接使用的呢?這就是本篇博客將要介紹的——類加載過程。

1、類的生命周期

  類從被加載到虛擬機內存開始,到卸載出內存為止,其聲明周期流程如下:

  

  上圖中紅色的5個部分(加載、驗證、準備、初始化、卸載)順序是確定的,也就是說,類的加載過程必須按照這種順序按部就班的開始。這裏的“開始”不是按部就班的“進行”或者“完成”,因為這些階段通常是互相交叉混合的進行的,通常會在一個階段執行過程中調用另一個階段。

2、加載

  “加載”階段是“類加載”生命周期的第一個階段。在加載階段,虛擬機要完成下面三件事:

  ①、通過一個類的全限定名來獲取定義此類的二進制字節流。

  ②、將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

  ③、在Java堆中生成一個代表這個類的java.lang.Class對象,作為方法區這些數據的訪問入口。

  PS:類的全限定名可以理解為這個類存放的絕對路徑。方法區是JDK1.7以前定義的運行時數據區,而在JDK1.8以後改為元數據區(Metaspace),主要用於存放被Java虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。詳情可以參考這邊該系列的第二篇文章——。

  另外,我們看第一點——通過類的權限定名來獲取定義此類的二進制流,這裏並沒有明確指明要從哪裡獲取以及怎樣獲取,也就是說並沒有明確規定一定要我們從一個 Class 文件中獲取。基於此,在Java的發展過程中,充滿創造力的開發人員在這個舞台上玩出了各種花樣:

  1、從 ZIP 包中讀取。這稱為後面的 JAR、EAR、WAR 格式的基礎。

  2、從網絡中獲取。比較典型的應用就是 Applet。

  3、運行時計算生成。這就是動態代理技術。

  4、由其它文件生成。比如 JSP 應用。

  5、從數據庫中讀取。

  加載階段完成后,虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區中,然後在Java堆中實例化一個 java.lang.Class 類的對象,這個對象將作為程序訪問方法區中這些類型數據的外部接口。

  注意,加載階段與連接階段的部分內容(如一部分字節碼文件的格式校驗)是交叉進行的,加載階段尚未完成,連接階段可能已經開始了。

3、驗證

  驗證是連接階段的第一步,作用是為了確保 Class 文件的字節流中包含的信息符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。

  我們說Java語言本身是相對安全,因為編譯器的存在,純粹的Java代碼要訪問數組邊界外的數據、跳轉到不存在的代碼行之類的,是要被編譯器拒絕的。但是前面我們也說過,Class 文件不一定非要從Java源碼編譯過來,可以使用任何途徑,包括你很牛逼,直接用十六進制編輯器來編寫 Class 文件。

  所以,如果虛擬機不檢查輸入的字節流,將會載入有害的字節流而導致系統崩潰。但是虛擬機規範對於檢查哪些方面,何時檢查,怎麼檢查都沒有明確的規定,不同的虛擬機實現方式可能都會有所不同,但是大致都會完成下面四個方面的檢查。

①、文件格式驗證

  校驗字節流是否符合Class文件格式的規範,並且能夠被當前版本的虛擬機處理。

  一、是否以魔數 0xCAFEBABE 開頭。

  二、主、次版本號是否是當前虛擬機處理範圍之內。

  三、常量池的常量中是否有不被支持的常量類型(檢查常量tag標誌)

  四、指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。

  五、CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 編碼的數據。

  六、Class 文件中各個部分及文件本身是否有被刪除的或附加的其他信息。

  以上是一部分校驗內容,當然遠不止這些。經過這些校驗后,字節流才會進入內存的方法區中存儲,接下來後面的三個階段校驗都是基於方法區的存儲結構進行的。

②、元數據驗證

  第二個階段主要是對字節碼描述的信息進行語義分析,以保證其描述的信息符合Java語言規範要求。

  一、這個類是否有父類(除了java.lang.Object 類之外,所有的類都應當有父類)。

  二、這個類的父類是否繼承了不允許被繼承的類(被final修飾的類)。

  三、如果這個類不是抽象類,是否實現了其父類或接口之中要求實現的所有普通方法。

  四、類中的字段、方法是否與父類產生了矛盾(例如覆蓋了父類的final字段、或者出現不符合規則的重載)

③、字節碼驗證

  第三個階段字節碼驗證是整個驗證階段中最複雜的,主要是進行數據流和控制流分析。該階段將對類的方法進行分析,保證被校驗的方法在運行時不會做出危害虛擬機安全的行為。

  一、保證任意時刻操作數棧中的數據類型與指令代碼序列都能配合工作。例如不會出現在操作數棧中放置了一個 int 類型的數據,使用時卻按照 long 類型來加載到本地變量表中。

  二、保證跳轉指令不會跳轉到方法體以外的字節碼指令中。

  三、保證方法體中的類型轉換是有效的。比如把一個子類對象賦值給父類數據類型,這是安全的。但是把父類對象賦值給子類數據類型,甚至賦值給完全不相干的類型,這就是不合法的。

④、符號引用驗證

  符號引用驗證主要是對類自身以外(常量池中的各種符號引用)的信息進行匹配性的校驗,通常需要校驗如下內容:

  一、符號引用中通過字符串描述的全限定名是否能夠找到相應的類。

  二、在指定類中是否存在符合方法的字段描述符及簡單名稱所描述的方法和字段。

  三、符號引用中的類、字段和方法的訪問性(private、protected、public、default)是否可以被當前類訪問。

4、準備

  準備階段是正式為類變量分配內存並設置類變量初始值的階段,這些內存是在方法區中進行分配。

  注意:

  一、上面說的是類變量,也就是被 static 修飾的變量,不包括實例變量。實例變量會在對象實例化時隨着對象一起分配在堆中。

  二、初始值,指的是一些數據類型的默認值。基本的數據類型初始值如下(引用類型的初始值為null):

  

 

   比如,定義 public static int value = 123 。那麼在準備階段過後,value 的值是 0 而不是 123,把 value 賦值為123 是在程序被編譯后,存放在類的構造器方法之中,是在初始化階段才會被執行。但是有一種特殊情況,通過final 修飾的屬性,比如 定義 public final static int value = 123,那麼在準備階段過後,value 就被賦值為123了。

5、解析

  解析階段是虛擬機將常量池中的符號引用替換為直接引用的過程。

  符號引用(Symbolic References):符號引用以一組符號來描述所引用的目標,符號可以是任何形式的字面量,只要使用時能無歧義的定位到目標即可。符號引用與虛擬機實現的內存布局無關,引用的目標不一定已經加載到內存中。

  直接引用(Direct References):直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用是與虛擬機實現內存布局相關的,同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同。如果有了直接引用,那麼引用的目標必定已經在內存中存在。

  解析動作主要針對類或接口、字段、類方法、接口方法四類符號引用,分別對應於常量池的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANTS_InterfaceMethodref_info四種類型常量。

6、初始化

   初始化階段是類加載階段的最後一步,前面過程中,除第一個加載階段可以通過用戶自定義類加載器參与之外,其餘過程都是完全由虛擬機主導和控制。而到了初始化階段,則開始真正執行類中定義的Java程序代碼(或者說是字節碼)。

  在前面介紹的準備階段中,類變量已經被賦值過初始值了,而初始化階段,則根據程序員的編碼去初始化變量和資源。

  換句話來說,初始化階段是執行類構造器<clinit>() 方法的過程

  ①、<clinit>() 方法 是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊(static{})中的語句合併產生的,編譯器收集的順序是由語句在源文件中出現的順序所決定的,靜態語句塊中只能訪問到定義在靜態語句塊之前的變量,定義在它之後的變量,在前面的靜態語句塊中可以賦值,但是不能訪問。

  比如如下代碼會報錯:

  

 

   但是你把第 14 行代碼放到 static 靜態代碼塊的上面就不會報錯了。或者不改變代碼順序,將第 11 行代碼移除,也不會報錯。

  ②、<clinit>() 方法與類的構造函數(或者說是實例構造器<init>()方法)不同,它不需要显示的調用父類構造器,虛擬機會保證在子類的<init>()方法執行之前,父類的<init>()方法已經執行完畢。因此虛擬機中第一個被執行的<init>()方法的類肯定是 java.lang.Object。

  ③、由於父類的<clinit>() 方法先執行,所以父類中定義的靜態語句塊要優先於子類的變量賦值操作。

  ④、<clinit>() 方法對於接口來說並不是必須的,如果一個類中沒有靜態語句塊,也沒有對變量的賦值操作,那麼編譯器可以不為這個類生成<clinit>() 方法。

  ⑤、接口中不能使用靜態語句塊,但仍然有變量初始化的賦值操作,因此接口與類一樣都會生成<clinit>() 方法。但接口與類不同的是,執行接口中的<clinit>() 方法不需要先執行父接口的<clinit>() 方法。只有當父接口中定義的變量被使用時,父接口才會被初始化。

  ⑥、接口的實現類在初始化時也一樣不會執行接口的<clinit>() 方法。

  ⑦、虛擬機會保證一個類的<clinit>() 方法在多線程環境中被正確的加鎖和同步。如果多個線程同時去初始化一個類,那麼只會有一個線程去執行這個類的<clinit>() 方法,其他的線程都需要阻塞等待,直到活動線程執行<clinit>() 方法完畢。如果在一個類的<clinit>() 方法中有很耗時的操作,那麼可能造成多個進程的阻塞。

  比如對於如下代碼:

package com.yb.carton.controller;

/**
 * Create by YSOcean
 */
public class ClassLoadInitTest {


    static class Hello{
        static {
            if(true){
                System.out.println(Thread.currentThread().getName() + "init");
                while(true){}
            }
        }
    }

    public static void main(String[] args) {
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h1 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();


        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h2 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();
    }

}

View Code

  運行結果如下:

  

 

   線程1搶到了執行<clinit>() 方法,但是該方法是一個死循環,線程2將一直阻塞等待。

  知道了類的初始化過程,那麼類的初始化何時被觸發呢?JVM大概規定了如下幾種情況:

  ①、當虛擬機啟動時,初始化用戶指定的類。

  ②、當遇到用以新建目標類實例的 new 指令時,初始化 new 指定的目標類。

  ③、當遇到調用靜態方法的指令時,初始化該靜態方法所在的類。

  ④、當遇到訪問靜態字段的指令時,初始化該靜態字段所在的類。

  ⑤、子類的初始化會觸發父類的初始化。

  ⑥、如果一個接口定義了 default 方法,那麼直接實現或間接實現該接口的類的初始化,會觸發該接口的初始化。

  ⑦、使用反射 API 對某個類進行反射調用時,會初始化這個類。

  ⑧、當初次調用 MethodHandle 實例時,初始化該 MethodHandle 指向的方法所在的類。

 

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

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

搶攻 EV 需求,三菱化學傳倍增美國鋰電池關鍵材料產能

日刊工業新聞 3 日報導,為了搶攻電動車(EV)需求,三菱化學(Mitsubishi Chemical)將擴增鋰離子電池關鍵材料「電解液」產能,計畫於 2019 年度內(2020 年 3 月底前)將美國工廠(位於田納西州曼非斯)電解液年產能提高至 2 萬噸、將達現行的 2 倍水準。

三菱化學計畫於 2020 年度結束前(2021 年 3 月底前)將電解液全球年產能提高至 8.5 萬噸、將較 2017 年度大增 95%,且計畫將另一項鋰電池關鍵材料「負極材」全球年產能提高至 2.9 萬噸(將較 2017 年度增加 61%),目標在 2020 年度將電池材料等新能源部門營收提高至 1,000 億日圓、2025 年度進一步倍增至 2,000 億日圓的規模。

三菱化學 2018 年 12 月 26 日宣布,日本國內外電動車、插電式油電混合車(PHV)、油電混合車(HV)市場呈現急速擴大,因此將擴增日本「電解液」產能,計畫將四日市事業所的電解液年產能自現行的 1.1 萬噸大幅擴產約 5 成至 1.6 萬噸。

日韓企業紛紛擴增鋰離子電池關鍵材料產能

旭化成(Asahi Kasei)3 月 14 日宣布,因鋰離子電池以電動車等車用需求為中心呈現急速增長,故決議投資 300 億日圓對位於日本滋賀縣守山市的守山製造所、以及位於北卡羅萊納州的美國工廠進行增產投資,增產鋰離子電池關鍵材料「分隔膜」,上述增產工程預計於 2021 年度上半年開始商轉,預估 2021 年度旭化成分隔膜全球年產能將擴增至約 15.5 億平方公尺、將較 2018 年度末提高 1 倍。

住友化學(Sumitomo Chemical)日前也傳出將階段性提高南韓工廠產能,目標在 2021 年度將分隔膜總年產能(合併日本工廠產能計算)提高至 6 億平方公尺、將達現行的近 2 倍水準。

全球第 2 大鋰離子電池關鍵材料「分隔膜」廠商南韓 SK Innovation 5 月 27 日表示,計畫在 2025 年結束前將分隔膜產能提高至現行的 5 倍,SK Innovation 社長金俊 27 日在首爾舉行的記者會上表示,「目標藉由大規模增產、搶當全球龍頭」。在全球分隔膜市場上,日本旭化成市佔約 2 成、位居首位,SK Innovation 市佔率超過 1 成居次。

日本民間調查機構矢野經濟研究所公布調查報告指出,因中國自 2019 年起開始實施新能源車規範,加上 2019-2020 年期間日歐車廠將進行車輛電動化,提振車用鋰離子電池材料需求今後將持續擴大,預估 2020 年全球 4 大關鍵材料(正極材、負極材、電解液和分隔膜)市場規模(廠商出貨金額)將擴增至 281.46 億美元、將較 2017 年暴增 9 成(增加 91.3%)。

(本文內容由 授權使用。首圖來源:)

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

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

Chrome OS 80 將可以直接構建 Android 應用

  在近期 Android Dev Summit 上,Chrome OS 團隊宣布 Chrome OS 80 將使 Chromebook 可以直接構建 Android 應用。

  這項特性其實是在 Chrome OS 中引入 Android 應用側加載(sideloading),該功能的具體介紹來自一個非公開 bug 記錄以及相應的代碼更改,根據該記錄,Android 應用的側加載被帶到了 Chromebook 上的 Android 容器中。

  根據內部文件,具體開發時的操作是啟動 Crostini 容器時需要一個特殊命令(從 Chromebook 的命令行啟動 Linux 時),需要添加–enable-features = ArcAdbSideloading

  目前開發人員必須通過 USB 線將 Android 設備連接到 Chromebook,然後將其應用推送到設備上進行測試或使用 Chrome OS 開發人員模式,才能構建 Android 應用,但這兩種都不是理想的選擇。

  這項新特性對於使用 Android Studio 在 Chromebook 上構建其應用的 Android 開發人員來說,是極其方便的功能。具體來看,Chrome OS 80 將為 Android 開發人員添加選項,這樣可以直接在 Chrome OS 設備上安裝和測試其應用。

  消息來源:

  https://www.aboutchromebooks.com/news/chrome-os-80-to-bring-arc-sideloading-of-android-apps-to-chromebooks

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

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

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

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

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

分類
發燒車訊

中國AI獨角獸完成全球競賽三連冠偉業:孫劍帶隊,曠視再刷榜

  邊策 郭一璞 發自 凹非寺
  量子位 報道 公眾號 QbitAI

  全球 AI 競賽再奪 3 項世界第一,實現 COCO 重頭戲“物體檢測”三連冠。

  新歷史、新紀錄,榮耀屬於中國公司,展示的統治力堪比乒乓球。

  這就是 AI 獨角獸曠視科技,剛剛從全球 AI 頂會 ICCV 2019 傳來的捷報。

  而且 IPO 上市當前,無疑是既有實力的繼續展示。

  全球 AI 競賽再奪 3 項第一

  ICCV,國際計算機視覺大會,英文全稱 International Conference on Computer Vision。

  被譽為計算機視覺領域三大頂級會議之一,與 CVPR 和 ECCV 並列。

  ICCV 兩年舉辦一次,今年 10 月 27 日在韓國首爾開幕。

  不過剛剛開幕,中國力量就捷報頻傳,繼續展現在全球 AI 研發領域的潛力和實力。

  特別是在本屆 ICCV 的 COCO 挑戰賽上,曠視再度問鼎,拿下 COCO 物體檢測(Detection)、人體關鍵點(Keypoint)和全景分割(Panoptic)3 項第一。

  繼 2017、2018 年後再度奪冠,更是在最重要的“物體檢測”完成三連冠偉業,自 2015 年 COCO 開賽以來,前無古人,創下新紀錄。

  此外,曠視還獲得今年新設立的 COCO+Mapillary 挑戰賽的最佳論文獎(Best Paper Award),原因是“最具創新性的算法”。

  COCO 是 ICCV 2019 的重頭戲,也是 AI 視覺領域最具影響力的通用物體檢測挑戰賽。

  今年的 COCO 挑戰賽與往年不同,加入了新的規則:

首先、參加者必須提交一份技術報告,該報告將替代先前要求的簡短描述。只有與報告一起提交的材料才會被考慮參賽,並被放入 COCO 排行榜中。

其次,今年的每個挑戰賽都將設立兩個不同的獎項:最佳結果獎和最具創新獎。最具創新獎根據根據參賽作品的創新而非最佳成績來評定,最終由 COCO 獎項委員會決定,獲獎團隊將受邀參加 Workshop。

最後,今年的大會針對所有挑戰提供最具創新性和成功解決方案的最佳論文獎。獲獎者將由研討會組委會確定。

  物體檢測任務是讓算法輸出邊界框輸出或實例分割,自動駕駛、醫療影像識別中都會用到。另外在 2019 年的挑戰賽中,只有具有目標分割輸出的檢測任務會被重點介紹。

  COCO 全景分割任務目的是生成豐富而完整的連貫場景分割,這是自動駕駛或增強現實等實際應用的中一項重要技術。

  人體關鍵點檢測是在不提供人位置的情況下,定位並返回人體各部位關鍵點坐標位置。關鍵點定位了頭、肩、肘、手、臀、膝、腳等部位,可以用於人的行為識別,對於安防技術有重大意義。

  三連冠偉業

  今年的 MS COCO 總共 7 項比賽,除了曠視的 3 項冠軍,香港中文大學-商湯科技聯合實驗室和南洋理工大學團隊也在 Object Detection 比賽中拿到了不含額外數據集的第一名。

  可以說中國軍團延續傳統,繼續在全球 AI 競技中展現實力。

  而且 COCO 中最被看重的“物體檢測”比賽,孫劍和其帶隊的中國軍團,更是實現了垄斷級的統治力。

  物體檢測項目,從 2015 年第一屆就存在,此後一直延續了下來。

  在第一屆比賽中,孫劍帶隊的 MSRA 團隊斬獲冠軍,成員包括何愷明(現 FAIR)、任少卿(現 Momenta)、代季峰(現商湯)和張祥雨(現曠視),所用的算法,是何愷明和 RBG 大神第一次合作的 Faster R-CNN。

  不過 2016 年,冠軍被谷歌研究院的G-RMI 隊拿下,只是所用的算法依然是 Faster R-CNN。

  2015 年第一屆 MS COCO 大賽中除了物體檢測,還有個生成圖片說明(Captioning Challenge)項目,當時奪冠的谷歌團隊,與人類 baseline 相比依然差了一大截,這個比賽項目也沒能繼續下去。

  在 2016 年,物體檢測之外的比賽項目變成了人體關鍵點檢測,當時奪冠的團隊來自 CMU。

  而從 2017 年開始,COCO 的各項比賽,就真正進入了中國時間——甚至可以更具體說“曠視時間”。

  這家中國 AI 獨角獸在孫劍加盟擔當研究院院長后,如虎添翼,在 COCO 競賽中展現出的實力,就像中國乒乓球、女排在奧運會展現的一樣。

  2017 年,MS COCO 的 6 個比賽項目中,曠視拿下了邊界檢測(Detection: Bounding Box)、人體關鍵點檢測(Keypoints)和地點實例分割(Places Instance Segmentation)3 個項目的冠軍,以及檢測分割(Detection: Segmentation)的亞軍。

  而在 2018 年的 6 個項目中,曠視拿下了物體檢測(Detection)、全景分割(Panoptic)、人體關鍵點檢測(Keypoints)和 Mapillary Panoptic4 個項目的冠軍。

  另外的兩個項目 DensePose 和 Mapillary 街景檢測則分別由北京郵電大學自動化學院模式識別與測控技術實驗室(BUTP-PRIV)和滴滴獲得——這一整屆比賽的冠軍都被中國團隊包了。

  所以算下來,曠視已經在三年 MS COCO 的比賽上拿到了累計 10 個冠軍。

  最重頭的“物體檢測”,更是完成三連冠偉業,前無古人。

  更加值得一提的是,之前我們也揭秘過,曠視在 COCO 上的統治力,去往年開始就啟用大牛老將帶實習生參賽的機制,於是諸多名不見經傳的本科實習生,早早就成為了 AI 世界冠軍。

  而且刷榜奪冠,不僅是鍛煉隊伍,而且對曠視自研的 Brain++,也是一次次最佳說明。

  在今年 ICCV 奪冠后,曠視研究院院長孫劍再次感謝曠視算法工具平台 Brain++,稱一連串成績的取得,離不開背後強大的 Brain++。

  曠視介紹,一方面 Brain++ 具備多機訓練方案,支持完備的底層算法,確保算法的高效實現與快速驗證。

  比如,在 COCO Detection 任務中,曠視重新設計了 RPN 匹配策略和 Proposal 採樣策略,使用兩階段檢測器即可直接獲得很好的高 IoU 檢測結果,甚至超過了使用更多階段的 Cascade R-CNN,最終大幅領先,取得 test-challenge 52.5 的冠軍成績。

  另一方面 Brain++ 針對計算機視覺定製優化,適合工業界的產品開發,為競賽技術的應用轉化鋪平道路。

  還集成了新一代 AutoML 技術,降低算法試錯成本,實現技術創新和產品落地齊頭並進。Brain++從算法設計、算法框架和算法平台三個方面為 AI 競賽保駕護航。

  在剛剛舉行的烏鎮世界互聯網大會上,Brain++還為曠視斬獲了“世界互聯網領先科技成果”。

  於是也有更多注意力開始關注起這個基礎算法研發平台,曠視聯合創始人及 CTO 唐文斌還比喻說,如果說曠視各種各樣的算法是“雞蛋”,那 Brain++ 就是出產“所有雞蛋”的“母雞”。

  總之,Brain++可以視為曠視面向 AI 時代的生產工具,而再配以優秀的人才,連續在全球 AI 競技中奪魁,自然也不是意料之外。

  One more thing

  最後,新冠軍、新紀錄和三連冠偉業之外,今年 COCO 的冠軍對曠視而言還有更多意義。

  一方面,這家 AI 獨角獸已經向港交所提交了招股書,IPO 上市只是時間問題,也將成為 AI 創業上市第一股。

  另一方面,就在不久前,曠視也突發遭遇偷襲,被美國列入了“實體名單”,成為“川普優選”的又一家公司。

  因為衝刺上市當前,還引發了更多關注。

  但 Brain++ 獲國家認證,COCO 比賽三連冠,毫無疑問就是最好回應。

  還是那句話,如果美國拉黑了你,不要悲傷,不要氣餒。

  猝不及防的日子,最好的回擊就是業績和人心。

  並且 ICCV 2019 這才剛剛開幕,聽說曠視的三連冠,還不是中國 AI 新榮譽的全部。

  讓我們保持關注,繼續期待~

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

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

Gogoro 發表 Gogoro S2 ABS,光譜靛新色登場

Gogoro 推出了 Gogoro S2 系列的新車 Gogoro S2 ABS,首度在 Gogoro S2 車款上引進 ABS(Anti-Lock Brake System) 防鎖死煞車系統。

Gogoro S2 ABS 最大的特色在於前後輪都搭載重車等級 BOSCH ABS 10 雙迴路煞車系統,煞車時系統會以每秒 200 次的高頻率監測前後輪轉動狀況,在車輪即將鎖死的瞬間自動釋放煞車,避免車輪在緊急煞車時鎖死。 Bosch ABS 10 雙迴路煞車系統重量僅 580 克,在僅少量提升車重的狀況下提升穩定性和操控性能。

Gogoro 也與 MAXXIS 攜手研發 Gogoro S2 ABS 獨家的 ABS 性能胎,在雨天濕滑路面時更能有效發揮 ABS 系統的制動性,讓用戶騎乘更加安全。獨特的顏色也是一大亮點,Gogoro S2 ABS 車身運用多層次染色的超細緻顆粒珍珠漆,打造出新色光譜靛,車體顏色會隨著光線角度產生變化。此外,Gogoro S2 ABS 也調整了 USB 插孔的位置,移到左把手的下方。

Gogoro S2 ABS。

搭載重車等級 BOSCH ABS 10 雙迴路煞車系統是 Gogoro S2 ABS 的最大特色。

Gogoro S2 ABS 的 USB 插孔位於左邊把手的下方。

Gogoro S2 ABS 使用 iQ System 智慧鑰匙卡靠近 S 標誌解鎖。

Gogoro S2 ABS 安全極速達到時速 92 公里,最大功率為 7.6 kW,靜止加速到時速 50 公里僅需 3.8 秒。Gogoro S2 ABS 時速 40 公里之下單次換電續航里程為 110 公里,時速 30 公里時單次換電續航里程則為 150 公里。 空車重量為 105 公斤,加上電池則為 123 公斤,擁有 25L 的置物空間。

Gogoro S2 ABS 僅有光譜靛一款顏色,定價為 101,980 元台幣,補助最高的雲林縣汰換二行程機車換購電動機車補助最高 30,000 元,最低台幣 71,980 元起,即日起正式上市。購買 Gogoro S2 全車系任一車款,加贈市價約台幣 6,800 元的限量 ROAV 聯名墨鏡。

(合作媒體:。圖片來源:)

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

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

科學家首次記錄下細菌「脫皮」的耐葯全過程

  本文作者:BioTalker

  面對抗生素的圍剿,細菌為了生存真是太拼了。

  近日,來自英國頂級學府紐卡斯爾大學的科學家 Katarzyna Mickiewicz 和 Jeff Errington 發現,人尿液中引起疾病的大腸桿菌,為了躲避抗生素的追殺,竟然能輕易地轉化成沒有細胞壁的L型細菌,讓青霉素等靶向細胞壁合成的抗生素,完全失去作用

  要知道,細菌體內的滲透壓可達到20-25 個大氣壓,在細胞壁遭到破壞的情況下,很快就會因過度吸水脹破死亡。青霉素等就是依靠這個原理殺死細菌的。


左:接連破裂的細菌右:正常生長的細菌

  不過,巧就巧在,尿液非常特殊,幾乎和細菌的細胞質是等滲的

  細菌:“為了活命,我連細胞壁都不要了,我看你咋搞我。”

  抗生素:“小賊,要不是因為尿液的高滲環境保護着你,你的小命早沒了。”

  讓研究人員沒有想到的是,L型細菌能輕鬆挺過抗生素治療周期(一般5-14 天),而且一旦抗生素撤離,L型細菌能在不到一天的時間內,分裂出有細胞壁的細菌,恢復往日活力,導致感染複發

  此外,在本研究中,科學家們還用視頻記錄下了細菌在L型和有壁型之間的轉換過程。證明了細菌變成L型是一種耐葯,導致疾病複發的方式。  實際上,L型細菌發現的並不晚。就在弗萊明發現青霉素的 7 年之後,德國生物學家 Emmy Klieneberger-Nobel 在英國 Lister 研究所研究念珠狀鏈桿菌時,第一次看到細胞壁缺陷型細菌(L型細菌的名字來自於 Lister 研究所的首字母)。在當時的認知條件下,Klieneberger-Nobel 的震驚程度可想而知。

  Klieneberger-Nobel:“沒有了細胞壁的保護,L型細菌怎麼還能存活而不炸裂?”

  現在我們已經知道,由於常用的細菌培養基是低滲的,因此不可能獲得L型細菌。不過,只要使用等滲培養基,就可以通過多種方法誘導出L型細菌,例如溶解細胞壁的溶菌酶,和青霉素等抑制細胞壁合成的抗生素。

  不過這種沒有細胞壁的L型細菌對細菌的生長繁殖有什麼作用,一直沒有定論。有科學家認為L型細菌廢了,沒啥致病能力;也有科學家認為,沒準兒這就是細菌的一個耐葯機制呢?但是都沒啥直接的有力證據。


在高滲條件下,抗生素處理,細菌失去細胞壁變圓,形成L型細菌

  其實,大家之所以對這個問題爭論不休,主要問題還是研究的比較少,沒有被重視起來,沒有認真地往耐藥方向想。

  長期以來,對於耐葯,有兩個主流認知:一個是產生耐葯基因了;另一個是產生了微生物持留菌。這個微生物持留菌引起的複發和因耐藥引起的複發還不一樣。

  微生物持留菌是細菌的一種特殊形態,可以說是,當外界的環境條件不適宜細菌生存時(例如抗生素治療),有一小部分細菌會改變細胞狀態,悄咪咪地蟄伏在一些細胞中長久地休眠,等抗生素打擊期過去之後,重新出來活躍,導致感染複發。

  有了這兩個認知,就很少有人把L型細菌當回事兒。


在低滲條件下,抗生素處理,細菌失去細胞壁,膨脹,炸了~

  微生物學家 Jeff Errington 把這個問題當做他的研究重點。去年,Errington 團隊在《細胞》雜誌上發文稱,在某些生理條件下,巨噬細胞等免疫細胞產生的溶菌酶,實際上對細菌起到了保護作用。因為,溶菌酶破壞了細菌的細胞壁,讓靶向細胞壁合成的抗生素沒了用武之地。

  為了進一步探索抗生素與L型細菌之間的關係,以及L型細菌與耐葯之間的關係,Errington 和 Mickiewicz 打算從尿路感染入手。

  尿路感染是一個非常常見的疾病,美國估計每年要在這個疾病上花費 16 億美元。

  其實不僅僅是美國患者受這個疾病的困擾。在全球範圍內,尿路感染每年影響着全球 1.5 億人,即使是接受抗生素治療,也仍有 30-50% 的患者在治療之後會複發


該圖片由 Gerd Altmann 在 Pixabay 上發布

  Mickiewicz 分析了 30 位複發性尿路感染患者的尿液樣本,她發現只有一個患者的尿液中沒有L型大腸桿菌,其他的患者都有。而且他們還用一些方法證實,他們看到的L型物體確實是細菌,而不是人的細胞產生的囊泡等物質。粗略估計的話,每毫升尿液中有 100 到 10000 個L型細菌

  體外實驗显示,在抑制細胞壁生成的抗生素存在的條件下,如果培養基對L型細菌沒有滲透保護作用,在 2.5 小時之內,細菌都膨脹、裂解死光光;如果在滲透保護的培養基中,大約經過 3 個小時,L型細菌就出現了

  如果想證明L型細菌是感染反覆發作的原因,就必須得證明L型細菌確實能轉化成有細胞壁的細菌。Mickiewicz 不僅證實了這一點,而且還用視頻記錄下了L型細菌,分裂增殖出正常細菌的全過程。在體外的條件下,整個過程大約需要 40 分鐘左右


撤除環境中的抗生素之後,L型細菌繁殖出有壁正常細菌

  最後研究人員還在斑馬魚體內觀察了L型細菌轉化成有壁細菌的過程。從研究人員將L型細菌注射到斑馬魚體內開始算起,20 個小時后取樣能檢測到有壁細菌的存在。而且他們還在斑馬魚體內觀察到了,在抗生素的處理下細菌變成L型細菌的過程。

  總的來說,這個研究表明,除了其他的耐葯機制之外,L型細菌也是一個耐葯途徑,而且無需基因變異,便可以通過丟棄細胞壁在抗生素治療期間頑強存活。更為重要的是,一旦撤出環境中的抗生素,這些L型細菌很快就會繁殖出一堆正常的有壁細菌出來

  研究人員認為,要想治好一些複雜的反覆感染,靶向細胞壁的抗生素要與其他類型的抗生素組合使用。

  *我看完這個論文一直在想一個問題,如果尿路感染的患者在接受靶向細胞壁的抗生素治療期間,每天都大量飲水,會不會有輔助治療的功效(我不知道,我瞎猜的哈
)。

  最後,我要說的是:你以為微生物就這麼點兒本事嗎?如果是這樣,那你就真的是“拿豆包不當乾糧”了。

  近二十年的研究表明,人體微生物的數量幾乎與人體細胞一樣多。這些看上去非常不起眼的小東西,與人類的多種疾病有關,從普通的感染和炎症,到精神疾病、心血管疾病,甚至是癌症,都有一股神秘的來自微生物的力量在背後操縱着

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

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

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

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

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

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

分類
發燒車訊

深空輻射、微重力、幽閉空間……火星之旅危險知多少

  科技日報記者 劉霞

  宇航員前往火星的旅程並不像遊客們前往瑞士那麼輕鬆、愜意且自在,而是一段充滿了各種不確定因素和未知風險的冒險之旅。執行火星探索任務的宇航員將不得不長期與深空輻射、微重力、幽閉空間、與世隔絕等壓力作鬥爭。

  畢竟,就目前的技術而言,宇航員到達火星至少需要 6 個月時間,而返回地球也需要同樣長的時間。因此,他們必須做好準備,克服生理和心理等方面的挑戰。美國國家航空航天局(NASA)也正努力在本世紀 30 年代將宇航員送上火星之前,降低其可能面臨的各種風險。

  壓力源“協同作戰”


火星上一個前哨基地的藝術圖。圖片來源:美國太空網

  據美國太空網近日報道,NASA 人類研究項目(HRP)首席科學家珍妮弗·福格蒂本月早些時候表示,宇航員搭乘的宇宙飛船“將不得不提供滿足宇航員基本生存所需的一切甚至更多,因為我們希望他們能夠勝任這份對認知和身體狀態都有極高要求的工作。”

  HRP 的任務是找出航天飛行對宇航員的影響,並制定減輕和降低這些影響的策略。福格蒂說,該項目旨在識別出 5 類“壓力源”,這些“壓力源”可以顯著影響人類在執行深空任務過程中的健康狀況和表現,包括重力場的改變、不友好的環境、輻射、隔離/限制,以及與地球之間的遙遠距離等。

  HRP 科學家和世界各地的其他研究人員正試圖認真分析並了解所有這些壓力源,他們在地球上進行實驗,仔細監測在國際空間站(ISS)工作的宇航員的心理和身體健康狀況。這項工作的長期目標是幫助實現載人火星任務,NASA 希望在本世紀 30 年代末之前完成這一使命。事實上,幾年前,NASA 宇航員斯科特·凱利和米哈伊爾·科爾尼延科在國際空間站呆了 11 個月(約是通常停留時間的兩倍),以幫助研究人員評估非常長期的太空任務(比如火星往返之旅)對宇航員的影響。

  然而,要準確描述這樣一次火星之旅會給宇航員帶來何種影響非常困難。福格蒂說,因為航天飛行的各種壓力源一般並非“單獨行動”,很有可能是“協同作戰”,幾乎不可能把所有危險因素放在一個實驗環境中。

  例如,科學家在地球實驗室中對動物進行輻射研究,就沒有考慮到微重力的影響,因為目前無法將其加入進去;而國際空間站無法提供深空輻射數據,因為它在地球的保護磁層內運行;此外,在軌道實驗室安裝輻射發射裝置似乎也不是個好主意。

  輻射是最大風險

  有些壓力源更令人擔憂——研究人員和 NASA 官員反覆強調,輻射是宇航員執行火星任務所面臨的最危險因素之一。

  HRP 項目的太空輻射元素科學家麗莎·西門森博士解釋稱:“人類前往火星最大的挑戰之一是暴露於輻射的風險。長期暴露於輻射中可能帶來的健康風險,輻射會通過活體組織傳播,沉積能量導致 DNA 結構損傷,並改變許多細胞過程。”

  研究表明,暴露於高輻射環境下會增加宇航員晚年患癌症的風險。最近一項研究表明,執行火星任務的宇航員可能受到高劑量輻射,這些累積的輻射足以損害他們的中樞神經系統,使他們在情緒、記憶力和學習能力等方面受到影響。

  福格蒂提到了另一個需要集中研究的問題:航天飛行相關的神經—眼綜合征(SANS),也稱為視覺障礙/顱內壓(VIIP)。SANS 指的是太空飛行可能給宇航員帶來嚴重而長期的視力問題,這可能是由於液體流動增加了顱骨內的壓力。

  福格蒂說:“目前在近地軌道上,SANS 非常容易管理而且也比較容易恢復,但以我們對這個系統的了解,還不足以預測在某些探測任務中,SANS 是否也會保持這種狀態。所以,這是我們目前研究的最優先的生理領域之一。”

  依靠月球上火星

  NASA 目前的計劃是,不直接去火星,而是以月球為中間站。到 2024 年,讓兩名宇航員在月球南極附近着陸,之後不久,在月球及其周圍建立長期可持續的基地。

  NASA 官員表示,他們將通過“阿爾忒彌斯”計劃開展這些活動,主要目的是學習將宇航員送上火星所需的技能和技術。“阿爾忒彌斯”基礎設施的關鍵部分之一是一個小型繞月空間站——“門戶”,它將作為月球表面活動的中心。無論是機器人的還是載人的着陸器,都將從“門戶”下降到月球表面,而在“門戶”前哨上的宇航員,很可能也會從那裡操作漫遊車。

  大量研究將在“門戶”內進行,其中大部分研究將調查宇航員在一個真正的深空環境內的健康狀況和表現。福格蒂提到了一種研究策略,這種策略可能對規劃“火星之路”特別有用——在月球軌道前哨上研究人類組織的小樣本。

  這樣能規避一個影響研究的最大問題——使用嚙齒動物和其它非人類動物作為模型。福格蒂說:“我們如何在老鼠和人類之間架起一座橋樑呢?因為它不是直接適用的,這也困擾着陸地醫學和研究。但是隨着芯片上器官和組織的不斷湧現,以及科學家對其不斷的驗證,你可以用這些芯片概括出人體非常複雜的側面。我們可以將芯片作為一個模型有機體,在理解複雜環境方面取得重大進展,以此來真正解決人類的局限性的問題。”

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

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

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

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

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

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

分類
發燒車訊

本田宣布 2021 年在歐洲停售柴油車,目標 100% 電動化

日本本田汽車公司(Honda Motor Co.)23 日宣布,該公司將於 2021 年前停止在歐洲銷售柴油車,目標是在 2025 年達成歐洲新售汽車全面電動化,成為喊出以電動車為終極願景的最新一家跨國汽車製造商。

《日經亞洲評論》、路透社報導,根據歐盟規定,自 2020 年起,車商必須進一步限制新售汽車的平均二氧化碳排放量,從目前的每公里 120.5 克降至每公里 95 克,否則每輛車每超標 1 克即罰款 95 歐元,到了 2021 年,歐盟所有新車都必須符合這項規定。

本田預估,2030 年時,混合動力車或純電動車將佔其全球銷量的三分之二。

由於歐洲的柴油車需求下降,加上實施更嚴格的汽車碳排限制,本田今年 2 月表示,將於 2021 年關閉英國唯一製造廠,約 3,500 名員工面臨失業。

其他日本汽車製造商也加入停售柴油車行列,包括日產(Nissan)決定停止開發柴油引擎,豐田(Toyota)及鈴木(Suzuki)已退出歐洲柴油車市場,而馬自達(Mazda)則計劃推出柴油電力混合動力車。

受 2015 年福斯(Volkswagen)爆發「柴油門」醜聞影響,歐洲消費者對柴油車失去信心,令銷量節節下滑。根據歐洲汽車製造商協會(European Automobile Manufacturers’ Association)的數據,2018 年柴油車占歐盟新車銷量的 36%,低於 2015 年的 52%。波士頓諮詢公司(Boston Consulting Group)預測,2025 年時,柴油車所佔比率將降至 21%。

(本文內容由 授權使用。首圖來源:)

 

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

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

分類
發燒車訊

漫畫:什麼是公有雲、私有雲和混合雲?

  在上一篇《什麼是雲計算》發表之後,很多小夥伴表示終於知道到底什麼是雲計算了,能夠幫到大家真的很開心。

  上一篇文章的評論中,有幾個朋友希望我們可以介紹下什麼是公有雲、私有雲和混合雲。那麼這一篇,就給大家介紹下這幾個概念。

  為了方便大家理解,我們盡量用通俗的語言和舉例子的方式講解,並且文中還配備了漫畫供大家參考學習。

  隨着最近幾年的雲計算技術的主鍵發展和普及,越來越多的企業通過採用雲服務的方式來搭建網站及服務器。

  為了方便不同需求的用戶,很多雲計算服務商都會提供很多形式的雲服務,這裏面比較常見的就是公有雲、私有雲以及混合雲,還有些服務商會提供社群雲(社區雲)等。

  那麼這些雲計算的形式有什麼區別呢?用戶又該如何選擇呢?

  公有雲

  公有雲是為廣大用戶、個人或企業提供的雲基礎設施。公有雲就是第三方的公有雲供應商為用戶提供可通過互聯網訪問的虛擬環境中的服務器空間。然後,用戶可以通過購買雲服務器、數據存儲和其他與雲相關的服務等公有雲服務來訪問這些服務器。

  在公有雲中,所有硬件、軟件和其他支持性基礎結構均為雲提供商所擁有和管理。

  在公有雲中,你與其他組織或雲“租戶”共享相同的硬件、存儲和網絡設備。你可以使用 Web 瀏覽器訪問服務和管理帳戶。

  公有雲部署通常用於提供基於 Web 的电子郵件、網上辦公應用、存儲以及測試和開發環境。

  如果拿租房子來舉例,公有雲就像是合租公寓,設施都是共用的,各個房間之間也都是通過虛擬化等方案進行隔離的。並且費用也是相對比較低的。

  公有雲非常適合計算能力需求有波動的企業或專門面向公眾的應用程序,如 Dropbox、Evernote 和 Netflix。

  公有雲優勢:

  • 成本更低 — 無需購買硬件或軟件,僅對使用的服務付費。
  • 無需維護 — 維護由服務提供商提供。
  • 近乎無限制的縮放性 — 提供按需資源,可滿足業務需求。
  • 高可靠性 — 具備眾多服務器,確保免受故障影響。

  但是同時,很多人擔心公有雲的安全性、私密性等問題。於是就有了私有雲。

  私有雲

  私有雲是雲計算的另一種形式。它為一個企業或組織提供專用的雲環境。私有雲可以由企業或組織內部的 IT 團隊在該組織的防火牆後面進行內部操作,因此組織可以更好地控制其計算資源。私有雲主要由企業使用,因此它也被視為一種企業雲。

  私有雲可在物理上位於組織的現場數據中心,也可由第三方服務提供商託管。

  在私有雲中,服務和基礎結構始終在私有網絡上進行維護,硬件和軟件專供組織使用。

  私有雲可使組織更加方便地自定義資源,從而滿足特定的 IT 需求。

  私有雲的使用對象通常為政府機構、金融機構以及其他具備業務關鍵性運營且希望對環境擁有更大控制權的中型到大型組織。

  如果拿租房子來舉例,私有雲就像是套房整租,資源獨享不需要和他人共用,有很高的自由性。

  私有雲優勢:

  • 靈活性更高 — 組織可自定義雲環境以滿足特定業務需求。
  • 安全性更高 — 資源不與其他組織共享,從而可實現更高控制性和安全性級別。
  • 縮放性更高 — 私有雲仍然具有公有雲的縮放性和效率。

  但是私有雲的費用相對較高, 並且維護成本也不低。於是有的廠商結合了公有雲和私有雲推出了混合雲。

  混合雲

  混合雲是一種雲計算模型,它通過安全連接(如 VPN 連接或租用線路)組合一個或多個公有雲和私有雲環境,從而允許在不同雲環境之間共享數據和應用程序。當在私有雲上運行的應用程序遇到使用高峰時,它們可以自動“突發”到公有雲環境以獲得額外的按需容量。這被稱為“雲爆發”。由於額外的需求將在公有雲上,因此無需擔心提前配置硬件以滿足高峰需求。連接公有雲和私有雲有兩種方法:VPN 和點對點專用連接。

  混合雲通常被認為是“兩全其美”,它將本地基礎架構或私有雲與公有雲相結合,組織可利用這兩者的優勢。

  在混合雲中,數據和應用程序可在私有雲和公有雲之間移動,從而可提供更大靈活性和更多部署選項。

  如果拿租房子來舉例,公有雲就像是更加靈活的整租+單租自動調節。可以在價格、安全性、靈活性等方面做一個平衡。

  混合雲優勢:

  • 控制性 — 組織可針對敏感資產維持私有基礎結構。
  • 靈活性 — 需要時可利用公有雲中的其他資源。
  • 成本效益 — 具備擴展至公有雲的能力,因此可僅在需要時支付額外的計算能力。
  • 容易輕鬆 — 無需費時費力即可轉換至雲,因為可根據時間按工作負荷逐步遷移。

  混合雲整合了公有雲和公有雲的優勢。它提供高可擴展性,幾乎無限的存儲空間,靈活的支付模式,並且與公有雲一樣具有成本效益。混合雲也非常安全;它為您提供了更多的靈活性和對雲資源的控制。

  但是目前支持混合雲的服務廠商並不是很多,並且這種方案目前也不是很成熟。

社群雲

  除了常見的公有雲、私有雲以及混合雲以外,還有些公司在使用社群雲。

  社群雲,也稱社區雲,是由幾個組織共享的雲端基礎設施,它們支持特定的社群,有共同的關切事項,例如使命任務、安全需求、策略與法規遵循考量等。管理者可能是組織本身,也能是第三方;管理位置可能在組織內部,也可能在組織外部。

  如果拿租房子來舉例,公有雲就像是單位的員工宿舍,在價格和安全性方面都是比較適中的。

  社群雲在模式和機制、可靠性、安全、組織管理等方面面臨挑戰,有待進一步解決。社群雲與私有雲、公有雲相比模式上複雜一些,由多個組織共同構建和共享雲設施。

  總結

  本文介紹了雲計算的四種部署模式,分別是公有雲、私有雲、混合雲以及社群雲。

  這四種雲的主要區別就是使用的人群和使用的方式不一樣:

  • 公有雲由公眾開放使用
  • 私有雲由單一組織獨佔使用
  • 混合雲則是前述的兩種以上模式的混合
  • 社群雲是由一個特定社區獨佔使用,該社區由具有共同關切 (如使命、安全要求、政策等) 的多個組織組成

  使用場景區別:

  • 公有雲部署通常用於提供基於 Web 的电子郵件、網上辦公應用、存儲以及測試和開發環境。
  • 私有雲的使用對象通常為政府機構、金融機構以及其他具備業務關鍵性運營且希望對環境擁有更大控制權的中型到大型組織。
  • 混合雲的使用對象通常由大流量的互聯網業務,同時部分業務有合規需求或者需要充分利用現有 IT 資產的企業或組織
  • 社群雲的使用對象通常是多個有密切關係的組織一起聯合使用。

  企業在進行選擇的時候,應該根據實際情況,選擇最適合自己的雲服務。

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

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

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

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

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

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