基於軟硬整合觀點

By By 高煥堂高煥堂 misoo.tw@gmail.com misoo.tw@gmail.com

海峽兩岸海峽兩岸智慧電視智慧電視&&家庭商業策略與技術論壇家庭商業策略與技術論壇http://home-cloud.blogspot.tw/http://home-cloud.blogspot.tw/

AA段架構師段架構師__發揮四項假設性思維發揮四項假設性思維----以終端產品跨平以終端產品跨平台台策略為例策略為例

內容內容

1. 回顧：溯因(Abductive)推理2. 探索跨平台策略：願景(Vision) vs. 現實(Reality)3. 探索跨平台策略：<假定-否證>4. Mapping from vision to reality：全腦思考5. 學習未知，成為已知：EIT造形&Android框架6. 從簡單造形“理解”複雜

前言

商業模式

創新產品 架構設計

獨特性(軟硬整合)

普遍性 可靠性(跨平台) (測試)

產

品

策

略VISION

軟硬整合

跨平台 測試

EIT

•現在，來思索、擬定有效的跨平台策略

• 你學過了”四項假設性思維”，這強有力支撐A段架構師的創意和策略思維。

反思：從願景到想法(Vision & Idea)

假定：以事實來檢驗 (Based on Facts)

(觀想)結果：全腦並用(Mapping from Vision to Reality)

備胎：預見失敗 (Consequence)

• 這”四項假設性思維”的幕後，就是溯因溯因(Abductive)(Abductive)推理法。

基於軟硬整合觀點11、、回顧回顧：： 溯因溯因(Abductive)(Abductive)推理推理

• 這4項假設性思維背後是： 溯因溯因(Abductive)(Abductive)推理推理。。

★ 溯因(Abductive)推理是去猜測現象的可能原因，具有高度靈活性，是具創造性的推理方法。

★ 溯因邏輯是<假定-否證>的邏輯，透過檢 驗方式，發現走不通的路，就刪除之(減

法) 。

Q：養乳牛的村莊裡許多人沒得天花

舉例

• (假定性)推理H：擠牛乳的人一旦感染了 牛痘，就會對天花產生免疫性。 • (可能性)P：感染過牛痘的人，不會再感染 天花。

朔因邏輯

天花免疫 得過牛痘有天花免疫力

得牛痘

Q

P

• 觀察~Q的現象，然後從中尋覓其中之一是P原因所產生的結果。

”否證”

朔因邏輯

天花免疫 得過牛痘有天花免疫力

得牛痘

~Q

P

得天花

果(現象)

Q

因

P

假定(Hypothesis)果(現象)

Q H

因P

假定(Hypothesis)果(現象)

~Q H<否證>

基於軟硬整合觀點22、、探索跨平台策略： 願景(Vision) 現象(Reality)

發揮 ”四項假設性思維”

朔因邏輯

觀想(Visualize)願景，觀察眼前現(實景)象

H

跨(別人)平台的問題有兩個來源：

1) 來自終端產品總是面對外來晶片(及其 API)的善變。這稱為”跨小平台”問題。 2) 平台軟體(如Android)升級和版本變更 頻繁，終端(軟硬整合)產品必須隨之而 更新。這稱為”跨大平台”問題。

觀察問題來源

• 自己平台愈多差異化(獨特性)，在商場上，可能擁有更多優勢。

• 然而，隨著自己公司業務的成長，自己平台版本變更頻繁；如何包容自己平台的差異化呢? 稱為”跨自己平台”問題。

跨自己平台的問題來源：

• 假設(Assumption)：如果有能力跨別人的平台，也就有能力跨自己的平台。

• 反思：這項假設，在現象下還算合理。• 於是，先具焦於跨(別人的)平台。

假設&反思

Vision

與Realit

y的落差

Q(現象)

Vision：讓產品普遍執行於 各平台，擴大市場

Reality：必須使用別人晶片平台， 卻被它牽絆。

必須使用Android平台， 它卻版本變更頻繁。

Gap

常見現象如下：• 1、例如，Camera/Display沒有標準linux

驅動，整體方案全部由AP廠商實現，方案差異較大，而且其中還要嵌入不同廠商的LCD部分，涉及到多廠家配合問題。

• 2、例如，Telephony主體框架由Android實現，但由晶片廠家在模組的各個檔中進行完善補充，修改點非常分散於Android各層級中，也促成更多Android碎片化。

27

Problem

◎智慧終端機總是面對外來晶片的善變；架構師如何規劃跨晶片(硬體)平台的架構?◎晶片平台有其API(即服務功能或軟體函數)這晶片API是善變的。

基於軟硬整合觀點33、、探索跨平台策略： <假定-否證>

前言

Q(現象)

Vision：讓產品普遍執行於 各平台，擴大市場

Reality：必須使用別人晶片平台， 卻被它牽絆。

必須使用Android平台， 它卻版本變更頻繁。

Gap

• 願景(Vision)與現實景象(Reality)有落差(Gap)，其解決策略是什麼? 如何探索、擬定呢?

P

Q HVision

RealityGAP ?

P(因)

Q(果) H

有效策略

願景成真

持續反覆(Iteration)進行溯因推理

P

Q H

假定：採用HTML5，基於瀏覽器(Browser) 或採用Java，基於虛擬機(VM)

H(假定)

P

~Q H

• 引導人們去探索新的事實根據， 嘗試否證假定(H)。

P

<否証>

終端產品，很多底層服務都是C/C++代碼

~Q

基於Browser或 VM

P

~Q H

P基於Browser或 VM

持續發揮創意，繼續溯因推理

創意愛上限制(Creativity loves constraint)

繼續反思&假定

假定：基於EIT造形， 不限制程式語言

H(假定)

• 如果找不到事實證據來否證這項假定(Hypothesis)，就保持熱情繼續探索下去。

P

~Q基於EIT造形的策略，可實現跨平台

H

基於EIT造形的跨平台策略

跨晶片(小)平台跨Android(大)平台

• 這引導我們方向，持續探索下去，包括更多的觀察景象、更多的<假定-否證>，更有創意的策略，更深入的策略細節探索。

• 下一回合裡，將對這個沒有足夠證據可否證的”假定”，繼續探索下去。

基於軟硬整合觀點44、、Mapping from vision to reality

--全腦思考

前言

獨特性(軟硬整合)

普遍性 可靠性(跨平台) (測試)

起始願景

P

~Q基於EIT造形的策略，可實現跨平台

H

基於EIT造形的跨平台策略

跨晶片(小)平台跨Android(大)平台

軟硬整合

跨平台 測試 策略

EIT

細膩的願景

普遍性

全腦思考(完成性假設思維 )

• 右腦能清晰於impossible vision，左腦能推理出possible vision。

• 西方自從亞里斯多德、柏拉圖之後，增強長程邏輯推理能力，支持右腦想像，右腦成長，帶動左腦跟進成長，就出現許多全腦思考，創意就出來了。

• 依據「第三智慧」 一書所述，華人是模擬式而非推理式思維，擅於與過去的事實模擬，不擅于長程的邏輯推理(rule-based)。

• 有效引導我們去尋找原所缺乏的新知識(Unknown)：

Mapping

from vision

to reality

Vision &EIT 造形

已知事物

未知事物

變成已知事物

•讓它變成Known，成為左腦的推理基礎。

Reality：終端廠商 必須使用別人晶片平台， 卻被它牽絆。 必須使用Android平台， 它卻版本變更頻繁。

已知事物

探索未知事物(Know Unknown)

已知事物

未知事物

Vision &EIT 造形

引導

• Android具有多層級框架(Framework)。• 平台服務接口表現於框架的API上。• 晶片平台服務接口， 有些表現於晶片廠商提供的驅動API， 有些隱藏於Android的框架API的幕後。

基於軟硬整合觀點55、、學習未知，成為已知： --EIT造形&Android框架

前言

• 深入探索未知事物，讓它變成Known，成為左腦的推理基礎。

未知事物

變成已知事物

已知事物

未知事物

Vision &EIT 造形

引導

• Android具有多層級框架(Framework)。• 平台服務接口表現於框架的API上。• 晶片平台服務接口， 有些表現於晶片廠商提供的驅動API， 有些隱藏於Android的框架API的幕後。

基於軟硬整合觀點66、、從簡單造形從簡單造形““理解理解””複雜複雜

從簡單造形探索細微事實

• 從簡單造形探索隱藏於複雜中的細微事實。

假定：接口(Interface)是與平台的 交會點，是探索的焦點。

H(假定)

Vision: 跨平台

• 這看似合理的，沒有眼前事實可以否證這項假設。

• 在這項假定的引導下探索平台的介面。

已知事物

未知事物

Vision &EIT 造形

引導

• Android具有多層級框架(Framework)。• 平台服務接口表現於框架的API上。• 晶片平台服務接口， 有些表現於晶片廠商提供的驅動API， 有些隱藏於Android的框架API的幕後。

已知事物

未知事物

Vision &EIT 造形

引導

• Android具有多層級框架(Framework)。• 平台服務接口表現於框架的API上。• 晶片平台服務接口， 有些表現於晶片廠商提供的驅動API， 有些隱藏於Android的框架API的幕後。

Client

1. get_module()

HAL框架

Stub

2. open()

3. set_on()等 HAL-Driver

Kernel-Driver

發現一個

不起眼的事實

我們的模組都依賴於別人 訂定的接口(Interface)上。

• 這是一個驚奇的發現，但卻很不起眼。這意思是，我們心中有個<不自覺的假設>(四項架設性思維的#1思維)：

Assumption: “平台訂定、提供API給上層Client使用”是合情合理的(像真理一般)。

• 當我們反思一下，就會發現這項假設，大大局限了我們的視野和創意，讓我們會無視於上述的驚奇事實(視而不見)。所以，我才說這項發現是不容易的，因為不在視野之內，就是俗稱的”不起眼”。

I

T

Client

1. get_module()

HAL框架

Stub

2. open()

3. set_on()等 HAL-Driver

I

基於軟硬整合觀點77、、從簡單造形從簡單造形““掌控掌控””複雜複雜

• 基於這項不起眼的新發現事實，做了大膽的假定(Hypothesis)：

• 若擁有接口制定權，就能大幅降低對平台的依賴性(提高跨平台性)。

假定：若擁有接口制定權，就 能大幅提高跨平台性。

H(假定)

P

Q若擁有接口制定權，就能大幅提高跨平台性。

H

取得接口 制定權。

大幅降低對平台的依賴性(提高跨平台性)。

• 引導我們去探索、發現和確認新事實：

☆EIT造形確能有效封裝別人的介面，包括Android框架API和晶片驅動的 API。

P

Q若擁有接口制定權，就能大幅提高跨平台性。

H

運用EIT造形來封裝別人API，並制定自己API。

大幅降低對平台的依賴性(提高跨平台性)。

擬定”基本跨平台策略”

於是，獲得了策略的訂定方向了：

• What：擅用EIT造形。• How-to：封裝別人API，制定自己API。

• 在下一個單元裡，將基於此方向來擬定”跨平台的實踐策略”，並評估其可實現性。

高煥堂 misoo.tw@gmail.com

Thanks…