前言：使用"框架的插件管理器" 管理好业务逻辑插件，包括：插件定义、插件创建、插件配对、插件Callback(含同步与异步)等等。然后，让 HTML5幕后的WebView事件能传递给管理器，同时也能让Android一般的View的事件也能传递给管理器，就行了。

有些业务逻辑需要在终端上执行。例如，有些游戏的运算、影像处理逻辑、还有，如股票分析师在自己家庭里的TV/STB上执行。在Android平台上的同一份业务逻辑插件(Plug-in)设计，可以提供给HTML5-based App使用；也能给传统Native Android App使用。你知道如何达成这目标? 你知道这对大型移动终端应用开发有多大的好处吗? 攸关客户业务逻辑的分析、设计、维护和复用等等。

本书缘由：高焕堂于2013年在日本退休之前，基于日本师徒制的要求而传承给下一代架构师的架构思考技术(俗称设计心法)。25年来他专精于A段(投资决策前)架构设计，退休闲暇将之写成中文，欢迎大家指教。

目录：請看目錄

欢迎访问 =>高老师的ADT技术论坛

高焕堂：MISOO(大数据.大思考)联盟.台北中心和东京(日本)分社.总教练

<<看上一集-------看下一集>>

[#2101]今年来，我积极推动行业别应用框架(AF)平台开发技术和实务交流，包括框架API规划&设计，企业的业务逻辑插件(Plug-in)、平台插件的开发、复用、改版、测试和管理等。也含敏捷开发&测试框架等。

[#2102]即使是身为 "码农" 的App开发者，也不应该继续坚持从 App看软件世界视角，因为这样就无法知彼知己，扩展视野了。更多新思维：http://t.cn/8Fo3z3r

[#2103]只要使用"框架的插件管理器" 管理好业务逻辑插件，包括：插件定义、插件创建、插件配对、插件Callback(含同步与异步)等等。然后，让 HTML5幕后的WebView事件能传递给管理器，同时也能让Android一般的View的事件也能传递给管理器，就行了

[#2104]有些业务逻辑需要在终端上执行。例如，有些游戏的运算、影像处理逻辑、还有，如股票分析师在自己家庭里的TV/STB上执行。 //@Angry_Jimmy:业务逻辑，是不是做成web service比较好？

[#2105]在Android平台上的同一份业务逻辑插件(Plug-in)设计，可以提供给HTML5-based App使用；也能给传统Native Android App使用。你知道如何达成这目标? 你知道这对大型移动终端应用开发有多大的好处吗? 攸关客户业务逻辑的分析、设计、维护和复用等等。

[#2106]我百思不解，为什么系统架构都是<移动端/建康云>两层架构呢? 如果设计为<终端/家庭云/建康云>三层架构又如何呢?

[#2107] 客厅配件市场是<藉助TV/STB的既有销售渠道>帮配件厂商创造量产机会。在将TV/STB与微信平台对接的，微信也将是<3亿个移动用户 + 3亿个家庭>的中心平台。 更多思维： http://t.cn/8FGlU1n

[#2108]许多架构师偏向于将所有 "业务逻辑" 摆在后台Web Service里。这可能带来分工开发上的极大困境。例如，移动端与后台的分工中，业务逻辑的变动部分该分给谁来做呢? Web Service接口属于被动型API，将让后台开发者成为前端开发者的小弟，还可能沦为救火队!!

[#2109]#行业应用API设计# 行业应用API设计，依赖丰富而扎实的行业领域知识，包括从客户进行Use Case分析，从企业经理分析Business Rules，从产业资深专家分析领域概念及其信息结构等(如图)。之后，对映到EIT代码造形，将其<E&I>部分美妙组合成为框架和API了。

[#2110]家庭的主人应该有全利决定其家庭建康检测数据如何授权给医疗机构，而不是使用不同检测仪器而分散于自己都不知道的"云平台"!! 唯有尊重家庭人员的权利和隐私，家庭健康产业才能健康成长与茁壮!!

[#2111]@让您成为杰出架构师#家庭物联网 + 微信移动互联网# 智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

[#2112]行业型应用框架，可以扩大成为应用平台(即俗称的中间件)，提供API来支持特定行业的App开发，并将客户插件交给App开发者，外包出去。这些客户插件包括因客户不同而有差异的各种逻辑(含UI、业务性、平台性)，都能外包出去，大幅降低公司的系统开发、管理和维护成本。

[#2113] 在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。更多思维：http://t.cn/8Fo3HIo

[#2114]行业型应用框架开发的主要效益，必须从"分工"的角度去衡量，不是仅仅从Client/Server 或<移动端/后台云端>的实体硬件或网络架构去看。这也是为什么当今业界那么重视以框架来提供API的原因。掌握API的制定权，就拥有产业的话语权!

[#2115]我百思不解，为什么Android开发者都只会用代码表示想法，而不重视图形思考；那么，请问接口(Interface)如IBinder, BnInterface<T>又如何从代码里看出来呢? 我从2007年陪着Android产业发展，但是显而易见的是Android开发者心灵并没有同步成长，颇令人忧心的。

[#2116] 敏捷的精神，偏向于UML是代码的图形表示。或是坚持1990年代的UML图形表示呢? 我是偏于前者，代码就是 {基类 / 子类}的结构，例如Android、iOS的代码都是如此。这是视角问题，不是真理问题。取决于 代码的 {基类/子类}结构是否需要与UML一致的问题。http://t.cn/8Fo3z3r

[#2117]人人都在谈"从开发到设计"，却没留意到"从(架构)设计到(代码)开发"的反向观点。例如，类(Class)观念是来自于OOP，是代码层级的结构改进，却因而改变了系统分析从结构化(Structured)设计改变为OOAD设计，也改变了测试单元和方法。因此，让架构师回归到代码造形也是很关键的。

[#2118]特定行业的软件框架，易于跨OS(和硬件)平台；反之，特定平台的框架，则易于跨行业。因之，特定行业的软件框架，能有效地跨Android、iOS和Win-8平台，不依赖HTML5也能轻易跨平台。

[#2119]#行业别框架&API# 基于行业别框架&API，独立出业务插件，并由框架管理之，基于这些共享插件，和一致性API，而发展的跨平台App，可称为<行业级别app>。

[#2120]在古典的架构思维里，”平台 = (服务)引擎”，App直接使用平台(引擎)的API，由于引擎API是被动地被调用(左图)，往往绑死引擎，业务规则代码动弹不得，带给企业恶梦。为了维护底层<引擎>的变动自由度，就采用新思维和新架构实践(右图)。

[#2121]掌握行业应用API，才有软件平台上的话语权，才能具有商业策略的主导权。行业API来自软件框架设计与特定行业的领域知识(Domain knowledge)的完美结合。唯有兼具<架构+代码>的优质架构师，才能设计出优越框架和API，强力支撑商业策略。

[#2122]如今，数字家庭产业的客厅配件市场的全新商业模式里，平台软件几乎完全是Android天下了。数字家庭OFA联盟大力整合产学研之力量，推动<以TV/STB为中心的数字家庭产业的客厅配件市场>新兴产业策略，并有投资基金支撑。

[#2123]<<Why? Android学生的投资效益日益低落?>>Android产业的发展活力，一直以来都在于它的开源开放，扎根于软硬结合，向多机整合、多屏互动，物联网+移动互联网发展出枝叶茂盛的大树。产业路线与iOS, Win-8封闭平台不同，所以教育途径也应该不同，否则不适当的初学途径，只会让学生投资效益更低落!!

[#2124]随着Android平台的飞跃成长，各行各业的<行业别应用框架平台>日益受到关注，<行业别应用框架平台>意味着：专门的行业知识+软件框架技术。尤其是该行业的领头羊企业，掌握了最完整、最先进的专业领域知识；一旦这些知是纳入软件框架平台，并掌握API，则能大幅提升它在整个行业的主导性。

[#2125]在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。

[#2126]行业别应用框架(AF)平台开发的关键部分：业务逻辑插件的接口(API)设计。只需要替客户(如广电CRM)一份API，以不同平台的语言(如Android的Java，iOS的Objective-C)实现之。针对一个客户，只需要一套需求分析、一套架构设计、一套测试方案，大幅节省开发费用和时程。这是大型行业移动应用项目的必然之路。

[#2127]家庭配件市场策略与商机# 客厅配件市场是<藉助TV/STB的既有销售渠道>帮配件厂商创造量产机会。在将TV/STB与微信平台对接的，微信也将是<3亿个移动用户 + 3亿个家庭>的中心平台。 更多思维： http://t.cn/8FGlU1n

[#2128]<从客厅看Android TV/STB可看到"客厅配件市场"巨大商机；也可看到TV/STB与微信平台对接的庞大商业机会。> 这项超级的架构设计，将影响数亿人的移动和居家生活，并带来庞大商机。同时，腾讯微信将成为全球最大的<移动互联网+物联网>的整合中心平台。

[#2129]当敏捷(项目)团队不顺畅时，如果从团队管理视角去求解，而无效时；很可能是架构设计是问题所在，可尝试从架构设计视角去求解。来自架构师的视角和习惯的蜕变；就能 让架构设计和项目开发都敏捷起来。信不信由你!!更多思维： http://t.cn/8FGlU1n

[#2130]#敏捷开发# 如何解答<Android项目 + 敏捷开发>的谜题呢?

[#2131]YES；但是，如果架构师和架构设计本身并不敏捷的话，可能无法支撑整体项目的敏捷开发呢!! 更多思维： http://t.cn/8FGlU1n

[#2132]<Android项目 + 敏捷开发>谜题的焦点：传统架构设计视角偏于抽象思维，致力于抽象出稳定、可靠、不变的共同性架构；做为应用发展的基础。然而，这项稳定架构无法迅速得到，不是“足够好”而已，这违背敏捷的Simple Solution的要求，不易迅速推动敏捷迭代。

[#2133]组合的核心工作就是“接口”设计。因而，架构与敏捷完美结合之秘诀就是：每回敏捷的迭代，都让其接口落实为代码，交给TDD来触发反馈 。

[#2134]其实，<Android项目+敏捷>是完美结合。Android完善的测试框架，有利于TDD机制来推动迭代。此外，Android是一个多层框架(Framework)体系，框架内涵是代码，能密切配合TDD和迭代过程。那么，<Android项目+敏捷>不顺畅的谜底又是什么呢?

[#2135]当敏捷项目推动不顺畅时，大多将焦点放在"组织架构"的改进上，因此把偏重于项目经理(PM)和团队领导(如Scrum Master)的视角和技能的改变上。但是，我则另寻他途，将焦点放在"架构设计"的改进上，因此专注于架构师的视角和技能的<蜕变>上。

[#2136]无论是基于Android或iOS等OS平台，建构自己行业的软件框架都是非常重要的，为什么呢? 理由只有一个：掌控API接口，制约别人的软件模块，而且保护自己的业务逻辑模块。例如，图中的中间件框架掌握了三项接口，安内攘外作用兼备矣。

[#2137]#行业应用API设计# 行业应用API设计，依赖丰富而扎实的行业领域知识，包括从客户进行Use Case分析，从企业经理分析Business Rules，从产业资深专家分析领域概念及其信息结构等(如图)。之后，对映到EIT代码造形，将其<E&I>部分美妙组合成为框架和API了。

[#2138]物联网业者给家庭带来许多的"加法"思维，也带来复杂思维，例如买来三星的烤箱，如何与TCL电视机对接呢? 谁来对接呢? 物联网厂商? TCL? 三星? 都不是!! 而是第三方App开发者来替用户做"减法"设计。请问：这些App跑在那里? 在网关??

[#2139]软件框架的存在，犹如万里长城的作用，API的功用也犹如山海关的作用。唯有主动型API才能像山海关一样制约关外势力(App)，才能保护关内居民(即底层模块的变动自由度)。只要了解这个道理，你就能理解Android关于DB的架构设计了。

[#2140]传统上，将框架视为平台，会产生严重误区；因为许多人因而会求平台稳定、可靠和不变；这是不对的。框架像集装箱，可容纳形形色色的业务逻辑模块(即软件的插件)，也备有优良的插件管理器(如图)来管理插件。其实，人人只能追求稳定的API。

[#2141]行业框架能跨越移动终端与后台云端(如附图)，能有效化解过去Client-Server架构的分工困境。古典分工模式让Server团队成为忙于应付终端需求的"救火队"；主要原因是Server提供给Client的API属于被动型API，被Client调用，没有主导权所致。

[#2142]框架不仅仅是软件系统平台而已，其API是该行业里<强龙/地头蛇>分工与合作的分界线。在更高级的架构设计里，框架与行业领域的业务逻辑引擎是分离的，自家的逻辑引擎(如图右下)模块必须被框架完美而有效的保护，确保其变动的自由度。

[#2143]#家庭物联网 + 微信移动互联网# 智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

[#2144]掌握在"智能家庭软硬结合平台者手中"；例如，1980年代企业办公室的争霸战，掌握Office平台软件的MS得天下，而不是思科、或宏碁。综观当今物联网业者，都是以数据流动、网络流量思维为主，可能比彩电厂商更没机会，更是当局者迷；您觉得如呵呢?

[#2145]<<微信 + 智慧家居>> 对于微信而言，最好的切入点是智慧家居。智慧家居是物联网9大试点领域最接近终端用户的行业，智慧家居是最需要人与物互动的物联网行业之一。

[#2146]有人问我：为什么需要去推动这项对接工作呢? 不是让家庭的电视机或网关成为微信平台里的一个客户终端就行了吗? 替电视机赋予一个2D码即可了。这是单向沟通功能而已，并没有考虑到家庭信息(如Shopping List)推送给家人的微信手机客户端的双向流畅联系。

[#2147]智慧家庭今年热门议题是："家庭物联网"与"微信移动互联网"的对接。当我在推动这项对接的工作时，发现此项对接是双方有利的完美结合，而且对微信未来发展的"虚实相依"、"软硬结合"是非常有正面贡献的。大家可预期这项完美的对接工程。更多思维：http://t.cn/8Fo3HIo

[#2148]着眼于家人(family)的心灵联系的无限关怀：在外用微信手机终端，回家在客厅使用TV等的双向沟通&家人心灵联系。这个视角可让人们重新看待智慧TV，例如传统上认为TV就是娱乐、就是一块屏、就是音视频播放而已；并没有真正发挥"智慧"的时代意义。

[#2149]这项超级架构设计的主要功能并不在于传统的"智能TV"或"智慧家居"的视角，例如从手机端操控家里设备等等。而是着眼于家人(family)在外用微信手机终端，回家在客厅使用TV等的双向沟通&家人之间心灵联系的无限关怀。

[#2150]这项超级架构设计的神奇效果是：物联网和移动互联网两者都是N:N大型网状结构(Network)；在相对接之后，却神奇地变成更大的树状结构。虽然变大了，确因树状结构(Hierarchy)而能稳定、有机成长。这种神奇效果来自高老师的EIT造形的架构设计新思维。

[#2151]许多人将TV/STB定位成为音视频播放的娱乐终端，然后就没继续探究TV/STB的"非音视频"角色。因此，比较不容易领会TV/STB成为微信平台的"不移动终端"的重要涵意了。

[#2152]客厅里的TV/STB将扮演重要角色，可与微信对接，成为微信的"不移动客户端"。微信既有的3亿移动客户端，服务在外的家人； 国内3亿个家庭里的"微信不移动客户端"则服务在家中的人。创造极为温馨的"Family"生活。

[#2153]微信平台就像一个轿子，它的必备条件是有人抬轿。就微信而言，目前的商业应用都属于依附轿子的人，而非抬轿人。一旦，微信能回首关照一下抬轿人，也让抬轿人受惠，则微信平台就会涌现无限多的新潮商业模式了。

[#2154]数字家庭# <<OFA不是制定TV业界标准>> 高老师正担任<工信部数字家庭促进中心>的OFA联盟主席，致力于<数字家庭物联网与移动互联网(如WeChat、Weibo)>对接API规范。但是许多人误解这是制定官方标准的老路；其实是基于数字家庭产业的客厅配件市场的全新商业模式而规划。更多思维：http://t.cn/8Fo3HIo

[#2155]Android是开源开放的平台和系统，就像一棵大树；当您想要了解它、爬它、养它、喂它、安慰它、疼它、在它树下乘凉抓萤火虫；您完全可以就树干(架构)、树根(底层驱动)、树梢(App)兼顾；而不是当瓢虫在外围看树叶(App)。这是许多Android初学者的陷阱，高老师给您一条轻松之路。

[#2156]我除了盼望将Android最新潮的知识和软件技术普及到乡村各地，也盼望这些广大地区的人才，能透过互联网而帮全球各地的业主，开发杰出软件，包括新潮的智慧电视、车机软硬结合系统，工业物联网与WeChat的信息推送业务等。深山幽谷里的人才是被正确呵护、关怀、培养，就绽放无限芬芳。

[#2157]Android产业需要培养更多的软硬结合、多机整合多屏互动、端&云结合的人才。这种人才的培养需要整体观，需要善用Android开放开源平台的特质，唯有紧扣这项特质，从第一秒钟得初学就培养全局观才是正确的教育。就如同，要培养好的网球人才，第一秒钟就要进场，而不对着墙壁打球!!

[#2158]App代码开发者要清晰业务流程(Logic Flow)；平台(系统)代码开发者要清晰内存进程(process)和线程(Thread)。两者兼顾，整体系统才能稳定发展。由于Android是开源开放平台，初学者必须一开始就非常重视线程，才能放眼全局，有正确的视角和视野。学习Android本来就不应该跟iOS、Win-8一样的学法!!

[#2159]在学习Android时，从第一秒钟就持着优雅的素养：对于每一行代码，都必须能准确而正确地说出来，目前该行代码正由那一个线程(Thread)所执行的。

[#2160]#码农的图形思考# 为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 更多思维：http://t.cn/8Fo3HIo

[#2161]我在课程里，全程使用世界标准的UML Class Diagram来绘制架构图，以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。兼具<代码+架构>就能陪养正确的素养，正确的学习出发点，是成功的保证。例如，学习打网球时，先面向墙壁练球，球感素样就永远错了。

[#2162]<<Why? Android学生的投资效益日益低落?>>Android产业的发展活力，一直以来都在于它的开源开放，扎根于软硬结合，向多机整合、多屏互动，物联网+移动互联网发展出枝叶茂盛的大树。产业路线与iOS, Win-8封闭平台不同，所以教育途径也应该不同，否则不适当的初学途径，只会让学生投资效益更低落!!

[#2163]当今Android初学者的<码农式>(又谑称"码奴式")教育方式，让人人的学习的"本益比"日益低落。因为忽略了Android式开源开放的平台，其产业发展的活力来自软硬结合，多机多屏互动，以及"物联网+移动互联网"系统开发。<码奴式")初学教育阻碍产业发展!!

[#2164]<<为一个新兴市场而整合>> 将移动互联网平台(如Weibo,Skype)的软件接口，做进去数以亿计的Android TV里，这不是去订定业界标准，而是为了一新兴的巨大市场而整合。这就是：以Android TV为中心的智能家庭的客厅配件市场，并提供Android新一代整合开发者创业的空间。

[#2165]#行业别应用框架开发# 在<行业别应用框架开发>潮流下，各终端服务厂商，无不力求在Android、iOS、Win8等平台之上，建立一个跨平台的行业别应用框架，并设计行业领域API，有效实践跨平台，强力掌握行业别App。更多思维：http://t.cn/8Fo3HIo

[#2166]<<为一个新兴市场而整合>> 我主持的<工信部数字家庭促进中心OFA(Open Family Alliance)联盟，不是要去订定业界标准，而是为了一新兴的巨大市场而整合。跳脱古典的音视频视角来看Android TV和智慧家庭，从具有高度产值的客厅配件市场出发，衔接移动互联网，延伸到广大的移动终端。

[#2167]<<为一个新兴市场而整合>> 如果你从主件的战场下来，可以转移到配件市场，例如来自美国的柯博文老师将与IC Coffee合办的<iPhone & iPAD 与接口设备连结之软/硬/韧体应用整合开发>技术讲座。此外，高焕堂老师也担任北京数字家庭OFA联盟主席，致力推动<以TV/STB为中心的家庭客厅配件市场>。

[#2168]随着Android平台的飞跃成长，各行各业的<行业别应用框架平台>日益受到关注，<行业别应用框架平台>意味着：专门的行业知识+软件框架技术。尤其是该行业的领头羊企业，掌握了最完整、最先进的专业领域知识；一旦这些知是纳入软件框架平台，并掌握API，则能大幅提升它在整个行业的主导性。

[#2169]使用世界标准的UML Class Diagram来绘制架构图，不仅内容以作品来期许，还以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。

[#2170]#码农的图形思考#为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 更多思维：http://t.cn/8Fo3HIo

[#2171]善用UML类图(Class Diagram)来表达代码结构，是迈向有效架构设计的起点。我在课程里，全程使用世界标准的UML Class Diagram来绘制架构图，以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。

[#2172]<<图形思考>>。有效的架构师都具备出色的图形思考能力。目前Android课程和教案，唯有高老师坚持特别重视培养开发者的图形思考能力，其它大多数书籍都只有代码，非常不利于开发者迈向架构师之路。

[#2173]从代码解析软件，和从结构理解软件；它们本来就是两个必备的学习途径。从代码解析软件，仰赖流程逻辑；从结构理解软件，仰赖架构接口。在传统封闭平台上(如 Windows, iOS)只能依循<从代码解析软件>学习途径；在Android开源开放平台上的正确学习途径则是<代码+架构>兼具。

[#2174]从代码解析软件，和从结构理解软件；它们本来就是两个必备的学习途径。在Android开源开放平台上的正确学习途径则是<代码+架构>兼具。<从结构理解软件>需要以图形来表达软件里的类(class)和接口(interface)，以及其间的关系(relationship)，此时像UML class diagram就很有用处了。

[#2175]<<如何让码农也使用UML?>> UML用在系统建模是OK的，但是Android开发者和书籍作者都不用它；因为UML都被用来表达业务逻辑、企业对象和用例分析，而不是给<码农>来表述其代码架构，这是UML的瓶颈也是Android开发者的损失。我希望UML不仅能表达大象的知识，也能完美表述小虾米(码农)思路。

[#2176]为什么，使用世界标准的UML Class Diagram来绘制架构图呢? 其用意是：以" 世界级"图形思考来给初学者一个架构师的基本能力(绘制正确的系统架构图)。在Android开源开放平台上的正确学习途径则<代码+架构>兼具。<从结构理解软件>需要以UML来表达软件里的类(class)和接口(interface)。

[#2177]由于云计算、大数据中心的潮流，使得人们都是围绕着数据去思考系统架构，却忘了：一个云一张网、一个中心一张网，产生的信息孤岛大问题。因此，我们必须从"网"的角度去建构一个超级架构，来整合各云计算、大数据中心所衍生的网，而间接、实质地整合了大数据本身。

[#2178]@让您成为杰出架构师#顶层设计# <<家庭物联网 + 微信移动互联网>> 这项架构设计的神奇效果是：物联网和移动互联网两者都是N:N大型网状结构(Network)；在相对接之后，却神奇地变成更大的树状结构。虽然变大了，确因树状结构(Hierarchy)而能稳定、有机成长。这种神奇效果来自高老师的EIT造形的架构设计新思维。

[#2179]双向联系的典型范例：TV里有个家庭Shopping List，早上安排好家人预定购买的东西，并储存于Shopping List上。下班时，家庭妈妈临时逛了超市，决定将东西都买了。于是透过手机浏览器上网，访问TV里的网页去更新Shopping List。TV立即透过微信平台将更新信息推送到各家人的手机终端。

[#2180]家庭物联网的专注焦点，逐渐从原来的House转移到Home，如今更迈向Family。因为House因Home而存在；至于Home则因Family而存在。更何况，一个Home有多个house；一个Family可能分散于各Home。此时，TV/STB将扮演联系Family的"不移动终端"。

[#2181]TV/STB的主板大厂沟通，都非常期待早日与微信对接，将微信推送的接口安全机制，部分直接写入主板里。如此让微信直接深入TV/STB的硬件核心，实现与3亿个不移动终端之间的虚实相依，将能有效弭补微信在移动终端一直无法虚实相依，缩小商业模式空间的短板问题

[#2182]在这超级架构设计里，"虚实相依原则"与"EIT设计造形"，一直扮演着设计的核心思维。其中的虚实相依原则是：虚在上，实在下；务虚者必须主动接触务实者，否则虚脱离了实，就像失根的兰花，难以取得养分或水分(在商业上，就是难以找到创新的有效商业模式）。同时，务实者也会生存得很辛苦。

[#2183]一旦微信切入了TV/STB的主板(Motheboard)，就能依循EIT树状体系架构，而迅速、顺势网下层延伸，掌握了整个家庭物联网众多Sensor端。以此类推，一旦掌握了家庭，此模式就能进而复制到学校、医院等来服务教师、医生等。于是，微信-based的智慧城市就自然形成了。

[#2184]高老师提出这项<<智慧城市顶层设计的统一系统架构刍议>> ，仅仅是"造形"的建议而已，并没有任何实践"标准化"的意图。例如，唐诗七言绝句的形式，并没有强迫或规范李白、杜甫等诗人的意图。

[#2185]Herbert Simon(经济学诺贝尔奖得主)写的一本书：The Architecture of Complexity，谈到N:N网状架构可以转变成为多层级N:1树状体系，得到稳定、有机成长的活力。所以发现，这正是全国智慧城市顶层设计的有效思维借镜。更多思维：http://t.cn/8Fo3HIo

[#2186]回复青润: 1. 基于我提出的多层树状体系，以手机进形摄像机和后台的动态绑定(Binding); 2)摄像机和后台进行视频实时分析处理； 3) 信息推送到手机。

[#2187]<<智慧城市顶层设计的统一系统架构刍议>> 在"移动互联网"与"物联网"对接的实践层面，分为绑定(Binding)与数据传输(Transmit)两个步骤。这个统一架构偏于前者，以一个稳定、能有机成长的树状体系来组织众多终端或中间结点；迅速绑定目标对象，并决定最佳的数据传输途径。

[#2188]<<智慧城市顶层设计的统一系统架构刍议>> 在"移动互联网"与"物联网"对接的实践层面，分为绑定(Binding)与数据传输(Transmit)两个步骤。这个统一架构偏于前者，以一个稳定、能有机成长的树状体系来组织众多终端或中间结点；迅速绑定目标对象，并决定最佳的数据传输途径。

[#2189] 有人问到：为什么要由"移动互联网"来衔接智慧城市里各个区块的"物联网"呢? 其实，我是倒过来从物联网出发的，想藉由"移动互联网"来将各"物联网"的信息，推送到移动终端里，因为这些物联网悠关的主人们(Stakeholder)大多随身携带移动终端。更多思维：http://t.cn/8Fo3HIo

[#2190]可先从目的想起。Herbert Simon(经济学诺贝尔奖得主)写的一本书：The Architecture of Complexity，谈到N:N网状架构可以转变成为多层级N:1树状体系，得到稳定、有机成长的活力。所以发现，这正是全国智慧城市顶层设计的有效思维借镜，改善目前物联网网状架构的瓶颈。

[#2191]<城市远比家庭更为复杂> 所以大家想想如何在架构设计上，从众多N:N结构的信息孤岛群中，建立一个比较稳定、能有机成长的多层级树状体系。由于只是结构之形，与各业务(如家庭、医疗、公交等)的内涵是无关的。

[#2192]就微信而言，透过各业务区块(如家庭、医疗、公交车等领域)里的小平台(如家庭平台)的主角(如TV)，来间接(却众星拱月)地连结到物联网的感知终端，因而以API衔接到无限数量硬设备，可以弥补微信在移动终端OS和通信平台上没有掌握对硬设备API的主导权的困境。

[#2193]@让您成为杰出架构师#顶层设计# 智慧城市源于物联网的基础，实体层是网状结构，但是逻辑层必须转换成一个较为减化的结构，才能支撑上层商业的复杂关联性。例如，Database的结构设计，实体层的数据结构识网状的，必须经由Normalization的减化才能稳定、有机成长。更多思维：http://t.cn/8Fo3z3r

[#2194]就微信而言，透过各业务区块(如家庭、医疗、公交车等领域)里的小平台(如家庭平台)的主角(如TV)，来间接(却众星拱月)地连结到物联网的感知终端，藉由微信强大的互联能力来帮各物联网推送信息(不一定是实际数据)，借机成为智能城市的Command Flow整合中心，也帮了物联网和城市。

[#2195]武汉是全球幅员最大的城市，但目前许多信息孤岛，就像古代的中国。欲社会和谐、生态均衡，顶层设计需要"减法设计"，如秦国 " 书同文、车同轨"，和唐朝"诗同形"。亦即，专家Brooks提出的Conceptual Integrity。

[#2196]我建议武汉在规划层面要留意：规划概念的一致性(即书同文、车同轨、诗同形)。另外我还建议在系统架构上，可藉由移动互联网(如微信、微博等)来联接众多物联网，将众多的网状信息孤岛，转变成为多层树状体系。

[#2197]智慧城市的焦点在"智慧"而不在"城市"，城市本质不能因智慧而变，它是永续经营的；智能本身则是善变的，就像衣服(智慧)加诸于人(城市)。衣服要随着人的成长而换新，不能将人"衣服化"，也不能将城市本质智慧化了。

[#2198]高老师提出这项<<智慧城市顶层设计的统一系统架构的刍议>> ，仅仅是"造形"的建议而已，并没有任何实践"标准化"的意图。例如，唐诗七言绝句的形式，并没有强迫或规范李白、杜甫等诗人的意图。

[#2199]将Android与iOS采相同的初学教育方式，很可能是错误的。因为iOS封闭，学员看不到树干，只好看树叶，各自想象树干长相。Android可以直接看树干，对树叶的来龙去脉轻易撩若指掌，何苦只知其然(树叶)不知所以然(树干)呢? 换个有效的新观点!!

[#2200]@让您成为杰出架构师#敏捷开发与Android# 为什么敏捷开发与Android是个很好的搭配呢? 更多思维：http://t.cn/8Fo3z3r

[#2201] 阿里的“智能TV生态联盟”。阿里将焦点放在OS上，并非是最好策略，因为阿里的强处在于移动互联网，属于OTT层而不是OS层，如果想要两层兼顾，将失去OS层合作和奥援。阿里可以直接将OTT平台接口，穿透Android-based OS而直接做进去TV硬件(主板里)，既能得到OS层支持，也能得到硬件厂撑腰。

[#2202] 7月下旬，阿里发布阿里智能TV操作系统，并推出搭载该系统的盒子产品。阿里TV操作系统将打通电视、机顶盒、手机等终端，并接入电商、互联网支付等功能。OTT层、OS层和硬件层兼顾，这可能是阿里策略上的陷阱所在。OS就如同轿子，轿子自己做，自己坐，自己抬，这是许多优秀OS英才早逝的主因。

[#2203]阿里TV生态联盟的最佳策略应该是：发挥阿里的移动互联网优势，试图主导智能家庭的OTT层(优势空军)，主张开放Android-based OS层(结盟陆军)，趁机深入硬件层(强化海军)，展开三军联合作战。阿里将所向无敌、势如破竹。

[#2204] <<第8届中国敏捷软件开发大会>> ：软件系统的架构从来都不是一蹴而就的，它需要在不断的演化中改进设计，甚至做出重要的架构迁移。如何运用敏捷技术来保证这种演化，并将软件架构更好地与敏捷实践结合起来，以设计优良的架构？

[#2205]为什么敏捷开发(Agile)逐渐进入到Android世界呢? 因为Android已经跨越单机开发，迈入多机整合、多屏互动的领域了。尤其是当今兵家必争的智慧家庭，以及新兴的智能城市领域。Android的项目日益扩大、复杂化。于是大型开发项目需要加入新潮的软件工程、新一代的架构设计思维和模式。

[#2206]为什么敏捷开发与Android是个很好的搭配呢? 理由之一是：Android有完善的测试框架，有利于建立TDD测试机制来推动迭代过程。理由之二是：Android平台架构是一个多层框架(Layered Framework)体系，框架内涵是代码，满足敏捷原则：”各项架构设计决策都必须迅速落实为代码”；有利于密切配合敏捷迭代过程

[#2207]本讲座阐述一个大型的Android开发项目和团队，应该如何采用敏捷过程、如何基于创新型的架构设计，让项目经理(PM)有效地组织开发、设计及测试人员，灵活敏捷地面对复杂多变的需求，维持高度的用户体验。

[#2208] @让您成为杰出架构师#架构师思维练习# 从智能家庭视角看智能电视，可避免陷入"见树不见林"的误区。例如，从客厅看TV/STB可看到"客厅配件市场"的巨大商机；可看到TV/STB与微信平台对接的另一种商业意义和机会。更多思维：http://t.cn/8Fo3z3r

[#2209]过去，软件人员大多认为软件架构应该像房子的地基一样，要求它稳定、可靠和不变。因而要求底层平台的稳定不变，来支撑上层App的多变；其实，执着于这种架构设计视角是有缺陷的。架构设计的目的是要保护底层模块的"变动自由度"，此视角才是理想的。

[#2210]一般而言，底层平台提供系统服务给上层AP；所以相对上，AP是Client，而平台是Server。保护底层模块的"变动自由度"以追求"没钱就改版、改版就有钱"商业机会。这项设计思维也适用于"终端产品/云平台"的移动互联网整体架构设计。

[#2211]过去，大多架构师的经济思维是：节省成本，所以强调软件模块的复用性(Reuse)；这属于成本思维。其实，架构师可以改为获利思维，强调容纳改变(Change)，跨别人的(芯片等)平台，跨Android版本更替。于是包容别人的多变，也创造了自己的复用性。

[#2212]在人人都在谈互联网、云计算、大数据之际，人人都在做加法设计之刻；软件架构师应该想想有效的减法设计。例如，Database的N:N复杂网状关系，软件就必须加以Normalization，减化为多个N:1的树状结构，才能支撑数据的未来成长。

[#2213]在移动互联网里，许多人基于简朴的架构来面对复杂的实务。例如，在手机终端呈现UI(如网页)，然后将各种 "业务逻辑" 的运算都放在云层上；于是，追求UI(HTML)代码的跨平台(如Android等)是目标。然而，也有许多业务逻辑必须摆在终端执行的，则架构该如何重构呢?

[#2214]随着感知端的数量急速增加，云端大数据风潮逐渐兴起；端与云都在强力进行系统复杂化的"加法设计"，那么软件架构师就必须负起"减法设计"的任务，提供简单的应用；才能让用户享受 "从简单中叫出复杂的满足感"，这种满足感就称为"用户体验"。

[#2215] <程序员>到<架构师>的快捷方式：类(Class)造形 –> EIT造形 –> 设计模式 –> 框架(Framework) –> 端&云平台(Platform) --> 产品创新

[#2216] @让您成为杰出架构师#架构师思维练习# Android的碎片化是大家最担心的事项之一，然而也是Android欣欣向荣、百花齐放的生命力光辉的展现。因此，如何有效运用Android这项特质、水涨船高，抓住机会展现自己产品的独特性和应变能力；更重要的是，确实掌握自己产品主动改版的话语权。更多思维：http://t.cn/8Fo3z3r

[#2217]有人认为 "智能TV/STB" 欠缺的简单的互动技术，以及丰富App。其实真正缺少的可能是"商业模式和策略"。例如，有人认为：智能电视机的焦点(和本质)是"电视机"，有人认为其焦点在于"内容"，有人认为其焦点在"智能"。这些观点或视角都没对没错；唯一错的可能是：坚持单一观点。这样商业模式就陈旧不堪了。

[#2218] EIT软件代码造形，就像集装相一般，影响最大的可能不是集装箱的使用者，而是集装箱的管理者，让管理者能从简单中掌握复杂的满足感。例如，我前天在SPI(软件过程&质量改进大会上讲演)，大大给了敏捷、CMMI等软件管理者们的惊艳。

[#2219]过去，码农思考的焦点在于代码的类(Class)，而设计师的思考焦点在于设计模式(Pattern)。在两者之间，高老师发现了一个EIT造形。让码农与架构师两者的思考焦点有了新的交集，能够汇合为一，有了一致的心灵、共同的感觉。对各方都好处连连。

[#2220]其实这个 EIT造形是在改变架构师的视角，反而不是针对码农；除非是码农想成为架构师；例如，集装箱的发明，影响最大的是运输业，而不是工厂；因此，虽然EIT是代码造形，影响最大的是架构师、PM和测试者；反而不是码农。

[#2221]随着Android的普及，Android的大型应用项目愈来愈多，各企业逐渐企盼建立自己的专业应用平台(Platform)和自己能掌控的API；并由自己的平台管理各种插件，透过迅速抽换插件来满足客户需求的改变、Android的改版，以及底层芯片的频繁更替。让自己的产品或系统能实践”没钱就改版、改版就有钱”。

[#2222]一首唐诗，含有两部分：1) 七言绝句之造形(Form)； 2)李白的情境内涵(Content)。<对架构的应用关键还是业务>这句话里的"业务" 就是内涵。造形则规范了内涵的呈现结构。 //六_个_轮_子:对架构的应用关键还是业务，老师说的形我的理解是控制即流程中的节点

[#2223] @让您成为杰出架构师拿代码造形来赋予分析和设计的内涵，有助于迅速落实为代码，并能进行组合重构，能提升敏捷跌代的流畅性。架构师采取多视角来看待 {基类 / 子类}的代码造形结构。一旦架构师能将分析&设计所得的内涵，赋予到简单的代码造形，就能衔接需求&代码，敏捷跌代就流畅了。欢迎访问：http://t.cn/8Fo3z3r

[#2224] #EIT架构设计思考# 将 {基类 / 子类} 结构视为一种 "代码"造形。然后从不同视角，将分析与设计的内涵赋予到此结构上，则这象造形就能有形形色色的内涵了。这摆脱掉传统 {基类 / 子类} 结构只有一种内涵(抽象&继承)的苍白思维世界；更能灵活地配合敏捷的跌代、并顺畅重构与成长了。

[#2225]把原来继承关系的 {基类 / 子类} 结构形式抽象出来，成为通用的造形(Form)。然后，再赋予继承、组合、插件等不同的内涵；这种造形，就是我提出的 "EIT代码造形" 了。

[#2226]基于代码造形，而将分析和设计内容嵌入于代码造形中，成为造形的内涵；于是，架构师必须采取多视角来看待 {基类 / 子类}的代码造形结构。一旦架构师能将分析&设计所得的内容，赋予到简单的代码造形，成为造形的内涵，就能有效衔接需求&代码了。

[#2227]过去，架构师没有考虑到代码造形，不同的分析&设计模式，都对映到不同的代码；一旦需求&架构改变了，代码架构需要改变，自动化单元测试方案也需要改变，大幅增加敏捷跌代的成本。

[#2228]从底层驱动(Driver)设计，到上层HTML5/PhoneGap的插件设计等不同的设计内容，对映到相同的｛基类 / 子类｝基本代码结构（造形），这项基本结构就成为软件世界的 ＂原子＂造形。则敏捷的重构与测试方案就完全改观了。

[#2229]华人的独尊抽象思维是有问题的，是创造力的关键因素之一。其实，在1980年代初期，类别(Class)已经让设计师与开发者迈向"一致心灵"的一大步；今天我们又想藉由EIT代码造形来更往前推进一步。

[#2230] @让您成为杰出架构师#华人抽象思维的视角# 30多年前，人们抽象出类(Class)来包容Function和Data，类既是程序员熟悉的代码造形，也是设计师熟悉的设计造形，两种人员获得一致的心灵、共同的感觉。30年后的今天，高老师设计了一个较高层的EIT代码造形，又推动软件产业迈向新的一步。欢迎访问：http://t.cn/8Fo3z3r

[#2231]华人的抽象思维是的视角的，专注于对用户领域知识进行抽象，得到抽象的领域知识(表达为抽象类)，这是一项很大的迷思!!!!

[#2232]回复海纳百通: 我的 EIT造形思维，就想下一代新的尝试...http://t.cn/zHAyDVz //海纳百通:这个很早就有大师提过：华人擅长归纳，不擅长演绎

[#2233]回复智慧笨蛋: 不仅仅软件，华人创造力普遍非常低落，都值得探讨... //智慧笨蛋:我觉得真相是：华人真正懂面向对象不多，可以把oo实际实现到真正项目的人不多 //高焕堂:根据我的研究，华人的独尊抽象思维是有问题的，是创造力萎缩的关键因素之一。

[#2234]华人的抽象思维是专注于对用户领域知识进行抽象，得到抽象的领域知识(表达为抽象类)，这是一项很大的迷思! 正确的做法是：抽象而得到的是能包容 "完整而具象的领域知识" 的集装箱，而不是 "抽象的领域知识" !!!!

[#2235]华人的抽象思维的视角，正确的做法是：抽象而得到的是能包容 "完整而具象的领域知识" 的集装箱，而不是 "抽象的领域知识" !! 君不见，洋人发明集装箱、计算机主板(装了许多IC)、软件类(Class)结构、数具XML等等；反观华人呢? 不是华人没创意，而是思维习惯问题。

[#2236]华人的抽象思维是的视角。例如，华人会使用集装箱、会弄出全球最大的集装相船运公司(台湾的长荣海运公司)，但是华人就是不习惯于：从具象的万事万物之中抽象出集装箱，容纳具象的万事万物 !!!

[#2237]华人的抽象思维的视角。例如华人会从一堆软件Function中抽象出 "抽象的函数"、也会从一堆软件Data中抽象出 "共同的数据结构"，但是华人就是不习惯于：从具象的一堆函数和一堆数据之中，抽象出 "类(Class)结构" 来包容具象或抽象的函数&数据。兹想想面向对象思维不过如此而已。

[#2238]架构师是否应该使用代码造形来思考设计呢? 不同的分析&设计模式，都对映到不同的代码；一旦需求&架构改变了，代码架构需要改变，自动化单元测试方案也需要改变，大幅增加敏捷跌代的成本。高老师极力主张以代码造形来思考架构设计，则程序员都能轻易成为架构师了，您相信吗?

[#2239]过去许多人的思维习惯是：从一堆软件函数(Function)中抽象出 "抽象的函数"、也会从一堆软件数据(Data)中抽象出 "共同的数据结构"，但是常常不习惯于：从具象的一堆函数和一堆数据之中，抽象出 "类(Class)结构" 来包容具象或抽象的函数&数据。Why?

[#2240]码农只要思考几个主要议题，就能具有新潮的架构设计能力了。例如，有个Client模块需要调用Server模块时，通常需要先知道Server模块的接口(Interface)才能调用到它。然而，如果现在还无法得知Server模块的接口，但却现在就必须撰写Client模块的代码。设计师(或码农)该如何面对这项限制呢?

[#2241]回复用心阁: 但确实能创建一个小线程去执行Task里的run()。 //用心阁:这种方式无法重用线程吧 //高焕堂:码农如果写出Java代码： class Task extends Thread { // function run() { .... } } 有些设计师会认为这是错的； 但在代码层级，这个写法有错吗? 到底何种观点正确呢?

[#2242] @让您成为杰出架构师#敏捷开发&设计思考#如何让架构师与开发者双方都来关助于"软件的形的抽像"，则形就成为架构师与开发者的共同心灵、一致感觉了。这对于项目开发的流畅性会有极大的影响；尤其是敏捷开发。欢迎访问：http://t.cn/8Fo3z3r

[#2243]我的讲题是：<如何紧密结合商业模式与 架构设计来支持产品创新>。商业模式是复杂的，架构师必须设计出简单，才能支撑复杂的产品创新活动。以<硬硬结合销售>商业模式下的<多机整合>创新产品为例，阐述架构师如何设计出简单造形、模式和架构，来支持复杂的产品创新。

[#2244]面对复杂，架构师必须设计出简单，让攸关人员皆能享受从简单中叫出复杂的满足感。本讲座阐述有效的架构师如何轻易实现这项目标。

[#2245]于是，架构师必须从复杂中设计出简单。然后，基于简单而<容>纳复杂多变(<易>)的内涵。亦即：容易。最后，让用户享受从简单中叫出复杂的满足感。我觉得我们太偏执于抽象思考，忽略了设计思考(Design Thinking)。设计思考正弭补传统独尊抽象思考的不足；让我们能兼具宏观和具象。

[#2246]由于科技只会继续变复杂，采取简单策略来突出自己的产品，是很有经济效益的。隐藏复杂功能对人而言就会变成一种享受，而不是讨厌的东西。会给人们掌握主动的力量，从简单中叫出复杂的满足感。

[#2247]技术应用与发展，与人类的思考是相关的。例如，如何思考一推复杂的鞋子呢? 记得，人类面对复杂事物时会害怕，就会想找到简单的掌控点。那么，如何取得简单的掌控点呢? 主要途径是：抽象。但抽像有不同视角，结果不同。例如：1)一堆鞋子的抽像，结果还是鞋子。 2) 一堆鞋子的抽象，结果是"集装箱"!!

[#2248]基于内涵(Content)的抽象，能从复杂得到简单；基于形(Form)的抽象，也能得到简单。传统上，软件分析师、架构设计师都专注于内涵的抽象，以内涵的架构来充当软件系统的架构。这样的特点是：稳定而难以应变。架构师较不留意替开发者设计出软件之形(集装箱)，让开发者将复杂的技术细节装入形里。

[#2249]架构师与开发者基于相同的形(集装箱)；然后，架构师(含系分员)将领域内涵装入形(集装箱)里；而开发者将技术细节(含通信协议等)装入形里。这样子，获利最大的是PM，因为人员的沟通有了基础概念，软件管理和测试都变得非常简单容易了。因为形(如集装箱之形，物理原子之形)只有一个。

[#2250]回复KorukH: 也可以看看java的Thread类，例如：class Task extends Thread{...} //KorukH:图片所示Tire类重写了父类Engine的抽象方法operation_1()，这不是典型的继承么？本来想表达的意思是Engine类里面有Tire的实例？

欢迎访问 ==>高老师的博客网页

ee                                                                                 ee

<<看上一集-------看下一集>>