本節主要介紹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 是電子產業重要的元件?

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

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

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