我要回覆

蘋果 iPad 設計最引以為傲的是拿掉了許多不必要的東西

OhiYooo

214分

151樓

OhiYooo

個人積分：214分

文章編號：18700012

拍郎 wrote:
我的看法不同
如果 iPhone OS 是從這個層級就去限制了多工進行的方式
那 JB 是不可能解放多工的

如果JB只是把排程器正常的釋放出來, 放任它運作, 那就有可能!

效能低落跟耗電
主要看 resource 被耗掉多少
這不完全跟多工有關

還有一種可能, 這種 ARM based CPU 跟一般桌上型電腦的CPU(Intel)非常的不同. 而是以省電性能為訴求.
省電的手段之一就是, 當需要時 CPU 隨時有能力將時脈停掉, 進入幾乎不耗電的模式. CPU也可以隨時再回來, 立即進入工作.

多工的頻繁排程器Context switching 會破壞CPU這種省電機制. 雖然目前是CPU是IDLE的, 但因為排程器要運作, 雖然暫時沒事作, 但CPU也被排程器搞得永遠不得休息. 電力當然就直直落囉...

拍郎

311分

152樓

拍郎

個人積分：311分

文章編號：18701584

OhiYooo wrote:
如果JB只是把排程器正常的釋放出來, 放任它運作, 那就有可能!

依照目前JB的方式
不太可能改到這麼核心
要改到 CPU 的排程方式
整個 OS 一定要重新編譯的

OhiYooo wrote:
還有一種可能, 這種 ARM based CPU 跟一般桌上型電腦的CPU(Intel)非常的不同. 而是以省電性能為訴求.
省電的手段之一就是, 當需要時 CPU 隨時有能力將時脈停掉, 進入幾乎不耗電的模式. CPU也可以隨時再回來, 立即進入工作.

這也不太可能
基本上 iPhone 的背景隨時都有一支程式在跑
就是『電話』
如果是您說的這種方式
那電話極有可能接不起來
一些提醒也可能都無法工作了

OhiYooo wrote:
多工的頻繁排程器Context switching 會破壞CPU這種省電機制. 雖然目前是CPU是IDLE的, 但因為排程器要運作, 雖然暫時沒事作, 但CPU也被排程器搞得永遠不得休息. 電力當然就直直落囉...

所以我才會說
iPhone 其實所有多工該做的事情早就都做了
要不然JB後也無法做到目前這樣的程度
也因此，我認為開放多工與否
跟耗電與效能並不能完全劃上等號

抗議Mobile01站方黑白不分亂停權，即日起關閉帳號不再參與討論

OhiYooo

214分

153樓

OhiYooo

個人積分：214分

文章編號：18702511

拍郎 wrote:
依照目前JB的方式
不太可能改到這麼核心
要改到 CPU 的排程方式
整個 OS 一定要重新編譯的

我自己覺得這並不難啊.
常看到人們破解軟體, 只要將關鍵的地方, 程式碼導引到另外一個修改過的碼. 就ok囉!
(病毒不也都是這樣運作的?)

這也不太可能
基本上 iPhone 的背景隨時都有一支程式在跑
就是『電話』
如果是您說的這種方式
那電話極有可能接不起來
一些提醒也可能都無法工作了

你說的這個方法, 叫做輪詢法(Polling).
一定要多工作業系統,使用輪詢法, 才有能力接電話嗎??? 不見得哦!
別忘了, 還有硬體的中斷服務(Interrupt)哦. 只要硬體中斷訊號進來, CPU就可以被派去做中斷服務. (即使CPU已經停掉了進入不耗電模式, 一樣可以被喚醒)
並不需要用個背景程式, 用輪詢(Polling)的方式. 這種最耗CPU資源, 反應也最慢!

我不覺得 iPhone 會用輪詢法來接電話, 那表示CPU必須24小時永遠運作, 不斷檢查是否有電話進來. 這真的太耗能了!

拍郎

311分

154樓

拍郎

個人積分：311分

文章編號：18705901

OhiYooo wrote:
我自己覺得這並不難啊.
常看到人們破解軟體, 只要將關鍵的地方, 程式碼導引到另外一個修改過的碼. 就ok囉!
(病毒不也都是這樣運作的?)

機會不大
排程邏輯不太可能作成 System Call
不是 System Call 的部份沒辦法用這種方式去 Hack

OhiYooo wrote:
你說的這個方法, 叫做輪詢法(Polling).
一定要多工作業系統,使用輪詢法, 才有能力接電話嗎??? 不見得哦!
別忘了, 還有硬體的中斷服務(Interrupt)哦. 只要硬體中斷訊號進來, CPU就可以被派去做中斷服務. (即使CPU已經停掉了進入不耗電模式, 一樣可以被喚醒)
並不需要用個背景程式, 用輪詢(Polling)的方式. 這種最耗CPU資源, 反應也最慢!

我不覺得 iPhone 會用輪詢法來接電話, 那表示CPU必須24小時永遠運作, 不斷檢查是否有電話進來. 這真的太耗能了!

中斷服務一般是在單工作業系統中要模擬多工的方式
在多工的作業系統中
通常不會允許用這種方式去破壞系統安全

另外，現在的 CPU 都會有 idle function 可以呼叫
不會因為 polling 就多耗 CPU 資源的
而且 Unix/Linux 本來就是 preemptive 的作業系統
程式要取得 resource 都必須透過 API
系統本身就會掌管所有資源
除非存心搞怪的程式
不然要造成 resource 的浪費並不容易
Apple 自己開發的程式更不可能去惡整自己的作業系統
要上 App Store 的程式需要經過 Apple 審核
要惡搞 iPhone OS 的機會也極低

您上面說的這兩種途徑都是很容易造成系統漏洞的方法
我相信 Apple 不太可能會這樣搬石頭砸自己的腳

抗議Mobile01站方黑白不分亂停權，即日起關閉帳號不再參與討論

pogolin

218分

155樓

pogolin

個人積分：218分

文章編號：18710046

目前上手機就一顆CPU，要做的事情非常多。

很多事情都得靠CPU來做，因此iPhone OS 3.0 不可能是單工的作業系統。

只是他讓一般的AP都是單工而已。

我贊同拍郎的說法。

iPhone OS 4.0馬上就有多工的功能，表示iPhone OS3.0本來就有，只是沒有開放權限給一般開發者開發的AP而已。

OhiYooo

214分

156樓

OhiYooo

個人積分：214分

文章編號：18711484

拍郎 wrote:
中斷服務一般是在單工作業系統中要模擬多工的方式
在多工的作業系統中
通常不會允許用這種方式去破壞系統安全

我很難贊同你這樣的說法. 硬體的中斷, 是由硬體所觸發的, 這跟系統安全不安全. 一點關係都沒有.
我很難相信, 為了系統安全, 放棄重要的CPU中斷技術於不顧, (自宮???) 而一切改用沒效率的輪詢法來運作. (難道你所有的I/O都必須藉由 backgrounder 在後面輪詢來偵測??)

iPod/iPhone 有眾多的 sensor, 例如陀螺儀, 它是靠輪詢法來運作的嗎? 錯!
資料顯示, 它是靠CPU中斷來運作的.

當陀螺儀偵測 iPad/iPhone 位置方向改變時, 硬體會送個中斷訊號給CPU要求中斷服務. iPhone OS 會以最早driver起始時所設定對應的中斷服務routine對其進行處理, 最後訊號以message型式通知上層的應用軟體.

資料連結如下

Example 1: Hardware to Application: Gyros

Now, the easiest way to break this down is via example, so we’ll use the gyros (the thingies that detect when you turn the iPhone to the side, A.K.A. Accelerometers), starting from the hardware:

1. Physical gyros detect a movement change, raise a bit (or modify a register) to indicate the change
2. Firmware detects the change, notes that the value indicates that the state of the iPhone is now different (as opposed to an erroneous value), and sends a processor interrupt through the system bus for attention.
3. The iPhone’s ARM processor receives the interrupt, and calls an in-memory interrupt service routine (ISR) that the iPhone operating system set up during driver initialization.
4. The ISR, a function (subroutine) located within the code for the iPhone OS, acknowledges the interrupt and begins to process it via the corresponding driver. The OS itself sends a signal to the current active application (if any) in the form of a Unix-style signal.
5. This signal is handled according to the specifications of the C/Objective-C runtimes, since the iPhone application compiler and linker constructs the application specifically to do this rather than handle the signal directly. The Objective-C runtime forwards the signal as a framework-specific message to the application, first checking whether the current application has been designed to handle said message.
...

OhiYooo

214分

157樓

OhiYooo

個人積分：214分

文章編號：18711622

pogolin wrote:
目前上手機就一顆CPU，要做的事情非常多。
很多事情都得靠CPU來做，因此iPhone OS 3.0 不可能是單工的作業系統。
只是他讓一般的AP都是單工而已。
我贊同拍郎的說法。
iPhone OS 4.0馬上就有多工的功能，表示iPhone OS3.0本來就有，只是沒有開放權限給一般開發者開發的AP而已。

Palm OS 會是你的反證.
早期的 Palm OS 是單工的作業系統, 但是早期的Treo90/180/270照樣可以處理電話這種你覺得需要"多工作業系統"才能處理的事情.
前面討論或拍郎自己也說了, 一個電話來了的硬體中斷給CPU, that's it!

拍郎

311分

158樓

拍郎

個人積分：311分

文章編號：18714715

OhiYooo wrote:
我很難贊同你這樣的說法. 硬體的中斷, 是由硬體所觸發的, 這跟系統安全不安全. 一點關係都沒有.
我很難相信, 為了系統安全, 放棄重要的CPU中斷技術於不顧, (自宮???) 而一切改用沒效率的輪詢法來運作. (難道你所有的I/O都必須藉由 backgrounder 在後面輪詢來偵測??)

iPod/iPhone 有眾多的 sensor, 例如陀螺儀, 它是靠輪詢法來運作的嗎? 錯!
資料顯示, 它是靠CPU中斷來運作的.

當陀螺儀偵測 iPad/iPhone 位置方向改變時, 硬體會送個中斷訊號給CPU要求中斷服務. iPhone OS 會以最早driver起始時所設定對應的中斷服務routine對其進行處理, 最後訊號以message型式通知上層的應用軟體....(恕刪)

用硬體來舉例子就偏離討論主軸(排程邏輯)了
driver 是作業系統跟硬體之間的橋樑
大部分的硬體都不能做多工處理(也沒必要)
所以多工的作業系統並不能讓硬體變成多工的
當然需要 driver 這樣的角色
而硬體對作業系統的工作方式當然是用硬體中斷處理
這也是為什麼 driver 對作業系統跟硬體之間的相依性這麼高
舉這樣的例子跟作業系統排程邏輯作對比實在是毫無相關

我前面所說的都是針對作業系統的排程處理邏輯而言
這跟硬體中斷基本上是兩碼子事
扯在一起會扯不清的
從 System Call 聊到排程邏輯
現在如果再扯到硬體控制那真的離原本的討論主軸太遠啦

我前面為什麼會舉電話做例子
因為 iPhone OS 很明顯的是用電話這個 process 在處理跟撥打電話相關的事宜
因為他是一個 process
所以我斷言他不是用硬體中斷的方式
一般硬體中斷的處理並不會在作業系統中形成一個 process

抗議Mobile01站方黑白不分亂停權，即日起關閉帳號不再參與討論

馬正唬

5分

159樓

馬正唬

個人積分：5分

文章編號：18719896

Apple 應該再拿掉一些功能, 以便使用者更專注在數位相框功能.

iPad來了！別害怕

pogolin

218分

160樓

pogolin

個人積分：218分

文章編號：18721209

基本上看iPhone的瀏覽器就可以知道，iPhone OS3.0就已經有多工的功能了。

因為使用者可以一邊瀏覽，可是瀏覽器卻可以背後幫你下載檔案，然後才慢慢呈現出來。

如果沒有Multithreading，沒辦法做到這樣的效果。

只是iPhone OS3.0並沒有把這樣的權限提供給一般AP的開發者。

因此我還是認為 iPhone OS 3.0本來就是多工的作業系統，只是只有Apple內建的AP才能使用，因為這是他們能夠控制的，可以最做到最佳化。