瞭解在Flash中的編程工作

來源:互聯網
上載者:User
編程

本文節選自《Flash MX professional 2004 第一步》(陳冰著)

第十八章 瞭解在Flash中的編程工作

  媽媽,這扇大門好雄偉好輝煌啊,它通向哪裡?
  寶貝,它通向編程的世界,那是充滿魔法的世界,進入那裡,你將成為偉大的魔法師。

  經曆了此前整整十七章的學習,我們終於來到了編程世界的大門,大門敞開著,顯然,它一直在等待我們的到來。

18.1 像軟體設計師那樣思考問題

  我相信你們中有很多人只有很少或完全沒有編程基礎,否則,你就不會選擇我寫的這本《第一步》了。我們已經知道,在Flash中使用ActionScript編寫指令碼,與使用其他語言編程沒有什麼不同。而要最終鍛煉成一名出色的軟體設計師,你要做的第一件事就是要時刻提醒自己要像一個軟體設計師那樣來思考問題。

18.1.1 不要總想著逃避編程

  對於在Flash中的編程而言,要做到像軟體設計師那樣來思考問題,最重要的一點就是不要總想著通過逃避編程來實現你的想法,很多人總是想方設法試圖用非編程的手段來完成他所面對的一切問題,為此,他可以不惜代價,可以花費大量的時間,他會想出數不清的繞過編程的變通方法,如果這些方法也可以被稱為演算法的話,絕對會令許多軟體設計師吃驚。

  實際上,在很多時候,使用編程的方法可以被非編程的方法節省大量的時間,而且會產生更為真實的效果。很典型的一個例子就是表現各種隨機運動,例如,大量雪花的飄落、魚的遊動。

18.1.2 認真的編寫設計說明書

  要像軟體設計師那樣來思考問題,你要努力地用邏輯清晰的語言來描述你想要實現的那個想法。這個過程就是軟體開發中非常重要的編寫設計說明書的過程。

  聽起來有些傲慢,但在你完成了一個詳細的設計說明書後,你的工作中的95%就已經完成了。每當有人問我某個想法是否能實現時,我總是回答說只要他能夠詳細的描述出它,我就能夠編出它來。對於Flash中的開發而言,一個設計說明書的全部就是一個對於Flash電影將如何執行和表現的詳細而嚴謹的描述。一個好的說明書將花費大量的時間和工作,但這是值得的。當它完成時,它將承擔起工作藍圖的職責。

  一個人的關於資料要詳細到何種程度的想法可能與另一個人不同,但越詳細越好。當你在工作的前期投入了額外的精力後,它將不僅僅在沿著這條路的行進中為你節省下時間,它也將減少返工的機會。

  編寫一個極為詳細的說明書所存在的一個問題是你很難做到充分的描述最終的程式,因為一個書面的說明書與最終的Flash電影差別巨大。簡單點說吧,僅僅用語言來描述一個繪圖中的顏色或在沒有某些音樂裝置的情況下描述一個歌曲的聲音是不可能,這裡存在著解釋錯誤。但這並不意味著你應該草率的放棄編寫說明書的整個過程。相反,你只需將它編寫的足夠詳細使你有把握依靠它展開工作就可以了。另外,你一定要知道先前你所做的工作將對以後的工作產生槓桿作用。失之毫釐,謬以千裡的事情經常是由不負責的設計說明書導致的。

18.1.3 要想到還有其他的可能

  有些時候,一個實現似乎有一個清晰的邏輯,似乎很明顯就該按照你設計的演算法和邏輯來編寫程式,但當開發進展到某一步時,你卻好像遭遇到了一堵牆,無法再前進一步,很多初學編程的人會在這裡投入大量的時間,不斷的反覆檢查自己設計的演算法的邏輯和程式碼的編寫,對其進行無數次的小修小改,最終陷入泥潭。

  然而,一個有經驗的軟體設計師在這種情況下,會很快意識到自己最初的判斷可能存在根本性的錯誤。很多時候,複雜事物的背後是簡單的邏輯,而簡單事物的背後卻潛藏著複雜的邏輯。徹底拋棄自己原先的演算法,換一種思維,儘力去猜測另一種可能,你會發現,那堵牆開始消失了。

  人們總是情願用簡單的方法去解決事情,在編程上也是一樣,這是正確的思路,但有的時候,當簡單的方法行不通時,你要意識到這件事情或許要用複雜的方法才能實現。
不要總把事情想的那麼簡單,總要想到還有其他的可能。

18.2 物件導向的軟體開發中的重要概念

  在第四章中我已經簡單的介紹了什麼是物件導向的軟體開發,你應該還記得那個以“人”作為對象的例子,以及當路遇惡狗而被惡狗攆這一事件發生時,他可以調用“撒腿就跑”這個方法來作為對這個事件的響應。
 
  但不管怎麼說,我不想因為這些例子而使你輕視了物件導向的軟體開發。事實上,物件導向含義深遠,涉及許多重要的概念,只有充分理解了這些概念的含義,你才算真正理解了什麼叫物件導向。很多概念你都應該知道,但限於篇幅,本節中我將講解其中最重要的九個。
  物件導向的軟體開發中九個最基本的概念:類、對象、屬性、方法、抽象、封裝、繼承、多態,以及事件。

18.2.1 類和對象

  類是對象的軟體抽象,是建立對象的模板。例如,如果一個人被看作一個對象的話,則人這個物種就可以被看作一個類。類定義描述了包括資料和功能在內的結構,對象由其建立。一個類表示一組相似的對象。對象是類的執行個體。

  為什麼需要類,想象這樣一個情況,假如我們要編寫一個Flash遊戲,裡面要有一些能自主活動的小人,這些小人都有相同的體貌特徵和活動能力,那麼,若我們要為每個小人編寫程式的話,則工作量毫無疑問是巨大和重複的。在這種情況下,我們就應該建立一個“小人”類,以後每當需要一個新的小人時就從“小人”類產生一個小人即可。

  話說到這裡,你一定想到了元件和執行個體的關係。沒錯,類和對象的關係與元件和執行個體的關係一樣,因為元件實際上就是Flash的內建類。

18.2.2 屬性和方法

  屬性是資料,而方法是函數。屬性是類知道的事情,而方法是類完成的事情。屬性和方法都是類的職責。物件導向的軟體開發是基於這樣的概念:系統應由對象來建立,對象擁有資料和功能。屬性定義資料,而方法定義功能。

  顯然,在物件導向的開發中,最重要的工作就是定義類。而定義類時,就必須定義它的屬性和方法。屬性的定義應該是直接明了的,需要定義它的名稱和資料類型。方法的定義就是建立一個函數的過程,根據需要,你可以建立出能夠接受參數且能夠傳回值的方法。

18.2.3 抽象

  世界非常複雜,為了處理它的複雜性,在軟體設計中,當需要對事物建立數學模型時,我們有必要對事物進行泛化或抽象。還是以人作為對象,從招聘的角度看,我們需要知道這個人的姓名、性別、年齡、教育背景、工作經曆,連絡方式,以及性格特點;而從相親的角度看,則需要知道這個人的年齡、身高、外貌、教育背景、家庭背景,甚至生辰八字。還是同一個人,只是對他(或她)進行了不同的抽象而已,對一個事物進行怎樣的抽象將依據你要設計的程式而定。

  抽象是個分析的過程,是在事物周圍繪製出一個清晰的架構的過程。抽象應該包含應用程式感興趣的功能、屬性、方法,而將其他因素忽略。這就是為什麼招聘的抽象包含教育背景和工作經曆,但不會包含生辰八字的原因。抽象的過程,就是定義類知道和要完成的事情的過程。

18.2.4 封裝

  儘管抽象告訴我們,對於招聘,我們應該儲存應聘者的教育背景和工作經曆,但它沒有告訴我們該怎樣完成這些事情。封裝解決了如何為系統功能建模的問題。在物件導向的世界中,我們要把系統建模成類,類也要建模為屬性和方法。設計類將如何完成這些事情的過程就被稱為封裝。

  封裝描述了如何在系統中劃分功能的問題。我們並不需要知道對象內部是怎樣實現的。封裝暗示著我們能夠以任何方式構建系統,如果需要的話,還可以在日後再次修改其內部的結構,只要系統中不同功能組件之間的介面沒有發生變化,那麼對系統中一個功能部分的改變不會對系統的其他功能部分產生影響。

  封裝是把事物周圍的那個架構塗黑的過程。你可以定義任何想要定義的東西,但你並不需要告知外界你的做法。例如,當你到銀行存取現金的時候,你並不需要知道銀行的資料中心是如何使用大型主機、小型機和PC機來記錄你的賬戶資訊的,它們使用著怎樣的資料庫和作業系統,也根本無關緊要,因為它們已經把賬戶服務的功能封裝起來了。你只需走到櫃檯前,把存摺遞給銀行的工作人員既可。通過隱藏起實現賬戶功能的細節,銀行能夠在任何時候自由改變功能實現,而不用費事得更換每一個使用者的存摺。

  為了讓應用程式容易維護和增加安全性及健壯性,需要限制對類的屬性和方法的訪問。基本思想如下:如果一個類想擷取另一個類的資訊,必需先徵得同意,而不是直接拿來就用。考慮一下,在現實世界中其實也是按照這種方法工作的。如果你想瞭解其他人的姓名,你該怎麼做?是直接詢問這個人他的姓名呢,還是偷走他的錢包看看他的身份證呢?

18.2.5 繼承

  不同的類之間經常會存在相似性。兩個以上的類也會經常共用相同的屬性和/或相同的方法。因為我們並不想重複編寫代碼,因此我們就要利用這種相似機制。繼承就是這種機制,它使你可以很容易的重用現有的資料和代碼。

  例如,學生都有姓名、地址、手機,也都能快跑。同時,老師也都有這些東西。毫無疑問,我們可以開發有關學生和老師的類,讓它們一起運行。實際上,僅需要先開發Student類,一旦它運行起來了,製作一份拷貝,就叫Teacher類,並對其進行一些適當的修改即可。這樣做很容易,但並不完美。如果Student類中的原始碼出現錯誤將會怎樣?你將不得不在兩個地方改正錯誤。這將是索然無趣的工作。如果僅有一份代碼拷貝用於開發和維護,這樣不是更好嗎?

  這就是繼承的思想。使用繼承,就可以定義一個類來封裝學生和老師之間的相似性。新的類將有屬性name、address、mobileTelephone,以及方法run。我們可以把這個類命名為Person。

  一旦定義了Person類,就可以從它繼承出Student和Teacher類。我們稱Person是Student和Teacher類的超類,而Student和Teacher類則是Person類的子類。任何超類知道和完成的事情,子類也知道。因此,既然Person類遇到惡狗時能撒腿就跑,Student和Teacher類也能。

18.2.6 多態

  讓我們考慮一下這個例子。你很愛你的女友,你對她說“親愛的,我愛你”,你的女友熱情的擁抱你,你還得到了一個吻,你覺得這很不錯。然後,你來到了大街上,看到一位很有氣質的美女,你也用跟女友打招呼的方式對這位美女說“親愛的,我愛你”,你將立刻得到有關你的神經和品德方面的一些建議。隨後,你又來到醫院,對一老中醫說“親愛的,我愛你”,老中醫將毫不猶豫的拉過你的手腕,開始為你把脈。你心想,無論何時當我遭遇這些對象並說“親愛的,我愛你”時,這種情況肯定就會發生—這就是多態。

  多態使得對象可以在事先不知道其他對象的類型時就與其他對象協作。
  從這次經曆中你可以學到幾個有意思的經驗:

  第一,多態阻礙了你與其他對象之間的互動。你並不區別其他對象的類型,你以同樣的方式對待他們。你的想法是其他對象都是人。多態是允許這種情況發生的一個概念。

  第二,不同的對象以他們自己的方式作出不同的響應。你的女友擁抱你並給你吻;陌生的美女給你有關神經和品德方面的建議;而老中醫則給你把脈。同一訊息到達不同的對象,每一個完成的事情都是不同的。實際上,從各個對象的角度看,他們做了應該做的事情。

  第三,多態可以實現一致而恰當的方法名。儘管每種對象都以適當的方式響應了“親愛的,我愛你”,但還是要實現方法的不同版本。

  多態性主要包括兩個方面:
  運算子的重載:同一運算子可以作用在多種物件類型上。
  函數名重載:相同的函數名可以作用在不同的物件類型上,併產生不同的效果。

18.2.7 事

  物件導向的軟體的運行是隨著一個個事件的發生來進行的,這被稱為“事件驅動”。例如,當你欣賞Flash動畫時,實際上是正在發生一個個“進入幀”事件,在這些事件中,Flash Player會呈遞每幀中的內容,所以你就能看到畫面。

  同樣的,當你點擊按鈕時,一個按鈕事件就發生了,該按鈕事件中的指令碼就被執行,這些指令碼的作用可能是把你帶到特定的情境、特定的幀,或是連結到某個URL。

  在物件導向的程式設計中,整個軟體都是以事件驅動的,這意味著假如沒有任何事件發生,你的程式將寸步難行,不過好在程式中總是有某些事情發生的,即使所有其他的事件都不發生,也會有時間流逝這一事件在時刻發生著。

  在本書後面章中的實際開發中,你將看到上述所有這些物件導向的概念的實際運用。

18.3 好的編程風格

  儘管你將進行先進的物件導向的軟體開發了,但一些在面向過程的年代就已經總結出的好的編程風格在任何時候(至少在可預見的未來)都不會過時。本節將教給你這些放之四海皆準的規則,這些規則不是強制性的,但遵守它們毫無疑問會使得你的生活變得容易。
  好的風格意味著以一種易維護的方式進行編程。你的代碼應該容易到足以使任何人都能夠理解它。這倒不是說其他人需要查看你已經編寫的這些代碼(當然這種情況可能會發生),而是說當你需要進行調試或修改錯誤時,你能夠快速的理解你已經開發出的到底是些什麼東西。人們總是很容易失去自製力的試圖去建立某些東西而忽視了有益的整理工作。草率的行事將引起無限的煩惱,因此你應該總是儘力遵循好的編程風格。
  當然,“好”不能輕易得到,“好”通常就意味著大量的工作。在這裡,好就意味著:好的名字、減少重複、總是注釋,以及分離代碼和資料。

18.3.1 好的名字

  什麼是好的名字?在編程世界中的好名字的概念和我們日常生活中好名字的概念有很大的不同。在我們的日常生活中,一個好名字往往意味著非常值得推敲:或者是表達父母的良好願望,或者是字典中絕妙的解釋。但一個日常生活中的好名字用在程式中卻是很糟糕的,一個這樣的名字無法提供除名字之外的其他資訊。

  在編程世界中,判斷一個好名字的標準是是否能夠以最少的字元提供更多的資訊。在Flash中,我們可以且需要命名的東西是非常多的,每一個按鈕或電影剪輯的執行個體,每一個文本執行個體,都有可能需要命名;每一個變數,每一個函數,每一個類,都必須命名。
在Flash中,當你命名一個事物的時候,你應該盡量讓這個名字反映出這個事物的所有重要的資訊。例如:fishCounterMC作為一個統計魚缸中魚的數量的電影剪輯的執行個體名就很不錯。很多天后,當你再次見到這個名字時,你能夠在瞬間獲得許多重要的資訊。首先,一打眼,我們就能知道這個名字指代的是一個電影剪輯(MC表示MovieClip),因此,這個名字是一個電影剪輯執行個體的名字,其次,我們能夠看出這是一個用來計數的電影剪輯(根據Counter),最後,我們可以推斷這個計數器應該是來統計魚的(根據fish)。
當為變數命名時,能夠在變數名中體現出這個變數的資料類型將是很有益的。childAge_Num作為一個用來儲存孩子年齡的變數的名字會是不錯的,從Num這個尾碼我們可以意識到這個變數應該儲存的是數字資料類型。

  有的時候,為了給事物賦予一個更有意義的名字,傳遞更多的資訊,你會發現名字正在變得越來越長,這不是好事情,太長的名字同樣會造成閱讀的困難。因為太多長名字堆積在一起會使得你看不清程式的邏輯,因此,對待任何事情,你都應該保持適可而止的態度,很多時候,你需要在傳遞更多的資訊和防止太長的名字之間進行妥協。

18.3.2 減少重複

  要使事情變得簡單,每一個編程工作應該在您的電影中只出現一次。如果你的同一段代碼出現在兩處,那麼你的更新和修改Bug的工作也將加倍。你將學到一些方法來實現這點,譬如說將指令碼儲存在庫中、儲存在函數中或從外部引入電影。任何時候,每當你打算拷貝和粘貼代碼時,一個不大的聲音應該在你的頭腦中響起—“住手!”。總會有一個更簡練的方法在等待著你。

  減少重複還意味著精鍊代碼,盡量用更少的代碼來完成同樣的工作。細想一下,當你為調試Bug而回頭檢查你的程式時,你所檢查的每一行代碼都必須在你的頭腦中進行翻譯,更少的行你必定讀起來會感覺更好。通常,任何時候你都可以以較少的步驟或更少的代碼來做某些事情。比較在代碼1和代碼2中的兩個程式碼片段,它們實現的是同樣的效果,但代碼2中的代碼要精鍊的多。

  代碼一:
on (release){
   setProperty ("highlight", _x, getProperty ("highlight", _x)+10);
   tellTarget ("highlight"){
    gotoAndStop(getProperty("",_currentframe)+1);
   }
}

  代碼二:
on (release){
   highlight._x+=10;
   highlight.nextFrame();
}

  那些在代碼一中的指令碼實現的是與代碼二中的指令碼同樣的效果,只是添了沒有必要的複雜性而已。這除了能引起比你水平低很多的選手的崇拜外,沒有更多的意義。

  誠然,沒有什麼方法是法定的最好的方法,但減少重複和精鍊代碼毫無疑問是有益的。當然,你也沒有必要把減少重複,精鍊代碼這點貫徹得太徹頭徹底。精簡代碼的要求不應重於易讀性。徹底失去自製力並最終終結於一堆連你自己都無法閱讀的代碼是很容易的事情。我永遠都不會在一個能夠工作的已完成的程式碼片段中挑刺兒—因為,說真的,這才是最優先要考慮的。其次,你的代碼通常都是由你來維護的,因此,編寫出你能夠閱讀和理解的代碼是最重要的。盡一切可能使用你能夠理解的代碼。如果這有時意味著你的代碼羅嗦一點的話,那也只能由它去了。隨著時間的推移,慢慢地你將看到你的代碼正在逐漸縮短。

  有時,當我審視那些僅僅是幾個月前才編好的程式時,我也會質疑我當時所採用的方法—但這僅僅是因為我總是在進步。如果你打算等到你的技術變得完美時再做的話,你將等待太長的時間。因此就這樣投入進去吧,時間自會證明你能夠進步。

18.3.3 總是注釋

  在Flash中,注釋是以//開始的文本。注釋在Flash中是被忽略的程式碼。注釋絕不是Flash的特點,翻開任何一本涉及編程的電腦書,你都會發現裡面有有關注釋的重要性的論述。的確,注釋是非常重要的,怎麼強調都不會為過。注釋能使你在數月甚至數年後仍能知道每段代碼的作用,仍能夠繼續對程式進行後續開發和維護;能夠在必要時候,讓別人看懂你的代碼,他(她)會一邊看一邊體味你的仁慈,並心懷感激,發誓也要做像你這樣的好男孩(或好女孩)。

  我認為我是一個壞男孩,因為我經常做不到對My Code進行充分的注釋,直到我讓它運行起來為止。但不管怎麼說,沒有將這一步繼續拖延下去對我來說很重要,因為在我寫出它的幾天之後,我會將有關這段代碼的一切忘的一乾二淨。沒有注釋,代碼的理解將變得困難的多。因此,花上一些時間去注釋你的代碼吧,即使你已經完成了你的代碼且熱情也日漸下降。比較一下代碼三中沒有注釋的代碼和代碼四中同樣的一些但做了注釋的代碼。儘管你目前可能不明白這些代碼的細節,但如果這裡存在問題的話,你將能夠輕鬆的識別出包含問題的部分。

  代碼三:
OnClipEvent (keyUp) {
   if (Key.getAscii()==13 | Key.getAscii()==0){
    return;
   }
   if (Key.getAscii()==8){
    if (cur.charAt(cur.length-2)==" "){
     _root.wordThisTime--;
    }
    cur=cur.slice(0, cur.length-2)+mbchr(8);
    if (_root.wrongPlace[_root.place-1]=="x"){
     _root.wrongPlace.pop();
     _root.wrongs--;
    }
    _root.place>0 && _root.place--;
    return;
   }
}

  代碼四:
OnClipEvent (keyUp) {
   //忽略這些字元
   if (Key.getAscii()==13 | Key.getAscii()==0){
    return;
   }
   //假如他們點擊退格鍵
   if (Key.getAscii()==8){
    //刪除一個空格?
    if (cur.charAt(cur.length-2)==" "){
     _root.wordThisTime--;
    }
    //刪除最後的字元
    cur=cur.slice(0, cur.length-2)+mbchr(8);
    //他們修改了一個錯誤嗎?
    if (_root.wrongPlace[_root.place-1]=="x"){
     _root.wrongPlace.pop();
     _root.wrongs--;
    }
    //後退一格
    _root.place>0 && _root.place--;
    //離開
    return;
   }
}

  代碼三在被注釋前,其中的代碼理解起來很困難。代碼四說明了不多的一點注釋就使得事情變得明朗,即使你還不明白這些代碼的潛在含義。

18.3.4 分離代碼和資料

  所有的程式設計師都應該力爭使代碼(簡單的說就是編程指令碼)和資料(或說特定工程的內容,例如:文本和圖形)保持分離。通過保持代碼和資料的分離,你能夠使你的編程成果輕鬆的移植到其他的工程。同樣的,當你想要對內容作重大的改變時—比如說,以不同的語言重做整個工程—你只需要替換資料而不必去碰(或破壞)那些代碼。這是偉大的思想但有時難以實現。

  假定你的Flash網站中有一些圖形按鈕,當使用者將他的滑鼠指標放置到按鈕之上時這些圖形按鈕將顯示出一個浮動的工具提示。如果你保持代碼(使工具提示出現的指令碼)和資料(實際將出現在工具提示中的文本)分離。你能夠輕鬆的將這個功能移植到另一種語言,而你所做的只是用另一種語言的文本來替換工具提示。理想的情況是,你將所有工具提示的所有文本儲存在同一個位置,這將使得移植工作變得更加的輕鬆。這一思想的主旨是你應該盡量做到對代碼或資料中任何一個所做的重大改變都不會對另一個產生影響。

  你可以將代碼資料分離視為一種模組化形式。還有一些其他的模組化形式—包括Flash的loadMovie(),它使你能夠在一個更大的電影的內部播放獨立的.swf檔案。除了所提及的代碼資料分離之外,模組化還有許多其他的優點。首先,通過模組化你的Flash電影,使用者們不需要等待整個電影的下載。他們可以有選擇的下載那些那他們感興趣的部分。此外,模組化也使得一個工程可以被乾淨的剝離成幾個獨立的部分,從而使得這些部分可以同時進行開發。思考這樣一種情況,如果你的整個電影僅由一個基本檔案構成,則同時只能有一個人可以工作。因此,可以看出,代碼資料分離及其它的一些模組化形式有著許多的優勢,你應該盡量保持以模組化的思想來考慮問題。

18.4 ActionScript術語

  我們已經知道了不少ActionScript的術語了,比如類、對象、屬性、方法、事件、指令碼等等。本節中將再介紹一些ActionScript中常用的術語,以便我在後面提及時,你不會感覺陌生。

  標識符—是一個符合特定規則要求的字串。具體的說,這個字串的第一個字元必須是字母、底線(_)或貨幣符號(

  執行個體—就是指對象。類的執行個體就是對象。很多人總是分不清類、對象和執行個體三者的關係。記住,對象就是從它所屬的那個類產生的。例如,當我們建立學生對象時,我們就說從Student類中把它執行個體化了。

  函數—是可重用的程式碼片段。一個函數完成一個特定的任務。你可以向函數傳遞參數,也可以從函數中傳回值。

  參數—是用於向函數傳遞值的預留位置。在下面的area函數中,x和y是該函數的兩個參數。

  function area(x,y){
   return x*y;
  }

  當你像下面這樣調用area函數時,就通過其參數向該函數傳遞了所需的兩個值,這兩個值在函數中進行運算,並將其運算結果返回到調用位置。
  rectangleArea= area(2,3);
  ActionScript中還有很多術語,我將在書中涉及它們時再進行講解



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。