1. 前言

之前用PointLight做了一個番茄鍾，效果還不錯，具體可見這篇文章：

後來試玩了Win2D，這次就用Win2D實現文字的鏤空效果，配合PointLight做一個內斂不張揚的番茄鍾。

實現鏤空文字的核心思想是使用CanvasGeometry.CreateText從TextLayout獲取一個Geometry，然後使用DrawGeometry將它畫到DrawingSurface。這篇文章介紹了具體的實現步驟。

2. 參考例子

Win2D Gallery提供了大量Win2D的Sample，這次就參考了其中的文字鏤空效果例子，地址和運行效果如下：

3. 實現步驟

Sample的代碼量雖多，其實核心並不複雜，下面講講需要用到的API：

3.1 CanvasDevice.GetSharedDevice

因為要用到Win2D，所以首先要引用 nuget包。因為我的目標不是輸出到CanvasControl上，而是想要輸出到一個SpriteVisual上，所以使用：

var canvasDevice = CanvasDevice.GetSharedDevice();

3.2 CanvasComposition.CreateCompositionGraphicsDevice

然後創建一個Compositor，並將這個Compositor和CanvasDevice關聯起來，這裏需要使用 創建 ：

var compositor = ElementCompositionPreview.GetElementVisual(this).Compositor;
var graphicsDevice = CanvasComposition.CreateCompositionGraphicsDevice(compositor, canvasDevice);

3.3 CompositionGraphicsDevice.CreateDrawingSurface

然後使用創建一個對象，它是用來繪畫內容的表面：

var drawingSurface = graphicsDevice.CreateDrawingSurface(e.NewSize, DirectXPixelFormat.B8G8R8A8UIntNormalized, DirectXAlphaMode.Premultiplied);

3.4 Compositor.CreateSurfaceBrush

使用創建一個CompositionSurfaceBrush，它的作用是使用像素繪製SpriteVisual，簡單來說它就是一張位圖，然後輸出到SpriteVisual上：

var maskSurfaceBrush = compositor.CreateSurfaceBrush(drawingSurface);
spriteTextVisual.Brush = maskSurfaceBrush;

3.5 CanvasComposition.CreateDrawingSession

有了CompositionDrawingSurface就可以為所欲為了，將這個DrawingSurface作為參數，調用創建，DrawingSession提供了多個函數，可以自由地在DrawingSurface上畫文字、形狀、圖片甚至SVG。

using (var session = CanvasComposition.CreateDrawingSession(drawingSurface))
{

}

3.6 CanvasTextFormat和CanvasTextLayout

要再DrawingSurface上寫字，需要，而CanvasTextLayout中的文字大小、格式等則由定義：

using (var textFormat = new CanvasTextFormat()
{
    FontSize = (float)FontSize,
    Direction = CanvasTextDirection.LeftToRightThenTopToBottom,
    VerticalAlignment = CanvasVerticalAlignment.Center,
    HorizontalAlignment = CanvasHorizontalAlignment.Center,

})
{
    using (var textLayout = new CanvasTextLayout(session, Text, textFormat, width, height))
    {
        Color fontColor = FontColor;
        session.DrawTextLayout(textLayout, 0, 0, fontColor);
    }
}

3.7 CanvasGeometry.CreateText

因為我的目標是鏤空的文字，所以不能直接使用DrawTextLayout。這裏需要使用從TextLayout獲取一個Geometry，然後使用DrawGeometry將它畫到DrawingSurface。CanvasStrokeStyle是可選的，它控制邊框的虛線。

using (var textGeometry = CanvasGeometry.CreateText(textLayout))
{
    var dashedStroke = new CanvasStrokeStyle()
    {
        DashStyle = DashStyle
    };
    session.DrawGeometry(textGeometry, OutlineColor, (float)StrokeWidth, dashedStroke);
}

4. 封裝為控件

將上面的代碼總結一下，封裝為一個OutlineTextControl 控件，它提供了Text、OutlineColor、FontColor等屬性，在控件SizeChanged時，或者各個屬性改變時調用DrawText重新在CompositionDrawingSurface上繪製文字。代碼大致如下：

public class OutlineTextControl : Control
{
    private CompositionDrawingSurface _drawingSurface;

    public OutlineTextControl()
    {
        var compositor = ElementCompositionPreview.GetElementVisual(this).Compositor;
        var graphicsDevice = CanvasComposition.CreateCompositionGraphicsDevice(compositor, CanvasDevice.GetSharedDevice());
        var spriteTextVisual = compositor.CreateSpriteVisual();

        ElementCompositionPreview.SetElementChildVisual(this, spriteTextVisual);
        SizeChanged += (s, e) =>
        {
            _drawingSurface = graphicsDevice.CreateDrawingSurface(e.NewSize, DirectXPixelFormat.B8G8R8A8UIntNormalized, DirectXAlphaMode.Premultiplied);
            DrawText();
            var maskSurfaceBrush = compositor.CreateSurfaceBrush(_drawingSurface);
            spriteTextVisual.Brush = maskSurfaceBrush;
            spriteTextVisual.Size = e.NewSize.ToVector2();
        };
        RegisterPropertyChangedCallback(FontSizeProperty, new DependencyPropertyChangedCallback((s, e) =>
        {
            DrawText();
        }));
    }


    private void DrawText()
    {
        if (ActualHeight == 0 || ActualWidth == 0 || string.IsNullOrWhiteSpace(Text) || _drawingSurface == null)
            return;

        var width = (float)ActualWidth;
        var height = (float)ActualHeight;
        using (var session = CanvasComposition.CreateDrawingSession(_drawingSurface))
        {
            session.Clear(Colors.Transparent);
            using (var textFormat = new CanvasTextFormat()
            {
                FontSize = (float)FontSize,
                Direction = CanvasTextDirection.LeftToRightThenTopToBottom,
                VerticalAlignment = CanvasVerticalAlignment.Center,
                HorizontalAlignment = CanvasHorizontalAlignment.Center,

            })
            {
                using (var textLayout = new CanvasTextLayout(session, Text, textFormat, width, height))
                {
                    if (ShowNonOutlineText)
                    {
                        session.DrawTextLayout(textLayout, 0, 0, FontColor);
                    }

                    using (var textGeometry = CanvasGeometry.CreateText(textLayout))
                    {
                        var dashedStroke = new CanvasStrokeStyle()
                        {
                            DashStyle = DashStyle
                        };
                        session.DrawGeometry(textGeometry, OutlineColor, (float)StrokeWidth, dashedStroke);
                    }
                }
            }
        }
    }

//SOME CODE AND PROPERTIES

}

5. 結語

文章開頭的那個番茄鍾源碼可以在這裏查看：

也可以安裝我的番茄鍾應用試玩一下，安裝地址：

6. 參考

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

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

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

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

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

導讀：本文主要介紹了高德在服務單元化建設方面的一些實踐經驗，服務單元化建設面臨很多共性問題，如請求路由、單元封閉、數據同步，有的有成熟方案可以借鑒和使用，但不同公司的業務不盡相同，要盡可能的結合業務特點，做相應的設計和處理。

一、為什麼要做單元化

• 單機房資源瓶頸

隨着業務體量和服務用戶群體的增長，單機房或同城雙機房無法支持服務的持續擴容。

• 服務異地容災

異地容災已經成為核心服務的標配，有的服務雖然進行了多地多機房部署，但數據還是只在中心機房，實現真正意義上的異地多活，就需要對服務進行單元化改造。

二、高德單元化的特點

在做高德單元化項目時，我們首先要考慮的是結合高德的業務特點，看高德的單元化有什麼不一樣的訴求，這樣就清楚哪些經驗和方案是可以直接拿來用的，哪些又是需要我們去解決的。

高德業務和傳統的在線交易業務還是不太一樣，高德為用戶提供以導航為代表的出行服務，很多業務場景對服務的RT要求會很高，所以在做單元化方案時，盡可能減少對整體服務RT的影響就是我們需要重點考慮的問題，盡量做到數據離用戶近一些。轉換到單元化技術層面需要解決兩個問題:

1.用戶設備的單元接入需要盡可能的做到就近接入，用戶真實地理位置接近哪個單元就接入哪個單元，如華北用戶接入到張北，華南接入到深圳。

2.用戶的單元劃分最好能與就近接入的單元保持一致，減少單元間的跨單元路由。如用戶請求從深圳進來，用戶的單元劃分最好就在深圳單元，如果劃到張北單元就會造成跨單元路由。

另外一個區別就是高德很多業務是無須登錄的，所以我們的單元化方案除了用戶ID也要支持基於設備ID。

三、高德單元化實踐

服務的單元化架構改造需要一個至上而下的系統性設計，核心要解決請求路由、單元封閉、數據同步三方面問題。

請求路由：根據高德業務的特點，我們提供了取模路由和路由表路由兩種策略，目前上線應用使用較多的是路由表路由策略。

單元封閉：得益於集團的基礎設施建設，我們使用vipserver、hsf等服務治理能力保證服務同機房調用，從而實現單元封閉(hsf unit模式也是一種可行的方案，但個人認為同機房調用的架構和模式更簡潔且易於維護)。

數據同步：數據部分使用的是集團DB產品提供的DRC數據同步。

單元路由服務採用什麼樣的部署方案是我們另一個要面臨的問題，考慮過以下三種方案：

第一種SDK的方式因為對業務的強侵入性是首先被排除的，統一接入層進行代理和去中心化插件集成兩種方案各有利弊，但當時首批要接入單元化架構的服務很多都還沒有統一接入到gateway，所以基於現狀的考慮使用了去中心化插件集成的方式，通過在應用的nginx集成UnitRouter。

服務單元化架構

目前高德賬號，雲同步、用戶評論系統都完成了單元化改造，採用三地四機房部署，寫入量較高的雲同步服務，單元寫高峰能達到數w+QPS (存儲是mongodb集群)。

以賬號系統為例介紹下高德單元化應用的整體架構。

賬號系統服務是三地四機房部署，數據分別存儲在tair為代表的緩存和XDB里，數據存儲三地集群部署、全量同步。賬號系統服務器的Tengine上安裝UntiRouter，它請求的負責單元識別和路由，用戶單元劃分是通過記錄用戶與單元關係的路由表來控制。

PS：因歷史原因緩存使用了tair和自建的uredis(在redis基礎上添加了基於log的數據同步功能)，目前已經在逐步統一到tair。數據同步依賴tair和alisql的數據同步方案，以及自建的uredis數據同步能力。

就近接入實現方案

為滿足高德業務低延時要求，就要想辦法做到數據(單元)離用戶更近，其中有兩個關鍵鏈路，一個是通過aserver接入的外網連接，另一個是服務內部路由(盡可能不產生跨單元路由)。

措施1：客戶端的外網接入通過aserver上的配置，將不同地理區域(七個大區)的設備劃分到對應近的單元，如華北用戶接入張北單元。

措施2：通過記錄用戶和單元關係的路由表來劃分用戶所屬單元，這個關係是通過系統日誌分析出來的，用戶經常從哪個單元入口進來，就會把用戶劃分到哪個單元，從而保證請求入口和單元劃分的相對一致，從而減少跨單元路由。

所以，在最終的單元路由實現上我們提供了傳統的取模路由，和為降延時而設計的基於路由表路由兩種策略。同時，為解無須登錄的業務場景問題，上述兩種策略除了支持用戶ID，我們同時也支持設備ID。

路由表設計

路由表分為兩部分，一個是用戶-分組的關係映射表，另一個是分組-單元的關係映射表。在使用時，通過路由表查對應的分組，再通過分組看用戶所屬單元。分組對應中國大陸的七個大區。

先看“用戶-(大區)分組”：

路由表是定期通過系統日誌分析出來的，看用戶最近IP屬於哪個大區就劃分進哪個分組，同時也對應上了具體單元。當一個北京的用戶長期去了深圳，因IP的變化路由表更新后將划進新大區分組，從而完成用戶從張北單元到深圳單元的遷移。

再看“分組-單元”：

分組與單元的映射有一個默認關係，這是按地理就近來配置的，比如華南對應深圳。除了默認的映射關係，還有幾個用於切流預案的關係映射。

老用戶可以通過路由表來查找單元，新用戶怎麼辦？對於新用戶的處理我們會降級成取模的策略進行單元路由，直至下次路由表的更新。所以整體上看新用戶跨單元路由比例肯定是比老用戶大的多，但因為新用戶是一個相對穩定的增量，所以整體比例在可接受範圍內。

路由計算

有了路由表，接下來就要解工程化應用的問題，性能、空間、靈活性和準確率，以及對服務穩定性的影響這幾個方面是要進行綜合考慮的，首先考慮外部存儲會增加服務的穩定性風險，後面我們在BloomFilter 、BitMap和MapDB多種方案中選擇BloomFilter，萬分之幾的誤命中率導致的跨單元路由在業務可接受範圍內。

通過日誌分析出用戶所屬大區后，我們將不同分組做成多個布隆過濾器，計算時逐層過濾。這個計算有兩種特殊情況：

1) 因為BloomFilter存在誤算率，有可能存在一種情況，華南分組的用戶被計算到華北了，這種情況比例在萬分之3 (生成BloomFilter時可調整)，它對業務上沒有什麼影響，這類用戶相當於被劃分到一個非所在大區的分組裡，但這個關係是穩定的，不會影響到業務，只是存在跨單元路由，是可接受的。

2) 新用戶不在分組信息里，所以經過逐層的計算也沒有匹配到對應大區分組，此時會使用取模進行模除分組的計算。

如果業務使用的是取模路由而非路由表路由策略，則直接根據tid或uid計算對應的模除分組，原理簡單不詳表了。

單元切流

在發生單元故障進行切流時，主要分為四步驟

打開單元禁寫 (跨單元寫不敏感業務可以不配置)

檢查業務延時

切換預案

解除單元禁寫

PS：更新路由表時，也需要上述操作，只是第3步的切換預案變成切換新版本路由表；單元禁寫主要是了等待數據同步，避免數據不一致導致的業務問題。

核心指標

單元計算耗時1~2ms

跨單元路由比例底於5%

除了性能外，因就近接入的訴求，跨單元路由比例也是我們比較關心的重要指標。從線上觀察看，路由表策略單元計算基本上在1、2ms內完成，跨單元路由比例3%左右，整體底於5%。

四、後續優化

統一接入集成單元化能力

目前大部分服務都接入了統一接入網關服務，在網關集成單元化能力將大大減少服務單元化部署的成本，通過簡單的配置就可以實現單元路由，服務可將更多的精力放在業務的單元封閉和數據同步上。

分組機制的優化

按大區分組存在三個問題：

通過IP計算大區有一定的誤算率，會導致部分用戶劃分錯誤分組。

分組粒度太大，單元切流時流量不好分配。舉例，假如華東是我們用戶集中的大區，切流時把這個分組切到任意一個指定單元，都會造成單元服務壓力過大。

計算次數多，分多少個大區，理論最大計算次數是有多少次，最後採取取模策略。

針對上述幾個問題我們計劃對分組機製做如下改進

通過用戶進入單元的記錄來確認用戶所屬單元，而非根據用戶IP所在大區來判斷，解上述問題1。

每個單元劃分4個虛擬分組，支持更細粒度單元切流，解上述問題2。

用戶確實單元后，通過取模來劃分到不同的虛擬分組。每個單元只要一次計算就能完成，新用戶只需經過3次計算，解上述問題3。

熱更時的雙表計算

與取模路由策略不同，路由表策略為了把跨單元路由控制在一個較好的水平需要定期更新，目前更新時需要一個短暫的單元禁寫，這對於很多業務來說是不太能接受的。

為優化這個問題，系統將在路由表更新時做雙(路由)表計算，即將新老路由表同時加載進內存，更新時不再對業務做完全的禁寫，我們會分別計算當前用戶(或設備)在新老路由表的單元結果，如果單元一致，則說明路由表的更新沒有導致該用戶(或設備)變更單元，所以請求會被放行，相反如果計算結果是不同單元，說明發生了單元變更，該請求會被攔截，直至到達新路由表的一個完全起用時間。

優化前服務會完全禁寫比如10秒(時間取決於數據同步時間)，優化後會變成觸髮禁寫的是這10秒內路由發生變更的用戶，這將大大減少對業務的影響。

服務端數據驅動的單元化場景

前面提到高德在路由策略上結合業務的特別設計，但整體單元劃分還是以用戶(或設備)為維度來進行的，但高德業務還有一個大的場景是我們未來要面對和解決的，就是以數據維度驅動的單元設計，基於終端的服務路由會變成基於數據域的服務路由。

高德很多服務是以服務數據為核心的，像地圖數據等它並非由用戶直接產生。業務的發展數據存儲也將不斷增加，包括5G和自動駕駛，對應數據的爆髮式增長單點全量存儲並不實現，以服務端數據驅動的服務單元化設計，是我們接下來要考慮的重要應用場景。

寫在最後

不同的業務場景對單元化會有不同的訴求，我們提供不同的策略和能力供業務進行選擇，對於多數據服務我們建議使用業務取模路由，簡單且易於維護；對於RT敏感的服務使用路由表的策略來盡可能的降低服務響應時長的影響。另外，要注意的是強依賴性的服務要採用相同的路由策略。

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

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

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

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

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

本節主要介紹SpringBoot Application類相關源碼的深入學習。

主要包括：

1. SpringBoot應用自定義啟動配置
2. SpringBoot應用生命周期，以及在生命周期各個階段自定義配置。

本節採用SpringBoot 2.1.10.RELASE，對應示例源碼在：

SpringBoot應用啟動過程：

SpringApplication application = new SpringApplication(DemoApplication.class);
application.run(args);

一、Application類自定義啟動配置

創建SpringApplication對象后，在調用run方法之前，我們可以使用SpringApplication對象來添加一些配置，比如禁用banner、設置應用類型、設置配置文件（profile）

舉例：

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(DemoApplication.class);
        // 設置banner禁用
        application.setBannerMode(Banner.Mode.OFF);
        // 將application-test文件啟用為profile
        application.setAdditionalProfiles("test");
        // 設置應用類型為NONE，即啟動完成后自動關閉
        application.setWebApplicationType(WebApplicationType.NONE);
        application.run(args);
    }

}

​ 也可以使用SpringApplicationBuilder類來創建SpringApplication對象，builder類提供了鏈式調用的API，更方便調用，增強了可讀性。

        new SpringApplicationBuilder(YqManageCenterApplication.class)
                .bannerMode(Banner.Mode.OFF)
                .profiles("test")
                .web(WebApplicationType.NONE)
                .run(args);

二、application生命周期

SpringApplication的生命周期主要包括：

1. 準備階段：主要包括加載配置、設置主bean源、推斷應用類型（三種）、創建和設置SpringBootInitializer、創建和設置Application監聽器、推斷主入口類
2. 運行階段：開啟時間監聽、加載運行監聽器、創建Environment、打印banner、創建和裝載context、廣播應用已啟動、廣播應用運行中

我們先來看一下源碼的分析：

SpringBootApplication構造器：

public SpringApplication(ResourceLoader resourceLoader, Class<?>... primarySources) {
        
        // 設置默認配置
        this.sources = new LinkedHashSet();
        this.bannerMode = Mode.CONSOLE;
        this.logStartupInfo = true;
        this.addCommandLineProperties = true;
        this.addConversionService = true;
        this.headless = true;
        this.registerShutdownHook = true;
        this.additionalProfiles = new HashSet();
        this.isCustomEnvironment = false;
        this.resourceLoader = resourceLoader;
        Assert.notNull(primarySources, "PrimarySources must not be null");
        // 設置主bean源
        this.primarySources = new LinkedHashSet(Arrays.asList(primarySources));
        // 推斷和設置應用類型（三種）
        this.webApplicationType = WebApplicationType.deduceFromClasspath();
        // 創建和設置SpringBootInitializer
  this.setInitializers(this.getSpringFactoriesInstances(ApplicationContextInitializer.class));
        // 創建和設置SpringBoot監聽器
    this.setListeners(this.getSpringFactoriesInstances(ApplicationListener.class));
        // 推斷和設置主入口類
        this.mainApplicationClass = this.deduceMainApplicationClass();
    }

SpringApplication.run方法源碼：

public ConfigurableApplicationContext run(String... args) {
        // 開啟時間監聽
        StopWatch stopWatch = new StopWatch();
        stopWatch.start();
        ConfigurableApplicationContext context = null;
        Collection<SpringBootExceptionReporter> exceptionReporters = new ArrayList();
        this.configureHeadlessProperty();
    
        // 加載Spring應用運行監聽器（SpringApplicationRunListenter）
        SpringApplicationRunListeners listeners = this.getRunListeners(args);
        listeners.starting();

        Collection exceptionReporters;
        try {
            // 創建environment(包括PropertySources和Profiles)
            ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);
            ConfigurableEnvironment environment = this.prepareEnvironment(listeners, applicationArguments);
            this.configureIgnoreBeanInfo(environment);
            
            // 打印banner
            Banner printedBanner = this.printBanner(environment);
            
            // 創建context(不同的應用類型對應不同的上下文)
            context = this.createApplicationContext();
            exceptionReporters = this.getSpringFactoriesInstances(SpringBootExceptionReporter.class, new Class[]{ConfigurableApplicationContext.class}, context);
            // 裝載context(其中還初始化了IOC容器)
            this.prepareContext(context, environment, listeners, applicationArguments, printedBanner);
            // 調用applicationContext.refresh
            this.refreshContext(context);
            // 空方法
            this.afterRefresh(context, applicationArguments);
            stopWatch.stop(); // 關閉時間監聽；這樣可以計算出完整的啟動時間
            if (this.logStartupInfo) {
                (new StartupInfoLogger(this.mainApplicationClass)).logStarted(this.getApplicationLog(), stopWatch);
            }

            // 廣播SpringBoot應用已啟動，會調用所有SpringBootApplicationRunListener里的started方法
            listeners.started(context);
            
            // 遍歷所有ApplicationRunner和CommadnLineRunner的實現類，執行其run方法
            this.callRunners(context, applicationArguments);
        } catch (Throwable var10) {
            this.handleRunFailure(context, var10, exceptionReporters, listeners);
            throw new IllegalStateException(var10);
        }

        try {
            // 廣播SpringBoot應用運行中，會調用所有SpringBootApplicationRunListener里的running方法
            listeners.running(context);
            return context;
        } catch (Throwable var9) {
            // run出現異常時，處理異常；會調用報錯的listener里的failed方法，廣播應用啟動失敗，將異常擴散出去
            this.handleRunFailure(context, var9, exceptionReporters, (SpringApplicationRunListeners)null);
            throw new IllegalStateException(var9);
        }
    }

三、application生命周期自定義配置

在SpringApplication的生命周期中，我們還可以添加一些自定義的配置。

下面的配置，主要是通過實現Spring提供的接口，然後在resources下新建META-INF/spring.factories文件，在裏面添加這個類而實現引入的。

在準備階段，可以添加如下自定義配置：

3.1 自定義ApplicationContextInitializer的實現類

@Order(100)
public class MyInitializer implements ApplicationContextInitializer {

@Override
public void initialize(ConfigurableApplicationContext configurableApplicationContext) {
    System.out.println("自定義的應用上下文初始化器：" + configurableApplicationContext.toString());
}
}

再定義一個My2Initializer，設置@Order(101)

然後在spring.factories文件里如下配置：

# initializers
org.springframework.context.ApplicationContextInitializer=\
  com.example.applicationdemo.MyInitializer,\
  com.example.applicationdemo.My2Initializer

啟動項目：

3.2 自定義ApplicationListener的實現類

@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
    void onApplicationEvent(E var1);
}![file](https://img2018.cnblogs.com/blog/1860493/201911/1860493-20191125130012982-1676057906.png)

即監聽ApplicationEvents類的ApplicationListener接口的實現類。

首先查看有多少種ApplicationEvents:

裏面還可以進行拆分。

我們這裏設置兩個ApplicationListener，都用於監聽ApplicationEnvironmentPreparedEvent

@Order(200)
public class MyApplicationListener implements ApplicationListener<ApplicationEnvironmentPreparedEvent> {

    @Override
    public void onApplicationEvent(ApplicationEnvironmentPreparedEvent applicationEnvironmentPreparedEvent) {
        System.out.println("MyApplicationListener: 應用環境準備完畢" + applicationEnvironmentPreparedEvent.toString());
    }
}

在spring.factories中加入applicationListener的配置：

# application-listeners
org.springframework.context.ApplicationListener=\
  com.example.applicationdemo.MyApplicationListener,\
  com.example.applicationdemo.MyApplicationListener2

在啟動階段，可以添加如下自定義配置：

3.3 自定義SpringBootRunListener的實現類

監聽整個SpringBoot應用生命周期

public interface SpringApplicationRunListener {
    // 應用啟動
    void starting();

    // 應用ConfigurableEnvironment準備完畢，此刻可以將其調整
    void environmentPrepared(ConfigurableEnvironment environment);

    // 上下文準備完畢
    void contextPrepared(ConfigurableApplicationContext context);

    // 上下文裝載完畢
    void contextLoaded(ConfigurableApplicationContext context);

    // 啟動完成（Beans已經加載到容器中）
    void started(ConfigurableApplicationContext context);

    // 應用運行中
    void running(ConfigurableApplicationContext context);

    // 應用運行失敗
    void failed(ConfigurableApplicationContext context, Throwable exception);
}

我們可以自定義SpringApplicationRunListener的實現類，通過重寫以上方法來定義自己的listener。

比如：

public class MyRunListener implements SpringApplicationRunListener {

    // 注意要加上這個構造器，兩個參數都不能少，否則啟動會報錯，報錯的詳情可以看這個類的最下面
    public MyRunListener(SpringApplication springApplication, String[] args) {

    }

    @Override
    public void starting() {
        System.out.println("MyRunListener: 程序開始啟動");
    }

    // 其他方法省略，不做修改
}

然後在spring.factories文件中添加這個類：

org.springframework.boot.SpringApplicationRunListener=\
  com.example.applicationdemo.MyRunListener

啟動：

3.4 自定義ApplicationRunner或CommandLineRunner

application的run方法中，有這樣一行：

this.callRunners(context, applicationArguments);

仔細分析源碼，發現這一句的作用是：SpringBoot應用啟動過程中，會遍歷所有的ApplicationRunner和CommandLineRunner，執行其run方法。

private void callRunners(ApplicationContext context, ApplicationArguments args) {
        List<Object> runners = new ArrayList();
        runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
        runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
        AnnotationAwareOrderComparator.sort(runners);
        Iterator var4 = (new LinkedHashSet(runners)).iterator();

        while(var4.hasNext()) {
            Object runner = var4.next();
            if (runner instanceof ApplicationRunner) {
                this.callRunner((ApplicationRunner)runner, args);
            }

            if (runner instanceof CommandLineRunner) {
                this.callRunner((CommandLineRunner)runner, args);
            }
        }

    }

@FunctionalInterface
public interface CommandLineRunner {
    void run(String... args) throws Exception;
}

@FunctionalInterface
public interface ApplicationRunner {
    void run(ApplicationArguments args) throws Exception;
}

分別定義一個實現類，添加@Component，這兩個實現類不需要在spring.factories中配置。

好了，關於這些自定義配置的具體使用，後續會繼續進行介紹，請持續關注！感謝！

具體示例代碼請去查看。

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

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

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

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

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

前言

• Android View 的 事件處理在我們的編程中，可謂是無處不在了。但對於大多數人而言，一直都是簡單的使用，對其原理缺乏深入地認識。
• 學 Android 有一段時間了，最近發現，很多基礎知識開始有些遺忘了，所以從新複習了 View 的事件分發。特地整理成了這篇文章分享給大家。
• 本文不難，可以作為大家茶餘飯後的休閑。

祝大家閱讀愉快！

方便大家學習，我在 GitHub 上建立個 倉庫

• 倉庫內容與博客同步更新。由於我在 稀土掘金 簡書 CSDN 博客園 等站點，都有新內容發布。所以大家可以直接關注該倉庫，即使獲得精彩內容

• 倉庫地址：

一、View 的事件回調

• 我們結合源碼看看 View 的事件分發是個怎樣的過程，首先我們建立一個類 MyButton 類繼承 AppCompatButton 用於測試：

public class MyButton extends AppCompatButton {

    private final String TAG = "DeBugMyButton";
        public MyButton(Context context) {
        super(context);
    }

    public MyButton(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public MyButton(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

}

1.1 事件分發流程

• 我們都知道有一個方法叫做 public boolean dispatchTouchEvent(MotionEvent event) 。首先我們要知道，對於我們這個自定義控件，他的觸摸事件都是從我們 dispatchTouchEvent 這個方法開始往下去分發的。所以可以說：這個方法是一個入口方法。

1.1.1 onTouchEvent 作用

• 現在我們重寫該方法和另一個方法：onTouchEvent ，並且打印一行日誌：

@Override
public boolean dispatchTouchEvent(MotionEvent event) {
    Log.d(TAG, "----on dispatch Touch Event----");
    return super.dispatchTouchEvent(event);
}

@Override
public boolean onTouchEvent(MotionEvent event) {
    switch (event.getAction()) {
        case MotionEvent.ACTION_DOWN:
            Log.d(TAG, "----on touch event----");
    }
    return super.onTouchEvent(event);
}

• 然後我們在 MainActivity 中，設置一個實例化一個 MyButton 控件對象用於測試，並且給他添加一個 onClickListenter 和 setOnTouchListener

public class MainActivity extends AppCompatActivity {

    private final String TAG = "DeBugMainActivity";

    /**
     * 自定義控件 MyButton
     */
    private MyButton mMyButton;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        
        iniView();
    }

    /**
     * 實例化控件
     */
    private void iniView() {
        mMyButton = findViewById(R.id.my_button);

    mMyButton.setOnTouchListener(new View.OnTouchListener() {
        @Override
        public boolean onTouch(View v, MotionEvent event) {
            switch (event.getAction()) {
                case MotionEvent.ACTION_DOWN:
                    Log.d(TAG, "----on touch----");
                    break;
                default:
                    break;
            }
            return false;
        }
    });
    
    mMyButton.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View v) {
            Log.d(TAG, "----on click----");
        }
    });
    }
}

• 然後我們運行這個 Demo ，點擊 MyButton 按鈕，會的到如下日誌：

• 我們可以看到首先回調了這個 dispatchTouchEvent ，然後是它的監聽器 OnTouch ，接着是它的 onTouchEvent，最後又執行了 dispatchTouchEvent ，那麼這是為什麼呢？

• 這是因為我們這兒只監聽了 ACTION_DOWN 而當手指抬起時它同樣還回去回調 dispatchTouchEvent ，最後我們打印 OnClick 的回調。

• 總結一下就是：
  dispatchTouchEvent -> setOnTouchListener -> onTouchEvent -> setOnClickListener

• 說明我們 setOnClickListener 是通過 onTouchEvent 處理，產生了 OnClick 。一會我們再來看看其中的原理。

• 既然說 dispatchTouchEvent 像一個入口，就先讓我們來看下它是怎麼處理和操作的： 首先，既然我們調用了 super.dispatchTouchEvent(event) ，那麼我們就來看看它父類中是怎麼實現該方法的。不信的是，它的父類 AppCompatButton 也沒有實現該方法 ，最後經過層層搜尋，我們發現這個方法是屬於 View 的方法。

1.1.2 dispatchTouchEvent 的實現

• 那麼現在我們來看看 View 的 dispatchTouchEvent 怎麼實現的：

public boolean dispatchTouchEvent(MotionEvent event) {
    ......
        //noinspection SimplifiableIfStatement
        ListenerInfo li = mListenerInfo;
        if (li != null && li.mOnTouchListener != null
                && (mViewFlags & ENABLED_MASK) == ENABLED
                && li.mOnTouchListener.onTouch(this, event)) {
            result = true;
        }

        if (!result && onTouchEvent(event)) {
            result = true;
        }
    }

    if (!result && mInputEventConsistencyVerifier != null) {
        mInputEventConsistencyVerifier.onUnhandledEvent(event, 0);
    }

    // Clean up after nested scrolls if this is the end of a gesture;
    // also cancel it if we tried an ACTION_DOWN but we didn't want the rest
    // of the gesture.
    if (actionMasked == MotionEvent.ACTION_UP ||
            actionMasked == MotionEvent.ACTION_CANCEL ||
            (actionMasked == MotionEvent.ACTION_DOWN && !result)) {
        stopNestedScroll();
    }

    return result;
}

• 在 dispatchTouchEvent 中，我們可以發現下面這樣一個代碼塊

if (li != null && li.mOnTouchListener != null
        && (mViewFlags & ENABLED_MASK) == ENABLED
        && li.mOnTouchListener.onTouch(this, event)) {
    result = true;
}

• 不難看出：如果執行了這個代碼段，那麼後面的方法就不會執行了，並且 dispatchTouchEvent 會返回 true 。我們再仔細觀察下其中的條件：在 if 條件中我們發現：只有當其滿足 li.mOnTouchListener != null && (mViewFlags & ENABLED_MASK) == ENABLED && li.mOnTouchListener.onTouch(this, event)) 時才會執行 if 內的操作

• 經過上面分析，我們可以知道： onTouch 事件必須返回 true 時，才會執行該方法塊。那麼我們就回到 MainActivity 中。我們發現 setOnTouchListener 的 onTouch 默認返回值是 false（ 不滿足返回值為 true ), 這就表明他會繼續去執行下一個代碼塊：

if (!result && onTouchEvent(event)) {
    result = true;
}

• 執行這個 if 語句的過程中。首先調用了 onTouchEvent 方法。這就解釋了，為什麼它先執行了 mOnTouchListener ，然後再執行 onTouchEvent 。

• 現在我們就可以總結一下：首先我們回調了 dispatchTouchEvent ，然後回調 OnTouchListener 。這個時候，如果 TouchListener 沒有 return true ，那麼就會接着去運行 onTouchEvent （ 當然，如果 return true 後面的層級就不會執行了 。一句話說就是：到那個層級 return true 那麼哪個層級就消費掉了這個事件 ）。

1.1.3 onTouchEvent 的處理

• 同時我們還有一個結果：我們 onClick （ 包括我們的 onLongClick ） 是來自於我們 onTouchEvent 這個方法的處理。那麼下面我們就來看看 View 中是怎麼處理 onTouchEvent 的：

public boolean onTouchEvent(MotionEvent event) {
    。。。

    if (clickable || (viewFlags & TOOLTIP) == TOOLTIP) {
        switch (action) {
            case MotionEvent.ACTION_UP:
                。。。
                break;

            case MotionEvent.ACTION_DOWN:
                if (event.getSource() == InputDevice.SOURCE_TOUCHSCREEN) {
                    mPrivateFlags3 |= PFLAG3_FINGER_DOWN;
                }
                mHasPerformedLongPress = false;

                if (!clickable) {
                    checkForLongClick(0, x, y);
                    break;
                }

                if (performButtonActionOnTouchDown(event)) {
                    break;
                }

                // Walk up the hierarchy to determine if we're inside a scrolling container.
                boolean isInScrollingContainer = isInScrollingContainer();

                // For views inside a scrolling container, delay the pressed feedback for
                // a short period in case this is a scroll.
                if (isInScrollingContainer) {
                    mPrivateFlags |= PFLAG_PREPRESSED;
                    if (mPendingCheckForTap == null) {
                        mPendingCheckForTap = new CheckForTap();
                    }
                    mPendingCheckForTap.x = event.getX();
                    mPendingCheckForTap.y = event.getY();
                    postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
                } else {
                    // Not inside a scrolling container, so show the feedback right away
                    setPressed(true, x, y);
                    checkForLongClick(0, x, y);
                }
                break;

            case MotionEvent.ACTION_CANCEL:
                。。。
                break;

            case MotionEvent.ACTION_MOVE:
                if (clickable) {
                    drawableHotspotChanged(x, y);
                }

                // Be lenient about moving outside of buttons
                if (!pointInView(x, y, mTouchSlop)) {
                    // Outside button
                    // Remove any future long press/tap checks
                    removeTapCallback();
                    removeLongPressCallback();
                    if ((mPrivateFlags & PFLAG_PRESSED) != 0) {
                        setPressed(false);
                    }
                    mPrivateFlags3 &= ~PFLAG3_FINGER_DOWN;
                }
                break;
        }

        return true;
    }

    return false;
}

二、onClick 和 OnLongClick

• 因為我們是拿 ACTION_DOWN 作為舉例的。那麼我們先來分析一下 case MotionEvent.ACTION_DOWN : 中 onTouchEvent 是怎麼執行的，以及 onClick 和 OnLongClick 是如何產生的：

2.1 onClick 和 OnLongClick 的產生

• 首先，當我們手指按下時，有一個 mHasPerformedLongPress 標識會先被設為 false 。再往下會執行一行 postDelayed(mPendingCheckForTap 和 ViewConfiguration.getTapTimeout()); 我們來看看這一行的作用：

• 首先，從名字我們就可以猜測，這是個延時執行的方法。我們進一步閱讀發現 mPendingCheckForTap 是一個 Runnable 動作； ViewConfiguration.getTapTimeout() 是一個 100mm 的延時。也就是說延時 100mm 後去執行 mPendingCheckForTap 中的動作。那麼我們就來看看 mPendingCheckForTap 中做了什麼：

private final class CheckForTap implements Runnable {
    public float x;
    public float y;

    @Override
    public void run() {
        mPrivateFlags &= ~PFLAG_PREPRESSED;
        setPressed(true, x, y);
        checkForLongClick(ViewConfiguration.getTapTimeout(), x, y);
    }
}

• 也就是說，停一百秒后就開始檢查，用戶的手指是否離開了屏幕。（ 就是當前 ACTION_DOWN 之後，有沒有觸發了 ACTION_UP 這個環節 ），但是 ACTION_DOWN 后，我們還有一個 ACTION_MOVE 過程。在這個 ACTION_MOVE 中，如果 100mm 內離開了屏幕、或者離開了這個控件就會觸發 ACTION_UP ，那麼就認為這是一個點擊事件 onClick 。如果沒有觸發 ACTION_UP 的話，就會再延時 400mm 。

2.2 ACTION_DOWN 之後流程

• 在 ACTION_DOWN 之後，會先等 100mm
• 如果沒有離開屏幕或者離開控件，就是沒有觸發 ACTION_UP 的話，就會再延時 400mm。
• 這 500mm 后就會觸發 onLongClick 事件。

2.3 那麼我們現在來驗證一下 onLongClick ：

• 首先再 MainActivity 中加上：

mMyButton.setOnLongClickListener(new View.OnLongClickListener() {
    @Override
    public boolean onLongClick(View v) {

        return true;
    }
});

• 接着，我們發現 OnLongClick 是有返回值的，如果返回值是 false 還會接着去觸發 onClick 事件，如果返回 true 的話，那麼這個長按事件就直接被消費掉了（ 也就是這個點擊事件就不會完後傳遞到 OnClickListener 中去了 ）。

2.4 總結

• 100mm 時為點擊，500mm 時為長按，接着觸髮長按事件。
• 再看長按事件的返回值，如果時 true 就結束。
• 如果時 false 那麼 OnClickListener 就同樣也被執行。
• 這就是由 obTouchEvent 產生出來的 onClick/onLongClick 的來龍去脈。

總結

• 我們 View 的事件方法，基本上就是這麼一個思路，從 dispatchTouchEvent 到 OnTouchListener 監聽器，再到 onTouchEvent，接着 onTouchEvent 由產生了 onClick/onLongClick 。
• 如果大家感興趣的話可以更深入的去閱讀源碼。
• 重點：學 Android 有一段時間了，我打算好好的梳理一下所學知識，包括 Activity 、Service 、BroadcastRecevier 事件分發、滑動衝突、新能優化等所有重要模塊，歡迎大家關注 ，方便及時接收更新
• 如果有可以補充的知識點，歡迎大家在評論區指出。

碼字不易，你的點贊是我總結的最大動力！

• 由於我在「稀土掘金」「簡書」「CSDN」「博客園」等站點，都有新內容發布。所以大家可以直接關注我的 GitHub 倉庫，以免錯過精彩內容！

• 倉庫地址：

• 一萬多字長文，加上精美思維導圖，記得點贊哦，歡迎關注 ，我們下篇文章見！

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

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

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

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

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

一年多以前，曾經以為自己對 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 是電子產業重要的元件?

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

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

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

08 決策樹與隨機森林

決策樹之信息論基礎

認識決策樹

1. 來源： 決策樹的思想來源非常樸素，程序設計中的條件分支結構就是if – then 結構，最早的決策樹就是利用這類結構分割數據的一種分類學習方法。

2. 舉例：是否見相親對象

信息的度量和作用

1. 克勞德 .艾爾伍德 .香農：信息論創始人，密西根大學學士，麻省理工學院博士。 1948年發表了划時代論文 – 通信的數學原理，奠定了現代信息論的基礎。

2. 信息的單位： 比特 （bit)

3. 舉例： 以32支球隊爭奪世界杯冠軍

• 如果不知道任何球隊的信息，每支球隊得冠概率相等。
  以二分法預測，最少需要使用5次才能預測到準確結果。 5 = log32 (以2為底）
  5 = -（1/32log1/32 + 1/32log1/32 + ……)

• 開放一些信息，則小於5bit, 如1/6 德國，1/6 巴西， 1/10 中國
  5 > -(1/6log1/4 + 1/6log1/4 + ….)

1. 信息熵：

• “誰是世界杯冠軍”的信息量應該比5 bit少， 它的準確信息量應該是：
• H = -(p1logp1 + p2logp2 + p3logp3 +……p32logp32 ) Pi 為第i支球隊獲勝的概率
• H 的專業術語就是信息熵，單位為比特

決策樹的劃分以及案例

信息增益

1. 定義： 特徵A對訓練數據集D的信息增益g(D,A), 定義為集合D的信息熵H(D)與特徵A給定條件下D的信息條件熵H(D|A) 之差，即：
   g(D,A) = H（D) – H(D | A)
   注： 信息增益表示得知特徵 X 的信息而使得類 Y的信息的不確定性減少的程度。

2. 以不同特徵下的信貸成功率為例

• H(D) = -(9/15log(9/15) + 6/15log(6/15)) = 0.971 # 以類別進行判斷，只有是否兩種類別
• gD,年紀） = H(D) – H(D’|年紀） = 0.971 – [1/3H(青年）+ 1/3H(中年）+ 1/3H(老年）] # 三種年紀對應的目標值均佔1/3
  – H(青年) = -（2/5log(2/5) + 3/5log(3/5)) # 青年類型中，類別的目標值特徵為（2/5, 3/5)
  – H(中年) = -（2/5log(2/5) + 3/5log(3/5))
  – H(老年) = -（4/5log(2/5) + 1/5log(3/5))

令A1, A2, A3, A4 分別表示年齡，有工作，有房子和信貸情況4個特徵，則對應的信息增益為：
g(D,A1) = H(D) – H(D|A1)
其中，g(D,A2) = 0.324 , g(D,A3) = 0.420 , g(D,A4) = 0.363
相比而言，A3特徵（有房子）的信息增益最大，為最有用特徵。
所以決策樹的實際劃分為：

常見決策樹使用的算法

1. ID3

• 信息增益，最大原則

1. C4.5

• 信息增益比最大原則 （信息增益占原始信息量的比值）

1. CART

• 回歸樹： 平方誤差最小
• 分類樹： 基尼係數最小原則 （劃分的細緻），sklearn默認的劃分原則

Sklearn決策樹API

1. sklearn.tree.DecisionTreeClassifier(criterion=’gini’, max_depth=None, random_state=None)

• criterion （標準）: 默認基尼係數，也可以選用信息增益的熵‘entropy’
• max_depth: 樹的深度大小
• random_state: 隨機數種子

1. 決策樹結構
   sklearn.tree.export_graphviz() 導出DOT文件格式

• estimator: 估算器
• out_file = “tree.dot” 導出路徑
• feature_name = [,] 決策樹特徵名

決策樹預測泰坦尼克號案例

import pandas as pd
from sklearn.feature_extraction import DictVectorizer
from sklearn.model_selection import train_test_split
from sklearn.tree import DecisionTreeClassifier, export_graphviz

"""
泰坦尼克數據描述事故后乘客的生存狀態，該數據集包括了很多自建旅客名單，提取的數據集中的特徵包括：
票的類別，存貨，等級，年齡，登錄，目的地，房間，票，船，性別。
乘坐等級（1,2,3）是社會經濟階層的代表，其中age數據存在缺失。
"""


def decision():
    """
    決策樹對泰坦尼克號進行預測生死
    :return: None
    """
    # 1.獲取數據
    titan = pd.read_csv('./titanic_train.csv')

    # 2.處理數據，找出特徵值和目標值
    x = titan[['Pclass', 'Age', 'Sex']]
    y = titan[['Survived']]
    # print(x)

    # 缺失值處理 （使用平均值填充）
    x['Age'].fillna(x['Age'].mean(), inplace=True)
    print(x)
    # 3.分割數據集到訓練集和測試集
    x_train, x_test, y_train, y_test = train_test_split(x, y, test_size=0.25)

    # 4. 進行處理（特徵工程) 特徵，類別 --> one_hot編碼
    dict = DictVectorizer(sparse=False)
    x_train = dict.fit_transform(x_train.to_dict(orient='records'))
    print(dict.get_feature_names())
    x_test = dict.transform(x_test.to_dict(orient='records'))  # 默認一行一行轉換成字典
    print(x_train)

    # 5. 用決策樹進行預測
    dec = DecisionTreeClassifier()
    dec.fit(x_train, y_train)

    # 預測準確率
    print("預測的準確率：", dec.score(x_test, y_test))

    # 導出決策樹
    export_graphviz(dec, out_file='./tree.dot', feature_names=['Pclass', 'Age', 'Sex'])
    return None


if __name__ == '__main__':
    decision()

隨機森林

集成學習方法

1. 定義：集成學習通過建立幾個模型組合，來解決單一預測問題。其工作原理是生成多個分類器 / 模型，各組獨立地學習和作出預測。這些預測最後結合成單預測，因此優於任何一個單分類的租出預測。

隨機森林

1. 定義：在機器學習中，隨機森林是一個包含多個決策樹的分類器，並且其輸出的類別是由個別樹輸出的類別的眾數而定。
   例如： 訓練了5棵樹，其中4棵樹的結果是True, 1棵樹為False, 那麼最終的結果就是True. (投票）

2. 問題： 如果每棵樹使用相同的特徵，相同的分類器，參數也相同，建立的每棵樹不就是相同的么？

隨機森林建立多個決策樹的過程：

單個樹的建立：(N個樣本，M個特徵）

1. 隨機在N個樣本中選擇一個樣本，重複N次， 樣本有可能重複
2. 隨機在M個特徵當中選出m個特徵 m << M
3. 建立10棵決策樹，樣本，特徵大多不一樣 隨機有放回的抽樣 （bootstrap抽樣)

為什麼要隨機抽樣訓練集？

如果不隨機抽樣，每棵樹的訓練集都一樣，那麼最終訓練處的樹分類結果也是完全一樣的

為什麼要有放回的抽樣？

如果不是有放回的抽樣，那麼每棵樹的訓練樣本都是不同的，都是沒有交集的，這樣的每棵樹都是“有偏的”，“片面的”。即，每棵樹訓練出來都是有很大的差異，而隨機森鈴最後分類取決於多棵樹（弱分類器）的投票表決。

隨機森林 API

• 分類器：sklearn.ensemble.RandomForestClassifier
  • n_estimators：integer(整數），option, default=10 (森林里數目的數量）
  • criteria: string (default =’gini’) 分割特徵的測量方法
  • max_depth 樹的最大深度
  • max_feature = ‘auto’ 每個決策樹的最大特徵數量
  • bootstrap: default = True 是否放回抽樣

隨機森林的優點

1. 在當前的所有算法中，具有極好的準確率
2. 能有有效地運行在大數據集上 （樣本，特徵）
3. 能夠處理具有高維特徵的輸入樣本，不需要降維
4. 能夠評估各個特徵在分類問題上的重要性

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

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

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

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

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

中華汽車在 7 月 19 日發表新款電動機車 eMOVING iE125，極速可達到時速 100 公里，成為市場關注的焦點。

iE 125 的命名除了代表 intelligent electricity，也有 industrial engineering 的含義，125 則象徵 125cc 等級燃油機車的性能與操控。iE125 安全極速達到時速 100 公里，靜止加速到時速 50 公里僅需 3.9 秒，30% 坡度爬坡最高速為時速 32 公里。iE125 在充滿電之後，時速 30 公里之下續航里程為 155 公里，TES 變速續航里程為 82 公里。支援超級快充功能，充電 10 分鐘就能充滿 50% 的電力，可以行駛 78 公里。

iE125 含電池車重為 124 公斤，配備 CBS 連動煞車和 IP67 防水等級。提供 ECO、SPEED 和 BOOST 三種行車模式，讓消費者在不同情境下使用。特別的電動駐車功能只要按下按鈕就能直接立起中柱，車主不再需要為立中柱而困擾。配置 QC 3.0 USB 充電座，方便騎乘時進行充電。

eMOVING iE125 藍色版。

eMOVING iE125 白色版。

eMOVING iE125 橘色版。

eMOVING iE125 灰色版。

iE125 精緻型儀錶板螢幕為彩色液晶螢幕，豪華型和旗艦型則為汽車級 TFT。豪華型和旗艦型搭載車輛診斷系統，能在儀表板上顯示車身、動力、電池和胎壓等資訊，並提供異常提示與保養提醒。儀表板還可以進行個人化設定，自由更換儀表板主題與桌布。

iE125 豪華型和旗艦型具有遙控防盜中控鎖，能夠連結手機進行上鎖、解鎖和座墊開啟。iOS 版本的 App 支援即時來電提醒，來電與訊息通知會即時顯示。旗艦型還特別內建前方行車記錄器和胎壓偵測器，進一步確保行車安全。

儀錶板能顯示各種車身資訊。

eMOVING 將充電分為 3 種類型，分別在不同需求時使用。家用滿足平時充電需求，約 160 分鐘可以充滿 50% 的電力。快速充電站則供在外逛街或用餐時補充電力，約 30 分鐘可以充滿 50% 的電力。超級充電站供臨時路途中繼充電，約 10 分鐘可以充滿 50% 的電力。

消費者可以自行選擇電池租賃方案，eMOVING 提供電池永久保固。基礎型在家充電每月 399 元，輕量型每月 599 元額外提供 100 分鐘的超級充電分鐘數，進階型每月 799 元可以不限時數進行超級充電。為了推廣超級充電，12 月以前輕量型和進階型方案皆以每月 499 元計價，而且享受不限時數的超級充電。

中華汽車預計在 12 月佈建 70 座以上的快速充電站，2020 年 6 月更要佈建超過 150 座快速充電站，早期合作夥伴包括肯德基、家樂福、順益汽車和滙豐汽車。中華汽車也宣布捐贈 5 座超級充電站給桃園市政府，未來讓符合快充共通規格電動機車車主都能免費充電。

中華汽車捐贈 5 座超級充電站給桃園市政府。

eMOVING 推出了 10 月底前購車，就贈送 5,000 元購車金的優惠，可以全額折抵車價或購買配件。iE125 提供藍色、白色、灰色和橘色 4 種顏色讓消費者選擇，精緻型定價為台幣 73,800 元，豪華型定價為台幣 79,800 元，旗艦型定價為台幣 85,800 元。補助最高的桃園市汰換二行程機車換購電動機車補助最高 29,000 元，再加上 10 月底前購車贈送的購車金 5,000 元，精緻型最低台幣 39,800 元起，豪華型最低台幣 45,800 元起，旗艦型最低台幣 51,800 元起。

（合作媒體：。圖片來源：）

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

【其他文章推薦】

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

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

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

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