跳到主要內容

Android DecorView 與 Activity 綁定原理分析

一年多以前,曾經以為自己對 View 的添加显示邏輯已經有所了解了,事後發現也只是懂了些皮毛而已。經過一年多的實戰,Android 和 Java 基礎都有了提升,是時候該去看看 DecorView 的添加显示。


概論


Android 中 Activity 是作為應用程序的載體存在,代表着一個完整的用戶界面,提供了一個窗口來繪製各種視圖,當 Activity 啟動時,我們會通過 setContentView 方法來設置一個內容視圖,這個內容視圖就是用戶看到的界面。那麼 View 和 activity 是如何關聯在一起的呢 ?


 上圖是 View 和 Activity 之間的關係。先解釋圖中一些類的作用以及相關關係:



  • Activity : 對於每一個 activity 都會有擁有一個 PhoneWindow。


  • PhoneWindow :該類繼承於 Window 類,是 Window 類的具體實現,即我們可以通過該類具體去繪製窗口。並且,該類內部包含了一個 DecorView 對象,該 DectorView 對象是所有應用窗口的根 View。

  • DecorView 是一個應用窗口的根容器,它本質上是一個 FrameLayout。DecorView 有唯一一個子 View,它是一個垂直 LinearLayout,包含兩個子元素,一個是 TitleView( ActionBar 的容器),另一個是 ContentView(窗口內容的容器)。


  • ContentView :是一個 FrameLayout(android.R.id.content),我們平常用的 setContentView 就是設置它的子 View 。




  • WindowManager : 是一個接口,裏面常用的方法有:添加View,更新View和刪除View。主要是用來管理 Window 的。WindowManager 具體的實現類是WindowManagerImpl。最終,WindowManagerImpl 會將業務交給 WindowManagerGlobal 來處理。



  • WindowManagerService (WMS) : 負責管理各 app 窗口的創建,更新,刪除, 显示順序。運行在 system_server 進程。


ViewRootImpl :擁有 DecorView 的實例,通過該實例來控制 DecorView 繪製。ViewRootImpl 的一個內部類 W,實現了 IWindow 接口,IWindow 接口是供 WMS 使用的,WSM 通過調用 IWindow 一些方法,通過 Binder 通信的方式,最後執行到了 W 中對應的方法中。同樣的,ViewRootImpl 通過 IWindowSession 來調用 WMS 的 Session 一些方法。Session 類繼承自 IWindowSession.Stub,每一個應用進程都有一個唯一的 Session 對象與 WMS 通信。


DecorView 的創建 


先從 Mainactivity 中的代碼看起,首先是調用了 setContentView;


protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}

該方法是父類 AppCompatActivity 的方法,最終會調用 AppCompatDelegateImpl 的 setContentView 方法:


// AppCompatDelegateImpl  
public void setContentView(int resId) {
this.ensureSubDecor();
ViewGroup contentParent
= (ViewGroup)this.mSubDecor.findViewById(16908290);
contentParent.removeAllViews();
LayoutInflater.from(
this.mContext).inflate(resId, contentParent);
this.mOriginalWindowCallback.onContentChanged();
}

ensureSubDecor 從字面理解就是創建 subDecorView,這個是根據主題來創建的,下文也會講到。創建完以後,從中獲取 contentParent,再將從 activity 傳入的 id xml 布局添加到裏面。不過大家注意的是,在添加之前先調用 removeAllViews() 方法,確保沒有其他子 View 的干擾。


    private void ensureSubDecor() { 
if (!this.mSubDecorInstalled) {
this.mSubDecor = this.createSubDecor();
......
}
......
}

 最終會調用 createSubDecor() ,來看看裏面的具體代碼邏輯:


 private ViewGroup createSubDecor() { 
// 1、獲取主題參數,進行一些設置,包括標題,actionbar 等
TypedArray a = this.mContext.obtainStyledAttributes(styleable.AppCompatTheme);
if (!a.hasValue(styleable.AppCompatTheme_windowActionBar)) {
a.recycle();
throw new IllegalStateException("You need to use a Theme.AppCompat theme (or descendant) with this activity.");
}
else {
if (a.getBoolean(styleable.AppCompatTheme_windowNoTitle, false)) {
this.requestWindowFeature(1);
}
else if (a.getBoolean(styleable.AppCompatTheme_windowActionBar, false)) {
this.requestWindowFeature(108);
}

if (a.getBoolean(styleable.AppCompatTheme_windowActionBarOverlay, false)) {
this.requestWindowFeature(109);
}

if (a.getBoolean(styleable.AppCompatTheme_windowActionModeOverlay, false)) {
this.requestWindowFeature(10);
}

this.mIsFloating = a.getBoolean(styleable.AppCompatTheme_android_windowIsFloating, false);
a.recycle();
// 2、確保優先初始化 DecorView
this.mWindow.getDecorView();
LayoutInflater inflater
= LayoutInflater.from(this.mContext);
ViewGroup subDecor
= null;
// 3、根據不同的設置來對 subDecor 進行初始化
if (!this.mWindowNoTitle) {
if (this.mIsFloating) {
subDecor
= (ViewGroup)inflater.inflate(layout.abc_dialog_title_material, (ViewGroup)null);
this.mHasActionBar = this.mOverlayActionBar = false;
}
else if (this.mHasActionBar) {
TypedValue outValue
= new TypedValue();
this.mContext.getTheme().resolveAttribute(attr.actionBarTheme, outValue, true);
Object themedContext;
if (outValue.resourceId != 0) {
themedContext
= new ContextThemeWrapper(this.mContext, outValue.resourceId);
}
else {
themedContext
= this.mContext;
}

subDecor
= (ViewGroup)LayoutInflater.from((Context)themedContext).inflate(layout.abc_screen_toolbar, (ViewGroup)null);
this.mDecorContentParent = (DecorContentParent)subDecor.findViewById(id.decor_content_parent);
this.mDecorContentParent.setWindowCallback(this.getWindowCallback());
if (this.mOverlayActionBar) {
this.mDecorContentParent.initFeature(109);
}

if (this.mFeatureProgress) {
this.mDecorContentParent.initFeature(2);
}

if (this.mFeatureIndeterminateProgress) {
this.mDecorContentParent.initFeature(5);
}
}
}
else {
if (this.mOverlayActionMode) {
subDecor
= (ViewGroup)inflater.inflate(layout.abc_screen_simple_overlay_action_mode, (ViewGroup)null);
}
else {
subDecor
= (ViewGroup)inflater.inflate(layout.abc_screen_simple, (ViewGroup)null);
}

if (VERSION.SDK_INT >= 21) {
ViewCompat.setOnApplyWindowInsetsListener(subDecor,
new OnApplyWindowInsetsListener() {
public WindowInsetsCompat onApplyWindowInsets(View v, WindowInsetsCompat insets) {
int top = insets.getSystemWindowInsetTop();
int newTop = AppCompatDelegateImpl.this.updateStatusGuard(top);
if (top != newTop) {
insets
= insets.replaceSystemWindowInsets(insets.getSystemWindowInsetLeft(), newTop, insets.getSystemWindowInsetRight(), insets.getSystemWindowInsetBottom());
}

return ViewCompat.onApplyWindowInsets(v, insets);
}
});
}
else {
((FitWindowsViewGroup)subDecor).setOnFitSystemWindowsListener(
new OnFitSystemWindowsListener() {
public void onFitSystemWindows(Rect insets) {
insets.top
= AppCompatDelegateImpl.this.updateStatusGuard(insets.top);
}
});
}
}

if (subDecor == null) {
throw new IllegalArgumentException("AppCompat does not support the current theme features: { windowActionBar: " + this.mHasActionBar + ", windowActionBarOverlay: " + this.mOverlayActionBar + ", android:windowIsFloating: " + this.mIsFloating + ", windowActionModeOverlay: " + this.mOverlayActionMode + ", windowNoTitle: " + this.mWindowNoTitle + " }");
}
else {
if (this.mDecorContentParent == null) {
this.mTitleView = (TextView)subDecor.findViewById(id.title);
}

ViewUtils.makeOptionalFitsSystemWindows(subDecor);
ContentFrameLayout contentView
= (ContentFrameLayout)subDecor.findViewById(id.action_bar_activity_content);
ViewGroup windowContentView
= (ViewGroup)this.mWindow.findViewById(16908290);
if (windowContentView != null) {
while(windowContentView.getChildCount() > 0) {
View child
= windowContentView.getChildAt(0);
windowContentView.removeViewAt(
0);
contentView.addView(child);
}

windowContentView.setId(
-1);
contentView.setId(
16908290);
if (windowContentView instanceof FrameLayout) {
((FrameLayout)windowContentView).setForeground((Drawable)
null);
}
}
// 將 subDecor 添加到 DecorView 中
this.mWindow.setContentView(subDecor);
contentView.setAttachListener(
new OnAttachListener() {
public void onAttachedFromWindow() {
}

public void onDetachedFromWindow() {
AppCompatDelegateImpl.
this.dismissPopups();
}
});
return subDecor;
}
}
}

上面的代碼總結來說就是在做一件事,就是創建 subDecor。攤開來說具體如下:


1、根據用戶選擇的主題來設置一些显示特性,包括標題,actionbar 等。


2、根據不同特性來初始化 subDecor;對 subDecor 內部的子 View 進行初始化。


3、最後添加到 DecorView中。


添加的具體代碼如下:此處是通過調用 


 // AppCompatDelegateImpl   this.mWindow.getDecorView(); 

// phoneWindow public final View getDecorView() {
if (mDecor == null || mForceDecorInstall) {
installDecor();
}
return mDecor;
}


private void installDecor() {
mForceDecorInstall = false;
if (mDecor == null) {
// 生成 DecorView mDecor = generateDecor(-1);
mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
mDecor.setIsRootNamespace(true);
if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
}
} else {
// 這樣 DecorView 就持有了window mDecor.setWindow(this);
}
......
}


protected DecorView generateDecor(int featureId) {
// System process doesn't have application context and in that case we need to directly use // the context we have. Otherwise we want the application context, so we don't cling to the // activity.
Context context;
if (mUseDecorContext) {
Context applicationContext = getContext().getApplicationContext();
if (applicationContext == null) {
context = getContext();
} else {
context = new DecorContext(applicationContext, getContext());
if (mTheme != -1) {
context.setTheme(mTheme);
}
}
} else {
context = getContext();
}
return new DecorView(context, featureId, this, getAttributes());
}

到此,DecorView 的創建就講完了。可是我們似乎並沒有看到 DecorView 是被添加的,什麼時候對用戶可見的。


 WindowManager


View 創建完以後,那 Decorview 是怎麼添加到屏幕中去的呢?當然是 WindowManager 呢,那麼是如何將 View 傳到 WindowManager 中呢。


看 ActivityThread 中的 handleResumeActivity 方法:


// ActivityThread
public
void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,
String reason) {
......
final int forwardBit = isForward
? WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION : 0;

// If the window hasn't yet been added to the window manager,
// and this guy didn't finish itself or start another activity,
// then go ahead and add the window.
boolean willBeVisible = !a.mStartedActivity;
if (!willBeVisible) {
try {
willBeVisible
= ActivityManager.getService().willActivityBeVisible(
a.getActivityToken());
}
catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
if (r.window == null && !a.mFinished && willBeVisible) {
r.window
= r.activity.getWindow();
View decor
= r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm
= a.getWindowManager();
WindowManager.LayoutParams l
= r.window.getAttributes();
a.mDecor
= decor;
l.type
= WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode
|= forwardBit;
......
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded
= true;
wm.addView(decor, l);
}
else {
// The activity will get a callback for this {@link LayoutParams} change
// earlier. However, at that time the decor will not be set (this is set
// in this method), so no action will be taken. This call ensures the
// callback occurs with the decor set.
a.onWindowAttributesChanged(l);
}
}

// If the window has already been added, but during resume
// we started another activity, then don't yet make the
// window visible.
} else if (!willBeVisible) {
if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set");
r.hideForNow
= true;
}

// Get rid of anything left hanging around.
cleanUpPendingRemoveWindows(r, false /* force */);

// The window is now visible if it has been added, we are not
// simply finishing, and we are not starting another activity.
if (!r.activity.mFinished && willBeVisible && r.activity.mDecor != null && !r.hideForNow) {
if (r.newConfig != null) {
performConfigurationChangedForActivity(r, r.newConfig);
if (DEBUG_CONFIGURATION) {
Slog.v(TAG,
"Resuming activity " + r.activityInfo.name + " with newConfig "
+ r.activity.mCurrentConfig);
}
r.newConfig
= null;
}
if (localLOGV) Slog.v(TAG, "Resuming " + r + " with isForward=" + isForward);
WindowManager.LayoutParams l
= r.window.getAttributes();
if ((l.softInputMode
& WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION)
!= forwardBit) {
l.softInputMode
= (l.softInputMode
& (~WindowManager.LayoutParams.SOFT_INPUT_IS_FORWARD_NAVIGATION))
| forwardBit;
if (r.activity.mVisibleFromClient) {
ViewManager wm
= a.getWindowManager();
View decor
= r.window.getDecorView();
wm.updateViewLayout(decor, l);
}
}

r.activity.mVisibleFromServer
= true;
mNumVisibleActivities
++;
if (r.activity.mVisibleFromClient) {
          
// 這裏也會調用addview
r.activity.makeVisible();
}
}

r.nextIdle
= mNewActivities;
mNewActivities
= r;
if (localLOGV) Slog.v(TAG, "Scheduling idle handler for " + r);
Looper.myQueue().addIdleHandler(
new Idler());
}

上面的代碼主要做了以下幾件事:


1、獲取到 DecorView,設置不可見,然後通過 wm.addView(decor, l) 將 view 添加到 WindowManager;


2、在某些情況下,比如此時點擊了輸入框調起了鍵盤,就會調用 wm.updateViewLayout(decor, l) 來更新 View 的布局。


3、這些做完以後,會調用 activity 的  makeVisible ,讓視圖可見。如果此時 DecorView 沒有添加到 WindowManager,那麼會添加。 


// Activity
void makeVisible() {
if (!mWindowAdded) {
ViewManager wm
= getWindowManager();
wm.addView(mDecor, getWindow().getAttributes());
mWindowAdded
= true;
}
mDecor.setVisibility(View.VISIBLE);
}

 接下來,看下 addview 的邏輯。 WindowManager 的實現類是 WindowManagerImpl,而它則是通過 WindowManagerGlobal 代理實現 addView 的,我們看下 addView 的方法:


// WindowManagerGlobal   
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
// ......

root
= new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);

mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView);
}
catch (RuntimeException e) {
// BadTokenException or InvalidDisplayException, clean up.
if (index >= 0) {
removeViewLocked(index,
true);
}
throw e;
}
}

在這裏,實例化了 ViewRootImpl 。同時調用 ViewRootImpl 的 setView 方法來持有了 DecorView。此外這裏還保存了 DecorView ,Params,以及 ViewRootImpl 的實例。


現在我們終於知道為啥 View 是在 OnResume 的時候可見的呢。


 ViewRootImpl


實際上,View 的繪製是由 ViewRootImpl 來負責的。每個應用程序窗口的 DecorView 都有一個與之關聯的 ViewRootImpl 對象,這種關聯關係是由 WindowManager 來維護的。


先看 ViewRootImpl 的 setView 方法,該方法很長,我們將一些不重要的點註釋掉:


   /** 
* We have one child
*/
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView
= view;
......

mAdded
= true;
int res; /* = WindowManagerImpl.ADD_OKAY; */

// Schedule the first layout -before- adding to the window
// manager, to make sure we do the relayout before receiving
// any other events from the system.

requestLayout();
......
}
}
}

這裏先將 mView 保存了 DecorView 的實例,然後調用 requestLayout() 方法,以完成應用程序用戶界面的初次布局。


 public void requestLayout() { 
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested
= true;
scheduleTraversals();
}
}

因為是 UI 繪製,所以一定要確保是在主線程進行的,checkThread 主要是做一個校驗。接着調用 scheduleTraversals 開始計劃繪製了。


void scheduleTraversals() { 
if (!mTraversalScheduled) {
mTraversalScheduled
= true;
mTraversalBarrier
= mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable,
null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}

這裏主要關注兩點:


mTraversalBarrier : Handler 的同步屏障。它的作用是可以攔截 Looper 對同步消息的獲取和分發,加入同步屏障之後,Looper 只會獲取和處理異步消息,如果沒有異步消息那麼就會進入阻塞狀態。也就是說,對 View 繪製渲染的處理操作可以優先處理(設置為異步消息)。


mChoreographer: 編舞者。統一動畫、輸入和繪製時機。也是這章需要重點分析的內容。


mTraversalRunnable :TraversalRunnable 的實例,是一個Runnable,最終肯定會調用其 run 方法:


final class TraversalRunnable implements Runnable { 
@Override
public void run() {
doTraversal();
}
}

doTraversal,如其名,開始繪製了,該方法內部最終會調用 performTraversals 進行繪製。


  void doTraversal() { 
if (mTraversalScheduled) {
mTraversalScheduled
= false;
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

if (mProfile) {
Debug.startMethodTracing(
"ViewAncestor");
}

performTraversals();

if (mProfile) {
Debug.stopMethodTracing();
mProfile
= false;
}
}
}

到此,DecorView 與 activity 之間的綁定關係就講完了,下一章,將會介紹 performTraversals 所做的事情,也就是 View 繪製流程。 

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

※為什麼 USB CONNECTOR 是電子產業重要的元件?



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



※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光



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




Orignal From: Android DecorView 與 Activity 綁定原理分析

留言

這個網誌中的熱門文章

有了四步解題法模板,再也不害怕動態規劃!(看不懂算我輸)

導言 動態規劃問題一直是算法面試當中的重點和難點,並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到,這篇文章的目的主要是解釋清楚 什麼是動態規劃 ,還有就是面對一道動態規劃問題,一般的 思考步驟 以及其中的注意事項等等,最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃,或者僅僅只有耳聞,或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 ",如果更準確些,其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中,大家經常會遇到一些系統配置的問題,配置不對,系統就會報錯,這個時候一般都會去 Google 或者是查閱相關的文檔,花了一定的時間將配置修改好。 過了一段時間,去到另一個系統,遇到類似的問題,這個時候已經記不清之前修改過的配置文件長什麼樣,這個時候有兩種方案,一種方案還是去 Google 或者查閱文檔,另一種方案是借鑒之前修改過的配置,第一種做法其實是萬金油,因為你遇到的任何問題其實都可以去 Google,去查閱相關文件找答案,但是這會花費一定的時間,相比之下,第二種方案肯定會更加地節約時間,但是這個方案是有條件的,條件如下: 之前的問題和當前的問題有着關聯性,換句話說,之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中,可以看到的是,上面這兩個條件均滿足,大可去到之前配置過的文件中,將配置拷貝過來,然後做些細微的調整即可解決當前問題,節約了大量的時間。 不知道你是否從這些描述中發現,對於一個動態規劃問題,我們只需要從兩個方面考慮,那就是 找出問題之間的聯繫 ,以及 記錄答案 ,這裏的難點其實是找出問題之間的聯繫,記錄答案只是順帶的事情,利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話,接    動態規劃 算法是通過拆分問題,定義問題狀態和狀態之間的關係,使得問題能夠以遞推(或者說分治)的方式去解決。它的幾個重要概念如下所述。    階段: 對於一個完整的問題過程,適當的切分為若干個相互聯繫的子問題,每次在求解一個子問題...

計算機本地文件快要滅絕了

   編者按: 文件是数字世界的基石,是我們基本的工作單位。但是,隨着互聯網的雲化、平台化、服務化,文件日益變得可有可無。這樣一種改變究竟好不好呢?喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處,哪怕這讓他顯得不合時宜。原文發表在 medium 上,標題是:Computer Files Are Going Extinct   我喜歡文件。我喜歡對文件重命名、移動、排序,改變它們在文件夾中的显示方式,去備份文件,將之上傳到互聯網,恢復它們,對其進行複製,甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻,在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章,文章會放在文件裏面。如果我要生成圖像,圖像會保存進文件裏面。    謳歌 files.doc   文件是擬物化的。這是個很花哨的詞,只是用來表示文件是反映現實物品的一個数字概念。比方說,Word 文檔就像一張紙,躺在你的辦公桌上(desktop)。JPEG 就像一幅畫,等等。它們每個都有一個小圖標,圖標的樣子看起來像它們所代表的現實物品。一堆紙,一個畫框,一個馬尼拉文件夾。真的挺很迷人的。   我喜歡文件的一點是,不管裏面有什麼,跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。   自從我開始在 Windows 95 裏面創建文件以來,我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機    services.mp3 的興起   十幾歲的時候,我開始痴迷於收集和管理数字音樂:我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運,有自己的 CD 刻錄機的話,就可以將它們刻錄到 CD 上,然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤!   我會仔細端詳我的收藏,然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝,大家開始開發可以在雲端自動獲取曲目列表的工具,這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西,儘管...

純電動 Mini Cooper SE 將成為中國國產車,年產 16 萬輛

BMW 集團與中國長城汽車合資,將於江蘇建立新廠,專門投入生產 MINI Cooper SE 和部分長城品牌電動車,預計於 2022 年完工並投入生產,每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper,在許多車迷心中都有著特殊的地位,今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後,獲得熱烈迴響,預訂數量已接近 8 萬台,顯示大家對於純電 Mini 的熱愛,因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價,最低從 27,900 歐元起算,美國售價約 29,900 美元。相比現有的三門款,只貴了一成左右。然而,三年後,中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元,扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布,將組建合資公司光束汽車,投入在中國的電動車生產計畫,而現在他們正式宣布啟動計畫,於江蘇張家港打造一個新工廠,全部投入電動車的製造,包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造,不難想像當產能轉移到中國後,Mini Cooper SE 的價格將有機會進一步調降,來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠,採用一個新的產銷模式,由 BMW 和長城共同合作開發、設計、製造新產品,但是銷售通路完全沿用原本的品牌渠道。 換句話說,2020 年到 2022 年銷售的電動 Mini,將會是英國製造,而 2022 年後就會有中國製造版本開賣,考量到 Mini 在中國每年約有 30 萬輛的銷售額,同時油電版的 Coutryman 銷量更佔了全球將近五分之一,無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後,簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上,盡力保持著跟經典造型一致的設計,畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌,車頭的氣壩則變成封閉式設計,除此之外,幾乎看不出來差別,連馬達...