— 摆脱对于供应商的束缚，提升終端产品的品质
— 如何解Android终端厂商的<自主性>谜题
— 高老师提出的跨(芯片)平台模式：一个造形、三个策略

By 高焕堂

课程简介：

大文豪苏东坡写过一首诗：

        “… 恰似飞鸿踏雪泥，泥上偶然留指爪，鸿飞哪复计东西。”

  面对强势的Android开源平台，我们不得不使用Android x.x 版本(踏上雪泥)。那么，我们有何高明的跨平台(摆脱雪泥的束缚)策略和技术，让我们(大鸿鸟)能振翅高飞、遨游天际呢?
  跨别人的平台，整合自己产品，进而推展自己的平台，是当今处于Android多元发展情势下的赢家之路。跨别人平台的问题有两个来源：

来自终端产品总是面对外来芯片(及其API)的善变
平台软件(如Android, iOS等)升级和版本变更频繁，终端必须随之而更新

  通常，芯片厂商的修改点并不聚焦，而是散落于产品(含芯片及其搭配的Android x.x版本)的各个层的各个模块中，如果逐点进行抽象封装很难解决问题。究竟厂商该如何克服这些挑战呢? 一般的终端厂商的常见的对策是什么? 采用那些设计模式和技术呢?
  在本课程里，将逐一帮你解答上述的问题。首先高老师善用Android 4.x核心多层框架体系及其API而提出：”一个造形、三个策略”来做为基础(摆脱别人枷锁)模式，然后扩大应用到跨云平台、跨端&云垂直整合的积极模式(振翅高飞)。高老师的这项模式，已经获得华阳、华为等大型终端厂商的好评和应用。
  最后，在本课程里，将由高老师指导大家充分理解Android 4.x的底层架构(含HAL驱动和核心服务)及其API，做为基础，然后亲自进行跨平台的架构设计，直接取得实务设计经验和开发技巧，并能顺畅落地到产品创新和开发上；一旦确保了产品自主性，便能走出自己的与众不同、抓住市场机运。

课程思路：

为了让您更清楚课程思路，请您阅读： “Android终端厂商的自主性策略及实践”

课程大綱：

内容
Part-1. 看待Android架构的十个制高点(新视角)
Part-2. Android产业自主化的跨平台策略
Part-3. 复习Android平台的多层框架体系
Part-4. 跨平台基础技术：EIT设计造形
Part-5. 范例：EIT造形及其组合规律
Part-6. 跨平台模式：一个造形，三个策略
Part-7. 振翅高飞：迈向软&硬件的无缝隙整合
Part-8. 跨平台策略下的自动化测试方法
Part-9. <Android + 敏捷>以及落地问题

Part-1. 看待Android架构的十个制高点(新视角)

大家都知道，创新不一定要去发明全新的东西，变换一些全新视角(View)来看原有事物，做不一样的联想、以新的连结&组合，做为新产品的独特架构，只要能更贴近用户的需要和口味，就能创造获利机会。Android设备愈来愈多、百花齐放，提供了无限大的组合创新空间；记得，变换观点、独特组合、贴近用户、努力经营，就能捕捉到好机运；千载难逢的好机会，不要错过。

图-5. 流畅地变换新视角

大家都会希望能愈流畅地变换新视角，但却往往被自己内心深处的假设(Assumption)所局限了。尤其，有许多内心的假设，是连自己都不自觉的、长久以来都信以为真(理)的，未曾质疑过它；从现在开始，试着经常反思内心的假设，审视它、放宽它，新视角就出现了，商机也就浮现出来了。关于反思内心的假设，可参考：”高老师的设计思考三部曲”。
在本课程里，将与您一起变换视角；一方面反思你内心深处的假设，一方面变换出十个新视角，来重新看看你已经很熟悉的Android系统架构。这十个新视角如下：

1.1 API = 话语权

      ◆  在Android 潮流下，商业成功的钥匙就藏在API隙缝中
      ◆  全面性理解框架API，即能拥有成功密码、造就天使，并成为商业竞争下的赢家
      ◆  对API拥有主导权，就能在商业上获得主导地位，就会是赢家。
      ◆  API与UI不同
      ◆  UI是App与用户的交互接口
      ◆  API则泛指软件模块间的接口，可分为：
               SI：本架构与外部系统之间的接口
               PI：本架构与内部挿件(Plug-in)之间的接口
               一般API：本架构与应用程序(App)之间的接口
      ◆  掌握API定义权，就拥有话语权(主导权)

1.2 应用框架：用来框住应用(App)的架构

◆ 框架的基本组成元素：EIT代码造形(Form)
 ◆ 造形的就是API
 ◆ 框架是鱼饵，API是鱼钩
 ◆ 鱼饵是送人的礼物；送越多，拥有市场版图越大

1.3 框架调用App，不是App调用框架

      ◆  用户没有直接碰触软件(App)
      ◆  用户碰触的都是硬件
      ◆  硬件通知框架，框架调用App

1.4 JNI： C调用Java，不是Java调用C

      ◆  Java层的框架(基类)是送人的礼物
      ◆  所以关键模块，以及控制点必须放在C/C++层
      ◆  控制点透过JNI控制Java层的框架(基类)，基类控制App

1.5 重视跨平台设计，才能建立自己平台

◆ 必须使用别人芯片平台，如何能摆脱别人的牵绊?
 ◆ 必须使用Android软件平台，如何协天子(Android)以令诸侯?
 ◆ 如何跨越Android的版本升级和碎片化障碍?
 ◆ 应用软件如何跨<操作系统>平台(如Android、iOS等)呢?
 ◆ 互联网&电信厂商如何追求跨终端平台(如TV, Pad等)?
 ◆ 终端产品如何云端(Cloud)平台?

1.6 没钱就改版，改版就有钱

      ◆  终端厂商的底层软&硬件模块变动自由度非常重要
      ◆  如此，创造”没钱就改版，改版就有钱”的机会
      ◆  上层模块不能要求底层的稳定不变，而是要处处维护底层变动自由度

1.7 软硬整合开发，硬硬结合销售

      ◆  如苹果公司的主(大)硬件种类不多，但其(小)配件总类多达600多种
      ◆  软硬整合能涵盖大、小硬件整合一起销售
      ◆  小配件的短期获利，能调降主硬件售价，扩大市场地盘

1.8 质量保证 = 跨平台架构设计+测试

      ◆  系统架构设计与测试两者携手，一起摆脱别人平台的牵绊，然后提高质量，振翅高飞
      ◆  检验别人(平台)软、硬件模块的功能
      ◆  测试您自己(平台)软、硬件模块的功能
      ◆  测试您的软硬整合平台框架&API
      ◆  测试您自己的应用(App)程序代码
      ◆  测试UI体验(look and feel)

1.9 项目管理：可以搭配敏捷(Agile)开发

      ◆  为什么敏捷开发与Android是个很好的搭配呢?
      ◆  理由(一)：Android有测试框架，可建立TDD测试机制来推动迭代过程
      ◆  理由(二)：Android框架内涵是代码，满足敏捷原则：”各项设计必须迅速落实为代码”，这很有利于密切配合敏捷迭代过程，并漂亮地”落地”在Android平台上

1.10 未来性：以软件接口包装通信协议

      ◆  通信协议的善变是本质性的
      ◆  软件接口可以包容善变的协议
      ◆  例如，以软件的Socket接口包装Zigbee或Bluetooth的善变性

Part-2. Android产业自主化的跨平台策略

2.1 产业供应链与芯片技术发展

      ◆  介绍主流Android 4.x兼容芯片(如高通的7X27, 8X60,TI OMAP等)的产业技术现况与发展趋势
      ◆  以智能TV/STB的供应链为例，阐述主流芯片(如晨星MSD6A806, 高通Snapdragon S4 MPQ8064)与终端厂商的合作关系及其商业模式
      ◆  这些不同的芯片技术上的共同点和差异点
      ◆  不同芯片平台与Android软件平台结合的共同点和差异点

2.2 终端厂商的跨平台(又称平台化)策略

◆ 讨论不同终端厂商最常采用的平台化策略
 ◆ 举例说明<芯片平台化策略>的要点
 ◆ Android版本升级时，产品更新速度如何解决，各厂商有哪些新技术
 ◆ 如何建置中间件，跨自己平台(的版本)问题
 ◆ 芯片厂商的基线升级后，应该如何跟进? 说明高老师的观点和策略

2.3 跨平台对策的挑战议题

◆ 跨平台目标：如何让产品普遍执行于各平台，扩大市场?
 ◆ 必须使用别人芯片平台，如何能摆脱别人的牵绊?
 ◆ 必须使用Android软件平台，如何协天子(Android)以令诸侯?
 ◆ 如何跨越Android的版本升级和碎片化障碍?
 ◆ 如何提升自己平台的稳定性，降低升级成本?
 ◆ 应用软件如何跨<操作系统>平台(如Android、iOS等)呢?
 ◆ 互联网&电信厂商如何追求跨终端平台(如TV, Pad等)?
 ◆ 终端产品如何云端(Cloud)平台?

Part-3. 复习Android平台的多层框架体系

3.1 Android基础知识

◆ Android进程与IPC机制
◆ Android线程模式

3.2 Android的分层框架

      ◆  HTML5/JavaScript层
         ★ 创造跨平台的HTML5/JS层
         ★ 这透过WebView呼叫下层的Java插件(属于Java层)
      ◆  Java层
         ★ 这是专属于Android平台的App
   ★ 透过JNI呼叫本地C函数(属于本地C层)
◆  JNI/C层
         ★ 能透过ServiceManager绑定下层的C++核心服务
         ★ 也能直接呼叫HAL-based驱动模块
◆  核心(系统)服务层
         ★ 直接呼叫下层的HAL-based驱动模块
         ★ 也能将讯息传送给上层本地C模块
         ★ 核心服务也能以Java来撰写，这种核心服务属于Java层
◆  HAL & 驱动层
         ★ 为了避开GPL协议，Android驱动大多写成HAL Stub模块
         ★ HAL Stub可透过System Call呼叫Linux内核，实际控制硬件

3.3 Java与C/C++层沟通API设计

◆  JNI(Java Native Interface)编程要则
◆  正向通讯：Java函数呼叫本地C函数
◆  反向通讯：本地C函数呼叫Java函数

3.4 核心服务API设计与开发技术

◆  包括Android Service和 Native Service两种
◆  核心服务都是在开机过程中，由Android的INIT进程启动的
◆  应用服务可以透过ServiceManager去绑定(Bind)核心服务
◆  范例：撰写一个核心服务

3.5 IPC通讯接口设计方法

◆ Proxy-Stub设计模式
◆ C/C++层的包装：核心服务的专用接口设计

Part-4. 跨平台基础技术：EIT设计造形

4.1 容易，插件容纳变化

◆ 插件的分类
◆ 插件与界面(Interface)
◆ 强龙设计接口、地头蛇开发插件
◆ EIT造形里的插件<T>

4.2 结构制约，积极掌控插件

◆ 什么是接口?
◆ 谁控制?
◆ 决定控制权
◆ 没钱就改版，改版就有钱

4.3 组合创新，让整体<飞>起来

◆ 什么是平台<E>?
◆ <E>是控制点，透过来驱动<T>
◆ <E>像人的头脑：逻辑控制
◆ 像人的脊椎：结构组合

4.4 需求分析，插件从那里来?

◆ 把领域知识写入于框架基类<E>里
◆ 把买主知识需求写入到子类<T>里
◆ 定义两者之间的接口
◆ <E>是平台，透过来呼叫<T>

Part-5. 范例：EIT造形及其组合规律

5.1 Android的ListView框架

◆ 观摩ListView的框架，解析其幕后的EIT造形，理解其插件<T>如何容纳用户(App)的变化
◆ Step-1：需求分析，解析用户需求变化
◆ Step-2：依据需求分析表，设计接口
◆ Step-3：详细设计接口和插件<T>
◆ Step-4：将EIT造形对映到Android的程序码

5.2 Slot Machine游戏机的情境，设计您的造形

◆ 分析情境
 ★ 用户(User)是：玩家
 ★ 买主(Buyer)是：赌场老板
 ★ (前端)游戏机制造商(Maker)是：G公司
◆ 分析买主需求的变化
 ★ 变化(一)：选择赌场的后端Console平台
 ★ 变化(二)：自订UI
 ★ 变化(三)：修正奖金
◆ 依据上述分析，依循EIT造形，规划您的<E&I>，并设计<T>来吸纳买主的变化

5.3 观摩Android平台<Context-View>框架的风格

◆ 情境：Android如何播放MP4影片
◆ 解析架构，其含有3个EIT造形
 ★ 造形-1：{ ViewRoot, View, SurfaceView }
 ★ 造形-2：{ SurfaceView, Callback, <T> }
 ★ 造形-3：{ ActivityThread, Activity, <T> }
◆ 并使用到一个外来的平台：MediaPlayer播放器
◆ 请您观摩这三个造形的细节设计，以及三个造形之间的组合结构和组合规律
◆ 组合规律有两种
 ★ 造形之内：元素之间的组合规律
 ★ 造形之外：造形之间的组合规律

Part-6. 跨平台模式：一个造形，三个策略

6.1 一个造形，三个策略，巧妙组合出无限风格

◆ 在别人的平台上，受制于人，因而有”跨平台”的期盼
 ◆ 于是，展开了：争夺制定权，以及逻辑<E>控制权
 ◆ 尚方宝剑：一个造形，三个策略
 ◆ 一个造形：EIT造形
 ◆ 三个策略
 ★ 策略-1：把它”EIT(设计)”了
 ★ 策略-2：挟天子以令诸侯
 ★ 策略-3：建立中间件(middleware)
 ◆ 众多风格：策略的变化与组合

6.2 跨芯片(小)平台：采取<策略-1>

情境A：先有别人的(小)平台，然后才建立我的平台
 ◆ 小平台是指别人的平台，该平台的变化决定于别人
 ◆ 为了跨平台，就不宜直接使用别人的平台
 ◆ 您设计<E&I>，而且设计<T>来包容别人平台的变化，这就称为：把它”EIT(设计)”了。
情境B：先建立我的平台，然后才让别人来扩充(Extend)
 ◆ 这反过来，让别人设计插件<T>来扩充(extend)您的<E&I>
 ◆ 别人为了保护他自己，也会将插件分成两部分：<壁虎尾巴>与<壁虎身体>
 ◆ 万一您的<E&I>有变化时，这只壁虎(插件)便能弃尾求生，让<壁虎身体>跨您的<E&I>

6.3 跨Android版本(大)平台：采取<策略-2>

◆ Android升级和版本变更频繁，终端必须随之而更新
 ◆ Android是一个多层级<E&I>结构，各层都是由Google所开发，Google是强龙，位居天子角色，其设计来控制您的插件<T>
 ◆ 您可以拿EIT造形搭配Proxy-Stub设计模式，规划Stub类别(曹操类)，制定自己的，让<T>脱离Android的<E&I>所牵制；实现”挟天子以令诸侯”的效果

6.4 跨自己的平台：采取<策略-3>

◆ 随着您的公司业务成长，您的平台版本变更频繁；如何包容自己平台的变化呢?
 ◆ 您可以规划一个上层平台<E&I>来吸纳自己平台的变化
 ◆ 此平台又称为中间件，其提供稳定的(又称API)，也保护自己平台的变动自由度，实现”没钱就改版，改版就有钱”的效果
 ◆ 中间件还能提供您的专有API，来凸显自己平台的独特性

6.5 终端跨云平台：应用上述策略

封闭型云平台
 ◆ 这属于传统的Client-Server架构
 ◆ 您可以采取<策略-1>来别人的Server(即云平台)
开放型云平台
 ◆ 别人设计云端的平台<E&I>，让您来写云端插件<T>
 ◆ 您可以采取<策略-2>来规划曹操类，制定自己的，让<T>脱离别人的<E&I>所牵制；实现”挟天子以令诸侯”的效果

6.6 其它情境：组合上述策略

大强龙跨云&端平台
 ◆ 于终端或云端，谁掌握了<E&I>，谁就是强龙
 ◆ ”设计中间件”是掌握<E&I>的不二法门
 ◆ 欲成为大强龙，您除了掌握云平台的<E&I>之外，还要掌握终端的<E&I>
 ◆ 例如，在Android平台上，Google就是大强龙
小强龙跨端&云平台
 ◆ 大强龙在云与端都有强势的<E&I>，您该如何面对呢?
 ◆ 您将”协天子以令诸侯”策略应用于终端和云端上。在两端都设计”曹操类”(Stub) ，并搭配Proxy类，成为Proxy-Stub机制

Part-7. 振翅高飞：迈向软&硬件的无缝隙整合

7.1 一个造形，一个大策略，四个小策略，组合出无限风格

◆ 一个造形：EIT造形
 ◆ 一个大策略：抛出鱼钩(和鱼饵)，控制钓竿
 ◆ 四个小策略
 ★ 小策略-1：将视为鱼钩、把<E>分解为鱼饵和钓竿。
 钓竿<C>是从<E>独立出来的逻辑控制点，<E>成为控制的代理者(agent)。
 ★ 小策略-2：把您的<E&I>当礼物大量送人
 ★ 小策略-3：鼓励别人加盟，开发<T>搭配您的<E&I>
 ★ 小策略-4：透过大量复制的<E&I>(即EIT造形)，带给<C>广大市场，而且拥有控制权
 ◆ 众多风格：策略的变化与组合

7.2 流行的风格：多层(Layered)蛋糕架构

◆ 典型的架构风格：多层蛋糕
 ◆ 把您的<C>比喻为蛋黄，把<E&I>比喻为蛋白
 ◆ 一层蛋糕 = { 以一堆鸡蛋为主的巧妙组合 }
 = { 以一群<E&I>为主的巧妙组合 }
 = 一个框架(framework)
 ◆ 多层蛋糕架构，就是多层框架的结构
 ◆ 策略运用：把多层蛋糕大量送人，替您的<C>带来巨大市场

7.3 多层框架的组合韵律

◆ 各层框架的内涵都不同，却都是一群EIT造形的组合
 ◆ 由于内涵不同，每一层您都必须创造不同组合风格来呈现出不一样的内涵
 ◆ 上下层框架组合规律
 一般的规律
 ★ 上层<E&I>可以直接或透过<T>来与下层<E&I>交互
 ★ 上层<T>可与下层<T>交互
 重要而特别的规律
 ★ 运用上述的小策略，您将上层的<E&I>与<C>分解开来
 ★ 您可写下层<T>来容纳这个<C>，成为下层框架内涵的一部分
 ★ 这个<C>可直接呼叫上层的<E>，这<E>就扮演<C>的代理者角色
 ★ 您就可以把上层<E&I>当成礼物大量送人了，实践了上述的大策略

7.4 软硬整合的关键：如何让鱼上钩

运用上述的大策略
 ◆ 就是鱼钩
 ◆ 从<E>独立出<C>，于是<C>是钓竿，剩下的<E>是鱼饵
 ◆ 设计好，充实<E>
 ◆ 然后把<E&I>当礼物赠送出去，放长线钓大鱼
成败关键：掌握API(即)设计
 ◆ 若无法主导API制定，就支持通用API
 ◆ 聚焦于您所擅长行业的API，主导行业API制定权
 ◆ 基于您优势的行业知识，充实<E>和<C>
 ◆ 把<C>隐藏于下层框架(或伺服端，或云端)，并将上层框架的<E&I>大量赠送出去
<T>的管理风格
 ◆ 前面介绍了三种EIT造形
 ★ 扮演主角的”产品(product)型EIT”
 ★ 扮演配角的”工厂(factory)型EIT”
 ★ 扮演配角的”容器(container)型EIT”
 ◆ 面对各种软硬整合情境，您认为还需要更多种配角的EIT吗?

Part-8. 跨平台策略下的自动化测试方法

8.1 擅用Android的JUnit测试框架

测试用途的EIT造形
 ◆ Android提供多种测试工具，都是基于JUnit测试框架的
 ◆ 框架是由许多<E&I>所组成；其TestCase基类是<E&I>
 ◆ 从TestCase衍生出各种子类别，如ServiceTestCase就是扩充的<E&I>；其内涵的setUP()和tearDown()函数就是
 ◆ 您可以撰写一个<T>(即test case)，来测试一个Service的子类别(即Service基类<E&I>的<T>)
 ◆ 如果有许多个test case，您可以使用TestSuite基类EIT来管理它们；也就是写一个TestSuite的<T>(即子类别)，来容纳上述TestCase的<T>
风格：造形组合规律
 ◆ 上述测试情境，共组合了三种EIT造形
 ★ ”产品(product)型EIT”：Service基类EIT
 ★ ”测试(test)型EIT”：TestCase基类EIT
 ★ ”容器(container)型EIT”：TestSuit基类EIT
 ◆ 的EIT用来测试Service的<T>
 ◆ 的EIT容纳TestCase的<T>

8.2 检验别人(小)平台

一般的设计
 ◆ 由于您的平台没有EIT造形的结构性制约，与别人(小)平台之间衔接点没统一、不集中
 ◆ 您想对别人(小)平台的所有<CI>进行测试是事倍功半的
采用EIT跨平台设计
 ◆ 两个平台之间的衔接点就在于<T>，这<T>的数量是有限的，可能只使用到别人(小)平台的<CI>的部分功能而已
 ◆ 由于数量、功能有限；您能轻易撰写test case去测试这些<T>，也就测试到别人(小)平台了

8.3 测试您自己的平台

一般的设计
◆ 两个平台之间的衔接点没统一、不集中；要建立Mock 模块来仿真别人(小)平台，是旷日废时的
采用EIT跨平台设计
◆ 两个平台之间的衔接点就在于<T>，且<T>的数量和功能都有限，您很容易建立Mock 模块来仿真别人(小)平台

8.4 测试您自己的重要模块

一般的设计
      ◆  重要模块(和逻辑)与Android大平台混合在一起，非常不容易独立出来测试
采用EIT跨Android(大)平台设计
      ◆  采取”挟天子以令诸侯”策略，并搭配”壁虎身体/尾巴分离”小策略，重要模块(即壁虎身体)独立于Android平台的牵绊，很容易撰写test case来测试之
      ◆  不必因Android改版而重新进行单元测试

Part-9. <Android + 敏捷>以及落地问题

9.1 敏捷与架构的完美组合

◆ 敏捷开发的原则和价值观
 ◆ 开发、架构、测试之关系
 ◆ 架构在敏捷过程里的角色
 ◆ 架构师在敏捷过程的职责
 ◆ 过程观点：(需求)测试做<反馈>，敏捷(过程)做<迭代>；
 ◆ 分合观点：(架构)设计做<分>，(代码)开发做<合>
 ◆ 测试触发反馈，反馈带动迭代，迭代驱动<架构à代码>重构
 ◆ 迭代促进了<架构师&开发者>的心灵沟通与携手协作
 ◆ 举例：架构师如何设计敏捷的起始架构(Simple Solution)
 ★ 加法设计：围绕问题( Problem)和愿景(Vision)，产生创意构想(Creative Idea)
 ★ 减法设计：创意爱上限制(Creativity loves constraint)

9.2 代码是架构的外貌，永远青春

◆ 架构师与开发者的合作成果：架构+代码=软件(系统)
 ◆ 架构是软件的骨架、代码是软件的外貌
 ◆ 架构是软件的核心
 ◆ 架构的用意：创新组<合>
 ◆ 架构设计的焦点：接口(Interface)
 ◆ 设计决策具有<未来性>，系统才能适应未来

9.3 设计与开发的分工合作

◆ 架构设计的目的是：组合
 ◆ 架构师做<分>，支持开发者做<合>，合作实践(系统)组合
 ◆ 分得妙，就能合得快(即：分之以为用，合之以为利)
 ◆ 分得妙，就能得好接口(Interface)
 ◆ 架构师的核心工作：接口设计(Interface Design)
 ◆ 开发者的核心工作：依据接口，开发(系统)模块并整合
 ◆ 有许多种开发者：如App开发者、底层系统开发者等

9.4 敏捷的落地问题

      ◆  为什么要将敏捷开发(Agile)带进Android世界呢? 因为Android已经跨越单机开发，迈入多机整合、多屏互动的领域了。Android的项目日益扩大、复杂化。我们需要加入新潮的软件工程、新一代的架构设计思维和模式。
      ◆  为什么敏捷开发与Android是个很好的搭配呢? 理由之一是：Android有完善的测试框架，有利于建立TDD测试机制来推动迭代过程。理由之二是：Android平台架构是一个多层框架(Layered Framework)体系，框架内涵是代码，满足敏捷原则：”各项架构设计决策都必须迅速落实为代码”；有利于密切配合敏捷迭代过程，让敏捷方法漂亮地”落地”在Android平台上。
      ◆  于是，Android开发团队采用主流的敏捷开发方法，基于创新型的架构设计模式，让项目经理(PM)有效地组织开发、设计及测试人员，灵活敏捷地面对复杂多变的需求，维持高度的用户体验。

~ end ~

Android终端厂商的跨(芯片)平台架构设计_A04课程大綱