在Python中定義Main函數

目錄

創新互聯建站專業為企業提供橋東網站建設、橋東做網站、橋東網站設計、橋東網站制作等企業網站建設、網頁設計與制作、橋東企業網站模板建站服務，十載橋東做網站經驗，不只是建網站，更提供有價值的思路和整體網絡服務。

許多編程語言都有一個特殊的函數，當操作系統開始運行程序時會自動執行該函數。這個函數通常被命名為main()，并且依據語言標準具有特定的返回類型和參數。另一方面，Python解釋器從文件頂部開始執行腳本，并且沒有自動執行的特殊函數。

盡管如此，為程序的執行定義一個起始點有助于理解程序是如何運行的。Python程序員提出了幾種方式對此進行實現。

本文結束時，您將了解以下內容：

Python中的基本main()函數

一些Python腳本中，包含一個函數定義和一個條件語句，如下所示：

此代碼中，包含一個main()函數，在程序執行時打印Hello World!。此外，還包含一個條件（或if）語句，用于檢查__name__的值并將其與字符串"__main__"進行比較。當if語句為True時，Python解釋器將執行main()函數。更多關于Python條件語句的信息可以由此獲得。

這種代碼模式在Python文件中非常常見，它將作為腳本執行并導入另一個模塊。為了幫助理解這段代碼的執行方式，首先需要了解Python解釋器如何根據代碼的執行方式設置__name__。

Python中的執行模式

Python解釋器執行代碼有兩種方式：

更多內容可參考如何運行Python腳本。無論采用哪種方式，Python都會定義一個名為__name__的特殊變量，該變量包含一個字符串，其值取決于代碼的使用方式。

本文將如下示例文件保存為execution_methods.py，以 探索 代碼如何根據上下文改變行為：

在此文件中，定義了三個對print()函數的調用。前兩個打印一些介紹性短語。第三個print()會先打印短語The value __name__ is，之后將使用Python內置的repr()函數打印出__name__變量。

在Python中，repr()函數將對象轉化為供解釋器讀取的形式。上述示例通過使用repr()函數來強調__name__的值為字符串。更多關于repr()的內容可參考Python文檔。

在本文中，您將隨處可見文件(file)，模塊(module)和腳本(script)這三個字眼。實際上，三者之間并無太大的差別。不過，在強調代碼目的時，還是存在細微的差異：

“如何運行Python腳本”一文也討論了三者的差別。

基于命令行執行

在這類方法中，Python腳本將通過命令行來執行。

執行腳本時，無法與Python解釋器正在執行的代碼交互。關于如何通過命令行執行代碼的詳細信息對本文而言并不重要，但您可以通過展開下框閱讀更多有關Windows，Linux和macOS之間命令行差異的內容。

命令行環境

不同的操作系統在使用命令行執行代碼時存在細微的差異。

在Linux和macOS中，通常使用如下命令：

美元符號($)之前的內容可能有所不同，具體取決于您的用戶名和計算機名稱。您鍵入的命令位于$之后。在Linux或macOS上，Python3的可執行文件名為python3，因此可以通過輸入python3 script_name.py來運行python腳本。

在Windows上，命令提示符通常如下所示：

根據您的用戶名，之前的內容可能會有所不同，您輸入的命令位于之后。在Windows上，Python3的可執行文件通常為python。因此可以通過輸入python script_name.py來運行python腳本。

無論哪種操作系統，本文的Python腳本的輸出結果都是相同的。因此本文以Linux和macOS為例。

使用命令行執行execution_methods.py，如下所示：

在這個示例中，__name__具有值'__main__'，其中引號(')表明該值為字符串類型。

請記住，在Python中，使用單引號(')和雙引號(")定義的字符串沒有區別。更多關于字符串的內容請參考Python的基本數據類型。

如果在腳本中包含"shebang行"并直接執行它(./execution_methods.py)，或者使用IPython或Jupyter Notebook的%run，將會獲取相同的結果。

您還可以通過向命令行添加-m參數的方法實現以模塊的方式執行。通常情況下，推薦如下方式pip: python3 -m pip install package_name。

添加-m參數將會運行包中__main__.py的代碼。更多關于__main__.py文件的內容可參考如何將開源Python包發布到PyPI中。

在三種情況中，__name__都具有相同的值：字符串'__main__'。

技術細節：Python文檔中具體定義了__name__何時取值為'__main__'。

當通過標準輸入，腳本或者交互提示中讀取數據時，模塊的__name__將取值為'__main__'。（來源）

__name__與__doc__，__package__和其他屬性一起存儲在模塊的全局命名空間。更多關于屬性的信息可參考Python數據模型文檔，特別是關于模塊和包的信息，請參閱Python Import文檔。

導入模塊或解釋器

接下來是Python解釋器執行代碼的第二種方式：導入。在開發模塊或腳本時，可以使用import關鍵字導入他人已經構建的模塊。

在導入過程中，Python執行指定模塊中定義的語句（但僅在第一次導入模塊時）。要演示導入execution_methods.py文件的結果，需要啟動Python解釋器，然后導入execution_methods.py文件：

在此代碼輸出中，Python解釋器執行了三次print()函數調用。前兩行由于沒有變量，在輸出方面與在命令行上作為腳本執行時完全相同。但是第三個輸出存在差異。

當Python解釋器導入代碼時，__name__的值與要導入的模塊的名稱相同。您可以通過第三行的輸出了解這一點。__name__的值為'execution_methods'，是Python導入的.py文件。

注意如果您在沒有退出Python時再次導入模塊，將不會有輸出。

注意：更多關于導入在Python中如何工作的內容請參考官方文檔和Python中的絕對和相對導入。

Main函數的最佳實踐

既然您已經了解兩種執行方式上的差異，那么掌握一些最佳實踐方案還是很有用的。它們將適用于編寫作為腳本運行的代碼或者在另一個模塊導入的代碼。

如下是四種實踐方式：

將大部分代碼放入函數或類中

請記住，Python解釋器在導入模塊時會執行模塊中的所有代碼。有時如果想要實現用戶可控的代碼，會導致一些副作用，例如：

在這種情況下，想要實現用戶控制觸發此代碼的執行，而不是讓Python解釋器在導入模塊時執行代碼。

因此，最佳方法是將大部分代碼包含在函數或類中。這是因為當Python解釋器遇到def或class關鍵字時，它只存儲這些定義供以后使用，并且在用戶通知之前不會實際執行。

將如下代碼保存在best_practices.py以證明這個想法：

在此代碼中，首先從time模塊中導入sleep()。

在這個示例中，參數以秒的形式傳入sleep()函數中，解釋器將暫停一段時間再運行。隨后，使用print()函數打印關于代碼描述的語句。

之后，定義一個process_data()函數，執行如下五項操作：

在命令行中執行

當你將此文件作為腳本用命令行執行時會發生什么呢？

Python解釋器將執行函數定義之外的from time import sleep和print()，之后將創建函數process_data()。然后，腳本將退出而不做任何進一步的操作，因為腳本沒有任何執行process_data()的代碼。

如下是這段腳本的執行結果：

我們在這里看到的輸出是第一個print()的結果。注意，從time導入和定義process_data()函數不產生結果。具體來說，調用定義在process_data()內部的print()不會打印結果。

導入模塊或解釋器執行

在會話（或其他模塊）中導入此文件時，Python解釋器將執行相同的步驟。

Python解釋器導入文件后，您可以使用已導入模塊中定義的任何變量，類或函數。為了證明這一點，我們將使用可交互的Python解釋器。啟動解釋器，然后鍵入import best_practices：

導入best_practices.py后唯一的輸出來自process_data()函數外定義的print()。導入模塊或解釋器執行與基于命令行執行類似。

使用__name__控制代碼的執行

如何實現基于命令行而不使用Python解釋器導入文件來執行呢？

您可以使用__name__來決定執行上下文，并且當__name__等于"__main__"時才執行process_data()。在best_practices.py文件中添加如下代碼：

這段代碼添加了一個條件語句來檢驗__name__的值。當值為"__main__"時，條件為True。記住當__name__變量的特殊值為"__main__"時意味著Python解釋器會執行腳本而不是將其導入。

條件語塊內添加了四行代碼（第12，13，14和15行）：

現在，在命令行中運行best_practices.py，并觀察輸出的變化：

首先，輸出顯示了process_data()函數外的print()的調用結果。

之后，data的值被打印。因為當Python解釋器將文件作為腳本執行時，變量__name__具有值"__main__"，因此條件語句被計算為True。

接下來，腳本將調用process_data()并傳入data進行修改。當process_data執行時，將輸出一些狀態信息。最終，將輸出modified_data的值。

現在您可以驗證從解釋器（或其他模塊）導入best_practices.py后發生的事情了。如下示例演示了這種情況：

注意，當前結果與將條件語句添加到文件末尾之前相同。因為此時__name__變量的值為"best_practices"，因此條件語句結果為False，Python將不執行process_data()。

創建名為main()的函數來包含要運行的代碼

現在，您可以編寫作為腳本由從命令行執行并導入且沒有副作用的Python代碼。接下來，您將學習如何編寫代碼并使其他程序員能輕松地理解其含義。

許多語言，如C，C++，Java以及其他的一些語言，都會定義一個叫做main()的函數，當編譯程序時，操作系統會自動調用該函數。此函數通常被稱為入口點(entry point)，因為它是程序進入執行的起始位置。

相比之下，Python沒有一個特殊的函數作為腳本的入口點。實際上在Python中可以將入口點定義成任何名稱。

盡管Python不要求將函數命名為main()，但是最佳的做法是將入口點函數命名為main()。這樣方便其他程序員定位程序的起點。

此外，main()函數應該包含Python解釋器執行文件時要運行的任何代碼。這比將代碼放入條件語塊中更好，因為用戶可以在導入模塊時重復使用main()函數。

修改best_practices.py文件如下所示：

在這個示例中，定義了一個main()函數，它包含了上面的條件語句塊。之后修改條件語塊執行main()。如果您將此代碼作為腳本運行或導入，將獲得與上一節相同的輸出。

在main()中調用其他函數

另一種常見的實現方式是在main()中調用其他函數，而不是直接將代碼寫入main()。這樣做的好處在于可以實現將幾個獨立運行的子任務整合。

例如，某個腳本有如下功能：

如果在單獨的函數中各自實現這些子任務，您（或其他用戶）可以很容易地實現代碼重用。之后您可以在main()函數中創建默認的工作流。

您可以根據自己的情況選擇是否使用此方案。將任務拆分為多個函數會使重用更容易，但會增加他人理解代碼的難度。

修改best_practices.py文件如下所示：

在此示例代碼中，文件的前10行具有與之前相同的內容。第12行的第二個函數創建并返回一些示例數據，第17行的第三個函數模擬將修改后的數據寫入數據庫。

第21行定義了main()函數。在此示例中，對main()做出修改，它將調用數據讀取，數據處理以及數據寫入等功能。

首先，從read_data_from_web()中創建data。將data作為參數傳入process_data()，之后將返回modified_data。最后，將modified_data傳入write_data_to_database()。

腳本的最后兩行是條件語塊用于驗證__name__，并且如果if語句為True，則執行main()。

在命令行中運行如下所示：

根據執行結果，Python解釋器在執行main()函數時，將依次執行read_data_from_web()，process_data()以及write_data_to_database()。當然，您也可以導入best_practices.py文件并重用process_data()作為不同的數據輸入源，如下所示：

在此示例中，導入了best_practices并且將其簡寫為bp。

導入過程會導致Python解釋器執行best_practices.py的全部代碼，因此輸出顯示解釋文件用途的信息。

然后，從文件中存儲數據而不是從Web中讀取數據。之后，可以重用best_practices.py文件中的process_data()和write_data_to_database()函數。在此情況下，可以利用代碼重寫來取代在main()函數中實現全部的代碼邏輯。

實踐總結

以下是Python中main()函數的四個關鍵最佳實踐：

結論

恭喜！您現在已經了解如何創建Python main()函數了。

本文介紹了如下內容：

現在，您可以開始編寫一些非常棒的關于Python main()函數代碼啦！

用python怎么實現RSA簽名

你可以使用rsa這個python庫：

(bob_pub, bob_priv) = rsa.newkeys(512)

message = 'hello Bob!'

crypto = rsa.encrypt(message, bob_pub)

message = rsa.decrypt(crypto, bob_priv)

print message

hello Bob!

文檔地址：

如果解決了您的問題請采納！

如果未解決請繼續追問

如何打包安卓手機Zip升級包？如何簽名？不換Recovery，用官方Recovery

通過分析update.zip包在具體Android系統升級的過程，來理解Android系統中Recovery模式服務的工作原理。

我們先從update.zip包的制作開始，然后是Android系統的啟動模式分析，Recovery工作原理，如何從我們上層開始選擇system update到重啟到Recovery服務，以及在Recovery服務中具體怎樣處理update.zip包升級的，我們的安裝腳本updater-script怎樣被解析并執行的等一系列問題。分析過程中所用的Android源碼是gingerbread0919（tcc88xx開發板標配的），測試開發板是tcc88xx。

一、 update.zip包的目錄結構

|----boot.img

|----system/

|----recovery/

`|----recovery-from-boot.p

`|----etc/

`|----install-recovery.sh

|---META-INF/

`|CERT.RSA

`|CERT.SF

`|MANIFEST.MF

`|----com/

`|----google/

`|----android/

`|----update-binary

`|----updater-script

`|----android/

`|----metadata

二、 update.zip包目錄結構詳解

以上是我們用命令make otapackage 制作的update.zip包的標準目錄結構。

1、boot.img是更新boot分區所需要的文件。這個boot.img主要包括kernel+ramdisk。

2、system/目錄的內容在升級后會放在系統的system分區。主要用來更新系統的一些應用或則應用會用到的一些庫等等。可以將Android源碼編譯out/target/product/tcc8800/system/中的所有文件拷貝到這個目錄來代替。

3、recovery/目錄中的recovery-from-boot.p是boot.img和recovery.img的補丁(patch),主要用來更新recovery分區，其中etc/目錄下的install-recovery.sh是更新腳本。

4、update-binary是一個二進制文件，相當于一個腳本解釋器，能夠識別updater-script中描述的操作。該文件在Android源碼編譯后out/target/product/tcc8800/system bin/updater生成，可將updater重命名為update-binary得到。

該文件在具體的更新包中的名字由源碼中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。

5、updater-script：此文件是一個腳本文件，具體描述了更新過程。我們可以根據具體情況編寫該腳本來適應我們的具體需求。該文件的命名由源碼中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。

6、 metadata文件是描述設備信息及環境變量的元數據。主要包括一些編譯選項，簽名公鑰，時間戳以及設備型號等。

7、我們還可以在包中添加userdata目錄，來更新系統中的用戶數據部分。這部分內容在更新后會存放在系統的/data目錄下。

8、update.zip包的簽名：update.zip更新包在制作完成后需要對其簽名，否則在升級時會出現認證失敗的錯誤提示。而且簽名要使用和目標板一致的加密公鑰。加密公鑰及加密需要的三個文件在Android源碼編譯后生成的具體路徑為：

out/host/linux-x86/framework/signapk.jar

build/target/product/security/testkey.x509.pem

build/target/product/security/testkey.pk8 。

我們用命令make otapackage制作生成的update.zip包是已簽過名的，如果自己做update.zip包時必須手動對其簽名。

具體的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/product/security/testkey.x509.pem gingerbread/build/target/product/security/testkey.pk8 update.zip update_signed.zip

以上命令在update.zip包所在的路徑下執行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用絕對路徑。update.zip 是我們已經打好的包，update_signed.zip包是命令執行完生成的已經簽過名的包。

9、MANIFEST.MF：這個manifest文件定義了與包的組成結構相關的數據。類似Android應用的mainfest.xml文件。

10、CERT.RSA：與簽名文件相關聯的簽名程序塊文件，它存儲了用于簽名JAR文件的公共簽名。

11、CERT.SF：這是JAR文件的簽名文件，其中前綴CERT代表簽名者。

另外，在具體升級時，對update.zip包檢查時大致會分三步：①檢驗SF文件與RSA文件是否匹配。②檢驗MANIFEST.MF與簽名文件中的digest是否一致。③檢驗包中的文件與MANIFEST中所描述的是否一致。

三、 Android升級包update.zip的生成過程分析

1) 對于update.zip包的制作有兩種方式，即手動制作和命令生成。

第一種手動制作：即按照update.zip的目錄結構手動創建我們需要的目錄。然后將對應的文件拷貝到相應的目錄下，比如我們向系統中新加一個應用程序。可以將新增的應用拷貝到我們新建的update/system/app/下（system目錄是事先拷貝編譯源碼后生成的system目錄），打包并簽名后，拷貝到SD卡就可以使用了。這種方式在實際的tcc8800開發板中未測試成功。簽名部分未通過，可能與具體的開發板相關。

第二種制作方式：命令制作。Android源碼系統中為我們提供了制作update.zip刷機包的命令，即make otapackage。該命令在編譯源碼完成后并在源碼根目錄下執行。 具體操作方式：在源碼根目錄下執行

①$ . build/envsetup.sh。

②$ lunch 然后選擇你需要的配置(如17)。

③$ make otapackage。

在編譯完源碼后最好再執行一遍上面的①、②步防止執行③時出現未找到對應規則的錯誤提示。命令執行完成后生成的升級包所在位置在out/target/product/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip將這個包重新命名為update.zip，并拷貝到SD卡中即可使用。

這種方式(即完全升級)在tcc8800開發板中已測試成功。

2) 使用make otapackage命令生成update.zip的過程分析。

在源碼根目錄下執行make otapackage命令生成update.zip包主要分為兩步，第一步是根據Makefile執行編譯生成一個update原包（zip格式）。第二步是運行一個python腳本，并以上一步準備的zip包作為輸入，最終生成我們需要的升級包。下面進一步分析這兩個過程。

第一步：編譯Makefile。對應的Makefile文件所在位置：build/core/Makefile。從該文件的884行（tcc8800,gingerbread0919）開始會生成一個zip包，這個包最后會用來制作OTA package 或者filesystem image。先將這部分的對應的Makefile貼出來如下：

[python] view plaincopyprint?

# -----------------------------------------------------------------

# A zip of the directories that map to the target filesystem.

# This zip can be used to create an OTA package or filesystem image

# as a post-build step.

#

根據上面的Makefile可以分析這個包的生成過程：

首先創建一個root_zip根目錄，并依次在此目錄下創建所需要的如下其他目錄

①創建RECOVERY目錄，并填充該目錄的內容，包括kernel的鏡像和recovery根文件系統的鏡像。此目錄最終用于生成recovery.img。

②創建并填充BOOT目錄。包含kernel和cmdline以及pagesize大小等，該目錄最終用來生成boot.img。

③向SYSTEM目錄填充system image。

④向DATA填充data image。

⑤用于生成OTA package包所需要的額外的內容。主要包括一些bin命令。

⑥創建META目錄并向該目錄下添加一些文本文件，如apkcerts.txt(描述apk文件用到的認證證書)，misc_info.txt(描述Flash內存的塊大小以及boot、recovery、system、userdata等分區的大小信息)。

⑦使用保留連接選項壓縮我們在上面獲得的root_zip目錄。

⑧使用fs_config(build/tools/fs_config)配置上面的zip包內所有的系統文件(system/下各目錄、文件)的權限屬主等信息。fs_config包含了一個頭文件#include“private/android_filesystem_config.h”。在這個頭文件中以硬編碼的方式設定了system目錄下各文件的權限、屬主。執行完配置后會將配置后的信息以文本方式輸出 到META/filesystem_config.txt中。并再一次zip壓縮成我們最終需要的原始包。

第二步：上面的zip包只是一個編譯過程中生成的原始包。這個原始zip包在實際的編譯過程中有兩個作用，一是用來生成OTA update升級包，二是用來生成系統鏡像。在編譯過程中若生成OTA update升級包時會調用（具體位置在Makefile的1037行到1058行）一個名為ota_from_target_files的python腳本，位置在/build/tools/releasetools/ota_from_target_files。這個腳本的作用是以第一步生成的zip原始包作為輸入，最終生成可用的OTA升級zip包。

二 下面我們分析ota_from_target_files這個python腳本是怎樣生成最終zip包的。先講這個腳本的代碼貼出來如下：

[python] view plaincopyprint?

import sys

if sys.hexversion 0x02040000:

print sys.stderr, "Python 2.4 or newer is required."

sys.exit(1)

主函數main是python的入口函數，我們從main函數開始看，大概看一下main函數（腳本最后）里的流程就能知道腳本的執行過程了。

① 在main函數的開頭，首先將用戶設定的option選項存入OPTIONS變量中，它是一個python中的類。緊接著判斷有沒有額外的腳本，如果有就讀入到OPTIONS變量中。

② 解壓縮輸入的zip包，即我們在上文生成的原始zip包。然后判斷是否用到device-specific extensions（設備擴展）如果用到，隨即讀入到OPTIONS變量中。

③ 判斷是否簽名，然后判斷是否有新內容的增量源，有的話就解壓該增量源包放入一個臨時變量中（source_zip）。自此，所有的準備工作已完畢，隨即會調用該 腳本中最主要的函數WriteFullOTAPackage(input_zip,output_zip)

④ WriteFullOTAPackage函數的處理過程是先獲得腳本的生成器。默認格式是edify。然后獲得metadata元數據，此數據來至于Android的一些環境變量。然后獲得設備配置參數比如api函數的版本。然后判斷是否忽略時間戳。

⑤ WriteFullOTAPackage函數做完準備工作后就開始生成升級用的腳本文件(updater-script)了。生成腳本文件后將上一步獲得的metadata元數據寫入到輸出包out_zip。

⑥至此一個完整的update.zip升級包就生成了。生成位置在：out/target/product/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。將升級包拷貝到SD卡中就可以用來升級了。

四、 Android OTA增量包update.zip的生成

在上面的過程中生成的update.zip升級包是全部系統的升級包。大小有80M多。這對手機用戶來說，用來升級的流量是很大的。而且在實際升級中，我們只希望能夠升級我們改變的那部分內容。這就需要使用增量包來升級。生成增量包的過程也需要上文中提到的ota_from_target_files.py的參與。

下面是制作update.zip增量包的過程。

① 在源碼根目錄下依次執行下列命令

$ . build/envsetup.sh

$ lunch 選擇17

$ make

$ make otapackage

執行上面的命令后會在out/target/product/tcc8800/下生成我們第一個系統升級包。我們先將其命名為A.zip

② 在源碼中修改我們需要改變的部分，比如修改內核配置，增加新的驅動等等。修改后再一次執行上面的命令。就會生成第二個我們修改后生成的update.zip升級包。將 其命名為B.zip。

③ 在上文中我們看了ota_from_target_files.py腳本的使用幫助，其中選項-i就是用來生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作為輸入，以update.zip包作 為輸出。生成的update.zip就是我們最后需要的增量包。

具體使用方式是：將上述兩個包拷貝到源碼根目錄下，然后執行下面的命令。

$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。

在執行上述命令時會出現未找到recovery_api_version的錯誤。原因是在執行上面的腳本時如果使用選項i則會調用WriteIncrementalOTAPackage會從A包和B包中的META目錄下搜索misc_info.txt來讀取recovery_api_version的值。但是在執行make otapackage命令時生成的update.zip包中沒有這個目錄更沒有這個文檔。

此時我們就需要使用執行make otapackage生成的原始的zip包。這個包的位置在out/target/product/tcc8800/obj/PACKAGING/target_files_intermediates/目錄下，它是在用命令make otapackage之后的中間生產物，是最原始的升級包。我們將兩次編譯的生成的包分別重命名為A.zip和B.zip，并拷貝到SD卡根目錄下重復執行上面的命令：

$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。

在上述命令即將執行完畢時，在device/telechips/common/releasetools.py會調用IncrementalOTA_InstallEnd,在這個函數中讀取包中的RADIO/bootloader.img。

而包中是沒有這個目錄和bootloader.img的。所以執行失敗，未能生成對應的update.zip。可能與我們未修改bootloader（升級firmware）有關。此問題在下一篇博客已經解決。

制作增量包失敗的原因，以及解決方案。

Android系統Recovery工作原理之使用update.zip升級過程分析（二）---update.zip差分包問題的解決

在上一篇末尾提到的生成差分包時出現的問題，現已解決，由于最近比較忙，相隔的時間也比較長，所以單列一個篇幅提示大家。這個問題居然是源碼中的問題，可能你已經制作成功了，不過我的這個問題確實是源碼中的一個問題，不知道是不是一個bug，下文會具體分析！

一、生成OTA增量包失敗的解決方案

在上一篇中末尾使用ota_from_target_files腳本制作update.zip增量包時失敗，我們先將出現的錯誤貼出來。

在執行這個腳本的最后讀取input_zip中RADIO/bootloader.img時出現錯誤，顯示DeviceSpecifiParams這個對象中沒有input_zip屬性。

我們先從腳本中出現錯誤的調用函數中開始查找。出現錯誤的調用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位于WriteIncrementalOTAPackage()中的末尾。進一步跟蹤源碼發現，這是一個回調函數，他的具體執行方法位于源碼中/device/telechips/common/releasetools.py腳本中的IncrementalOTA_InstallEnd()函數。下面就分析這個函數的作用。

releasetools.py腳本中的兩個函數FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是從輸入包中讀取RADIO/下的bootloader.img文件寫到輸出包中，同時生成安裝bootloader.img時執行腳本的那部分命令。只不過一個是直接將輸入包中的bootloader.img鏡像寫到輸出包中，一個是先比較target_zip和source_zip中的bootloader.img是否不同（使用選項-i生成差分包時），然后將新的鏡像寫入輸出包中。下面先將這個函數(位于/device/telechips/common/releasetools.py)的具體實現貼出來：

我們的實際情況是，在用命令make otapackage時生成的包中是沒有這個RADIO目錄下的bootloader.img鏡像文件（因為這部分更新已被屏蔽掉了）。但是這個函數中對于從包中未讀取到bootloader.img文件的情況是有錯誤處理的，即返回。所以我們要從 出現的實際錯誤中尋找問題的原由。

真正出現錯誤的地方是：

target_bootloader=info.input_zip.read(“RADIO/bootloader.img”)。

出現錯誤的原因是：AttributeError：‘DeviceSpecificParams’object has no attribute ‘input_zip’，提示我們DeviceSpecificParams對象沒有input_zip這個屬性。

二、updater-script腳本執行流程分析：

先看一下在測試過程中用命令make otapackage生成的升級腳本如下：

[python] view plaincopyprint?

assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));

assert(getprop("ro.product.device") == "tcc8800" ||

下面分析下這個腳本的執行過程：

①比較時間戳：如果升級包較舊則終止腳本的執行。

②匹配設備信息：如果和當前的設備信息不一致，則停止腳本的執行。

③顯示進度條：如果以上兩步匹配則開始顯示升級進度條。

④格式化system分區并掛載。

⑤提取包中的recovery以及system目錄下的內容到系統的/system下。

⑥為/system/bin/下的命令文件建立符號連接。

⑦設置/system/下目錄以及文件的屬性。

⑧將包中的boot.img提取到/tmp/boot.img。

⑨將/tmp/boot.img鏡像文件寫入到boot分區。

⑩完成后卸載/system。

三、總結

以上的九篇著重分析了Android系統中Recovery模式中的一種，即我們做好的update.zip包在系統更新時所走過的流程。其核心部分就是Recovery服務的工作原理。其他兩種FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE與OTA INSTALL是相通的。重點是要理解Recovery服務的工作原理。另外詳細分析其升級過程，對于我們在實際升級時，可以根據我們的需要做出相應的修改。

【Python】基礎總結

input("提示性信息")

如：

input("請輸入數字")

因為 Python 沒有特別人為規定數據類型，數據類型是由計算機進行判定，所以我們 input() 輸入的數據均默認作為字符串處理，而如果要輸入一些數字，著需要 eval() 評估函數對字符串進行評估，化為語句（數字）。

print(...)

默認空一行，如果想不空行，則

print(...., end = "")

特性：

進制：

特性：

浮點數間運算存在不確定尾數，不是 bug

如：0.1+0.3 → 0.4

0.1+0.2 → 0.30000000000000004

這是由于在計算機中一切數據都是化為二進制進行存儲的，而有的浮點數并不能完全化為相等的二進制數，只能無限趨近于二進制數。

如：0.1 →

解決方法：

四舍五入：

例如：z = 1.23e-4 + 5.6e+89j

z.real 獲得實部，z.imag 獲得虛部

三種類型存在一種逐漸“擴展”或“變寬”的關系：

整數 → 浮點數 → 復數

特點：

字符串有 2 類共 4 種表示方法：

擴展：

使用[]獲取字符串中一個或多個字符

使用[M:N:K]根據步長對字符串切片

{參數序號:格式控制標記}

右對齊

^ 居中對齊 | 槽設定的輸出寬度 | 數字的千位分隔符 | 浮點數小數精度 或 字符串最大輸出長度 | 整數類型

b , c , d , o , x , X

浮點數類型

e , E , f , % |

填充、對齊、寬度這三個一組，例如：

"{0:=^20}".format("PYTHON")

→ '=======PYTHON======='

"{0:*20}".format("BIT")

→ '*****************BIT'

"{:10}".format("BIT")

'BIT '

剩下的三個一組，例如：

"{0:,.2f}".format(12345.6789)

→ '12,345.68'

"{0:b},{0:c},{0:d},{0:o},{0:x},{0:X}x".format(425)

→ '110101001,Σ,425,651,1a9,1A9'

"{0:e},{0:E},{0:f},{0:%}".format(3.14)

'3.140000e+00,3.140000E+00,3.140000,314.000000%'

↓CloseCode↓

使用 raise 語句拋出一個指定的異常。

raise [Exception [, args [, traceback]]]

緊湊形式：適用于簡單表達式的二分支結構

表達式1 if 條件 else 表達式2

例如：

↓CloseCode↓

↓CloseCode↓

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

由條件控制的循環運行方式

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

↓CloseCode↓

可選參數例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

可變參數例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

在函數定義中，經常會碰到 *args(arguments) 和作為參數 **kwargs(keyword arguments)。

（事實上在函數中，和才是必要的，args 和 kwargs 可以用其他名稱代替）

*args 是指不定數量的非鍵值對參數。

**kwargs 是指不定數量的鍵值對參數。

*args 作為作為元組匹配沒有指定參數名的參數。而 **kwargs 作為字典，匹配指定了參數名的參數。

*args 必須位于 **kwargs 之前。

args( 通常緊跟一個標識符，你會看到a或者args都是標識符)是python用于接收或者傳遞任意基于位置的參數的語法。當你接收到一個用這種語法描敘參數時（比如你在函數def語句中對函數簽名使用了星號語法），python會將此標識符綁定到一個元祖，該元祖包含了所有基于位置的隱士的接收到的參數。當你用這種語法傳遞參數時，標識符可以被綁定到任何可迭代對象（事實上，它也可以是人和表達式，并不必須是一個標識符），只要這個表達式的結果是一個可迭代的對象就行。

**kwds(標識符可以是任意的，通常k或者kwds表示)是python用于接收或者傳遞任意基于位置的參數的語法。（python有時候會將命名參數稱為關鍵字參數，他們其實并不是關鍵字--只是用他們來給關鍵字命名，比如pass,for或者yield，還有很多，不幸的是，這種讓人疑惑的術語目前仍是這門語言極其文化根深蒂固的一個組成部分。）當你接收到用這種語法描敘的一個參數時（比如你在函數的def語句中對函數簽名使用了雙星號語法）python會將標識符綁定到一個字典，該字典包含了所有接收到的隱士的命名參數。當你用這種語法傳遞參數時，標識符只能被綁定到字典（我ID號I它也可以是表達式，不一定是一個標識符，只要這個表達式的結果是一個字典即可）。

當你在定義或調用一個函數的時候，必須確保a和k在其他所有參數之后。如果這兩者同時出現，要將k放在a之后。

lambda函數返回函數名作為結果

↓CloseCode↓

例如：

↓CloseCode↓

運行結果：

↓CloseCode↓

謹慎使用lambda函數

請教，直接調Python接口做ECC簽名

從原理上可以這樣處理：用私鑰對一個數據進行簽名，然后用公鑰對這個簽名進行驗證。如果驗證通過即可證明這對密鑰對是匹配的。

文章題目：python入口函數簽名 python 函數簽名
網站URL：http://m.newbst.com/article48/hjjhhp.html

成都網站建設公司_創新互聯，為您提供品牌網站設計、靜態網站、網站建設、微信小程序、外貿網站建設、外貿建站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯