1.keychain 鑰匙串訪問
10年的定安網(wǎng)站建設(shè)經(jīng)驗(yàn),針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù),響應(yīng)快,48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動(dòng)調(diào)整定安建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì),從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“定安網(wǎng)站設(shè)計(jì)”,“定安網(wǎng)站推廣”以來,每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
2.申請開發(fā)證書
3.注冊Bundle ID
4.配置開發(fā)證書 (生成.mobileprovision文件)
5.安裝證書
6.打包ipa
7.開發(fā)團(tuán)隊(duì)如何公用證書
進(jìn)入以下程序
此文件保存到你想保存的地方,后面生成證書有用。
1.打開 蘋果開發(fā)者中心 ( )
2.按照以下圖片步驟走:
上面省略的步驟,按照具體需要選擇,基本是“傻瓜式點(diǎn)擊
到這bundle id就OK了
.mobileprovision文件格式的配置文件是讓開發(fā)者的項(xiàng)目(APP)能有真機(jī)調(diào)試,發(fā)布的權(quán)限。
配置開發(fā)證書,就會(huì)需要你設(shè)置,在這個(gè)項(xiàng)目中添加哪些設(shè)備作為真機(jī)調(diào)試的設(shè)備
1.Xcode打開以下文件夾
2.三個(gè)必填項(xiàng)
4.選擇發(fā)布平臺(tái):
1.本地安裝完.cer證書文件
輸入密碼之后點(diǎn)擊好,即可生成.p12文件
點(diǎn)擊 “協(xié)議、稅務(wù)和銀行業(yè)務(wù)”
內(nèi)購用的是付費(fèi)應(yīng)用程序,先簽署《付費(fèi)應(yīng)用程序協(xié)議》,同意后狀態(tài)變更為“用戶信息待處理”,等待審核。
狀態(tài)更改完畢后,點(diǎn)擊“開始設(shè)置稅務(wù)、銀行業(yè)務(wù)和聯(lián)系信息”。
(1)添加銀行賬戶,按照要求填寫相關(guān)內(nèi)容即可。
(2)選擇報(bào)稅表,并填寫。所有與 Apple 有商業(yè)合作者必選都是美國,若有其他需求,可以多選。
繼續(xù)填寫,首先認(rèn)證公司基本信息,選擇所有人類型,確認(rèn)無誤后認(rèn)證條款處打?qū)?/p>
Part I 部分,繼續(xù)核對公司相關(guān)信息,選填內(nèi)容可不填。
Part III 部分,簽署稅務(wù)條約,設(shè)置利益限制條款的種類,選填內(nèi)容可不填。此部分如果需要可勾選上下圖勾選框,不需要可不勾選,我們這個(gè)項(xiàng)目沒有用到part III 部分,所以沒有勾選。
Part XXX 部分,確認(rèn)之前填寫的信息,勾選完畢后,提交
(3)填寫聯(lián)系信息,共5個(gè)。高級(jí)管理、財(cái)務(wù)、技術(shù)、法務(wù)、營銷。只需要提供5個(gè)人的基本信息即可。
只可使用一次的產(chǎn)品,使用之后即失效,必須再次購買。
示例: 釣魚 App 中的魚食。
只需購買一次,不會(huì)過期或隨著使用而減少的產(chǎn)品。
示例: 游戲 App 的賽道。
允許用戶在固定時(shí)間段內(nèi)購買動(dòng)態(tài)內(nèi)容的產(chǎn)品。除非用戶選擇取消,否則此類訂閱會(huì)自動(dòng)續(xù)期。
示例: 每月訂閱提供流媒體服務(wù)的 App。
允許用戶購買有時(shí)限性服務(wù)的產(chǎn)品。此 App 內(nèi)購買項(xiàng)目的內(nèi)容可以是靜態(tài)的。此類訂閱不會(huì)自動(dòng)續(xù)期。
示例: 為期一年的已歸檔文章目錄訂閱。
App 內(nèi)購買項(xiàng)目的截屏,即所售項(xiàng)目的示意圖。例如,如果 App 內(nèi)購買項(xiàng)目是一本圖書,您可以提交圖書的截屏。您也可以提交購買頁的截屏。該截屏僅用于 Apple 審核,不會(huì)在 App Store 中顯示。
截屏要求如下:
iOS 至少需要 640 x 920 像素
Apple tvOS 需要 1920 x 1080 像素
macOS 需要 1280 x 800 像素
App 審核圖像上傳后,可以替換,但無法移除。當(dāng)您的 App 內(nèi)購買項(xiàng)目處于審核中時(shí),您無法更新截屏。
沙箱賬號(hào)是不能直接在App Store進(jìn)行登錄的,只能在點(diǎn)擊了購買商品之后,在彈出的登錄框進(jìn)行登錄 。
驗(yàn)證是否已登錄沙箱測試賬號(hào):
設(shè)置--iTunes Store與App Store,頁面拉到最底部,會(huì)看到沙箱賬戶項(xiàng)會(huì)列出你已登錄的沙箱測試賬號(hào)!
操作方法一:打開App Store應(yīng)用首頁滑到最下方--選中AppleID--注銷
操作方法二:設(shè)置--iTunes Store與App Store--選中AppleID--注銷
checks if the client can make payments(檢測App是否能支付)
getAvailablePurchases
Get all non-consumed purchases 獲取未消費(fèi)的商品
打印信息查詢;
原因:
沒有先執(zhí)行g(shù)etProducts,直接執(zhí)行requestPurchase方法,要先拉取商品列表,再執(zhí)行購買操作.
問題描述;
1.漏單必須要處理,玩家花RMB購買的東西卻丟失了,是絕對不能容忍的。所謂的漏單就是玩家已經(jīng)正常付費(fèi),卻沒有拿到該拿的道具。
解決:只要購買成功,便將購買記錄(receipt等賬單信息)保存下來,然后將賬單信息傳送給我們游戲服務(wù)器,游戲服務(wù)器獲得賬單后,和蘋果服務(wù)器驗(yàn)證,賬單有效的話,回饋給游戲服務(wù)器處理,游戲服務(wù)器處理后,返回給游戲客戶端處理,處理完畢,將本地保存的購買記錄刪除。
官方文檔:向蘋果校驗(yàn)支付憑證
21000 App Store無法讀取你提供的JSON數(shù)據(jù)
21002 收據(jù)數(shù)據(jù)不符合格式
21003 收據(jù)無法被驗(yàn)證
21004 你提供的共享密鑰和賬戶的共享密鑰不一致
21005 收據(jù)服務(wù)器當(dāng)前不可用
21006 收據(jù)是有效的,但訂閱服務(wù)已經(jīng)過期。當(dāng)收到這個(gè)信息時(shí),解碼后的收據(jù)信息也包含在返回內(nèi)容中
21007 收據(jù)信息是測試用(sandbox),但卻被發(fā)送到產(chǎn)品環(huán)境中驗(yàn)證 【請求sandbox校驗(yàn)支付憑證】
21008 收據(jù)信息是產(chǎn)品環(huán)境中使用,但卻被發(fā)送到測試環(huán)境中驗(yàn)證
消耗類型: 例如:金幣、道具等。
非續(xù)訂訂閱: non-renewable subscription 例如:VIP
您的首個(gè) App 內(nèi)購買項(xiàng)目必須以新的 App 版本提交。請創(chuàng)建您的 App 內(nèi)購買項(xiàng)目,然后前往 App 的“App Store”頁,從“App 內(nèi)購買項(xiàng)目”中進(jìn)行選擇,點(diǎn)按“提交”。 了解更多
在上傳二進(jìn)制文件并提交首個(gè) App 內(nèi)購買項(xiàng)目以供審核后,您可以使用下表提交其他 App 內(nèi)購買項(xiàng)目。
唐巧-iOS應(yīng)用內(nèi)付費(fèi)(IAP)開發(fā)步驟列表
未完~待續(xù)
當(dāng)使用內(nèi)購購買過商品之后沒有把這個(gè)交易關(guān)閉,所以再次去購買商品后就會(huì)調(diào)用以前已經(jīng)購買成功的交易去購買因?yàn)橐呀?jīng)購買過,才會(huì)有這個(gè)提示
原因:添加內(nèi)購項(xiàng)目時(shí),信息填寫不完整,app審核圖像未上傳
處理方法:上傳app審核圖片( 合適的尺寸 ),點(diǎn)擊提交,狀態(tài)改為正在準(zhǔn)備審核中。
這個(gè)是內(nèi)購選擇類型不匹配原因?qū)е隆?/p>
購買成功之后,Apple會(huì)返回以下四個(gè)數(shù)據(jù)給應(yīng)用
Reference
Review the updated Paid Applications Schedule.
游客身份解決方案:即不登錄也要能購買
1)服務(wù)器端做一個(gè)蘋果審核機(jī)制,審核期間游客身份可以進(jìn)行一切行為,一旦審核通過,修改服務(wù)端即可達(dá)到強(qiáng)制用戶登錄進(jìn)行內(nèi)購買的目的(這個(gè)有點(diǎn)。。。)
2)游客可以進(jìn)行內(nèi)購買,購買時(shí)以設(shè)備UUID為準(zhǔn),生成一個(gè)游客賬號(hào),將購買信息保存在服務(wù)器和本地,當(dāng)用戶登錄正式賬戶后判斷此設(shè)備是否進(jìn)行過內(nèi)購,有的話提示用戶將游客身份購買的權(quán)益與現(xiàn)有賬號(hào)綁定,如果綁定,游客權(quán)益則遷移到正式賬戶,如果不遷移,則游客身份和正是賬戶是兩個(gè)獨(dú)立賬戶,正式賬戶不享有游客身份的權(quán)益(我用的這個(gè))
內(nèi)購游客模式解決方案
iOS內(nèi)購規(guī)則
文/陳爐軍
整理/LiveVideoStack
大家好,我是阿里巴巴閑魚事業(yè)部的陳爐軍,本次分享的主題是Flutter浪潮下的音視頻研發(fā)探索,主要內(nèi)容是針對閑魚APP在當(dāng)下流行的跨平臺(tái)框架Flutter的大規(guī)模實(shí)踐,介紹其在音視頻領(lǐng)域碰到的一些困難以及解決方案。
分享內(nèi)容主要分為四個(gè)方面,首先會(huì)對Flutter有一個(gè)簡單介紹以及選擇Flutter作為跨平臺(tái)框架的原因,其次會(huì)介紹Flutter中與音視頻關(guān)系非常大的外接紋理概念,以及對它做出的一些優(yōu)化。之后會(huì)對閑魚在音視頻實(shí)踐過程中碰到的一些Flutter問題提出了一些解決方案——TPM音視頻框架。最后是閑魚Flutter多媒體開源組件的介紹。
Flutter
Flutter是一個(gè)跨平臺(tái)框架,以往的做法是將音頻、視頻和網(wǎng)絡(luò)這些模塊都下沉到C++層或者ARM層,在其上封裝成一個(gè)音視頻的SDK,供UI層的PC、iOS和Android調(diào)用。
而Flutter做為一個(gè)UI層的跨平臺(tái)框架,顧名思義就是在UI層也實(shí)現(xiàn)了一個(gè)跨平臺(tái)開發(fā)??梢灶A(yù)想的是未Flutter發(fā)展的好的話,會(huì)逐漸變?yōu)橐粋€(gè)從底層到UI層的一個(gè)全鏈路的跨平臺(tái)開發(fā),技術(shù)人員分別負(fù)責(zé)SDK和UI層的開發(fā)。
在Flutter之前已經(jīng)有很多跨平臺(tái)UI解決方案,那為什么選擇Flutter呢?
我們主要考慮性能和跨平臺(tái)的能力。
以往的跨平臺(tái)方案比如Weex,ReactNative,Cordova等等因?yàn)榧軜?gòu)的原因無法滿足性能要求,尤其是在音視頻這種性能要求幾乎苛刻的場景。
而諸如Xamarin等,雖然性能可以和原生App一致,但是大部分邏輯還是需要分平臺(tái)實(shí)現(xiàn)。
我們可以看一下,為什么Flutter可以實(shí)現(xiàn)高性能:
原生的native組件渲染以IOS為例,蘋果的UIKit通過調(diào)用平臺(tái)自己的繪制框架QuaztCore來實(shí)現(xiàn)UI的繪制,圖形繪制也是調(diào)用底層的API,比如OpenGL、Metal等。
而Flutter也是和原生API邏輯一致,也是通過調(diào)用底層的繪制框架層SKIA實(shí)現(xiàn)UI層。這樣相當(dāng)于Flutter他自己實(shí)現(xiàn)了一套UI框架,提供了一種性能超越原生API的跨平臺(tái)可能性。
但是我們說一個(gè)框架最終性能怎樣,其實(shí)取決于設(shè)計(jì)者和開發(fā)者。至于現(xiàn)在到底是一個(gè)什么狀況:
在閑魚的實(shí)踐中,我們發(fā)現(xiàn)在正常的開發(fā)沒有特意的去優(yōu)化UI代碼的情況下,在一些低端機(jī)上,F(xiàn)lutter界面的流暢性是比Native界面要好的。
雖然現(xiàn)在閑魚某些場景下會(huì)有卡頓閃退等情況,但是這是一個(gè)新事物發(fā)展過程中的必然問題,我們相信未來性能肯定不會(huì)成為限制Flutter發(fā)展的瓶頸的。
在閑魚實(shí)踐Flutter的過程中,混合棧和音視頻是其中比較難解決的兩個(gè)問題,混合棧是指一個(gè)APP在Flutter過程中不可能一口氣將所有業(yè)務(wù)全部重寫為Flutter,所以這是一個(gè)逐步迭代的過程,這期間原生native界面與Flutter界面共存的狀態(tài)就稱之為混合棧。閑魚在混合棧上也有一些比較好的輸出,例如FlutterBoost。
外接紋理
在講音視頻之前需要簡要介紹一下外接紋理的概念,我們將它稱之為是Flutter和Frame之間的橋梁。
Flutter渲染一幀屏幕數(shù)據(jù)首先要做的是,GPU發(fā)出的VC信號(hào)在Flutter的UI線程,通過AOT編譯的機(jī)器碼結(jié)合當(dāng)前Dart Runtime,生成Layer Tree UI樹,Layer Tree上每一個(gè)葉子節(jié)點(diǎn)都代表了當(dāng)前屏幕上所需要渲染的每一個(gè)元素,包含了這些元素渲染所需要的內(nèi)容。將Layer Tree拋給GPU線程,在GPU線程內(nèi)調(diào)用Skia去完成整個(gè)UI的渲染過程。Layer Tree中有PictureLayer和TextureLayer兩個(gè)比較重要的節(jié)點(diǎn)。PictureLayer主要負(fù)責(zé)屏幕圖片的渲染,F(xiàn)lutter內(nèi)部實(shí)現(xiàn)了一套圖片解碼邏輯,在IO線程將圖片讀取或者從網(wǎng)絡(luò)上拉取之后,通過解碼能夠在IO線程上加載出紋理,交給GPU線程將圖片渲染到屏幕上。但是由于音視頻場景下系統(tǒng)API太過繁多,業(yè)務(wù)場景過于復(fù)雜。Flutter沒有一套邏輯去實(shí)現(xiàn)跨平臺(tái)的音視頻組件,所以說Flutter提出了一種讓第三方開發(fā)者來實(shí)現(xiàn)音視頻組件的方式,而這些音視頻組件的視頻渲染出口,就是TextureLayer。
在整個(gè)Layer Tree渲染的過程中,TextureLayer的數(shù)據(jù)紋理需要由外部第三方開發(fā)者來指定,可以把視頻數(shù)據(jù)和播放器數(shù)據(jù)送到TextureLayer里,由Flutter將這些數(shù)據(jù)渲染出來。
TextureLayer渲染過程:首先判斷Layer是否已經(jīng)初始化,如果沒有就創(chuàng)建一個(gè)Texture,然后將Texture Attach到一個(gè)SufaceTexture上。
這個(gè)SufaceTexture是音視頻的native代碼可以獲取到的對象,通過這個(gè)對象創(chuàng)建的Suface,我們可以將視頻數(shù)據(jù)、攝像頭數(shù)據(jù)解碼放到Suface中,然后Flutter端通過監(jiān)聽SufaceTexture的數(shù)據(jù)更新就可以順利把剛才創(chuàng)建的數(shù)據(jù)更新到它的紋理中,然后再將紋理交給SKIA渲染到屏幕上。
然而我們?nèi)绻枰肍lutter實(shí)現(xiàn)美顏,濾鏡,人臉貼圖等等功能,就需要將視頻數(shù)據(jù)讀取出來,更新到紋理中,再將GPU紋理經(jīng)過美顏濾鏡處理后生成一個(gè)處理后的紋理。按Flutter提供的現(xiàn)有能力,必須先將紋理中的數(shù)據(jù)從GPU讀出到CPU中,生成Bitmap后再寫入Surface中,這樣在Flutter中才能順利的更新到視頻數(shù)據(jù),這樣做對系統(tǒng)性能的消耗很大。
通過對Flutter渲染過程分析,我們知道Flutter底層需要渲染的數(shù)據(jù)就是GPU紋理,而我們經(jīng)過美顏濾鏡處理完成以后的結(jié)果也是GPU紋理,如果可以將它直接交給Flutter渲染,那就可以避免GPU-CPU-GPU這樣的無用循環(huán)。這樣的方法是可行的,但是需要一個(gè)條件,就是OpenGL上下文共享。
OpenGL
在說上下文之前,得提到一個(gè)和上線文息息相關(guān)的概念:線程。
Flutter引擎啟動(dòng)后會(huì)啟動(dòng)四個(gè)線程:
第一個(gè)線程是UI線程,這是Flutter自己定義的UI線程,主要負(fù)責(zé)GPU發(fā)出的VSync信號(hào)時(shí)候用當(dāng)前Dart編譯的機(jī)器碼和當(dāng)前運(yùn)行環(huán)境創(chuàng)建出Layer Tree。
還有就是IO線程和GPU線程。和大部分OpenGL處理解決方案中一樣,F(xiàn)lutter也采取一個(gè)線程責(zé)資源加載,一部分負(fù)責(zé)資源渲染這種思路。
兩個(gè)線程之間紋理共享有兩種方式。一種是EGLImage(IOS是 CVOpenGLESTextureCache)。一種是OpenGL Share Context。Flutter通過Share Context來實(shí)現(xiàn)紋理共享,將IO線程的Context和GPU線程的Context進(jìn)行Share,放到同一個(gè)Share Group下面,這樣兩個(gè)線程下資源是互相可見可以共享的。
Platform線程是主線程,F(xiàn)lutter中有一個(gè)很奇怪的設(shè)定,GPU線程和主線程共用一個(gè)Context。并且在主線程也有很多OpenGL 操作。
這樣的設(shè)計(jì)會(huì)給音視頻開發(fā)帶來很多問題,后面會(huì)詳細(xì)說。
音視頻端美顏處理完成的OpenGL紋理能夠讓Flutter直接使用的條件就是Flutter的上下文需要和平臺(tái)音視頻相關(guān)的OpenGL上下文處在一個(gè)Share Group下面。
由于Flutter主線程的Context就是GPU的Context,所以在音視頻端主線程中有一些OpenGL操作的話,很有可能使Flutter整個(gè)OpenGL被破壞掉。所以需要將所有的OpenGL操作都限制在子線程中。
通過上述這兩個(gè)條件的處理,我們就可以在沒有增加GPU消耗的前提下實(shí)現(xiàn)美顏和濾鏡等等功能。
TPM
在經(jīng)過demo驗(yàn)證之后,我們將這個(gè)方案應(yīng)用到閑魚音視頻組件中,但改造過程中發(fā)現(xiàn)了一些問題。
上圖是攝像頭采集數(shù)據(jù)轉(zhuǎn)換為紋理的一段代碼,其中有兩個(gè)操作:首先是切進(jìn)程,將后面的OpenGL操作都切到cameraQueue中。然后是設(shè)置一次上下文。然后這種限制條件或者說是潛規(guī)則往往在開發(fā)過程中容易被忽略的。而這個(gè)條件一旦忽略后果就是出現(xiàn)一些莫名其妙的詭異問題極難排查。因此我們就希望能抽象出一套框架,由框架本身實(shí)現(xiàn)線程的切換、上下文和模塊生命周期等的管理,開發(fā)者接入框架以后只需要安心實(shí)現(xiàn)自己的算法,而不需要關(guān)心這些潛規(guī)則還有其他一些重復(fù)的邏輯操作。
在引入Flutter之前閑魚的音視頻架構(gòu)與大部分音視頻邏輯一樣采用分層架構(gòu):
1:底層是一些獨(dú)立模塊
2:SDK層是對底層模塊的封裝
3:最上層是UI層。
引入Flutter之后,通過分析各個(gè)模塊的使用場景,我們可以得出一個(gè)假設(shè)或者說是抽象:音視頻應(yīng)用在終端上可以歸納為視頻幀解碼之后視頻數(shù)據(jù)幀在各個(gè)模塊之間流動(dòng)的過程,基于這種假設(shè)去做Flutter音視頻框架的抽象。
咸魚Flutter多媒體開源組件
整個(gè)Flutter音視頻框架抽象分為管線和數(shù)據(jù)的抽象、模塊的抽象、線程統(tǒng)一管理和上下文同一管理四部分。
管線,其實(shí)就是視頻幀流動(dòng)的管道。數(shù)據(jù),音視頻中涉及到的數(shù)據(jù)包括紋理、Bit Map以及時(shí)間戳等。結(jié)合現(xiàn)有的應(yīng)用場景我們定義了管線流通數(shù)據(jù)以Texture為主數(shù)據(jù),同時(shí)可以選擇性的添加Bit Map等作為輔助數(shù)據(jù)。這樣的數(shù)據(jù)定義方式,避免重復(fù)的創(chuàng)建和銷毀紋理帶來的性能開銷以及多線程訪問紋理帶來的一些問題。也滿足一些特殊模塊對特殊數(shù)據(jù)的需求。同時(shí)也設(shè)計(jì)了紋理池來管理管線中的紋理數(shù)據(jù)。
模塊:如果把管線和數(shù)據(jù)比喻成血管和血液,那框架音視頻的場景就可以比喻成器官,我們根據(jù)模塊所在管線的位置抽象出采集、處理和輸出三個(gè)基類。這三個(gè)基類里實(shí)現(xiàn)了剛才說的線程切換,上下文切換,格式轉(zhuǎn)換等等共同邏輯,各個(gè)功能模塊通過集成自這些基類,可以避免很多重復(fù)勞動(dòng)。
線程:每一個(gè)模塊初始化的時(shí)候,初始化函數(shù)就會(huì)去線程管理的模塊去獲取自己的線程,線程管理模塊可以決定給初始化函數(shù)分配新的線程或者已經(jīng)分配過其他模塊的線程。
這樣有三個(gè)好處:
一是可以根據(jù)需要去決定一個(gè)線程可以掛載多少模塊,做到線程間的負(fù)載均衡。第二,多線程并發(fā)式能夠保證模塊內(nèi)的OpenGL操作是在當(dāng)前線程內(nèi)而不會(huì)跑到主線程去,徹底避免Flutter的OpenGL 環(huán)境被破壞。第三,多線程并行可以充分利用CPU多核架構(gòu),提升處理速度。
從Flutter端修改Flutter引擎將Context取出后,根據(jù)Context創(chuàng)建上下文的統(tǒng)一管理模塊,每一個(gè)模塊在初始化的時(shí)候會(huì)獲取它的線程,獲取之后會(huì)調(diào)用上下文管理模塊獲取自己的上下文。這樣可以保證每一個(gè)模塊的上下文都是與Flutter的上下文進(jìn)行Share的,每個(gè)模塊之間資源都是共享可見的,F(xiàn)lutter和音視頻native之間也是互相共享可見的。
基于上述框架如果要實(shí)現(xiàn)一個(gè)簡單的場景,比如畫面實(shí)時(shí)預(yù)覽和濾鏡處理功能,
1:需要選擇功能模塊,功能模塊包括攝像頭模塊、濾鏡處理模塊和Flutter畫面渲染模塊,
2:需要配置模塊參數(shù),比如采集分辨率、濾鏡參數(shù)和前后攝像頭設(shè)置等,
3:在創(chuàng)建視頻管線后使用已配置的參數(shù)創(chuàng)建模塊
4:最后管線搭載模塊,開啟管線就可以實(shí)現(xiàn)這樣簡單的功能。
上圖為整個(gè)功能實(shí)現(xiàn)的代碼和結(jié)構(gòu)圖。
結(jié)合上述音視頻框架,閑魚實(shí)現(xiàn)了Flutter多媒體開源組件。
組要包含四個(gè)基本組件分別是:
1:視頻圖像拍攝組件
2:播放器組件
3:視頻圖像編輯組件
4:相冊選擇組件
現(xiàn)在這些組件正在走內(nèi)部開源流程。預(yù)計(jì)9月份,相冊和播放器會(huì)實(shí)現(xiàn)開源。
后續(xù)展望和規(guī)劃
1:實(shí)現(xiàn)開頭所說的從底層SDK到UI的全鏈路的跨端開發(fā)。目前底層框架層和模塊層都是各個(gè)平臺(tái)各自實(shí)現(xiàn),反而是Flutter的UI端進(jìn)行了跨平臺(tái)的統(tǒng)一,所以后續(xù)會(huì)將底層也按照音視頻常用做法把邏輯下沉到C++層,盡可能的實(shí)現(xiàn)全鏈路跨平臺(tái)。
2:第二部分內(nèi)容為開源共建,閑魚開源的內(nèi)容不僅包括拍攝、編輯組件,還包括了很多底層模塊,希望有開發(fā)者在基于Flutter開發(fā)音視頻應(yīng)用時(shí)可以充分利用閑魚開源出的音視頻模塊能力,搭建APP框架,開發(fā)者只要去負(fù)責(zé)實(shí)現(xiàn)特殊需求模塊就可以,盡可能的減少重復(fù)勞動(dòng)。
ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/Flutter.framework/Flutter: _ptrace.?
原因: 使用了 Flutter 的debug 版產(chǎn)物?打成 iPa 包?
就是Frameworks/Flutter.framework 是debug 版的產(chǎn)物
Debug 版的 Flutter 產(chǎn)物 ,SDK 內(nèi)部使用了 蘋果內(nèi)部私有的API , 會(huì)被蘋果審核監(jiān)測到,存在安全性隱患. 導(dǎo)致拒絕上傳到蘋果后臺(tái).
產(chǎn)生的原因: 因?yàn)殚_發(fā)過程中,直接使用了debug 模式進(jìn)行開發(fā), 在打包的時(shí)候,直接打開 iOS 文件夾下面的工程,在Xcode 里設(shè)置 release 模式時(shí),此時(shí),Flutter 的產(chǎn)物還是 debug 模式下的產(chǎn)物. 沒有刪除替換成 release 產(chǎn)物
1.先 將工程 清理一遍,清理之前debug模式下 的Flutter 產(chǎn)物
2.然后 打開Xcode 工程,配置好相關(guān) 版本號(hào),證書,release 模式
3. 使用命令行 打包 release ,這樣Flutter.framework就會(huì)生成 release? 產(chǎn)物
4.最后 在Xcode 工程內(nèi),按照正常 打包上傳 包過程就可以了
1.進(jìn)入 Flutter 工程 命令行操作
flutter clean
2 .清理之前debug 模式下的 殘留產(chǎn)物 (或者手動(dòng)進(jìn)入文件夾刪除)
rm -rf ios/Flutter/Flutter.framework
3.?獲取 Flutter 的第三方依賴庫
flutter pub get
4.編譯 release 打包 產(chǎn)物?
flutter build ios --release?
(此時(shí)這里可以打包出 app 了, 為了安全起見,最好再次進(jìn)入Xcode 清理一遍,直接打包上傳,)
上面這一步,主要目的是生成 Flutter.framework? 的release 版本產(chǎn)物
5.進(jìn)入Xcode 工程,clean 一遍,檢查相關(guān)證書配置,版本號(hào)等
6.直接 Xcode? Archive 打包IPA 上傳 蘋果后臺(tái)
最后上傳成功:
思路: 通過檢查Flutter.framework 它的CPU 架構(gòu)支持
如果: 該產(chǎn)物 支持模擬器 x86_arm64 這樣的架構(gòu)的話,說明該產(chǎn)物就是 Debug 版的 產(chǎn)物
因?yàn)閞elease 版的 產(chǎn)物是 不支持 模擬器CPU架構(gòu)的.? ?
輸入終端命令:? lipo -info? 產(chǎn)物的物理路徑
比如:? lipo -info /Users/zzc/Documents/rce_flutter/ios/Flutter/Flutter.framework/Flutter
為了提升用戶體驗(yàn),使用三方登錄APP的功能怎么能少呢,但是蘋果的AppStore有一個(gè)很變態(tài)的要求,接入其他三方登錄的話,要求必須也要接入蘋果登錄。面對這么變態(tài)的要求,作為一個(gè)有實(shí)力的碼農(nóng)怎么能拒絕呢!
下面為大家介紹一個(gè)好用的Flutter插件 Sign in With Apple ,可以幫助我們快速的接入蘋果賬號(hào)功能,插件的英文文檔講的比較詳細(xì)了,英文好的同學(xué)可以直接參閱英文文檔集成。
在項(xiàng)目的 pubspec.yaml 文件中添加sign_in_with_apple插件的依賴,如果您使用的Flutter SDK 1.x版本請?zhí)砑右蕾嚢姹?2.5.4 :
如果您使用的Flutter SDK為2.x,請使用最新版本,當(dāng)前最新版本 3.0.0
使用XCode打開項(xiàng)目后,按照以下圖片上的步驟添加 Sign in With Apple Capabilities:
成功添加 Sign in With Apple能力后,可以在下面的列表中就代表添加成功了,如下圖:
當(dāng)前名稱:flutter蘋果,flutter蘋果支付
分享鏈接:http://jinyejixie.com/article12/dsdgegc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供軟件開發(fā)、電子商務(wù)、網(wǎng)站內(nèi)鏈、靜態(tài)網(wǎng)站、網(wǎng)站改版、面包屑導(dǎo)航
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)