整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
十七章：輸入和輸出文件
17.1 體數據的文件格式
體數據由三維空間中的規則網格組成。每個柵格點的體積元素“體元”表示柵格點上的值。體元類似于像素，它表示2D圖像數據。
通常，有兩種類型的格式用于記錄文件中的體數據：常規柵格和周期柵格。圖17.1示意性地說明了這兩種格式的一般概念。
常規柵格是一個均勻的網格，位于分子邊界框和晶體單位晶胞內。對于晶體結構，由于數據的周期性，常規柵格中的部分數據是冗余的。例如，（1，1，1）處的數值等于原點處的數值，即（0，0，0）。省略了這些冗余點的網格稱為周期柵格。
VESTA自動將網格類型與文件擴展名區分開來。對于周期柵格格式的體數據，VESTA通過添加冗余數據點在內部生成常規柵格。在使用自制腳本或程序準備體數據時，用戶必須自己注意文件的柵格類型。
：不可約數據點：冗余點（周期性副本）
圖17.1：平面上體數據的兩種網格。（A） 常規柵格和（B）周期柵格
17.2 用戶設置目錄
VESTA在用戶設置目錄中加載并保存兩個文件，VESTA.ini和style/default.ini，分別存儲程序和圖形的用戶設置。在同一目錄中還創建了一個用于存儲臨時文件的目錄tmp。設置目錄的位置取決于操作系統，并按以下優先級順序確定。
17.2.1 Windows
· 定義環境變量VESTA_PREF時，將使用指定的目錄。
· 當%HOMEPATH%\AppData\Roaming\中存在名為VESTA的目錄時，將使用該目錄。
（%HOMEPATH%表示用戶主目錄的完整路徑，%HOMEPATH%\AppData\是一個隱藏目錄。）
· 當用戶有權在VESTA的程序目錄中寫入時，將使用該目錄，以免使主目錄混亂。
· 第一次執行VESTA時創建目錄%HOMEPATH%\AppData\Roaming\VESTA\，并使用該目錄。
17.2.2 macOS
· 定義環境變量VESTA_PREF時，使用指定的目錄。要為GUI應用程序定義環境變量，必須在名為environment.plist的文本文件中對其進行描述。該文件位于隱藏目錄~/.MacOSX下。為了更容易定義VESTA_PREF，一個名為set_VESTA_PREF.app的應用程序，包含在RIETAN-VENUS軟件包中；有關詳細信息，請參閱set_VESTA_PREF.app中的Readme_mac.pdf文件。
· 第一次執行VESTA時創建目錄~/Library/Application Support/VESTA/，并使用該目錄。請注意，~/Library是主目錄（~/）下的一個隱藏目錄。
17.2.3 Linux
· 定義環境變量VESTA_PREF時，將使用指定的目錄。
· 第一次執行VESTA時創建隱藏目錄~/.VESTA/，并使用該目錄。
17.3 VESTA使用的文件
表17.1：VESTA使用的文件
17.4 輸入文件
17.4.1 結構數據
1、VESTA格式（*.vesta）
包含整個結構數據和圖形設置的文本文件。VESTA保存的*.vesta文件，可能包含體數據文件的相對路徑，以及當*.vesta文件再次打開時，自動讀取的晶體數據文件。如果*.vesta中包含IMPORT_STRUCTURE、IMPORT_ORFFE、IMPORT _DENSITY和IMPORT_TEXTURE中的任何一個關鍵字，且后面是指定數據文件相對路徑的行，當*.vesta文件打開時，VESTA也會輸入這些數據文件。
使用RIETAN-FP進行Rietveld分析后，如果*.vesta和*.ins在同一個文件夾中，*.vesta中的晶格和結構參數會自動更新。
2、VICS格式（*.vcs）
http://fujioizumi.verse.jp/visualization/VENUS.html
VICS是VESTA結構圖部分的前身，現已過時。盡管如此，VESTA仍支持此格式以保持兼容性。
3、American Mineralogist Crystal Structure Database美國礦物學晶體結構數據庫（*.amc）
http://rruff.geo.arizona.edu/AMS/amcsd.php
在部分AMCSD文本文件中，空間群名稱附加了額外的字符，并使用了非標準的空間群符號。某些非標準空間群設置可能無法正確讀取。在這種情況下，請適當修改空間群符號，然后根據需要在Edit Data對話框的Unit cell選項卡中更改設置編號。有時，如果采用《國際結晶學表》A卷中未描述的非標準設置，則必須自行轉換分數坐標。
4、asse（*.asse）
http://www.nims.go.jp/cmsc/staff/arai/asse/
5、Chem3D（*.cc1）
http://openbabel.org/docs/2.3.1/FileFormats/3D_viewer_Formats.html
6、Crystallographic Information File晶體學信息文件（CIF; *.cif）
http://www.iucr.org/resources/cif/
CIF有多種晶體數據格式。可以從上述網站獲得有關CIF的詳細信息。例如，CIF文件可能包含笛卡爾坐標，但VESTA無法輸入它們。請注意，VESTA不支持CIF格式中允許的所有格式。例如，CIF中包含的笛卡爾坐標不能輸入到VESTA；CIF中只應給出分數坐標。有關可讀格式，請參閱VENUS/examples/VICS/CIF中的示例*.cif文件。
在*.cif包含多相數據的情況下，所有數據都輸入到同一個選項卡中，并且相互重疊。要在這種情況下僅可視化一個相，請選擇菜單欄中的Edit | Edit Data | Phase...。在列表中選擇一個不必要的相，然后按下Delete按鈕。
CIF范式提供了多種輸入空間群對稱性的方法。VESTA按以下順序搜索條目：
如果*.cif文件中給出了上述條目之一，VESTA識別空間群對稱性。例如，SHELX-97通過WinGX創建的CIF既不包含空間群編號，也不包含空間群符號，但具有對稱操作列表。
如果以上條目均未正確給出，則空間群被視為P1。在這種情況下，請在打開此類文件后，在Edit Data對話框的Unit cell選項卡中設置空間群，或按以下方式修改CIF中與空間群相關的行：
7、CrystalMaker text file（*.cmt, *.cmtx）
http://www.crystalmaker.comCrystalMaker
是一個用于構建、顯示和操作各種晶體和分子結構的商業程序。
8、Crystal Structure Search and Retrieval晶體結構搜索與檢索（CSSR; *.cssr）
http://www.maciejharanczyk.info/Zeopp/input.html
在CSSR格式的文件中，可以在“OPT=”后給出設置編號。遺憾的是，沒有關于以這種格式設置編號的信息。如有必要，請在Edit Data對話框的Unit cell選項卡中進行更改。
9、Cambridge Structural Database劍橋結構數據庫（CSD/FDAT; *.csd, *.fdt）
http://www.ccdc.cam.ac.uk/Solutions/CSDSystem/Pages/CSD.aspx
10、DL_POLY格式（CONFIG, REVCON, *.config）
https://www.scd.stfc.ac.uk/Pages/DL_POLY.aspx
11、FEFF輸入文件（feff.inp）
http://www.feffproject.org/
FEFF是原子團簇X射線吸收精細結構（XAFS）和X射線吸收近邊結構（XANES）譜從頭算多重散射的自動程序。FEFF的輸入文件名必須為feff.inp或FEFF.inp。
12、FHI-aims輸入文件（*.in）
https://aimsclub.fhi-berlin.mpg.de/
FHI-aims為計算材料科學提供準確的全電子、全電勢電子結構代碼包。
13、Elk FP-LAPW代碼的輸出文件（GEOMETRY.OUT）
Elk是一種全電子全電勢線性增強平面波（FP-LAPW）代碼，用于測定晶體固體的性質。
14、GSAS格式（*.EXP）
http://www.ncnr.nist.gov/xtal/software/gsas.html
15、Inorganic Crystal Structure Database無機晶體結構數據庫（ICSD; *.ics）
http://www2.fiz-karlsruhe.de/icsd_home.html
ICSD的兩個檢索程序，用于MS-DOS的RETRIEVE和用于Windows的FindIt，輸出格式完全不同的文本文件。VESTA能夠讀取兩種類型的晶體數據文件。
在這些*.ics文件中，有時會將額外字符附加到空間群名稱，例如“P 42/n m c S”，應該是“P 42/n m c”（P42/nmc）。此外，ICSD文本文件中有時會給出完整的Hermann-Mauguin空間群符號。在這種情況下，文本區域和消息框中都會顯示錯誤消息。請仔細閱讀以進行下一個操作。遇到此類錯誤時，強烈建議輸出CIF而不是*.ics。
16、ICSD-CRYSTIN:（*.cry）
17、MDL Molfile（*.mol）
http://en.wikipedia.org/wiki/Chemical_table_file
18、Crystallographic Database for Minerals礦物晶體學數據庫（MINCRYST; *.min）
http://database.iem.ac.ru/mincryst/
在部分MINCRYST文本文件中，空間群名稱附加了額外的字符，并使用了非標準的空間群符號。在這種情況下，文本區域會顯示錯誤消息。應適當修改空間群名稱。根據需要在Edit Data對話框的Unit cell選項卡中更改設置編號。
19、MOLDA（*.mld）
http://www3.u-toyama.ac.jp/kihara/cc/mld/readme.html
MOLDA的網站已經關閉，因為其作者Hiroshi Yoshida于2005年去世。這里簡要解釋*.mld的MODRAST/MOLDA格式。此格式由以下行組成：
（a） 第1行：關于化合物的注釋，例如其名稱
（b） 第2行：化合物中的原子數na
（c） 第3~（3+na）行：笛卡爾坐標（x、y和z）和原子序號
（d） 第（4+na）行：化合物中的鍵數nb
（e） 第（5+na）~（5+na+nb）行：原子序號對
例如，如果是乙烯，其中na=6，nb=5，則需要以下行：
20、Protein Data Bank 蛋白質數據庫（PDB; *.pdb）
http://www.wwpdb.org/PDB
有多種晶體數據格式。可以在http://www.wwpdb.org/docs.html網頁中獲取PDB的詳細信息。請注意，VESTA不支持這兩種格式中允許的所有格式。有關可讀格式，請參閱VENUS/examples/VICS/PDB中的*.pdb文件。
21、RIETAN-FP/2000的輸入文件（*.ins）
http://fujioizumi.verse.jp/download/download_Eng.html
VESTA無法輸入早于RIETAN-2000的RIETAN版本（例如，RIETAN-94）的*.ins文件。如果*.ins中包含多相數據，只輸入第一相的晶體數據。
在*.ins中，根據RIETAN-FP中的規范，國際表格的卷名不應為“I”，而應為“A”。例如，“A-230-2”是空間群Fd-3m的第二個設置的輸入。輸入“I-230-2”會導致錯誤。晶格參數必須按以下方式在一行內給出：
22、RIETAN-FP的輸出文件（*.lst）
http://fujioizumi.verse.jp/download/download_Eng.html
謹防RIETAN-2000輸出的*.lst文件的輸入。
23、SHELXL的輸入文件（*.ins）
24、STRUCTURE TIDY的輸出文件（*.sto）
25、USPEX輸出的結構數據文件（gatheredPOSCARS, BESTgatheredPOSCARS）
http://han.ess.sunysb.edu/~USPEX/
26、WIEN2k（*.struct）
http://www.wien2k.at/
27、XMol XYZ（*.xyz）
http://en.wikipedia.org/wiki/XYZ_file_formathttp://openbabel.org/docs/2.3.1/FileFormats/XYZ_cartesian_coordinates_format.html
明尼蘇達超級計算機中心開發的XMol是一種用于創建和查看分子圖像的實用程序。
28、SCAT的F01，和contrd的C04D
http://www.dvxa.org/
如果結構模型與體數據重疊，VESTA除了需要讀取f01外，還需要讀取contrd的輸入文件c04d。為此，需要使用c04d中的邊界框（體數據輸出到文本文件的區域）尺寸。有關contrd的詳細信息，請參閱VENUS軟件包中的Readme_contrd.txt。當然，c04d和f01應該放在同一個文件夾中。如果VESTA未輸入c04d，原子坐標將在笛卡爾坐標系中處理，就像*.xyz文件的情況一樣。在這種情況下，體數據*.scat和*.sca不能與結構模型重疊。
f01中記錄的所有原子必須包含在上述邊界框內。否則，通過假設周期性，原子坐標將在邊界框內標準化，這將導致圖形區域中出現不正確的結構。
在執行一系列電子狀態計算時，使用Hidemaru Editor的DV-Xα方法輔助環境非常方便。
岡山理工大學Genta Sakane的網站：
http://www.chem.ous.ac.jp/~gsakane/
對于想要將contrd計算的物理量可視化的研究者來說非常有用。詳細的日語文檔《DV-Xα方法輔助環境簡介》，適合初學者使用DV-Xα法和VESTA。
29、MXDORTO/MXDTRICL（FILE06.DAT, FILE07.DAT）
http://kats-labo.jimdo.com/mxdorto-mxdtricl/
MXDORTO和MXDTRICL是分子動力學模擬的Fortran程序。
30、XTL格式（*.xtl）
Cerius2（Accelrys，Inc.）中使用的文本文件。GULP和GSAS能夠以這種格式輸出晶體數據。
17.4.2 體數據
31、二進制格式的MEM密度（*.pri, *.prim）
http://fujioizumi.verse.jp/visualization/VENUS.html
http://jp-minerals.org/dysnomia/en/
PRIMA或Dysnomia輸出的3D電子和核密度二進制文件以及ALBA輸出的Patterson函數二進制文件。這些文件中記錄的電子密度（嚴格來說，電子數密度）單位是?-3，核密度單位為fm ?-3。
32、文本格式的MEM密度（*.den）
PRIMA、Dysnomia、MEED、MEND和ENIGMA輸出的3D電子和核密度文本文件。這些文件中記錄的電子密度單位是?-3，核密度單位為fm ?-3。
33、Energy Band能帶（*.eb）
與*.rho格式幾乎相同的文本文件。文件*.eb用于根據能帶結構計算程序（如WIEN2k）獲得的結果可視化費米面。為了方便起見，在*.eb中的所有能量本征值上加上一個常數，使它們大于或等于零。因此，在設置等值面數值時必須考慮到這種修改。
NIMS的Masao Arai在他的網站上提供了有關*.eb的詳細信息：
http://www.nims.go.jp/cmsc/staff/arai/
34、通用體數據（文本文件格式）（*.?ed）
具有通用體數據格式的文件存儲根據Tsirelson提出的程序從電子密度轉換而來的以下物理量之一（見14.15節）：
?2ρ(r)：電子密度的拉普拉斯算符（*.led）。
g(r)：電子動能密度（*.ked）。
ν(r)：電子勢能密度（*.ped）。
he(r)：電子能量密度（*.ted）。
格式（擴展名為?ed的所有文件通用）：
標題：標題最多80個字符。
a、 b、c、α、β、γ：晶格參數，兩個參數之間至少有一個空格（自由格式）。
N1+1、N2+1、N3+1：分別沿a、b和c軸的體元數量，兩個整數之間至少有一個空格（自由格式）。
接下來為三維數組元素D：
每行中有任意數量的數據，兩個真實數據之間至少有一個空格（自由格式）。請注意，N1+1、N2+1和N3+1的體元分別位于x=1、y=1和z=1。一個示例*.ted文件的初始幾行如下所示：
VESTA輸入的*.grd文件，應在傅里葉計算設置中選擇選項““C – Select section (X, Y, or Z) selection”，然后輸入“X”以顯示提示“Enter section desired (X,Y,Z - choose Z for DSN6 maps”。
文件格式基本上與通用體數據格式相同，但三維數據數組D的輸出范圍如下：
VESTA同樣允許以這種格式導出體數據。
36、通用體數據格式（二進制格式）（*.ggrid）
37、周期體數據（二進制格式）（*.pgrid）
38、壓縮體數據格式（*.m3d）
39、SCAT體數據格式（*.sca, *.scat）
http://www.dvxa.org/
利用contrd從F09和F39文件計算的電子密度、靜電勢和波函數，通過SCAT輸出。使用名為contrd.bat的批處理文件創建的文本文件（CHG3D.SCA、POT3D.SCA、WXXX-3D.SCA、WXXXU-3D.SCA和WXXXU-3D.SCA），可以直接由VESTA輸入，其中XXX表示分配給波函數的整數。如要了解*.SCA文件的詳細信息，請參閱軟件包中的Readme_contrd.txt文件。記錄于*.SCA或*.SCAT的三維數值數據在繪制時不用進行任何轉換。
電子密度、靜電勢和波函數的單位分別是bohr-3, Ry (rydberg)和bohr-3/2，其中bohr是長度的原子單位，即1 bohr=a0=5.29177211×10-11 m=0.529177211 ?（a0：玻爾半徑），1 Ry=Eh/2=2.179 871 9×10-18 J（Eh：hartree）。
DV-Xα方法的輔助環境及其用日語編寫的詳細文件見17.4.1節第23條。
40、WIEN2k（*.rho）
http://www.wien2k.at/ (WIEN2k)
http://www.nims.go.jp/cmsc/staff/arai/wien/venus.html (wien2venus.py)
NIMS的Masao Arai用Python編寫的腳本wien2venus.py，可以將用WIEN2k計算的電子密度導出到文本文件*.rho中，之后使用VESTA將其可視化。這個文件中存儲的電子密度單位是bohr-3。
41、WinGX 3D傅里葉映射（*.fou）
http://www.chem.gla.ac.uk/~louis/software/wingx/
WinGX輸出的3D Fourier Maps文本文件。如要創建可以用VESTA輸入的*.fou文件，從菜單欄中的Maps | FOURIER MAP | Slant plane，打開WinGX的“FOURIER MAP Control Panel”。選擇“33D Fouier (Beevers-Lipson)”和“Write MarchingCubes File”選項，并在Z軸設置“Projection”。對于所有X、Y和Z軸，“Summation limits”的最小值和最大值應設置為0和1。考慮到以下問題，應仔細設置每個軸的分辨率。
在這種格式中，沿每個軸的數據點不是均勻分布的，而是以給定分辨率的間隔放置的。當軸的長度為L且分辨率設置為d時，數據點的數量NPIX設置為L/d+1的整數部分。僅當L/d接近整數時，輸出文件具有近似正確周期的通用網格格式。建議特殊位置正好位于數據網格上。例如，如果鏡像平面位于x=1/4和x=3/4，則L/d應為4的倍數。
42、X-PLOR/CNX（*.xplor）
http://en.wikipedia.org/wiki/X-PLOR (CNX)
http://superflip.fzu.cz/ (Superflip)
Superflip是用電荷翻轉法從頭算求解晶體結構的計算機程序。Superflip使用X-PLOR格式在文件*.x-plor中輸出單位晶胞中的電子密度，可由VESTA直接顯示。
17.4.3 結構和體數據
43、CASTEP（*.cell, *.charg_frm）
http://www.castep.org/
文件*.cell包含晶體結構數據，而文件*.charg_frm以?-3為單位存儲電子密度。當*.cell在VESTA中打開時，僅顯示結構模型。另一方面，打開*.charg_frm時，顯示結構模型和電子密度分布。因為單位晶胞尺寸未記錄在*.charg_frm文件中，必須同時打開*.cell。
44、GAMESS輸入文件和MacMolPlt輸出的體數據文件
http://www.msg.ameslab.gov/GAMESS/GAMESS.html (GAMESS)
https://brettbode.github.io/wxmacmolplt/ (MacMolPlt)
GAMESS輸入文件*.inp，可以很容易地使用MacMolPlt從GAMESS日志文件*.log中獲得。首先，使用文本編輯器檢查該文件中收斂后的最終笛卡爾原子坐標單位。然后，運行MacMolPlt打開*.log。在Windows菜單中，通過*.log名稱選擇“Coordinates”，并檢查笛卡爾坐標的單位是?還是bohr (au)。與VESTA一樣，單位應為?。如果單位為bohr，請選擇菜單欄中的Molecule | Convert to Angstroms。然后，在Windows菜單中，通過*.log名稱選擇“Input Builder”，并單擊Write File按鈕，創建*.inp存儲原子符號和笛卡爾坐標。接下來是體數據文件*.mmp，必須輸出其中記錄的3D網格原點。在Windows菜單中，通過*.log名稱選擇“Surfaces”。從“3D Orbital”、“3D Total Electron Density”和“3D Molecular Electrostatic Potential”中指定項目。在隨后出現的對話框中，適當更改網格點的數量和網格大小，選擇一個軌道（在“3D Orbital”的情況下），然后單擊Update按鈕。等值面和球棍模型將出現在*.log窗口中。單擊Parameters...按鈕，可顯示網格點的數量、原點和網格增量。然后，單擊Export...按鈕。指定與*.inp同名的*.mmp文件的名稱和位置。請注意*.inp和*.mmp必須在同一文件夾中。
45、Gaussian Cube格式（*.cube, *.cub）
http://www.gaussian.com/
存儲使用Gaussian計算的電子密度、自旋密度、靜電勢、波函數等的文本文件，關鍵字為“Cube”。Cube文件也可以由Firefly（以前稱為PC GAMESS）創建。
46、VASP（*.vasp, CHG, CHGCAR, PARCHG, LOCPOT, ELFCAR, POSCAR, CONTCAR）
http://www.vasp.at/
http://www.materialsdesign.com/medea（商業軟件MedeA，包含VASP為其組件）
以上文件均為存儲VASP輸出的晶體結構和體數據的文本文件。
CHG存儲晶格矢量、原子坐標和總電荷密度乘以單位晶胞體積V。PAW單個中心占據率添加到CHGCAR中。雖然CHG和CHGCAR提供了相同的價電子信息，但由于數值數據的精度較低，CHG的文件大小小于CHGCAR。PARCHG具有與CHG相同的格式，存儲特定k點和/或帶的部分電荷密度。當讀取這些文件以可視化等值面和切面時，數據值除以V（單位為bohr3）。因此，VESTA輸入的電荷密度單位為bohr-3。LOCPOT包含晶格矢量、原子坐標和庫侖勢（單位：eV），即無交換相關分量的總電勢（除非LEXCHG=-1行在main中被注釋掉）。ELFCAR的格式與CHG相同，它存儲無量綱電子局域化函數（ELF）。POSCAR和CONTCAR包括晶格矢量、原子坐標，以及用于分子動力學計算的可選初始速度和預測-校正坐標。POSCAR和CONTCAR分別對應于計算任務結束時VASP輸出的初始結構和最終結構；CONTCAR可用于計算任務續算。由于這些文件中沒有元素符號或原子序數，它們必須與另一個文件OUTCAR一起顯示結構模型。OUTCAR可以重命名為*.out，與*.vasp具有相同的名稱。只有OUTCAR頂部“POTCAR:”后面的行才能讀取元素符號。
讀取文件進行表面著色時，除非文件名為CHGCAR或PARCHG，否則不會縮放數據值。
47、XCrySDen XSF格式（*.xsf）
http://www.xcrysden.org/ (XCrySDen)
http://www.abinit.org/ (ABINIT)
http://www.abinit.org/documentation/helpfiles/for-v6.4/users/cut3d_help.html (Cut3D)
http://www.quantum-espresso.org/ (Quantum ESPRESSO)
用于材料性質從頭算的ABINIT軟件包具有輸出存儲電子密度、靜電勢和波函數的二進制文件的功能。它們可以使用名為Cut3D的轉換器，轉換具有XCrySDen的XSF格式的文本文件*.xsf。電子密度的單位是bohr-3。Cut3D支持數據類型13（XCrySDen/VENUS波函數實數數據），因此可以直接在*.xsf中輸出波函數。用于材料量子力學模擬的Quantum ESPRESSO還具有輸出XSF格式文件的功能。有關XSF格式的詳細信息，請訪問http://www.xcrysden.org/doc/XSF.html
一般來說，*.xsf由一些以關鍵字開頭的部分組成。VESTA從BEGIN_BLOCK_DATAGRID部分讀取體數據。為了使等值面與結構模型重疊成為可能，*.xsf還應包含（1）PRIMEVEC和PRIMCOORD部分或（2）CONVVEC和CONVCOORD部分。此外，PRIMVEC或CONVVEC部分中的晶格矢量必須與BEGIN_DATAGRID部分中的生成矢量一致。在XSF格式中，基本晶格矢量（PRIMVEC）和笛卡爾坐標的單位是?。
17.5 輸出文件
17.5.1 數據文件
結構數據
1、VESTA原始格式（*.vesta）
當前顯示的數據的全部信息保存在VESTA格式的文本文件*.vesta中。VESTA格式的文件包含所有結構數據和圖形設置，而體數據不直接記錄在*.vesta中，而從外部文件導入。存儲體數據的文件的目錄和名稱記錄在*.vesta中，作為從*.vesta的目錄到體數據文件的相對路徑。它可以將當前數據的全部信息保存在一個小文件中，而無需復制龐大的體數據。
可以選擇以相同的方式從外部文件導入結構數據。防止結構數據直接記錄在*.vesta中，使用帶有Link選項的Import Data對話框導入結構數據（見6.3.6節）。文件名*。ORFFE輸出的*.ffe文件的名稱也記錄在*.vesta中，因此在重新打開*.vesta文件后，*.ffe中記錄的幾何參數將自動列在Geometrical Parameters對話框中（見14.2節）。使用RIETAN-FP進行Rietveld分析后，如果*.vesta文件和標準輸入文件*.ins在同意文件夾中，*.vesta中的晶格和結構參數會自動更新。
2、Chem3D（*.cc1）
http://openbabel.org/docs/2.3.1/FileFormats/3D_viewer_Formats.html
3、Crystallographic Information File晶體學信息文件（CIF; *.cif）
http://www.iucr.org/resources/cif/
4、DL_POLY輸入文件（*.config）
https://www.scd.stfc.ac.uk/Pages/DL_POLY.aspx
5、Protein Data Bank蛋白質數據庫（PDB; *.pdb）
http://www.wwpdb.org/
6、RIETAN-FP/2000的用戶輸入文件（*.ins）
http://fujioizumi.verse.jp/download/download_Eng.html
輸出*.ins的功能，使得能夠使用VESTA讀取各種格式的晶體數據文件，模擬粉末衍射圖譜，并使用RIETAN-FP進行后續的Rietveld精修。請注意，RIETAN-2000和RIETAN-FP的標準輸入文件彼此不兼容。VESTA使用模板文件導出RIETAN-FP/2000的輸入文件，默認模板文件template.ins，具有RIETAN-FP格式。如果需要RIETAN-2000格式的標準輸入文件，請在Preferences對話框中將模板文件更改為RIETAN2000格式的文件（請參見第16章）。
在Rietveld精修或使用RIETAN-FP模擬粉末衍射圖譜時，應選擇嵌入RIETAN-FP的STRUCTURE TIDY的以下標準晶格設置：
· 單斜晶系：b軸單獨設置（β≠90°），
· 三方晶系：六邊形晶格（a=b≠c，γ=120°），
· 中心對稱空間群：反演心位于原點處（原點選擇2）。
除非采用這三種標準設置，被納入RIETAN-FP中的LAZY PULVERIX無法生成正確的衍射指數hkl及其多重性。因此，VESTA在導出RIETAN-FP/2000格式的*.ins時，會自動將晶體結構的晶格設置轉換為標準晶格設置。
需要指出的是，數據庫中記錄的部分晶體數據中的分數坐標的有效位數太小，例如0.3333而不是0.333333。在這種情況下，請在輸出*.ins之前將有效位數增加到6或7。
7、VASP（POSCAR, *.vasp）
http://www.vasp.at/
8、VRML（*.wrl）
http://www.web3d.org/x3d/specifications/vrml/
9、XMol XYZ（*.xyz）
http://en.wikipedia.org/wiki/XYZ_file_format
http://openbabel.org/docs/2.3.1/FileFormats/XYZ_cartesian_coordinates_format.html
10、P1結構（*.p1）
存儲晶格參數和單位晶胞中所有原子的原子位置的簡單文本文件。原子位置用分數坐標表示，晶體的空間群被轉換成P1（三斜晶系，第1號）。在計算模擬中建立初始原子構型時，此格式非常有用。
11、分數坐標（*.xtl）
xtl文件格式的簡單文本文件，存儲當前圖形區域中顯示的所有原子的原子位置。原子位置用分數坐標表示。為了方便起見，晶體的空間群被視為P1（三斜晶系，第1號）。
12、MADEL輸入文件（*.pme）
雖然VESTA可以執行MADEL（見14.5節），但MADEL的輸入文件*.pme，應手動編輯，以計算間隙（空位）位置的靜電位勢，其分數坐標必須輸入*.pme尾部的FORMAT（3F9.6）。強烈建議使用RIETAN-FP系統分發文件中包含的RIETAN-FP–VENUS集成輔助環境，編輯*.pme并運行MADEL將其輸入Hidemaru Editor。有關上述輔助環境的詳細信息，請閱讀分發文件中的Readme_macros.txt。
使用此格式導出文件時，系統會提示輸入兩個參數，RADIUS和REGION（請參見14.5節）。有關要輸入*.pme的這些參數的詳細信息，請參閱MADEL的用戶手冊。13、STRUCTURE TIDY輸入文件（*.sto）
體數據
14、PRIMA二進制格式（*.pri）
15、通用體數據格式（*.3ed）
16、周期性體數據格式（*.grd）
17、通用體數據格式（二進制）（*.ggrid）
導出體數據時，最推薦使用通用體數據格式。它是無損的，但是這種格式的文件大小比文本格式甚至其他一些二進制格式的文件小得多。對于周期性體數據，由于更好的壓縮效率，下面描述的*.pgrid是首選的。
18、周期性體數據格式（二進制）（*.pgrid）
此文件格式與*.ggrid格式相似，但假設網格具有周期性以最小化數據冗余。當有兩個以上的對稱操作（由空間群信息集生成或由用戶直接編輯）時，只有非對稱單元中的網格數據記錄在*.pgrid中。
19、壓縮體數據格式（*.m3d）
二維數據
假設已打開2D Data Display窗口，在Create New Slice對話框中選擇選項“（hkl）plane defined by two vectors”或“project along [hkl] axis”（參見15.5節）。然后，就可以通過從File菜單中選擇2D Data Display項，輸出2D Data Display窗口中顯示的二維數據。請注意，當選擇第一個選項“(hkl) plane in the bounding box”時，此功能將被禁用。
例如，金紅石型TiO2中距離原點0.5d的（100）晶面上的電子密度輸出如下：第六行中的兩個整數（65和65）是沿x軸和y軸的分隔數。每個數據行中的三個數據分別是X、Y和密度，其中X和Y分別是從二維圖的原點算起的X和Y坐標（單位：?）。
17.5.2 光柵圖像
1、BMP
2、EPS
3、JPEG
4、JPEG 2000
5、PNG
6、PPM
7、RAW
8、RGB（SGI）
9、TGA
10、TIFF
圖形區域和2D Data Display窗口中顯示的結構和體數據的圖像可以記錄在具有各種圖形格式的文件中。保存存儲位圖圖像的文件時，在File菜單中選擇Export Raster Image...。導出的圖形文件的圖像大小將放大為圖形區域大小的倍數。在文件選擇對話框中輸入文件名后，將輸入比例因子。VESTA可以導出超出窗口最大寬度和高度的巨大圖像，這些圖像在啟動VESTA后顯示在文本區域，例如：
對象的分辨率，即原子和鍵的疊層和切片數，也由Preferences對話框中設置的兩個因子Scale和Increasing factor for stacks/slices進行縮放（請參見12.1.2、12.1.3節和第16章）。
17.5.3 矢量圖像
1、封裝式PostScript（EPS）
2、便攜式文檔格式（PDF）
3、PostScript（PS）
4、可縮放矢量圖形（SVG）
圖形區域和主窗口中顯示的結構和體數據的圖像可以保存為矢量圖像。當保存存儲矢量圖像的文件時，在File菜單中選擇Export Vector Image...。導出矢量圖像有一些限制。根據體數據著色的等值面和切面的顏色不能用矢量圖像格式表示。多面體、晶面和等值面的半透明多邊形在除PDF以外的所有格式中都變得不透明。
17.5.4 輸出文本
通過在File菜單中選擇Save Output Text...，可以將文本區的內容保存為文本文件。
欲善其事，必先利其器。要想開發速度高，開發工具要選好。
接下來給大家推薦10款CSS代碼編輯器。
與其他代碼編輯器相比，VisualStudioCode是一個相對較新的代碼編輯器，它已迅速成為當前最流行的代碼編輯器之一，尤其是在web開發人員中。
它為許多現成的語言提供了大量語法高亮顯示，包括CSS和CSS預處理器，如SCSS和LESS。一些擴展，如CSS IntelliSense、CSS Peek和CSS模塊，使其在使用CSS時更加強大。
顯著特點：速度快，可與Gulp和Grunt等多種語言和工具以及大量擴展一起開箱即用。
一個免費的源代碼編輯器，尤其是Windows中的“記事本”替代品。它簡單、運行速度快，支持多種語言，包括CSS，并具有Word完成、函數完成和函數參數提示等功能，以幫助在編寫CSS時提高效率。
顯著特點：語法高亮顯示和折疊、宏錄制和回放以及文檔映射。
JetBrain的IDE實現了包括CSS在內的所有內容的正確自動完成，您還可以隨時獲得有關CSS問題的通知。它還集成了Styleint等開箱即用的工具，可以幫助您格式化并保持CSS代碼的一致性。
顯著特點：與Stylent、Grunt、Gulp和NPM等web開發工具無縫集成。用于調試和跟蹤的內置工具，以及更智能的自動完成。
一個內置CSS編輯器的高級代碼編輯器，為您提供兩種CSS編輯模式，以獲得更靈活的設計體驗，能夠在更改后立即看到結果。除此之外，您還可以在編輯器中的實時預覽工具中覆蓋網站的CSS。
顯著特點：TouchBar集成、實時預覽和內置SFTP/FTP。
Github構建的免費開源代碼編輯器。它不僅僅具有代碼編輯功能。它有一個與GitHub無縫集成的嵌入式Git控件。您還可以為CSS安裝許多附加組件，以增強CSS編輯的體驗。
顯著特點：可通過各種API輕松擴展和破解，可與CSS和流行的CSS預處理器一起使用。
一個流行的web開發代碼編輯器。它跨平臺工作，本機支持多種語言和標記語言，包括CSS，并提供多種擴展以改善編輯器中的CSS編輯體驗。它可以說是現代代碼編輯器的基本靈感。它引入了多行選擇、"Go to Anywhere"和"Command Pallete"等功能，這也提高了開發人員的工作效率。
值得注意的功能：超快的高級代碼編輯功能，如"Go to Anywhere"和多行選擇，以及subl CLI。
由Adobe Systems專門為web開發創建的免費輕量級編輯器。它是用JavaScript、HTML和CSS編寫的，并且本機支持CSS預處理器。
它介紹了使用所謂的“內聯編輯”進行編輯的獨特體驗。您可以按Command/Ctrl+E，它將在內聯窗口中顯示具有該ID的所有CSS選擇器，并允許您直接在當前文件中編輯CSS選擇器，而不是在多個文件之間跳轉。
用于代碼編輯的漂亮macOS應用程序。它帶有一個很好的GUI工具，可以輕松編輯CSS樣式。編輯樣式表時，此工具將顯示在右側邊欄的下半部分。它允許您調整文本樣式、文本顏色、對齊方式、字體、大小、行高以及布局，如填充、邊距、顯示樣式、浮動等。
顯著特點：用于編輯CSS的GUI工具，本機SCSS和LESS支持，自動完成。
macOS的代碼編輯器，具有一些高級編輯功能，并支持多種編程語言（包括CSS）。TextMate因其TextMate語法.tmLanguage而頗受歡迎，該語法被許多流行的代碼編輯器（如Atom和Sublime Text）采用，以創建語言的自定義語法高亮顯示。
顯著特點：本機宏支持自動化重復任務、代碼段和Shell集成
bbEdit也稱為TextWrangler，是為macOS構建的輕量級但高級的代碼編輯器。除了一些基本功能，如各種編程語言的語法著色、代碼折疊和代碼自動完成，bbEdit還內置了SFTP/FTP支持，并與各種macOS功能（如AppleScript、Automator和Unix腳本）無縫集成。
值得注意的功能：macOS集成，以及用于編輯HTML的內置GUI工具。
著環境問題越來越嚴重，人們越來越重視低碳環保的生活方式。作為碼農的我們自然也應該為環保做出應有的貢獻。那么什么是低碳環保，簡而言之就是就是低能量、低消耗、低開支的生活方式，映射到我們的工作中就是以最低的消耗的來完成組織交給我們的任務。
以下就以 Android 開發為例從庫和語言兩方面來討論如何實現低碳環保的編程方式。
從第三方庫來說
充分利用現存資源，盡可能不重復造輪子。從以往來看，如果你對現存的輪子有各種不滿試圖從頭寫，那么最終結局中可能性最大的就是只寫了部分后直接放棄轉而成為某個輪子的支持者，寫完且比現有輪子要好的可能性還不如轉行去大學城門口賣炒面。當然如果你寫的是就是 SDK 之類的基礎工具，那還是盡量減少依賴為好。
那么該如何挑選第三方庫呢？Android 的應用層開發雖然使用 Java 語言，但并不是 Java 上的庫都適合 Android 開發。Android 使用的不是 Oracle JDK 也不是 Open JDK，而是 Google 改寫過的 Apache Harmony JDK，很多 Oracle JDK 自帶的類（特別是 javax 包下的）在 Android 中并不存在，所以使用這些方法的庫 Android 不能使用。
此外 Android 存在 65536 問題，這個坑體現在以下兩點：
1）Android 機器在應用的安裝過程中，系統會運行 dexopt 工具，將 .dex 文件優化為 .odex 文件，其中 dexopt 工具使用了固定的緩沖區大小來保存方法的元信息，低版本的 Android 機器上該緩沖區非常小，所以一旦方法數過多會直接導致 dexopt 崩潰，應用無法運行。
2）Dalvik 指令集對于一個 .dex 文件只能保存 65536 個方法的索引，所以一個 .dex 文件即使可以擁有很多方法，但是那些多余的方法也都是無法運行的。詳細信息可以閱讀官方的 dalvik-bytecode 的 invoke-kind {vC, vD, vE, vF, vG}, meth@BBBB 條目。
因此選擇 Android 的第三庫需要嚴格注意控制方法的總數量。
Android 常用庫 vs J2EE 常用庫
以下我總結了一些 J2EE 和 Android 上的常用庫的對比以供參考，使用這些庫可以有效提供編程效率，減少能量消耗：
| 功能 | J2EE | Android | 備注 |
|---|---|---|---|
| JSON 解析 | Jackson | Gson | Jackson 功能全面，但太大；Gson 速度一般但勝在體積 |
| Restful | Jersey | Retrofit | Jersey 面向服務端，符合 JAX-RS 標準， Retrofit 面向客戶端，不符合 JAX-RS 標準 |
| 依賴注入 | Guice | Dagger | Guice 使用反射，Dagger 使用預編譯，效率不是一個等級的 |
| NoSQL | MongoDB | Realm | Realm 兼容 Android，iOS，ReactNative，比起 Sqlite3 快得多 |
| 單元測試 | JUnit | Robolectric + Espresso | JUnit 只能運行在 JVM 上，Robolectric 使 Android 代碼可以運行在 JVM 上，Espresso 簡化 UI 測試流程（雖然很多情況下 UI 測試沒什么用） |
| 異步調用 | CompletableFuture/RxJava | RxJava + RxAndroid +RxLifecycle | 三合一基本是標配，除此之外還可以加上 RxBinding，RxPermissions，RxAndroidAudio 等等組成完整的 Rx 大家族 |
| 網絡請求 | - | OkHttp/Volley | OkHttp 功能強大，Fluent API 可以寫出更優秀的代碼；Volley 由 Google 開發，代碼量小容易擴展，有非常優秀的隊列機制 |
| 時間處理 | Java 8/Joda-Time | - | Java 原生時間處理 API 非常糟糕，因此 Java 8 直接加入了 Joda-Time。Joda-Time 雖然易用，但一個只是處理時間的庫有 5000 多方法對于 Android 顯然不實際，盡管有 joda-time-android 庫但通常 Android 端需要處理時間的代碼不多，建議還是直接調用難用的原生 API |
其它方法
構建良好的 Android 架構，盡量將 Context 相關的一切和業務邏輯進行分離，使業務邏輯能夠脫離于 UI 組件進行本地測試。MVC，MVP,MVVM,Flux 之類的只有適合自己才是最好的。也可以參考下 Google 最近開始編寫的 Android 架構的示例代碼，不得不說 Google 這一步做得是實在有點晚。
引入 Fragment 后 Android 應用的生命周期 過于恐怖，所以盡管 Google 提倡使用 Fragment，但還是能少用就盡量少用。
使用 Timber + Hugo 記錄 Log 信息而不是使用原生的 Log 工具，這樣無需再自己拼接類名，方法名，參數名和參數值，也不用為了使 Log 更容易被識別加上一堆=========afafaf=============或者 ~~~~~~~~~~~~~~~~~~~~~ 這樣的提示符。
使用 Android DataBinding，盡管你不一定喜歡它的數據綁定方式。但是使用了 DataBinding 后你無需調用 findViewById 后再強制進行類型轉換，也不用使用 Butter Knife 之類的庫編寫各種注解。
對于圖像加載注重質量和包大小可以使用 Picasso，注重加載速度或者需要支持 GIF 類型和大圖片可以使用 Google 人出品的 Glide。除此之外還有老牌的 Universal Image Loader 和相對較新的 Facebook 出品的 Fresco（Fresco 在這里面是重量級選手，無論是功能還是體積，剛推出時坑不少，還有非常嚴重的內存泄露，目前該庫已經作為 React Native 的圖片加載庫，不知道這些問題都解決了么）
使用 IDEA Live Template 保存常用的類或方法的模板，這是我最常使用的方式，這樣有時甚至可以減少近一半的工作量。
強制豎屏，Android 上除了視頻播放和游戲大部分情況下豎屏足以，根據 2-8 法則很多時候專門適配橫屏是很大的資源浪費
從語言本身來說
以上的方法在實現低碳環保的功能上還是非常有限的，還有一種方法比較偏的方法就是直接從最根本的語言層面進行著手。
使用 Lambda 表達式
使用 Lambda 表達式可以省去不少代碼，可惜直到 Java 8 才支持，索性的是 Android 上有一些解決方法。
使用 Retrolambda Gradle Plugin
Retrolambda Gradle 插件可以在編譯時通過字節碼轉換使 Android 能夠使用 Lambda 表達式。
開啟 Jack 與 Jill
在介紹 Jack 與 Jill 之前先來看看 Android 那坑爹的構建系統，以下圖片來自 Google 官方文檔，請注意這只是一個大綱，而且有些過時，實際更復雜，想想如果沒有 IDE 自己手動敲的痛苦吧：
而 Jack 與 Jill 就是在 Android M 時 Google 為了簡化以上流程而推出的構建工具。
以前的主要流程
為了減小 I/O 讀取的次數，dx 工具將所有 .class 文件合并成 .dex 文件
javac (.java --> .class) --> dx (.class --> .dex)
使用 Jack 與 Jill
Jill 將第三方 .class 文件和 .jar 文件轉換為 .jayce 文件。
Jack 將 .java 和 .jayce 文件合并后轉換為優化過的 .dex 文件。
Jack (.java --> .jack --> .dex)
Jill (.class --> .jayce)
當然 Jack 實際是一個工具鏈，除了以上功能 Jack 還包含了 multidex, proguard 等大量功能，直接替代了原來構建過程中的很多工具。
使用 Jack 與 Jill 還有一個吸引人的特點是可以在今年將發布的 Android N 平臺使用上大部分 Java 8 的功能。感興趣的人可以現在就去嘗試一下，但是需要注意的是 IDE 必須大于 Android Studio 2.1 (preview)，SDK 平臺必須為 Android N Preview SDK。
此外由于 Java 8 提供的 Lambda 表達式實際就是通過函數式接口實現的，所以在使用 Jack 與 Jill 后這一功能也可以直接使用在 Android N 以前的平臺，而不用使用 Retrolambda 這些第三方工具（當然其它的 Java 8 功能都不支持）
目前來說 Jack 與 Jill 有一個很大的缺點就是速度較慢，不支持 Instant Run。此外由于不生成中間狀態的字節碼文件，所以開啟 Jack 與 Jill 后基于字節碼的各種工具（如 JaCoCo， Mockito）都將無法使用。（注：Gradle 插件在 1.5 版本提供了 Transform API，可以讓我們直接對生成的 dex 文件進行處理，但是目前 Jack 與 Jill 不支持，所以使用該種方式 JaCoCo 仍然無法使用）
換種語言
相比較 Lambda 表達式也許換種語言是種更有效的方法。以下就介紹一下適用于 Android 開發的其它語言，當然這并不是說真的需要在實際工作中應用。更多得是因為如果你只會用錘子，那你眼里的所有東西都是釘子，換種語言是為了開拓思路，了解在其它語言中是如何實現同樣的功能的。
Java + Native
該方案以 Java 代碼為主，以少量 Native 代碼為輔。主要有兩種實現方式：
Java + C/C++
很明顯這種方法非常不環保，基于 NDK 的開發非常復雜，出了錯誤也不好調試，目前這種方式主要用于 Cocos2D-X 這種游戲引擎。
Java + Go
Go 從 1.5 版本開始同時支持 Android 和 iOS 開發。由于 Go 是 Google 親兒子所以 1.5 出來時大家對未來都非常期待。不過至今為止實際發展非常緩慢，文檔非常稀少。相比較使用 C/C++ 方式使用 Go 有這么幾個特點：
優點：
語法簡單，開發迅速，不用寫頭文件，不用寫 Makefile，不用手動寫 Native 方法，借助插件 Go 代碼會被直接編譯成包含 .so 文件的 .aar 庫，導入 Android 工程后就像寫原生 Java 代碼一樣直接使用即可。
缺點：
文檔奇缺，發展緩慢劇。
目前只支持 arm 架構。
有 Bug，我寫的代碼編譯版本選擇 API 22 正常運行，選擇 API 23 上直接奔潰。
Native + Java
該方案以 Native 代碼為主，以少量 Java 代碼為輔。最大的特點就是提倡以同一種語言為不同平臺編寫不同代碼，而不是一套代碼到處運行。主要代表有以下幾種：
RubyMotion
RubyMotion 由 MacRuby 的開發者發明，可以通過 Ruby 代碼編寫 iOS 和 Android 代碼。
優點：
提供了 Android 上的幾乎所有的 API 的 Ruby 實現，也可以直接使用 Java 庫。
缺點：
iOS 還有些文檔，Android 方面則沒有任何像樣的官方文檔。導致我在寫的時候需要打開 IDEA 先用 Java 寫一遍大致框架然后再用 Ruby 進行改寫。
不支持直接調用 Java 代碼，必須使用打包好后的 Java 庫。
除了官方發布的包，不支持其它任何 Gem 上的包。
由于沒有錢付正式版，所以我使用的是試用版，使用時不但難以調試，速度慢，而且還 Bug 滿天飛，完全沒有寫 Ruby 的爽快感，正式版估計會好點。
ReactNative
ReactNative 由 Facebook 在去年發布，一經發布瞬間成為 Github 上的網紅。可以使用 JavaScript 進行代碼的編寫以及動態更新是其最大特點。然而相比較 iOS 來說 Android 版本并沒有發布多少時間，目前還有不少問題。由于最近在看 ReactNative 所以這里寫得稍微詳細點：
優點：
使用 JavaScript 編寫，ES 6 語法對于 Java 程序員可能更有親和力。
Flex 布局和 JSX 語法和 Android 原生布局方式非常相近，很多屬性幾乎就是換個名字，容易上手。
支持 HotLoad，寫個界面刷一下就行了，Android 開發者終于不用忍受 Gradle 那漫長的編譯過程。
缺點：
目前只是 0.2x 版本，不穩定，并且 React Native 本身使用了不少已經標示為廢棄的 API， API 有很大可能會大更新。
如果碰到框架本身 Bug，基本沒有修復的可能性，只能被動等待官方出解決方案或者切換為 Java 平臺。
原生 Android 開發就有各種兼容性問題，特別是對于國內小米，華為，魅族等平臺，國外的 React Native 是否能處理得好不得而知。
ReactNative 框架自身綁定了不少第三方庫，雖然這些庫都挺有名的，但也不能保證人人喜歡，人人用得到。
沒有重用機制，導致 ListView 效率問題。
沒有布局管理器，組件間嵌套嚴重，實際代碼中會有大量 嵌套 的情況，不適合寫復雜的布局。
Android 有多種類型 Resource 文件，還有 10 多種限定修飾符，React Native 基本都無法使用，意味著在面對屏幕適配，i18n，切換主題等問題時會非常蛋疼。
目前只支持老式的 Drawable 目錄下的圖片資源，不支持 5.0 以后的 Mipmap 目錄下的資源。
Flux 和在其基礎上的 Redux 架構與 Android 傳統開發理念不符，很難吸引到廣大碼農。
除了以上兩個之外 Xamarin 也屬于這一類，不過上周微軟的一些決定使我個人并不看好它，有興趣的人可以自行到 Reddit 和 Twitter 上查閱 Xamarin + Libgdx + Microsoft 的相關信息。
其它 JVM 語言
相比較以上方案，使用其它 JVM 語言的最大特點就是可以和 Java 進行無縫切換，開發方式上沒有什么變更，很容易讓人接受。
Groovy
Groovy 官方從 2.4 開始就支持了 Android 開發。Groovy 本身是動態語言，效率較低。但是可以通過開啟靜態編譯來提高效率。由于 Groovy 在處理 XML 方面是一絕，所以如果你的應用服務器是基于 SOAP 的話，那么使用 Groovy 替換 Java 無疑是更好的選擇，原生的 DOM，SAX，PULL 方式使用起來都太痛苦了。
替換成 Groovy 后最大的優點就是上手沒有任何什么難度， 畢竟所有 Android 開發者都寫過 Groovy （build.gradle 實際就是 Groovy 源文件），而缺點就是編譯速度會更慢。
Scala
Android 應用中常常需要將上下文傳來傳去，所以很多人都會在每個 Activity 寫上 mContext=this 這樣沒營養的代碼。而使用了 Scala 后借助隱式參數 + 隱式轉換 + 隱式類這三兄弟就不用寫這些沒有營養的代碼。除此之外借助 Scala 各種 FP 特性代碼量也可以得到大量減少。
但是替換成 Scala 后有一個致命的弱點就是主流的 Scala 的 2.11.x 版本核心方法多達 5w。這意味著加上 Android 的原生代碼，即使你一行代碼沒寫，僅僅是集成 Scala 運行環境后就超過了 65536 的限制。即使開啟了 proguard 刪除掉那些不用的代碼這個問題也沒辦法根本解決，所以或許將 Scala 搬到 Android 平臺并不是一個好的解決方案。
Kotlin
Kotlin 是 JetBrain 研發的一門運行在 JVM 上的語言，官方支持 Android 開發，語法和其之后發布的 Swift 非常相似，所以也有人開發出了 Kotlin 2Swift 的工具，詳細對比可以見Swift is like Kotlin。Kotlin 的語法可以看做是 Scala++—，其語法借鑒了 Scala，但是也去除了 Scala 中大量復雜的概念。
在所有 JVM 語言中，目前個人最推薦使用 Kotlin 進行 Android 開發。有以下幾個原因：
Kotlin 由 JetBrain 開發，所以對 Android Studio 有很好的支持。
Android 界舉足輕重的 Jake Wharton 大神和其所在的公司 Square 都很欣賞 Kotlin，將一些 Android 庫改寫為了 Kotlin 版本。
Google Android 項目組也對 Kotlin 感興趣，目前我們常使用的 Databinding 的編譯器就是 Kotlin 寫的。
Kotlin 的運行庫只有不到 7000 個方法，這意味著它比 v4 還要小。
Google 目前和 Oracle 的官司越演越烈，以前有傳言 Google 會使用 Go 作為 Android 的一類語言，但是目前從發展速度來看可能性很小。近日又有傳言 Google 會使用 Swift 來代替 Java，個人覺得相比較而言不如說 Kotlin 可能性更大。（補：寫完這段不久后 Swift 就倉庫就出現了 For Android 的 Pull Request，看了下這玩意是基于 JNI 的，屬于上面說的 Java + Native 的開發方式，對于編寫應用來說用處不大，不過相信會被不少人炒作一段時間）
Kotlin 學習 Clojure 也分為 Kotlin on JVM 和 Kotlin on JavaScript 兩個版本。其中 Kotlin on JavaScript 目前內置了 JQuery，但是本身功能很弱，只能寫些原始的 JS 代碼。如果發展起來的話，說不定將來可以用于編寫 ReactNative 代碼。
Kotlin 沒有什么歷史負擔，增加新特性時無需像 Java 一樣思考再三。以下為 Kotlin 目前的 RoadMap，可以看到諸如協程之類的功能 Kotlin 都會在語言層面實現，而不用像 Java 一樣必須依賴 Quasar 這種第三方庫在字節碼方面做文章才行。如果等 Java 實現的話搞不好需要等到 Java 20.
就我個人開發中常使用的 Kotlin 功能有這么幾種：
方法擴展，該功能可以給已存在的類添加方法，本質上其實現類似 Scala 中的隱式類。所以你可以直接給 Activity 添加 toast, alert 功能。
使用 DSL 語句來編寫界面
internal 訪問權限。我們知道 Java 中包與包是沒有任何關系的，這意味這 a.b 和 a.b.c 實際是兩個包。所以在分層時 a.b.c 中不得不暴露大量的 public 方法給 a.b 包中所在的類。而在 SDK 開發中為了有良好的封裝性，盡量暴露更少的接口，所以往往不得不將大部分類都放在同一個包中，然后通過 default 訪問權限來限制外部訪問。類少的時候還能夠忍受，類的一多的話就會非常混亂。Kotlin 中的 internal 訪問權限可以限制只能屬于同一個模塊中的類進行訪問，其它模塊無法訪問。那么什么是模塊？在 Kotlin 中就是一個 jar 包，所以這功能對 SDK 來說就是神器。
Kotlin Android Extension。使用后無需修改任何代碼，直接就可以在代碼中使用 Xml 中聲明的任何的控件。
最后附上一段簡單的 kotlin 代碼
relativeLayout {
textView {
id=android.R.id.text1
text="Loading..."
}.lparams {
centerInParent()
}
editText {
id=android.R.id.edit
hint="Page Count for retain"
inputType=InputType.TYPE_NUMBER_VARIATION_NORMAL
}.lparams {
below(android.R.id.text1)
centerInParent()
}
button("click") {
}.lparams {
below(android.R.id.edit)
centerInParent()
}.onClick {
println("hello world")
}
}.style {
when(it){
is TextView -> it.textSize=20f
}
}
扯了這么多可能有很多人覺得就這些怎么可能實現低碳環保的編程。沒錯，你想的很對，要實現低碳環保的編程方式說到底只有唯一一個有效的方法就是說服你的項目經理或者其他有話語權的人取消或修改掉那些不環保的需要，僅此而已。本次扯淡到此為止。以上 Go 和 Ruby 編寫 Android 應用的示例可以見 AndroidDemoInOtherLanguages。其它 JVM 語言編寫 Android 應用的示例可以見 AndroidDemoIn4Languages。
?―――――――――↓―――――――――?
原文作者來自 MaxLeap 團隊_UX成員：Sidney Xu
歡迎關注微信訂閱號：從移動到云端
歡迎加入我們的MaxLeap活動群：555973817，我們將不定期做技術分享活動。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
